[mdaniel]

https://github.com/Nutomic/ibis#federation

> applying all associated edits in order. Instances can synchronize their articles with each other, and follow each other to receive updates about articles. Edits are done with diffs which are generated on the backend, and allow for conflict resolution similar to git.

I somehow got the impression that CRDT was stand of the art in multiple edits to a common document, and sincerely doubt that git's conflict resolution is going to be a good experience

Also, as I understand federated things, the real hazard to usefulness is one of discovery. So how would I, owner of a hypothetical mdaniel.wiki, discover who has the best CRDT documents in their wiki such that I could subscribe to updates on those pages? A wiki of wikis?

[kemayo]

Automatically merging updates between different variants of the article, in fact, seems like a terrible idea. This is because resolving conflicts between edits is easy, but making sure that (for lack of a better word) semantic conflicts don't make it through requires a manual review of changes.

Your CRDT merge can be a technological marvel that will seamlessly stitch together different edits on a topic... that say wildly different things about it, resulting in a completely nonsensical article.

[foul]

>I somehow got the impression that CRDT was stand of the art in multiple edits to a common document, and sincerely doubt that git's conflict resolution is going to be a good experience

CRDT adds automatic conflict resolution, wikis need at most, if any, manual conflict resolution, because their page editing has little need for concurrent real-time edits, it's a slower process (ironic given the meaning of wiki in Hawaiian). About git, OP tried to explain to non-wiki editors what wikis do under the hood, conflict reconciliation in wikis is vaguely similar to git but simpler, and the tech Ibis uses, paired to a design for independence prone to content rotting (every url of the federation can differ even in context about any page), makes me smell of just importing by hand or by trust edits from peers into the backing store.

[bawolff]

I think it depends what you want. Diffs are better if you want to review changes and intelligently merge them.

CDRT is better if you want there to be just one document that everyone is editing at the same time, with merging being an automatic process and the rare non-sensical merge being acceptable.

[tux3]

Git conflict resolution isn't great, but it's also not much worse than MediaWiki's existing conflict resolution today.

It doesn't matter all that much whether your servers are federated or served from a single domain, the time users spend with the page editor open is much longer than the latency of a federation request. A server somewhere might be horribly out of sync and cause a lot of conflicts, but presumably those are also the scuffy servers with low traffic that don't see a lot of edits per minute anyways.

CRDT is cool, but it's deploying a very shiny new tech for a small problem that doesn't really need anything fancy.

[rakoo]

CRDTs make sure there is only one version, but that version might be garbage. Think taking all the lines from all conflicts in git. Sometimes it's ok, sometimes not. It's even worse than that: you don't know there was a conflict, so you don't know if there was a problem or not. It's trying to solve social problems with technology, it's never enough (but can bring us a good way there)

Manual merging is mandatory to have human meaning, so might as well use it all the time.

[viraptor]

CRDTs are cool for tiny concurrent edits. For example two people typing on one line. But it doesn't save you when you get large conflicting edits. No system can automatically merge instance A removing a sentence and instance B adding some words within the that sentence. It's still the user that will have to make a decision. And at that point, you're effectively looking at a git style 3-way merge.