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…
Movable tree CRDTs and Loro's implementation
11–20 of 32 posts
Re: Movable tree CRDTs and Loro's implementation
#12We'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
Re: Movable tree CRDTs and Loro's implementation
#13When 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…
Re: Movable tree CRDTs and Loro's implementation
#14We'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
#15I wonder if there has been any practical CRDT for data dense applications, such as images (pixels) and 3D models?
Re: Movable tree CRDTs and Loro's implementation
#16We'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…
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).
Re: Movable tree CRDTs and Loro's implementation
#17Earlier 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)
Re: Movable tree CRDTs and Loro's implementation
#18I 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).
Re: Movable tree CRDTs and Loro's implementation
#19We'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…
Re: Movable tree CRDTs and Loro's implementation
#20Asking 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…
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