Automerge CRDT – Build local-first software | Hacker News Reader

Automerge CRDT – Build local-first software

automerge.org

39 pointswebmaven8 comments

Current CRDTs are not a magical solution to collaborative software. They have their own “way” of handling merge conflicts. For example it may merge English words in non sensical ways. Without review, there is no way to safely have automatic collaborative editing without side effects.

CRDTs have exposed to us that the desirable conflict resolution strategies are very deeply connected to the underlying semantics of the representation, not its syntax. I expect that it would produce much better results on top of parsed ASTs (for example) than raw strings. Combining CRDTs with tree-sitter would be interesting.

I tried to apply CRDTs many times, what I learned: CRDTs sound great in theory but for most use cases they cannot be applied to the buisness logic. Most of the time you either need to read out other information in from different collections to resolve a conflict. In other cases you have to ask the user to resolve the conflict. The cases where CRDTs work great are also the cases where you do not really care about conflicts and a last-write-wins is ok.

https://rxdb.info/downsides-of-offline-first.html

I didn't read details just introduction, and i do not understand how can it guarantee that order of operations do not matter. Eg. when one device delete some entity and other will later pin it to other entity how you handle that? and also in cases when you have like assigned owner and 2 devices change that owner to other one with change win? is there some timestamp that decide what change should win? and what in case when 2 changes have the same timestamp (i know it's corner case)?

Link needs to be edited (has an extra trailing /)

  <link data-react-helmet="true" rel="canonical" href="https://automerge.github.io//">

From the site itself. Interestingly, if you turn off JS the page loads just fine as is. Their own canonical link breaks with their own Javascript.

Reading the URL spec, the path elements (separated by /) are allows to be void, so // is syntactically valid. And POSIX specifies that // should be treated as / .

I know that these days that they are rarely actually file references, but still I feel that web servers should accept this, especially a site like github.

Just tried it out, Github does, in fact, let you use extra slashes. I just threw a bunch of /'s onto https://github.com/////// and it loaded just fine. The problem is with the JS on this particular page. When it first loads (on my slower and older laptop there was enough delay to see this) it loads the Automerge home page just fine. Then it tries to pull in contents because of that extra / and breaks. If you go to the Docusaurus home page (which is what Automerge's home page is built with) you can get similar behavior).

https://docusaurus.io/

https://docusaurus.io//

Try the second with JS turned off as well as on, you will get the home page when it's off and a 404 when it's on.

So it seems the problem is two-fold:

1. Automerge has the wrong canonical link, which HN pulls from submissions and replaces submitted URLs with (this is, I think, largely to help with de-duping).

2. Docusaurus' JS (which Automerge is using) takes a perfectly valid URL and generates a 404.

Reply on news.ycombinator.com