Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Loro's rich text CRDT

loro.dev

Post reply on HN
Print view View original

31–40 of 49 posts

Re: Loro's rich text CRDT

#31

Post by mikebelanger »

rubymamis wrote: post #2

Slightly off-topic - I don't think real-time collaboration is suitable for text-based formats. I believe collaboration similar to working with git is superior: 1. Fork the text 2. Submit proposal 3. Review 4. Merge/Cancel EDIT: To slightly expand on this - there are many reasons for this intuition - the main, IMO, is that people like to work on text privately before showing it to people. Also, the mental fear of your…

Git is still great for developers, who are comfortable with the command-line and are willing to learn all of Git's concepts.

But let's be honest, Git isn't the most friendly tool for most computer users, many of whom have never touched any command-line interface, let alone Git. And yes, there's git-GUIs, but I find those are even more complex.

Re: Loro's rich text CRDT

#32

Post by mikebelanger »

Looks neat! Would there be a way of intercepting state and making 'snapshots' into a more traditional format, like SQL, or even a JSON file?

It sounds like this defaults to the server storing the whole state in their binary format, ditto the client-side portion of it. Nothing wrong with the format, but this is an early project, and nobody wants their data in something that's potentially unstable, or something that might get corrupted.

Re: Loro's rich text CRDT

#33

Post by CodeGroyper »

mikebelanger wrote: post #32

Looks neat! Would there be a way of intercepting state and making 'snapshots' into a more traditional format, like SQL, or even a JSON file? It sounds like this defaults to the server storing the whole state in their binary format, ditto the client-side portion of it. Nothing wrong with the format, but this is an early project, and nobody wants their data in something that's potentially unstable, or something that mi…

Supposedly you can always make a deep copy or a backup of anything you have.

Re: Loro's rich text CRDT

#34

Post by zachmu »

wim wrote: post #16
rubymamis wrote: post #7

Earlier quoted context omitted.

So they mention my exact concerns and addressed them, very cool. But their solution in practice doesn't look very different from what we can already achieve with git (apart from seeing your collaborator changes in real-time, which I'm not sure how substantial it is), or am I missing something? At the end of the day, how will this look to the end user? > a user may work in isolation on their own copy of a document for…

Another issue which git won't solve is if you collaborate on text which has "structure". For example when merging indented (todo) lists as flat text, bullets might end up in the wrong place, e.g. [ ] Project [ ] Don't do this [ ] Task A While offline, user #1 adds '[ ] Task B' and '[ ] rm -rf /' under "Don't Do This", while user #2 adds '[ ] Do This' under 'Project'. Obviously you don't want to merge this as: [ ] Pro…

Does the app store structured text in a structured way? You probably need to for this to work the way you want.

We are writing a version controlled database (Dolt) and we recently implemented automatic merging of the contents of JSON documents, seems related to what you're doing:

https://www.dolthub.com/blog/2024-01-16-announcing-json-merg...

Re: Loro's rich text CRDT

#35

Post by cubefox »

josephg wrote: post #12
spencerflem wrote: post #9

Earlier quoted context omitted.

The merging is automatic, for one

Yeah; and the merging is correct in all cases. You don't get spurious conflicts like you can with git. Also the same system can work both in realtime and offline scenarios. And CRDTs can handle a lot more than just plain text editing. That said, one thing git does that I like is that sometimes I want conflict markers to be added to my document when concurrent edits happen on the same line. CRDTs (and REGs like this)…

What's more realistic: Git switching to some form of CRDT, or Git being superseded by a different system which is based on CRDTs?

Re: Loro's rich text CRDT

#36

Post by cubefox »

josephg wrote: post #24
bmacho wrote: post #18

Earlier quoted context omitted.

> Yeah; and the merging is correct in all cases. No, it's obviously not. I'd say most of the time the merging is incorrect, that is, it is in contrast to both of the parties intention. Unlike git, which actually notifies them, Loro just silently modifies both changes into something nonsense/wrong.

My correctness point is that Git can end up with commits which spuriously conflict with themselves. Git's merge algorithms simply aren't very good. CRDTs (and REG) are correct in that everyone always ends up seeing the same document state. But I take your point - which is essentially that Loro (and automerge, yjs, diamond types, etc) don't correctly preserve intent in all cases. As you point out, if two users concurr…

A while ago we would have said a computer program obviously can't guess the intent behind edits. But now we do have such programs: Language models. I wonder whether anyone has already used one to automatically solve merge conflicts.

Re: Loro's rich text CRDT

#37

Post by jacquesm »

josephg wrote: post #10
jitl wrote: post #6

I'm curious about this line describing REG: > The REG algorithm excels with its fast local update speeds and eliminate concerns about tombstone collection in CRDTs. For instance, if an operation has been synchronized across all endpoints, no new operations will occur concurrently with it, allowing it to be safely removed from the history. If you remove these ops from history, does that remove the ability to time trav…

Hi! I invented replayable event graphs. I'm writing a paper at the moment about it, which hopefully should be out in a month or so. Send me a private email and I can mail you the current draft if you like. > If you remove these ops from history, does that remove the ability to time travel Yes it does. You also need the ops from history to be able to merge changes. You can only merge changes so long as you have the op…

Is this a special case of operational transforms, vv or something else entirely?

Re: Loro's rich text CRDT

#38

Post by josephg »

jacquesm wrote: post #37
josephg wrote: post #10

Earlier quoted context omitted.

Hi! I invented replayable event graphs. I'm writing a paper at the moment about it, which hopefully should be out in a month or so. Send me a private email and I can mail you the current draft if you like. > If you remove these ops from history, does that remove the ability to time travel Yes it does. You also need the ops from history to be able to merge changes. You can only merge changes so long as you have the op…

Is this a special case of operational transforms, vv or something else entirely?

I think you can argue that it’s both a special case of an OT system, and a special case of a CRDT at the same time. It stores the original operations rather than transformed operations (like an OT system would). Then it does OT in bulk on those operations on every peer by constructing a crdt state object on the fly.

So it’s very closely related to both crdt and OT based systems. I think if you squint your eyes you could argue that it’s both. It’s a grow only set crdt, storing operations that we do OT on. We do OT by embedding another crdt implementation inside each peer.

Re: Loro's rich text CRDT

#39

Post by josephg »

cubefox wrote: post #36
josephg wrote: post #24

Earlier quoted context omitted.

My correctness point is that Git can end up with commits which spuriously conflict with themselves. Git's merge algorithms simply aren't very good. CRDTs (and REG) are correct in that everyone always ends up seeing the same document state. But I take your point - which is essentially that Loro (and automerge, yjs, diamond types, etc) don't correctly preserve intent in all cases. As you point out, if two users concurr…

A while ago we would have said a computer program obviously can't guess the intent behind edits. But now we do have such programs: Language models. I wonder whether anyone has already used one to automatically solve merge conflicts.

That’s a good idea that I’ve heard a lot of people suggest. But as far as I know nobody has actually implemented merging using a llm yet.

Part of the problem is that CRDTs want to have strong eventual consistency - so, after merging everyone should be looking at the same final result. It’s hard to guarantee that if you pass the conflicting data to a LLM.

Re: Loro's rich text CRDT

#40

Post by ghizmandier »

rubymamis wrote: post #2

Slightly off-topic - I don't think real-time collaboration is suitable for text-based formats. I believe collaboration similar to working with git is superior: 1. Fork the text 2. Submit proposal 3. Review 4. Merge/Cancel EDIT: To slightly expand on this - there are many reasons for this intuition - the main, IMO, is that people like to work on text privately before showing it to people. Also, the mental fear of your…

Hey, sounds like you'd love what we're building @ Ellipsus — https://ellipsus.com

We started off your same exact assumptions and built a text editor that combines the best of both worlds: you can collaborate in real-time on the same piece; or branch off of it, work on your own and then have it reviewed and merged back into the main branch. That and other features that should make writing together a pleasure.

Reach out if you want to give it a spin, we'd appreciate your feedback!

Post reply on HN