pdudits

Provocative article indeed. But some of the visions seem but naive to me:

Running exactly the same validation twice wouldn’t make data more valid.

What in a Web app scenario guarantees, that the validations are the same, that a potential attacker haven't removed the validation from client code? By embedding the rules inside database you just made it a proxy to the raw data - making it the same old, wrong architecture.

Network failures... should not undermine our consistency guarantees.

Offline... I should be able to do local modifications, then merge changes when I get back online.

So far it is proven, that to get any consistency guarantees in such case, you are severely limited in kinds of data you can process. No library can magically solve the conflicts for you as long as the data is not CRDT. There are not many applications consisting exclusively of sets and counters.

What I miss in the article or discussion is consistency of refs. The moment your remote is a distributed one, it may have two different values for HEAD in single point of time in different parts of network. If two clients push in this time, HEADs diverge even further.

So as in distributed databases, you either:

* need to acquire exclusive lock on the repository metadata, or

* accept, that your push will be eventually discarded because you did not have up to date metadata