I've pondered p2p apps that are secure from traffic analysis, sniffing, and leaking metadata. Chat being the easiest. Chat is low bandwidth and tolerates latencies well, much more so than audio or video streaming.
Tor has a much harder job, it's trying to handle full TCP communications, low latency, variable packet sizes, efficiency (no fake traffic), and high bandwidth all compound to make it very challenging.
However you can make the challenge much simpler. First nix TCP, variable packet sizes, and low latency. Pick a packet size like 256 bytes, send packets every 300 ms, and use any spare traffic to maintain the health of a DHT.
Then clients would use the same onion approach, decide the number of hops, and encrypt for those hops like an onion.
So each node would receive messages, decrypt it, if it's a DHT update handle that, if they are the intended recipient decrypt, if it's a forward request decrypt it and queue it for sending on the next free 300ms boundary.
Suddenly it's much harder to track traffic through the network, even with perfect knowledge of each packet's source and destination. Timing attacks don't work because everyone sends 256 bytes ever 300ms. Using packet size to watch traffic go through relays doesn't work.
So much less useful than Tor, but also more resistant to traffic analysis, and plenty of bandwidth for chat.
Tor has a much harder job, it's trying to handle full TCP communications, low latency, variable packet sizes, efficiency (no fake traffic), and high bandwidth all compound to make it very challenging.
However you can make the challenge much simpler. First nix TCP, variable packet sizes, and low latency. Pick a packet size like 256 bytes, send packets every 300 ms, and use any spare traffic to maintain the health of a DHT.
Then clients would use the same onion approach, decide the number of hops, and encrypt for those hops like an onion.
So each node would receive messages, decrypt it, if it's a DHT update handle that, if they are the intended recipient decrypt, if it's a forward request decrypt it and queue it for sending on the next free 300ms boundary.
Suddenly it's much harder to track traffic through the network, even with perfect knowledge of each packet's source and destination. Timing attacks don't work because everyone sends 256 bytes ever 300ms. Using packet size to watch traffic go through relays doesn't work.
So much less useful than Tor, but also more resistant to traffic analysis, and plenty of bandwidth for chat.