The TeleHash equation
That sounds simple & brilliant, yet too simple for many applications. This equation is neither considering protection of the social graph (onion routing is missing and the currently popular Tor solution doesn't work with UDP) and, what's even harder to solve, the scalability, that large scale social applications need.
Telehash doesn't provide distribution trees, so it only works as well as round-robin transmission works, which can be okay if it were just UDP in an F2F style, but this cuts out social transaction data protection. Or you try to fix that, but then you can no longer use "just" UDP and a round-robin approach. You need to use something like Tor which is a lot heavier than just UDP and will not scale for the one-to-many distribution use case, let alone many-to-many.
Also, the single parts of the equation could be improved. GNUnet's GNS could be used instead of a regular DHT, so you get to have query anonymity, reasonable consistency, a censorship resistance strategy and more. A generic lower layer transport system that runs well over all sorts of NAT and mesh, even bluetooth, could make sense rather than just UDP. A more efficient syntax than JSON, like for example PSYC.
The original planning for TeleHash didn't include any encryption at all, so that was very simple. Now that encryption does need to be wrapped around the UDP packets and a public key infrastructure does need to be deployed, the question of cryptographic discovery comes up, just like for any other of the crypto and darknet platforms.
Maybe it's better to go for a platform that was designed with all of these aspects in mind from the start. There is a reason why so-called darknet platforms, or we could call them public-key-based routing systems according to #youbroketheinternet, are not so simple. TeleHash shouldn't be too simple to actually serve a job for privacy, either.
See also
- http://www.telehash.org
- the protocol syntax benchmark