Ask HN: Is there a descentralized DB with a simple social conflict resolution?
I think this applies to most databases, but I'm particularly thinking of internal enterprise databases, some social networks, any federated database system, and different devices of a single user
I'm thinking of this features:
1- Append-only?, full history of operations. Deletes / edits do not remove data, they only modify the "active state"
2- Agents are public keys or similar (DIDs?)
3- Operations are signed, and receivers verify if operation is valid, and sender is allowed
4- Operations form a Merkel-DAG (similar to git, they link to the tips of current "active state", like a commit/merge in git)
So far I think I've basically described [OrbitDB](https://github.com/orbitdb/orbit-db)
Consensus is where things get real hard, [OrbitDb seems to use a last-write-wins CRDT](https://news.ycombinator.com/item?id=22920204), and although I don't know the details of orbitDb, I think for many simple use-cases, conflicts can just be resolved on the social layer. But I think we need to provide agents with good tools to resolve conflicts
I'll try my best here with some ideas:
When merging, we can order operations by their timestamp, if operations enter conflict, raise it to the conflicting agents, or someone with permission to solve them.
If an agent makes public an operation that forks its own history, mark agent as malicious or compromised, alert other agents, this needs resolution on the social layer, you have proof of misconduct, an agent has signed diverging operations
Any operation becomes fully settled if you have proof that all agents of your system have referenced it directly or indirectly through newer operations.
Timestamps can be upgraded by using opentimestamps.org to get proof that an operation existed at time X (prevents creation of operations in hindsight). Though this does not prove operation has been made public
11 comments
[ 3.8 ms ] story [ 43.0 ms ] threadOnly sometimes, and databases are notoriously picky because when something unexpected happens it can cause innumerable problems and pain.
In particular, distributed systems cannot efficiently assert objective/wallclock timestamps by definition.
opentimestamps.org is comically naïve.
> opentimestamps.org is comically naïve.
Can you elaborate?, I'm very interested, I have high regards with the idea of the project
Distributed systems cannot make reliable assertions about wall-clock timestamps of operations by definition. Even BFT consensus on a given timestamp does not change this fact. This is the whole rationale behind things like Lamport and vector clocks! Anything building on the assertion quoted above is invalid.
> Thus we can say Bitcoin is a notary, and we can use Bitcoin block headers as time attestations: proof that a notary that we trust attested to the fact that some data existed at some point in time.
You can use headers as evidence that supports a time attestation, yes. But that evidence does not in any sense _prove_ the time is accurate! It's easy to construct a pathological condition -- not necessarily malicious, either! -- which breaks these assumptions.
In a distributed system there is no notion of "a point in [wall clock] time" by definition. Timestamps can be attached to events but they cannot be taken as authoritative.
Tough I still think it is a really cool project, to me is the coolest use-case of blockchains beyond money (maybe the only one?)
If you don't want to trust anybody, you can ignore all time references, and just look at the proof of work on top of the attestation.
If you estimate the world's ability to generate proof of work, you can get a lower bound of how much time must have been passed in order to produce that proof, or estimate how much it cost, and you can be as conservative as you'd like, you'll still get a meaningful lower bound of time. Your only assumption is your own estimate
And from the proof of work point of view, it scales infinitely, you can put as many attestation as you can fit in a merkel tree into a single bitcoin transaction
You literally can't! All you can get from this is a lower bound on the _reported_ amount of time. But there's no way, definitionally, to assert any constraint on the _actual_ time. This is my point.
You can ignore any time anybody ever reported, the only thing you need reported from others are the proof of work accumulated from the attestation block to the latest block