ether/etherpad-next

Question: Use of yjs

Opened this issue · 8 comments

JannikStreek commented

Context

I proposed to @SamTV12345 in a private chat the use or at least a test of yjs. It's a library which handles concurrent updates on a datasource and could be a good fit for the project. Additionally or even more interestingly it's very easy to integrate in existing editors, see https://yjs.dev/#demos.

By default it uses peer-to-peer connections which isn't very fitting for etherpad. But a plugin exists to leverage websockets. See https://github.com/yjs/y-websocket . A rough server implementation can be seen here: https://github.com/yjs/y-websocke/blob/master/bin/server.js

It would bring research-grade-level conflict resolution for concurrent updates within the editor and, in addition, many existing editor integrations. At least it should be considered to be used as so much comes essentially for free.

EDIT: Also available as ready-to-go backends:

Tasks

I guess I makes sense to first start a small prototype and see how it goes? Especially before integrating the existing server setup.

AugustinMauroy commented

In my opinion, the architecture of the pad should be made up of small components:

pad itsel:

const Pad:FC = ()=> {
  //logic here
  return (
    <EditableArea/>
  );
}

button for bold

pad itsel:

const Pad:FC = ()=> {
  const handleBold = () => {}
  return (
    <button onclick={handleBold}//>
  );
}

so that each element has its own component and that makes sense

SamTV12345 commented

Can't we use yjs and still have our own editor? As far as I understood it is quite customizable and we would have a standard implemented than doing something custom.

JannikStreek commented

Can't we use yjs and still have our own editor? As far as I understood it is quite customizable and we would have a standard implemented than doing something custom.

sure, I think thats also possible or at least I can't think of reasons why not. It's just another advantage, that you can integrate existing editors rather quickly.

JannikStreek commented

Only the backend data model will be different as the shared data types won't be compatible the existing model - I guess.

AugustinMauroy commented

Only the backend data model will be different as the shared data types won't be compatible the existing model - I guess.

We can add an adaptator on etherpad-next v1.X to allow read from old format. What do you thinks.

JannikStreek commented

Only the backend data model will be different as the shared data types won't be compatible the existing model - I guess.

We can add an adaptator on etherpad-next v1.X to allow read from old format. What do you thinks.

All possible, first we would need to test yjs. Then we can decide if we want to use it and how to proceed later with old pads. At least that would be my suggestion. As this will be a complete rewrite, I guess it would also be fine to convert old pads during migration.

  • 👍1
SamTV12345 commented

Only the backend data model will be different as the shared data types won't be compatible the existing model - I guess.

We can add an adaptator on etherpad-next v1.X to allow read from old format. What do you thinks.

All possible, first we would need to test yjs. Then we can decide if we want to use it and how to proceed later with old pads. At least that would be my suggestion. As this will be a complete rewrite, I guess it would also be fine to convert old pads during migration.

Absolutely. If you can build a prototype with yjs for evaluation that would be awesome.

JannikStreek commented

Ok, I will build a small prototype the next couple of days :)