Could you elaborate on what you mean by "document oriented db with version control"? Couch stores revision identifiers with every document ID, though old versions are subject to deletion whenever DB compaction occurs...

Essentially, objects have the ability to be rolled back, forward etc. Support for messages attached to commits and transactional commits would be nice!

An extensible user collection would also be nice, so app users are database users and vice versa.

I'm more interested in the "distributed" part of the story. Version control can be fitted into any database with a bit of hacking, but a distributed ACID database where you can commit to any node and merge with any other node sounds like a really interesting concept.

Especially when combined with the fact that it is extremely difficult to forge git history without getting noticed, people could use something like git as a reliable, scalable, and censorship-resistant platform for data sharing and storage.

I agree, but alternatively, we could study git and the lessons learnt there and design a distributable ACID database with version controlled data, extensible user collections and the performance of a more traditional database.

Veracity has a database feature which might be what you are envisioning. (Disclosure: I am one of the developers of Veracity). But I would not describe it as document-oriented. It versions a collection of records with fields in the same way that regular version control manages a collection of directories and files, with support for history and changesets and push and pull.

CouchDB? http://couchdb.apache.org/docs/intro.html

As pointed out below, versions can be garbaged by an efficient Database administrator.

Couchdb keeps old versions of documents. And it is document oriented. So there's that.

We've dismissed CouchDB a couple of times...

No we have not. No need to be an ass.

I'm not a donkey.

We have dismissed it as the versions are deleted during compaction and aren't replicated to other nodes. Hence, dismissed.