I'm curious, it seems to me like the stated objections to CouchDB's approach aren't that bad, at least for quite a few use cases: - Client optimistically goes

I'm curious, it seems to me like the stated objections to CouchDB's approach aren't that bad, at least for quite a few use cases: - Client optimistically goes to POST a JSON document. If new, there is no _id field included. - If there is no conflict, it's fine. - If there is a conflict, the server tells the client this. The client can try again, including the _id field of the current document version. Could the CRDT process not be applied on the client looking to make an update? Or at least on the server side, where the client says, "OK, I've included the current _id, please merge my version"? I have not attempted personally to use this at scale, but had prototyped a tool for small-scale collaboration on a project that seemed to function "well enough." No CRDT merging, but then there was no expectation of typically trying to work on the same sentence simultaneously. This was basically as a client/project assessment tool; any given project would start from taking a copy of a template DB on the server, then syncing and updating from that. From there, any sort of local-first changes were trivial, and easily synced back to the central location when back online.