Matrix saving
mweidner037 opened this issue · comments
Currently, demos running over Matrix only "save" their state in that the Matrix room stores every message, and you can replay every message on startup to reconstruct the current document state. This has a number of issues:
- The Matrix client rarely provides us with every message sent to that widget on startup, causing loading to miss messages. This is compounded by causally ordered delivery: if we are missing one very early message, the demo will refuse to process all (causally) later messages.
- It is network- and CPU-inefficient to load & replay all past messages. Instead, we should use saved state (via
CRDTApp.save) to speed startup times. This can be persisted locally (e.g. IndexedDB) and also occasionally sent to the room as a state event, for new users (or long-offline existing users) to use. - In addition to locally persisting saved state, we should persist any further messages as they are sent/received, so that we can replay them next time before hearing from the server. This is necessary for the app to be truly local-first.
- Likewise, unless the Matrix client does this for us already, we should locally persist messages we've sent but that have not yet reached the server, so that we can replay them the next time we're loaded. (In case the tab is closed by the user before everything can be delivered.)
Suggestion from a FOSDEM viewer: "For better performance you could try sending smaller updates via EDUs and regular checkpoints as PDUs"
- See https://github.com/YousefED/Matrix-CRDT (more complete, local-first Yjs over Matrix deployment). That’s not suitable for widgets, though.
- Pin versions, so we don’t break existing deployments each time we update the demo server.
- Would be nice to host this somewhere more “live” and stable than our demo heroku. Should be easy since it’s just an HTML file - can we host this on github / some file sharing site?
- Add back to demo server.