y-crdt VS crdt-benchmarks

Definitely agree that would be valuable. In fact our multiplayer state synchronization aspect is largely implemented in TypeScript (there's a TS element to the stack as well), and is built on top of YJS – there is a Rust implementation of YJS already though, which would likely be a great start for anyone looking to build something similar purely in Rust: https://github.com/y-crdt/y-crdt

We are working on a plugin API, which will allow people to build functionality that leverages the multiplayer data model – but within the app rather than as standalone applications.

It sounds like you want a Conflict-Free Replicated Data Type, CRDT for short. There are some Rust libraries you can use, but y-crdt seems very feature-complete, a port of Yjs.

I've found reliably persistence on the backend irritating with yjs. Seems like the official path is to fork their example library and edit it. (The example is insufficient because, for example, it will silently eat data if the onchange webhook fails).

yrs initially looks tempting but it's unsound at it's core. (The plan is to port the API directly from JS, use unsafe to silence the borrow checker, then gradually fix specific instances of undefined behavior if they cause actual real world issues.[1] I don't this this is an approach that can work. That's a shame because a lot of impressive work has gone into yrs.)

[1]: https://github.com/y-crdt/y-crdt/issues/233

So exciting! Strangely enough, a couple of hours before this release, we just managed to wrap our heads around Yjs after playing with it on and off for a few weeks!

For anyone not up to date with the world of CRDTs, Seph Gentle's two blog posts have become legendary:

* https://josephg.com/blog/crdts-are-the-future/

* https://josephg.com/blog/crdts-go-brrr/

these are also worth checking out:

* https://github.com/y-crdt/y-crdt (rust implementation started by the creator of Yjs, Kevin Jahns)

* https://github.com/y-crdt/ypy (python bindings for the rust implementation)

* https://github.com/josephg/diamond-types (Seph Gentle's rust implementation of YATA, the algorith behind Yjs)

I found the concept of conflict-free relational data types (CRDTS) interesting as it allows you to have fully offline experiences while also having a conflict-free syncing experience. I was looking for some good libraries and came across automerge and yrs, but both had some rough APIs as they're primarily low-level libraries that are wrapped by TypeScript APIs.

Yrs (Yjs on Rust) maintainer here: we actually had some idea about building extension to Postgres ;) See: https://github.com/y-crdt/y-crdt/issues/220

Hi everyone! Author here. I'm happy to answer questions.

I wrote this a couple years ago. Since then I've been working on my own CRDT called Diamond Types[1], which uses a lot of these ideas to be bonkers fast. I've built several OT based collaborative editing systems, and diamond types is much faster than any of them - though rust and wasm might be the real MVPs here. I wrote a follow-up to this article last year when I got that working, talking about how some of the optimizations work. That article is here[2].

A fair bit has changed since I wrote that article. Yjs has started a rewrite in rust (called yrs[3]). And Automerge has apparently dramatically improved performance based on some of the ideas I talk about in this article. Oh, and diamond types has been rewritten from the ground up. Its now about 5x faster than it was last year, by completely changing the internal structure. But thats a story for another day.

Unfortunately I still only support collaborative text editing. Adding full JSON support comes soon, after I document some more of the tricks I'm doing. Its really fun work!

Why do I only support collaborative text editing? Because I care about performance, and text CRDT performance is hard because you have so many individual changes. (One for each keystroke!). Making text editing fast means everything is fast. But we've still got to do the work. To make that happen, my plan is to add full JSON editing support to diamond types using shelf[4]. Shelf is a super simple CRDT which fits in 100 lines of javascript.

[1] https://github.com/josephg/diamond-types/

[2] https://josephg.com/blog/crdts-go-brrr/

[3] https://github.com/y-crdt/y-crdt/tree/main/yrs

[4] https://github.com/dglittle/shelf

Author of Yjs here. I'm all for faster data structures. But only benchmarking one dimension looks quite fishy to me. A CRDT needs to be adequate at multiple dimensions. At least you should describe the tradeoffs in your article.

The time to insert characters is the least interesting property of a CRDT. It doesn't matter to the user whether a character is inserted within .1ms or .000000001ms. No human can type that fast.

It would be much more interesting to benchmark the time it takes to load a document containing X operations. Yjs & Yrs are pretty performant and conservative on memory here because they don't have to build an index (it's a tradeoff that we took consciously).

When benchmarking it is important to measure the right things and interpret the results somehow so that you can give recommendations when to use your algorithm / implementation. Some things can't be fast/low enough (e.g. time to load a document, time to apply updates, memory consumption, ..) other things only need to be adequate (e.g. time to insert a character into a document).

Unfortunately, a lot of academic papers set a bad trend of only measuring one dimension. Yeah, it's really easy to succeed in one dimension (e.g. memory or insertion-time) and it is very nice click-bait. But that doesn't make your CRDT a viable option in practice.

I maintain a set of benchmarks that tests multiple dimensions [1]. I'd love to receive a PR from you.

[1]: https://github.com/dmonad/crdt-benchmarks

Diamond types author here! Congratulations on getting your crdt working! It’s lovely to see a new generation of CRDTs which have decent performance.

And nice stuff implementing peritext! I’d love to do the same in diamond types at some point. You beat me to it!

Im building a little repository of real world collaborative editing traces to use when benchmarking, comparing and optimising text based CRDTs[1]. The automerge-perf editing trace isn’t enough on its own. And we’re increasingly converging on a format for multi user concurrent editing traces too[2]. It’d be great to add some rich text editing traces in the mix if you’re interested in recording something, so we can also compare how peritext performs in different systems.

Anyway, welcome to the community! Love to have more implementations around!

https://github.com/josephg/crdt-benchmarks

https://github.com/dmonad/crdt-benchmarks/issues/20

So yes, a particularly large document is not the norm but it can happen.

JavaScript CRDTs can be quite performant, see the Yjs benchmarks: https://github.com/dmonad/crdt-benchmarks