czx111331

Perhaps the most important difference is that software — even after being purchased and used — remains relatively easy to patch, unlike a physical lock.

loro-prosemirror[1] offers much better support for integrating Loro with ProseMirror/Tiptap.

In theory, loro-mirror could also be used to integrate Loro with other rich-text editors, but that wasn’t its original design goal and it may need further refinement to work well.

[1] https://github.com/loro-dev/loro-prosemirror

I believe that in the right contexts—specifically where eventual consistency is acceptable—the local-first paradigm is highly valuable and will gradually become mainstream. A major factor limiting adoption today is that existing local-first solutions are incomplete: when building such applications, developers must handle many problems that are trivial under strong-consistency or traditional models. This raises the learning cost and creates significant friction for paradigm shifts.

Our recent work on Loro CRDTs aims to bridge this gap by combining them with common UI state patterns. In React, developers can keep using `setState` as usual, while we automatically compute diffs and apply them to CRDTs; updates from CRDTs are then incrementally synced back into UI state [1]. This lets developers follow their existing habits without worrying about consistency between UI state and CRDT state. Paired with the synchronization protocol and hosted sync service, collaboration can feel as smooth as working with a purely local app. We’ve built a simple, account-free collaborative example app[2]. It only has a small amount of code related to synchronization; the rest looks almost the same as a purely local React app.

[1]: https://loro.dev/blog/loro-mirror

[2]: https://github.com/loro-dev/loro-todo

Is Bitcoin a "public sync" application by the definition?

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.

We are carefully stabilizing our encoding format and will have a clear storage format documentation introduced in version 1.0. I agree that a more transparent format can provide users with a better sense of control, and we will try to create a human-readable format for exporting CRDT data (the kind that includes operation history). As for the application state, Loro already supports direct export in json format.

Similar to OT, in certain scenarios, it's sufficient to ensure that only a subset of peers have the complete data, while others don't need the full history. For instance, in real-time collaboration scenarios with a central server, we can, just like OT, allow clients to hold only a shallow clone instead of the complete history. This approach results in minimal overhead for the clients.

> If you remove these ops from history, does that remove the ability to time travel (per the home page "An antidote to regret, enabling historical edits traversal") or merge branches?

Yes. But squash can be supported.

> How can we be sure an operation is synchronized?

In Loro, we not only record the real-world timestamp efficiently, similar to Git, but also capture the DAG information. This approach ensures that if an operation (op) is particularly old, it will have many other ops depending on it. By utilizing both pieces of information, we can determine the operations that are likely synced across all peers. For peers like servers, it's feasible to preserve all operations. However, we can remove some operations in scenarios such as opening the document online for the first time.

> If dropping these ops is necessary for speed/storage optimization but disables time-travel, is it possible to put the removed historical/tombstone ops into a "cold storage" that's optional and only loaded for time-travel use?

Yes. This is not supported at the moment, but we hope to implement it before version 1.0.

Yes, it's agnostic to the network layers. The output of doc.exportFrom() is just a binary array.

We are addressing the CRDT downsides mentioned in the article at Loro:

- Ever-growing state. This is no longer an issue. With OT-like CRDTs, you can discard unnecessary historical data at any time. This is theoretically feasible, and we are moving towards this goal. - Complex implementation. The complexity is internal within the package, and it's written in Rust, making it universally applicable. - Opaque state. We aim to expose these internal states through improved DevTools, making them easier to control and observe. This is one of the essential steps in enhancing our DX.

You can visit our blog to learn more: https://www.loro.dev/blog/loro-now-open-source

The code in the blog is from Vue Pinia, a state management library, and not from Loro. It serves as an example demonstrating that CRDTs can be modeled similarly. Thus, you might expect to use Loro in a similar way.

Indeed, schema migration is challenging. There is a lot to explore, both in reducing the need for migration and in ensuring a smooth transition when it's required. We plan to tackle this issue in the future.

Nice work! However, it doesn't seem like a fair benchmark. It doesn't calculate and store the ops, nor does it store the actual text. To build a text CRDT with delta updates support upon it, users must store OpID => Text in an extra structure, which isn't cheap.

Yeah, I'm referring to this. In essence, it's like a mind map that expands from left to right in a compact format. There are similar things like Logseq and Roam Research. Although the view is designed mostly for text, I think it is useful for visualizing flat and shallow trees. Though it might look less fancy, it's readable on mobile, and can display the hierarchy more clearly without disturbing lines, which contribute little information when reading.

Thanks for sharing. I might be able to build upon this.

Probably little. Because the tree is flat and wide, different tree layout algorithms have little effect on the overall compactness. However, I guess it might be improved by using an outline view like Workflowy.

Yes, I use a similar approach when debugging some parts of my CRDTs as well. It's very helpful.

However, this algorithm is designed specifically for trees. I'm not sure whether I could manage to make it work on DAGs (Directed Acyclic Graphs). It would require some rewrites of the aesthetic rules and designing a new algorithm.

Probably not. This algorithm is specifically designed for trees, not graphs.

PRs are welcome! I wasn't aware that Diamond types also provided a WASM version. I've included it in the native benchmark with Loro though. You can see it here: https://www.loro.dev/docs/performance/native

> Are you intending to add JSON-style editing support to your CRDT?

Loro is another CRDT library I'm working on. It's a superset of crdt-richtext and supports JSON-style editing.

> We can't properly optimize collaborative editing systems without them!

I'm totally with it

Hi! I really like your work, and I've learned a lot from your code ;)

I totally agree that we need more real-world datasets to make better benchmarks and avoid 'overfitting'. It'd be nice to have benchmarks for rich text.

I've also noticed that certain scenarios, like drawing, table editing, and whiteboard editing, aren't well covered. What are your thoughts on this?

Alright, I just added a link to the section of the original Peritext document related to preserving the author's intent: https://www.inkandswitch.com/peritext/#preserving-the-author...

The specific definition of user intent in the context of concurrent rich text editing can't be clearly explained in a few words. it's best understood through specific examples. I've provided some examples in my brief introduction to Peritext.

Thank you for the invitation! I'm really looking forward to being part of the community.

The source code of the benchmark is available here https://github.com/zxch3n/fugue-bench

Hi, I'm the developer of crdt-richtext. I'm humbly grateful for everyone's support and quite surprised to see the level of interest this project has generated. It's still just an experimental first step for us and not mature for production yet. As some of the comments have pointed out, performance may not be the main bottleneck for adopting CRDTs anymore. The potential bottlenecks in the user path might lie in the DX and the integration with existing tool stacks. Our primary project, Loro, which is still in closed development, aims to address these issues in the near future. We look forward to sharing updates with you as we progress.

Yeah, that's right

Thanks for pointing that out. I refined the text and added a bookmark to make the citation stand out.