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

You don't need a CRDT to build a collaborative experience

zknill.io

Post reply on HN
Print view View original

31–40 of 70 posts

Re: You don't need a CRDT to build a collaborative experience

#31

Post by zknill »

chromatin wrote: post #29

We took a super simple (IMO) approach to collaborative editing in my current project: Each block of text has a version number which must be incremented by one by the client at the time of submission. The database provides conflict prevention by uniqueness constraint which bubbles up to the API code. The frontend is informed of conflict, so that the user can be notified and let the human being perform conflict resolut…

How do you handle getting the changes that one client makes onto the other clients? Are you pushing it from the server to the clients with websockets, or waiting for the clients to ask for new info, or waiting for the conflict to happen when someone else tries to make a change, or something else?

I'm thinking a lot about keeping server and client data in sync while working on our hopefully-soon-to-be-released LiveSync product[1]

[1] https://ably.com/livesync

Re: You don't need a CRDT to build a collaborative experience

#32

Post by josephg »

lewisjoe wrote: post #12

> everyone’s gonna say “but hey, google docs uses operational transform not CRDTs”.. OK yes, but you are not google. Well, google docs works not because they somehow figured out how to converge OT edits with as much precision as CRDTs do, but simply because they have a central server which orders edits anyway and don't need true leader-less convergence. In fact, I agree not many things don't need a CRDT. CRDTs help w…

Yeah. Text based OT is pretty simple to implement, too. It’s about 200 lines of code, plus a simple network protocol. It’s fast and relatively straightforward to code up, and unlike text CRDTs it’s pretty fast by default.

I use it as my standard test when trying out a new programming language. It was unexpectedly ugly in go because of go’s lack of enums & unions, and that’s one of the big reasons I never got in to programming Go.

Re: You don't need a CRDT to build a collaborative experience

#33

Post by parhamn »

At this point, given the maturity of libraries (I was exploring this recently), I think you'd have to make the case that CRDTs are bad not just "too much".

Interfacing with the 'blob' is a real thing (y-js is solving some of this with a rust implementation that has cross language binding) but generally the things they noted (e.g. a Figma canvas) aren't things you commonly do joins across and if you did you'd have an independent indexing store for that functionality.

With tools like SyncedStore [1] and HocusPocus [2] you end up with a pretty good, we'll tested, easy to implement base for good collaboration.

[1] syncedstore.org

[2] github.com/ueberdosis/hocuspocus

Re: You don't need a CRDT to build a collaborative experience

#34

Post by [deleted] »

jitl wrote: post #19
zknill wrote: post #18

Earlier quoted context omitted.

So Last-Write-Wins (LWW) basically _is_ a CRDT, but not in the sense that anyone really expects, because they aren't that useful or intention preserving. Especially if the two writes happen in very quick succession / concurrently. LWW becomes useful if you can: a) help humans to see who is doing what on a doc b) reduce the size of the change that is LWW As you've said: > However our LWW texts are individually small -…

You can have a LWW CRDT, but not every LWW is a CRDT. LWW CRDTs generally pick a winner based on causal order which is convergent , the C in CRDT, because every peer receiving the same ops in any order would pick the same winner. Picking a winner based on wall clock time order (as suggested in the article, and implemented by Notion) is not convergent; if peers used that algorithm to apply ops I they would not converg…

[deleted]

Re: You don't need a CRDT to build a collaborative experience

#35

Post by yencabulator »

jes5199 wrote: post #23

CRDT is a different paradigm. Ideally we'd use it to replace client-server

And wrangling CRDTs into a client-server architecture is actually extra work. The basic design assumes you can trust every peer -- making sure that jes5199 actually was the peer who added a comment that is marked as author: "jes5199" is not trivial.

Re: You don't need a CRDT to build a collaborative experience

#36

Post by [deleted] »

jitl wrote: post #10

I agree broadly with the article’s position but I think locks are more harmful than helpful. When I was a Quip user (2018) it was super frustrating to get locked out of a paragraph because someone’s cursor idled there. Instead just allow LWW overwrites. If users have contention and your sync & presence is fast, they’ll figure it out pretty quick, and at most lose 1-2 keystrokes, or one drag gesture, or one color pick…

[deleted]

Re: You don't need a CRDT to build a collaborative experience

#37

Post by lmm »

> You can’t inspect your model represented by the CRDT without using the CRDT library to decode the blob, and you can’t just store the underlying model state because the CRDT needs its change history also. You’re left with an opaque blob of data in your database. You can’t join on it, you can’t search it, you can’t do much without building extra features around that state blob.

So use the CRDT library when building your indices? Or better yet use a CRDT-aware datastore. This doesn't seem like a real problem.

> Locking for safety

Please don't. You're inevitably going to have lost locks, lost updates, or most likely both.

Re: You don't need a CRDT to build a collaborative experience

#38

Post by [deleted] »

jitl wrote: post #10

I agree broadly with the article’s position but I think locks are more harmful than helpful. When I was a Quip user (2018) it was super frustrating to get locked out of a paragraph because someone’s cursor idled there. Instead just allow LWW overwrites. If users have contention and your sync & presence is fast, they’ll figure it out pretty quick, and at most lose 1-2 keystrokes, or one drag gesture, or one color pick…

[deleted]

Re: You don't need a CRDT to build a collaborative experience

#39

Post by swyx »

> I’ll run through a bunch of broad categories of applications, and describe how to make use of these features.

i love these kinds of taxonomies of apps, because then you can get specific about tech stack choices. just offering a couple more that i've come across in my years:

- more prototypical: 7GUIs https://eugenkiss.github.io/7guis/tasks

- Application holotypes: https://twitter.com/arthurwuhoo/status/1470489178186170374

Re: You don't need a CRDT to build a collaborative experience

#40

Post by aboodman »

It's true that a CRDT is often not the right thing for a classic client/server application. But this doesn't mean we should just give up on ux and use locking.

There are approaches to multiplayer that are client/server native. By leveraging the authoritative server they can offer features that CRDTs can't, while preserving the great ux.

I'm partial to server reconciliation:

https://www.gabrielgambetta.com/client-side-prediction-serve...

My product, Reflect, implements server reconciliation as a service. You can learn more about how it works here:

https://rocicorp.dev/blog/ready-player-two

Post reply on HN