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

11–20 of 49 posts

Re: Loro's rich text CRDT

#11

Post by codetrotter »

rubymamis wrote: post #7
jitl wrote: post #4

Earlier quoted context omitted.

What's great about CRDTs is that they're really good at both real-time and asynchronous collaboration, unlike the operational transform system used by Google Docs. Asynchronous collaboration is Peritext's major motivation [1]: > We interviewed eight people who regularly collaborate professionally on documents such as news articles, and several told us that they found real-time collaboration a stressful experience: th…

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…

Plenty of people would rather spend their time doing their job at hand, than to fight with git and spend time having to learn git.

Suggesting that everyone should use git, is like the famous HN comment that dismissed Dropbox because “you could just use rsync”. IMO.

Like yeah, you could. But no, plenty of people will never want to do that.

Re: Loro's rich text CRDT

#12

Post by josephg »

spencerflem wrote: post #9
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…

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) store strictly more information than git does, so theoretically it should be possible to make a CRDT which adds conflict markers too like git does. But as far as I know, nobody has built that yet! I really hope someone does, because it would be really neat.

I really want a git style version control system built on top of CRDTs with optional merge conflicts.

Re: Loro's rich text CRDT

#13

Post by rubymamis »

codetrotter wrote: post #11
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…

Plenty of people would rather spend their time doing their job at hand, than to fight with git and spend time having to learn git. Suggesting that everyone should use git, is like the famous HN comment that dismissed Dropbox because “you could just use rsync”. IMO. Like yeah, you could. But no, plenty of people will never want to do that.

Git is just the underlying mechanism. What you show to the user depends on your UX/UI. You don't need to show users the words "fork/merge" even. How about:

1. "Edit Joe's text"

2. "Ask Joe for a review"

3. "Do you want to add Alice's changes?"

Re: Loro's rich text CRDT

#14

Post by lewisjoe »

It's great work improvising over Peritext using joseph's latest CRDT work. Much needed literature in "applying CRDTs for richtext" space.

But I'm surprised why this one too hasn't focussed a lot on rich-text block elements (like lists, tables & sections) as much as it focussed on text attributes (like bold and italics).

Re: Loro's rich text CRDT

#15

Post by jitl »

rubymamis wrote: post #13
codetrotter wrote: post #11

Earlier quoted context omitted.

Plenty of people would rather spend their time doing their job at hand, than to fight with git and spend time having to learn git. Suggesting that everyone should use git, is like the famous HN comment that dismissed Dropbox because “you could just use rsync”. IMO. Like yeah, you could. But no, plenty of people will never want to do that.

Git is just the underlying mechanism. What you show to the user depends on your UX/UI. You don't need to show users the words "fork/merge" even. How about: 1. "Edit Joe's text" 2. "Ask Joe for a review" 3. "Do you want to add Alice's changes?"

For one thing, Git is abysmal at merging rich text formats that need balancing open/close annotation markers, like HTML and similar. With line/character oriented merge algorithms syntax errors from merge are inevitable. Once you start pulling that thread, like “ok can we clean up such mistakes automatically with a better merge algorithm that understands the content a bit more?” you’ll end up back here at CRDTs.

I’ve tried managing markdown docs in git a few times. Even with a team of senior+ engineer git experts it became a pain on frequently changing documents because conflicts were so common — if you wrap markdown at 80 characters, rewording a sentence is more likely to merge conflict than changing a variable in code since it may re-wrap several lines; and if you don’t wrap at all, any change in the paragraph will conflict on the entire paragraph.

Re: Loro's rich text CRDT

#16

Post by wim »

rubymamis wrote: post #7
jitl wrote: post #4

Earlier quoted context omitted.

What's great about CRDTs is that they're really good at both real-time and asynchronous collaboration, unlike the operational transform system used by Google Docs. Asynchronous collaboration is Peritext's major motivation [1]: > We interviewed eight people who regularly collaborate professionally on documents such as news articles, and several told us that they found real-time collaboration a stressful experience: th…

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:

   [ ] Project
      [ ] Don't do this
          [ ] A
      [ ] Do This
          [ ] B
          [ ] rm -rf /
We're working on an app [1] which needs to deal with this, but in general it also makes git less suitable for things like outliners or other collaborative text editors where people can work on lists, tables, and so on (structured data basically).

[1] https://thymer.com/

Re: Loro's rich text CRDT

#17

Post by injuly »

lewisjoe wrote: post #14

It's great work improvising over Peritext using joseph's latest CRDT work. Much needed literature in "applying CRDTs for richtext" space. But I'm surprised why this one too hasn't focussed a lot on rich-text block elements (like lists, tables & sections) as much as it focussed on text attributes (like bold and italics).

I've gone through the Peritext paper several times, and attempted to implement support for lists/tables/sections myself, but found it to be difficult owing to the limited scope of the original paper. I reached out to Martin Kleppman about this, and this is what he told me:

"Thanks for your message. I've written up a document on how to extend Patreon with nested block elements such as bullet points. It's not properly published yet, but you can find a draft here: https://martinkl.notion.site/Block-elements-in-rich-text-CRD... My colleagues are currently in the process of integrating this algorithm into Automerge, and creating bindings to the ProseMirror rich text editor."

Personally, I found the document to be very helpful.

Re: Loro's rich text CRDT

#18

Post by bmacho »

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)…

> 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.

Re: Loro's rich text CRDT

#19

Post by WorldMaker »

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)…

darcs [0] patch theory was a predecessor to OTs/CRDTs (and a predecessor to git as well; in some ways it is the "smart" to which git was named "dumb"). When it works and performs well it is still sometimes version control magic.

pijul [1] is an interesting experiment to watch, trying to keep the patch theory flag flying and also trying to bring in updates from OTs and CRDTs as it can.

[0] https://darcs.net

[1] https://pijul.org/

Re: Loro's rich text CRDT

#20

Post by mweidner »

lewisjoe wrote: post #14

It's great work improvising over Peritext using joseph's latest CRDT work. Much needed literature in "applying CRDTs for richtext" space. But I'm surprised why this one too hasn't focussed a lot on rich-text block elements (like lists, tables & sections) as much as it focussed on text attributes (like bold and italics).

The demo they show uses the Quill rich-text editor, which handles block elements analogously to text attributes: a block's type is determined by the attributes on its trailing newline. E.g., for a block that is part of an ordered list, the newline's format is `{ list: "ordered" }`.

https://quilljs.com/docs/delta/#line-formatting

Post reply on HN