Live data from Hacker News

Movable tree CRDTs and Loro's implementation

loro.dev

11–20 of 32 posts

Re: Movable tree CRDTs and Loro's implementation

#11
post #6

We're building a new multiplayer editor for tasks/notes [1] which supports both text and outliner operations. Although it behaves like a flat text document, the outliner features essentially turn the document into a large tree under the hood. We do something similar to the highly-available move operation to sync changes: There is one operation to change the tree, called insmov (move-or-insert). Whenever a client is o…

what rich text are you using?

Re: Movable tree CRDTs and Loro's implementation

#12
post #6

We're building a new multiplayer editor for tasks/notes [1] which supports both text and outliner operations. Although it behaves like a flat text document, the outliner features essentially turn the document into a large tree under the hood. We do something similar to the highly-available move operation to sync changes: There is one operation to change the tree, called insmov (move-or-insert). Whenever a client is o…

Hey wim! Coincidentally yesterday I was reading an old thread[0] and saw your post about thymer which got me curious. When I searched on HN for thymer I got a show hn in 2009[1] and it seems Thymer is in private beta for the past 15 years? 0. https://news.ycombinator.com/item?id=40786425 1. https://news.ycombinator.com/item?id=518803

Hah well there is definitely some scope/vision creep involved, and it all took a bit longer than planned. Not 15 years though! (that's about the very first app we ever made, which we only keep online for existing users). We've been working on this new project as a team of 2 for almost three years now. We really wanted to get it right so we spent a lot of time building the editor/IDE completely from scratch, as well as all the other stuff like the syncing layer (which is how I became interested in the topic of CRDTs and such).

Re: Movable tree CRDTs and Loro's implementation

#13
post #2

When working with formatted text content like in Google Docs / Zoho Writer: moving a list item down or adding a new column or any table/list operation is essentially a tree manipulation op. Concurrent conflicts in such cases are notoriously hard to converge without contextual special handling [1]. Does this implementation generalize a solution for such use-cases? I guess it should be possible to combine a list(or str…

The implementation can indeed combine multiple different CRDTs. Within Loro's internal implementation, each op does need to store a parent ID. However, as Seph mentioned, consecutive operations under the same parent can be effectively compressed, so the amortized overhead of these parent IDs is often not significant.

Re: Movable tree CRDTs and Loro's implementation

#14
post #6

We're building a new multiplayer editor for tasks/notes [1] which supports both text and outliner operations. Although it behaves like a flat text document, the outliner features essentially turn the document into a large tree under the hood. We do something similar to the highly-available move operation to sync changes: There is one operation to change the tree, called insmov (move-or-insert). Whenever a client is o…

what rich text are you using?

We built it from scratch, so not based on prosemirror or contenteditable or anything like that (as we needed something which feels as if you're just editing text but also supports outlining features)

Re: Movable tree CRDTs and Loro's implementation

#15

I wonder if there has been any practical CRDT for data dense applications, such as images (pixels) and 3D models?

It is not exactly the same, but I believe that Figma supports concurrent edits and uses an approach similar to CRDTs (https://www.figma.com/blog/how-figmas-multiplayer-technology...).

Re: Movable tree CRDTs and Loro's implementation

#16
post #6

We're building a new multiplayer editor for tasks/notes [1] which supports both text and outliner operations. Although it behaves like a flat text document, the outliner features essentially turn the document into a large tree under the hood. We do something similar to the highly-available move operation to sync changes: There is one operation to change the tree, called insmov (move-or-insert). Whenever a client is o…

> We don't use any fractional indices though. Instead, our insmov tuple not only contains a parent P, but also a previous sibling guid A. Because all tree ops will eventually be applied in the global linear order as determined by the server, "sorting" is handled by just using the insmov operation.

For what it's worth, this sounds equivalent to the RGA list CRDT [1], using the server's global linear order as a logical timestamp (in place of e.g. Lamport timestamps).

[1] https://inria.hal.science/inria-00555588/

Re: Movable tree CRDTs and Loro's implementation

#17
post #14

Earlier quoted context omitted.

what rich text are you using?

We built it from scratch, so not based on prosemirror or contenteditable or anything like that (as we needed something which feels as if you're just editing text but also supports outlining features)

very cool! can't wait to try I'm doing a note editor as well, and would love to have great outlining support!

Re: Movable tree CRDTs and Loro's implementation

#18

I wonder if there has been any practical CRDT for data dense applications, such as images (pixels) and 3D models?

I'm not sure that CRDTs would be necessary for image editing, since all conflicting edits could easily be resolved with a last-writer-wins approach. 3D models are a different beast, and I haven't seen any collaborative 3D modeling tool on the market (though I haven't actively searched).

There is a 3D modelling tool called Spline supports multiplayer editing. I suppose it's using OT

Re: Movable tree CRDTs and Loro's implementation

#19
post #6

We're building a new multiplayer editor for tasks/notes [1] which supports both text and outliner operations. Although it behaves like a flat text document, the outliner features essentially turn the document into a large tree under the hood. We do something similar to the highly-available move operation to sync changes: There is one operation to change the tree, called insmov (move-or-insert). Whenever a client is o…

> We don't use any fractional indices though. Instead, our insmov tuple not only contains a parent P, but also a previous sibling guid A. Because all tree ops will eventually be applied in the global linear order as determined by the server, "sorting" is handled by just using the insmov operation. For what it's worth, this sounds equivalent to the RGA list CRDT [1], using the server's global linear order as a logical…

Right but rather than working on an array it's combined with a tree operation in this case, so if someone drags a task to reorder but someone else moves it to another parent it won't cause (cycle) conflicts

Re: Movable tree CRDTs and Loro's implementation

#20
post #3

Asking for advice: I do not have a multiplayer app, but I have some large, interconnected, denormalized trees on my frontend as user profiles. Think like a tiled layout, where a user can add/remove/resize tiles, and then add a number of components into each tiled slot, each of those having their own profiles too. Multiple "layouts" can exist with different arrangements of tiles, and theres some other complexity with…

If your application makes active use of multiple tabs, it might make sense to use YJS or something, because it's very effective in resolving those types of problems. However, if your profile edits are single-user only, it's probably overkill to introduce a CRDT. At first glance, it seems the two-tabs-open scenario is your highest source of bugs, so what you could do is use a BroadcastChannel to signal update events t…

How is YJS different from introducing CRDT? Doesn't it basically just do that for you anyways?

If CRDT is complications and difficult to manage, either YJS resolves that completely, or more likely that complexity will leak out of the abstraction layer no matter what.

To me it seems more like that OP should compare and contrast concurrency solutions, one of which is CDRT via YJS or another could be something like concurrency based on Go routines.

Edit: Should obviously mention Loro, the literal thread we're in now lol

Post reply on HN