Been thinking about Decentralized P2P Document Databases, just thought some people might want some insight.
As I can figure the database I am talking about is shared between a multitude of people; of which, they are either admins or consumers. However, all people are able to fully replicate the database. An admin is able to modify the database, while a user is only able to consume the database.
1. Content distribution is uniform across roles.
2. Content is freely readable but not editable (explained below) by users.
3. Replication means merely using the database.
4. Ad hoc replication becomes possible.
1. Updates to existing documents can get out of sync and be hard to determine if an admin update was valid for both.
2. Updates need to be validated on updates (mitigate this with digests).
So... onto how this works.
The first thing is we need to determine what is needed for such a database.
1. Keys for encryption ( normal public / private pair works ).
2. Database or document revision ids ( document updates would change the entire database revision in the way described below ).
3. Data, a list of links for example.
So lets work on a simple example implementation. Our database will be held in a simple JSON representation and is meant to contain a list of strings.
Ok so the basic idea of using this structure is that the public key is freely available at any time to allow people to confirm the digest. The digest is used to test the data's validity and provide what the next revision will be using as an id in its digest. Finally the links are in nice plain text and can be confirmed against the digest (though the implication is the initial replication is from a trusted source).
When a user wants to view the list of links he would simple replicate the JSON down and read the "links" property.
When an admin wants to update the links, he would send out a new copy to his peers who would also update their peers. The process in doing so is merely to take the "next_id" property of the "digest" and use it when generating the "digest" for the next revision. This would give no exposure to the private key while maintaining validation between versions for users.
Should an admin wish to change the private key more information would need to be exchanged, since the old key was used to generate the encrypted "next_id" it, so you would need to do something like include "next_key" in the "digest". This becomes very important because after each update you only have until the "next_id" is cracked for your private key.
Anyways just wanted to post some thoughts, this is by no means a complete solution since it lacks revision reconciliation, but it is a decent start.