Throttling updates

Currently updates are created and sent as soon as possible after adding one or multiple changes. This can lead to a lot of updates being sent in a short period of time and especially when a user is not collaborating in real-time with someone else this is not necessary. In fact bundling more changes together makes it even more efficient as you need download and process less updates.

Ideally in the future there would be a mode where updates are bundled together based on a timeout if no other active collaborator is present (can be checked with the ephemeralMessage sessions).

To keep a good real-time experience sending every change as soon as possible is still a good practice. To even improve the experience it might make sense to apply changes one by one instead all at once when multiple active collaborators are present. (can be checked with the ephemeralMessage sessions).

Visualize which user made which change

• In Automerge the user or device public should be used as an ID.
• One idea was to leverage the clientID for it and assign it the publicKey. This approach would not work.
  • The main issue for the userId is that it's only a uin32 which results in only 4 bytes. The publicKey itself is way longer and also some randomness would be good in case users have multiple tabs open on the same web-device using the same publicKey. In the long run it's probably better to build a parallel structure allowing users to sign a transaction and make it verifyable instead of manipulating the clientID directly.
  • Note: For EphemeralMessages we already have validation. In the user state the publicKey is injected and verified within the useYjsSync hook. Details can be found here: https://github.com/serenity-kit/secsync/pull/47 (opens in a new tab)

Possible Meta data issues

• Should users be able to identify which device of a user made a certain change?