Sending the whole state instead of a diff for each update may have quite the throughput and data storage impact for 99.9% of the cases.
As a compromise, each webxdc (or the webxdc API) might provide hypothetical facilities for sanity checking so that apps themselves could implement such recovery, such as:
- The webxdc client who was offline for too long could detect that gaps happened in the timeline (in whatever way with a separate counter), and then sent a webxdc message with the missing ID ranges to request backfill from others. The request could either mention a list of participant IDs to interrogate or be broadcast in nature. It would signal this condition to the user, explaining either that a given time range of data is waiting to be filled in, or only showing the most recent version up to the point that is complete (also with a status message).
- The client of the next person who uses the webxdc in the group (or who has said webxdc app docked client-wide in the background) would notice this request. If it possesses said data for the missing ID, it would send either the missing pieces bundled or the final state as a response.
- This would continue with the next person until payload to all requested IDs have been sent to the group again. As a sanity check, the checksum (or timestamp) of the most recent full state could be sent in by all participants in the group to signal agreement.
- The webxdc in the client of the requestor would add up the backfill responses and show it to its user. Its user interface would indicate up to which point the client has already backfilled (i.e., showing the timestamp of last modification that was synced)