Real-time collaborative authoring?

[ericscheid]

A feature request humbly submitted:

Real-time collaborative editing is a technique where multiple people on different machines can edit the same document at the same time. Changes are propagated to other participants over the network and show up in their views of the document as soon as they arrive.

https://codemirror.net/6/examples/collab/

This would be really cool, but also not a trivial thing to implement. There will likely be difficult behind the scenes refactoring required too.

Logging in this issue so the idea doesn't fall between the cracks.

[BertoLucca]

While this may not be the best solution, having a "Sign Co-Authority" button at the metadata pane would not only solve the issue, but also let people contibute anonimously by not clicking it.

[calculuschild]

@BertoLucca users can already co-author. Anyone who visits the /edit/ url of a brew and makes a change will be added as a co-author.

This issue is for supporting live co-editing (a-la Google Docs). Currently that isn't supported here.

[5e-Cleric]

This issue should actually be a bug report, described as: "synchronously editing brews causes data loss".

In this comment i offer 3 approaches to solve this issue, 2 of which would complete the issue as is written (allowing for real time collaborative authoring). Coming from an actual paper from Google, which i will be citing:

Fraser, N. (2009, September). Differential synchronization. In Proceedings of the 9th ACM symposium on Document engineering (pp. 13-20).

Explanation of the issue:
When multiple authors edit a document at the same time, if no comparation of the changes is made, whoever saved the document first will lose any changes made to said document.

Approaches

There are different approaches to avoid this data loss:

1: Pessimistic approach

As defined in the article:

The pessimistic approach is the simplest. In its most basic form, a
shared document may only be edited by one user at a time.
[...]
The first user to open the
document has global write access, while all others have read-only
access. This does not allow for real-time collaboration by
multiple users.

A refinement of this method would be if we locked pages while being edited, instead of locking whole brews.

While this method is not the one we would prefer, it would be simpler to implement and would fix the issue at hand.

2: Three-way merges (the google docs approach)

An overview of the process is shown in Figure 1:

1. The client sends the contents of the document to the server.
2. The server performs a three-way merge to extract the user's changes and merge them with changes from other users.
3. The server sends a new copy of the document to the client.

If the user made any changes to the document during the time this synchronization was in flight, the client is forced to throw the newly received version away and try again later.3 This is a half-duplex system: as long as one is typing, no changes are arriving. Shortly after one stops typing, the input from other users is integrated and either appears, or else a dialog pops up to let one know that there was a collision.

This option is more than valid and should be considered.

Differential Synchronization

DS is a symmetrical algorithm employing an unending cycle of
background difference (diff) and patch operations.

Essentially, the contents of the server text are cloned into the shadow, and the client text diffed on that, then those edits are applied to client text, each if it is successful. Then the same process is reversely applied, if there are changes in server text (caused by another user) they are moved to client, and back to the beggining.

The in-depth explanation in the referenced article is very clarifying and easy to understand.

This method can be secured to avoid data loss by adding a backup shadow from the server side, as described in the article.

Pros and Cons of each method

While the three options would fix the data loss issue, each approach has its perks. As already mentioned, the pessimistic approach is worse for the user, in that it plainly blocks collab authoring at the same time. Users are already working on brews in this way, waiting for other authors to be offline to edit their documents.

As for the other two, both approachs are good, and we should choose based on which seems more easy to implement. Scalability should not be an issue since i don't think we need to handle more than 3 authors live at the same time...

The paper also speaks to the efficiency and methods for handling collisions and patching of texts, i recommend its reading to fully undersant the approaches.

---

This is a very long comment, did i turn into Gazook? - 5e-Cleric

[5e-Cleric]

Adding to this, the fact that this system would completely supersede the current saving system, do we want that? or do we want to allow for both?

I think we could keep the old system, for efficiency reasons, and add the new system on a per brew basis. Like offer a button of "turn this brew into a collab brew".

I could use everybody's opinion on this, so i will be tagging everyone, sorry in advance:

@Gazook89 @calculuschild @ericscheid @G-Ambatte @dbolack-ab

[Gazook89]

I’m pretty sure codemirror 6 has collab editing or at least utilities to make it easier. Have you looked into that?

[5e-Cleric]

I’m pretty sure codemirror 6 has collab editing or at least utilities to make it easier. Have you looked into that?

I have not, i was assuming we would want to build this separate from codemirror, as for not to need that upgrade.

[Gazook89]

My opinion is that we should wait for CM6 to handle this. That’s likely going to be awhile, but I also think it is inevitable. And with it, it will have an implementation of collab editing that has already been well considered, de-bugged, written about/documented, and have some level of support from the CM developer (marijn) if there are questions. Possibly even other plugins developed for it.

With something as integral to HB as the text editor, I’m skeptical about rolling our own novel implementation when the work has already been done. The risk of screwing up people’s brews would be high.