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).
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).
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.
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.
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.