Hacker News Reader

Comment by refulgentis | Hacker News Reader

To OP's point, which I secretly wished I had the courage to post when CRDTs came up a couple times last week: I've been seeing these posts, and your comment, for what feels like my entire 13 years on HN. (That can't be true. But I distinctly recall someone saying "if they can do text this fast hey'll be able to do arbitrary JSON soon!" at least 5 years ago)

At the beginning of that period I made and sold a startup on having a dead simple sync strategy, by myself, while I watched 3 funded competitors try to build sync, fail and go under. I had no funding and no CS education, I was a waiter.

View on HN

Arbitrary JSON has been done plenty of times, and it works great. Automerge, Yjs and ShareDB all manage it.

I don't quite understand what's going on then because I swear I just read in one of those threads last week that even the best text automerger still needs manual intervention to avoid creating nonsense...which, to be honest, sounded off because I thought this whole thing was popularized by Google Docs? Wave? and it didn't have that issue

Can you link the other comment? Its hard to know what you're talking about without that context.

In any case, you can't use a text "automerger" to collaboratively edit JSON text. (Whats an "automerger"?)

To understand why, suppose we had an empty (JSON) list: []. Two users concurrently inserted two items, "a" and "b". If those inserts get translated into string inserts, you end up with a JSON string containing ["a""b"] - which is a syntax error!

The trick to making this work correctly is that the CRDT / OT system needs to understand that you're editing a list. Don't collaboratively edit the JSON string. Collaboratively edit a list then JSON.stringify the result.

There's a possibility he's talking about what I wrote about CRDTs for syntax trees - https://writer.zohopublic.com/writer/published/grcwy5c699d67...

> the best text automerger still needs manual intervention to avoid creating nonsense

AFAIK the best production-ready CRDT solution for text is Yjs [0], and in some specific cases, the result of the merge might be something unexpected (one example [1]). However, there is research-quality CRDT called Peritext [2] which is specifically designed to handle styled text in an intuitive way, so the merge is more predictable.

[0]: https://github.com/yjs/yjs

[1]: https://github.com/yjs/yjs/issues/382

[2]: https://www.inkandswitch.com/peritext/

I don't think this comment makes much sense, arbitrary unicode text is very different than JSON. What application domain are you talking about?

Reply on news.ycombinator.com