Right now summary displayed on the WebXDC app message card is last-write-wins. Already I have seen this result in misleading results if eg two people vote in the poll app at once then they both send a summary of “1 vote” and so the summary says that even though there are 2 votes.
Of course we can’t make a whole system for this that lives outside the app because most of the data is custom to the app and not specified at all (the whole point).
So, my first thought I’ve had is, what if when a new WebXDC state update message comes in the client runs the WebXDC in a hidden webview (if it’s not open) and sends the state update there. Then instead of using this summary field to update the summary add a webxdc.setSummary() javascript API so the app can, based on its full knowledge of the current state, set a summary string.
Could you clarify your proposal? I don’t quite understand what’s the point of running a hidden instance.
Either way, I don’t think running hidden app instances is the way to solve this, this sounds like a problem that the app itself must solve. I.e. if two apps send an update at the same time, they still are going to receive each other’s updates relatively quickly (as much as it takes to deliver a Delta Chat message), so each app instance still has the full state at the end of the day.
In this case each instance, upon receiving the other app’s message, should sum up the actual number of votes and send another message with the updated summary (and perhaps an empty payload).
That is basically my proposal, to make the summary the WebXDC app’s problem. Having it just issue another summary message (rather than providing a new JavaScript API) is a way to acheive this, but I guess it relies on the app determining that the current summary was not correct, otherwise the instances will send summary messages back and forth forever.
So yeah, my proposal was basically to remove the summary from the message entirely and make it up to the WebXDC app to update the local summary, since as you say it is the WebXDC app which has the full state at the end of the day.
I’m not sure we should do background worker stuff for webxdcs in the near future.
Like we need to track the script so it won’t keep running in the background for longer than it needs to and stuff like that, maybe not even have something like full javascript but rather a small wasm function or rhai.rs script that gets run directly by deltachat core. The rhai.rs runtime has the option to set maximum operation count, that could be a way to limit it, so there can not be any loops. Maybe there are some wasm runtimes that have the possibility to track and limit operation count.
But apple could be against running user generated code, so we need to be kinda careful what we do here, also security wise only have a very limited api, so security would be another reason against javascript.
So I agree in principle, but nothing for the immediate near future IMO.
i like the general idea and thought about it myself sometimes – but It’s unclear how easy/possible this “running in a hidden web view” is in practise – and it can also be quite problematic resource-wise and probably also security/privacy wise to instantiate web views and let 3rd party code run there on incoming app-update messages. If i disable “read receipts” i don’t want anything to respond when i am just looking at the message list of a chat.
The app could just set the summary regardless of what the current summary is.
In this case the app could only update the summary only when it receives a new vote, and not when just summary is updated.
But I’m still not sure if I get the proposal correctly.
Is this the point? To make summary separate for each user and not global (per-app), and keep it up-to-date with the help of a background process that listens to new messages?
having some kind of processing background function for summary would also help us with localised summary, without having to duplicate the data on the wire (like translate on device instead of transferring summaries in all supported languages.)
Is this the point? To make summary separate for each user and not global (per-app), and keep it up-to-date with the help of a background process that listens to new messages?
Yes, that was my proposal.
One thing that would be a step between here and there but not require a background process would be to just add the JavaScript API to allow updating a local-only summary. Then use summary messages to update the summary as we do now while the app is closed, but when you open the app it can set it to something fully correct when it runs. So it means you always get a correct summary at least right after you open it.
Web extensions have a similar concept, it’s “background scripts”. They can also be non-persistent, i.e. they only activate on certain events and get unloaded on idle.
My proposal of “it’s good enough the way it is” has a problem: it still is impossible to keep the summary (and document) updated in the case when two peers webxdc.sendUpdate and immediately close the app, before they could receive each other’s updates (or just make sure that they both don’t have internet access when they send the messages). The summary could get updated when at least one app instance goes online, but it would remain incorrect before that.
Though I think it’s a very rare case, with very minute consequences, and I right now it doesn’t seem to be worth writing an entire module just to solve it.