Hiya! I’ve been happily using and evangelizing Delta Chat for its base featureset (after also trying Session for a while, I ultimately felt like it had more drawbacks… one of the biggest being inability to add new participants to a group chat). I’m also quite enthusiastic about these webxdc apps, although admittedly for the most part I haven’t gotten much traction with getting my friends to actively use them (eg I encouraged a friend who regularly arranges meetings with me to put them on the calendar app, but he’s not doing so :P)
But in my messing around, I’ve noticed 2 limitations that I think would make webxdc potential a lot harder to ignore.
The first is message persistence/reliability. When a client is offline for too long (for example, a spare phone/laptop that only occasionally gets pulled out), it will end up with a gap in its message state, as an understandable compromise so servers don’t have to retain data forever. I think this is unsurprising to users… however if you use webxdc apps, then the linear transaction log ends up looking like nonlinear state to users. Users will experience things like missing calendar entries that were added while their client was offline, or spurious calendar entries that were removed while their client was offline. I think this limits the potential for long term serious use of webxdc apps for planning etc. My proposed remedy would be that when a client returns from a hiatus, it should have a way to request a full webxdc app state dump… or something… (I’ll be honest, I don’t actually know how it works, but does this make sense?)
Okay! My second point is isolation. I’ll again use calendaring as an example (it does feel like one of the potential webxdc killer apps, imo). If I start using the calendar app to plan with 6 different people, well, now I have to go click through 6 different chats to check all the calendars. That’s certainly inconvenient! My proposed remedy here is maybe a bit broader in scope, but hear me out… what if there was a clientside way to create a linkage between multiple webxdc apps to exchange data? Then the calendar app could add a feature where you can link it to a master calendar you can look at, that fetches and shows you all your entries. I think similar benefit could apply to shared to-do lists, and also more complicated apps/workflows.
For the first, I think the Resend button can already bundle all state updates to the recipient sleepy laptop. The calendar app itself already supports exporting & importing to JSON, so you may as well have that file in your Saved Messages before you leave.
For the second, I think client side plugins would also cover this, where a “docked” webxdc could have access to API to iterate through multiple chats, read and write messages there, wexdc state or more ideally communicate with other webxdc over some restricted API. Or as an MVP, be able to click on its buttons and read back its labels?
I’m not sure what you mean by “before you leave”. I fear that if people have to plan ahead regarding when they do or don’t use given devices, you’ve already lost at usability. It’s good to know about the “resend” button, but I have similar concerns about a manual process. I think the solution here needs to be that the client that knows it has missed state can automatically request it, and other clients can automatically fulfill that request.
On the other point: I do agree that the functionality to share data between webxdc apps could be a plugin, but I think to do this cleanly, it would need to have a standardized API that webxdc apps can take advantage of. ie, someone should be able to make a calendar app that knows how to talk to other instances of itself and show a combined view, rather than it being up to the user to figure out how to scrape information from their webxdc apps.
Indeed, I also think that this is quite a big problem, at least in Delta Chat, at least hypothetically.
Although I don’t recall anyone noticing this happen in practice.
Our most recent “advancement” on this front is recommending that apps send the whole CRDT document (Yjs or whatever) state with each message:
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)