[urbit]

Unfortunately I wouldn't expect a lot of substantive technical discussion for a post like this on HN -- this post will expire before anyone has time to read it properly and produce thoughtful responses.

(Which is broadly the problem with posting enormous applied CS-research braindumps to HN. Don't know a better place to do it, though. And I see people are upvoting you. Also, the absence of thoughtless responses is itself a great response.)

The key point here, as far as I can tell, is really building a CRDT system as a true platform layer, rather than as a one-off solution for a special-purpose app. I think it's fairly clear that generic sync is a pretty essential part of a modern decentralized computing environment, and I don't think it's clear at all what the best way to solve it is.

But... it seems to me that you've solved a large piece of the problem but not the whole thing. Because the most important document sync and collaboration platform is, of course, source code control. If you have a document sync and collaboration model that doesn't at least generalize to classic revision control, why not?

Now, there's a sensible reason to separate these problems -- CRDT and OT solutions tend to specialize in the zero-maintenance case where a user-resolved merge is just impossible. Whereas if it was possible to build a zero-maintenance revision-control system, which automatically resolved all merges and conflicts, someone would have done so already.

This certainly suggests that the two are different problems. But generalizing across slight differences is what system software does. Maybe one is a special case of the other?

A generalized layer for lightweight collaboration is pretty powerful. But it certainly seems like the case that if you could generalize across lightweight collaboration and heavyweight revision control, you would have something that would be incredibly powerful.

Or is this too ambitious? I don't know so I'm asking you.

[blake8086]

I suspect you could build such a thing if you could more rigidly define edit operations on source code files. The way we edit code now is roughly "insert/edit/delete string <x> at position <y>", which doesn't really carry enough context to auto-merge.

If edits carried all the semantic information of what they were doing to the source: "rename symbol <x> to <y> everywhere" "perform step <x> after step <y>", then we could probably build a zero-maintenance revision-control system.

[kd5bjo]

I've had some thoughts along the same lines, but haven't taken the opportunity to flesh them out nearly as far.

A git repository is nearly a CRDT that represents a file system hierarchy -- the only thing that's missing is a deterministic merge algorithm. If you allow files to be committed in a conflicted state that gets resolved by a later edit, you have a full CRDT that automated systems can work freely with.

The catch, of course, is that despite pushing the resolution to an arbitrary point in the future, these conflicts still have to be resolved by hand eventually.