Question when peer networks differ during collaborative editing?

Whenever there are unconfirmed local changes, the peer should try to send them to the authority, along with its current synchronized version.

  • If that version matches the server’s version, the server accepts the changes and adds them to its history.
  • Otherwise, it rejects them, and the peer must wait until it receives the conflicting changes, and try again after integrating them.

Hello, everyone, the above is a quote about the principles section of the website example, my query centers on the second point (the bolded part).

Assuming that there are multiple peers editing continuously at the same time for a period of time, and that one of the peers has a poorer network than the others. Every time the authority receives an update from the weaker peers, it hits the second scenario, and then that other peers will never see that peer’s updates until all the other peers stop inputting.

I would like to know how to resolve this edge case, thanks.

This is a good point (and a similar issue was recently brough up for ProseMirror, which uses a comparable collab system).

I’ve added a rebaseUpdates function to @codemirror/collab 6.1.0 which allows a server to accept updates when the client’s version doesn’t match the current server document. The website example has been updated to make use of this. Does that sound like it addresses your concern?

I updated the relevant dependency and it’s working very well, which did eliminate my concern.

Thank you very much!

If my understanding is correct, this excerpt from the website example is outdated after the addition of rebaseUpdates:

Confirming Local Updates

The view plugin above ignores the return value from pushUpdates. To make sure its own updates are confirmed, it relies entirely on them coming back through the pull process.

If your control over the pull process is precise enough that you can ensure that you’re not going to confirm the same updates twice (which will break stuff), for example by making pull and push mutually exclusive, you could immediately use receiveUpdates on the local updates you pushed when the push comes back successful. This saves a bit of network traffic.

The push can come back successful but if the pushed updates were rebased on the authority, confirming the local updates will not produce the correct result.

Thanks for spotting that. That is indeed no longer safe if you are using rebaseUpdates. I’ve removed it.

1 Like