Has there been much thought about how users might be able to “upgrade” a WebXDC app? Many of the apps are ephemeral (such as polls) and so it doesn’t make sense, the app appears in the conversation and then goes past in scroll and if you want to use it again you attach it again.
But some apps, like shared notes or calendar, are more “sticky” in nature and it would make sense when a new “version” of the xdc file comes out to be able to replace it while keeping all state updates so far the same (of course this assumes the xdc is designed to be backwards-compatible with older versions of its own state updates…)
We thought about this, but ultimately postponed it because there are so many open questions.
Here two of them:
A: You can’t really expect all xdc to be perfectly backward compatible, so you would either need some backup or downgrade solution.
B: in a p2p scenario you can not be sure that everyone already uses the upgraded version, let alone even received it.
and some solution ideas:
A could be worked around with sending a new message/instance with all the old updates, but the new xdc version, this way the old state would not be lost immediately.
Exporting and importing state/backup between xdc instances could allow a first version of upgradable apps.
Also webxdc apps are currently pinned on a single message, but we could also imagine that you could pin an app to a chat or have it in a way where it is more persistent and new members automatically get it and it’s previous state.
But even then problem B remains, and unless your app is forward and backward compatible (by ignoring unknown properties for example) there really is a need for a solution to problem B.
Also there is the question how this would play into future status update discarding / condensing/aggregating into a single state (I think some call this “checkpointing”).