zefyr icon indicating copy to clipboard operation
zefyr copied to clipboard

maintainer

Open joe-getcouragenow opened this issue 5 years ago • 12 comments

I am wondering if anyone is interested in a new group of people that use this and the OT aspects taking over maintenance.

@pulyaevskiy ?

We use it for web, desktop and mobile.

There are others we know also using it and there are so many forks that it seems like its worth keeping this package going.

We want to extend the OT aspects so that it can be used by other packages that need OT aspects where many users are editing data and it all just needs to eventually merge.

We hang out here: https://t.me/getcouragenow_dev

Repo here: https://github.com/getcouragenow

joe-getcouragenow avatar May 20 '20 10:05 joe-getcouragenow

It would be nice to see this project gain more attention. I would love to make some PRs which I already change locally.

namchuai avatar May 20 '20 19:05 namchuai

hi @joe-getcouragenow just a quick message to let you know that there is also @cgestes working on fixing bugs: https://github.com/cgestes/zefyr

See #293 for more details

ghost avatar May 21 '20 09:05 ghost

Hey everyone, sorry for silence here.

We want to extend the OT aspects so that it can be used by other packages that need OT aspects where many users are editing data and it all just needs to eventually merge.

Zefyr (and Delta) by itself should already allow working with an OT server and accepting edits from multiple sites simultaneously. In fact, I did have an implementation of this in my own project.

There is of course more stuff that can be done on the UI side of things, multiple cursors for instance.

Re: maintainer.

It's great to see that many found this lib useful. I am planning to continue working on Zefyr when my free time allows it. I will be looking at some pull requests this week and try to read through and respond on all new submitted issues.

Again, really appreciate all the interest and feedback.

pulyaevskiy avatar May 22 '20 16:05 pulyaevskiy

Definitely interested in OT as well.

@joe-getcouragenow any idea of what a common base for implementing collaborative editing would look like?

Here is my rough idea of what it should do:

  • being able to send changes to other participants
  • being able to receive changes made by other participants and handle situation when we also made local edits on previous version of the document
  • display changes made by other participants, their cursor, their selection, their names

Can it be implemented as a ZefyrController?

A common question around OT/CRDT is how do we ensure the order of changes are the same for all participants?

cgestes avatar May 22 '20 20:05 cgestes

Can it be implemented as a ZefyrController?

Short answer is yes. Everything except multiple cursors/selections/names should be possible already.

A common question around OT/CRDT is how do we ensure the order of changes are the same for all participants?

This is more specific to OT, but the only way to implement conflict-free sync between multiple sites is to have a central server-side component which is responsible for storing revision history and serving as a source-of-truth.

As I mentioned, I have this implemented in my project, using Zefyr in its current state. I based my implementation on Firepad, mostly because I'm using Firebase as a source-of-truth store.

pulyaevskiy avatar May 22 '20 21:05 pulyaevskiy

Content

CRDT do not require a single source of truth, but it is easier to implement with one. (see https://github.com/automerge/automerge and especially https://github.com/automerge/automerge/pull/253)

Assuming we use a single source of truth (seems legit), I see at least two ways to implement collaborative edition:

With atomic commits

The server provides transaction for pushing changes. We are sure that our changes refers to the last version of the document when commited. We rebase changes before sending them to the server, if it fails, we rebase again and resubmit.

This is how it is done in prosemirror for example: https://prosemirror.net/docs/ref/#collab

Pro:

  • we may not need to store a version in the change

Cons:

  • require atomic commit support for the backend, may complicate offline first support
  • the transaction may be hard to get right for our users

Without atomic commits

the changes are pushed to the server and have a stable order ensured by the server, we know the document's version our change is based on, but some more changes may have been pushed in the middle.

I believe that in that case we need to include a reference to the document's version our change refers to, and we need to rebase the change before applying it. (when receiving)

Pro:

  • does not require atomic commits on the backend

Cons:

  • probably requires to store an identifier of the version the change is based on
  • requires to have all the changes between our base version and our change
  • may be harder to implement for us

Selection / Cursor

We will need an interface to monitor our cursor and selection changes (to send them over) We will need an interface to receive cursor/selection changes from other participants and display them

cgestes avatar May 22 '20 22:05 cgestes

CRDT do not require a single source of truth, but it is easier to implement with one. (see https://github.com/automerge/automerge and especially automerge/automerge#253)

That is correct, but in my understanding OT and CRDT are two different approaches to conflict-free resolution of changes.

I decided to go with OT because it's a simpler approach and covers use cases I needed. Though we can have a discussion around CRDTs as well.

Thanks for the pointer to automerge, very interesting.

pulyaevskiy avatar May 22 '20 22:05 pulyaevskiy

That said, I think implementation of an OT server is only indirectly related to the editor as it only needs to work with Deltas. Only exception is the cursor/selection metadata which requires API some interface to work with the editor.

pulyaevskiy avatar May 22 '20 23:05 pulyaevskiy

I agree with the server part, I believe that we can provide a good part of the client side, so that users do not have to use delta directly, but only sync changes between clients.

I know from experience that it is pretty tricky to implement. (it is racy by nature)

cgestes avatar May 23 '20 00:05 cgestes

I'm sincerely hyped about seeing Zefyr under more active development again! This is really great! Over the past weeks I've been trying to implement a collaborative editor using firebase and zefyr, but without success. Are there any useful links/tutorials you would recommend? Did anyone already develop an open-source example about a collaborative example with zefyr? Thanks for everyone's effort on making this awesome library :)

Albert-Jan avatar May 25 '20 07:05 Albert-Jan

I've had steady progress in the past few weeks on refactoring zefyr as well as covering missing functionality, like support for desktop platforms. Hopefully will have something for you guys to test in a few weeks. More info is coming.

pulyaevskiy avatar Sep 03 '20 16:09 pulyaevskiy

thanks @pulyaevskiy ! https://github.com/memspace/zefyr/tree/rendering-refactor looks good.

We are going to implement a backend for the Ops if you and anyone is interested.

joe-getcouragenow avatar Sep 05 '20 08:09 joe-getcouragenow