There was a discussion on slack about how Radiks’ mongo db storage could be replaced by a p2p storage. @jorishermans provided a pull request to include OrbitDB.
@jude gave a detailed answer to my question: “Is it that the problem is not well understood and solved or that the projects are not yet ready?” I wanted to save his answer here:
The problem is that all of these projects use a distributed hash table (DHT) for routing requests. DHTs are notoriously unreliable, have poor performance, and are easy to attack. They should not be used in open-membership p2p systems (which all of these are), since it only takes a single malicious node to do things like:
- split the network
- execute targeted censorship attacks (i.e. attack specific key/value pairs while leaving the rest of the system alone)
- force look-ups to pass through attacker-controlled networks (i.e. to de-anonymize users)
The problems with DHTs are well-understood and well-documented in academic p2p literature (my favorites papers on the subject are , , and ). The problem with the projects that use them is that the core developers usually fall into one of the following stances:
- They themselves do not understand how easy it is to break DHTs (this includes Ethereum, the subject of  no less)
- They think it’s acceptable to ship a project that uses a DHT by default as long as a less-desirable alternative is available (this is IPFS’s stance – they unironically tell people to use DNS if you don’t like the DHT)
- They learned too late that DHTs are problematic, and are actively trying to stop using them (this is DAT’s stance)
When investigating a newly-discovered p2p project, one of the first things I look at is how the system handles request routing, since in my experience the design of the request-routing system is a good indicator of how well-designed the whole system is. Sadly, almost all p2p projects these days use a DHT of some kind for this (usually Kademlia). As such, I usually don’t have many good things to say about most p2p systems out there – reliance on an open-membership DHT for core functionality is a deal-breaker for me.
Furthermore, there are lots of papers that try to make open-membership DHTs robust against certain kinds of attacks, but the countermeasures they document are usually very limited in scope and/or easy to circumvent with a small amount of additional effort over the usual attacks against naive DHTs.