On Wed, Dec 25, 2013 at 7:21 PM, Matthew Kaufman <matthew@matthew.at> wrote:

So there's already a system that until very recently did peer-to-peer delivery of messages over encrypted channels between hosts that participated in a peer-to-peer overlay. It was Skype.

Afaik, skype used a central lookup to get to unknown peers, not a DHT. So they perhaps knew who wanted to talk to who. Of course now skype is untrusted by anyone with a clue.

And none of these proposed solutions are viable until there's a solve for the very reason that Skype is moving away from P2P technology... and that is that the majority of the billions of new users joining the Internet over the next few years are doing so with the only Internet-accessing device they have: a mobile phone. When they're on WiFi, the bandwidth is good, but they sleep most of the time even in that case to preserve their otherwise meager battery life... and when they're on 3G/4G, the bandwidth isn't as good and it can be very expensive, and it burns the battery up even faster.

Sure, there's a class of users that want this, a big class. They can have and use their modified legacy centralized email as they wish. There's another big class that want's something more than that. We're also going to see faster hardware, lighter code, and maybe even wearable battery packs... because as you say, these users want it all and are willing to go to almost any means to get it. There could also be ways to make the heavier weight anonymous routing p2p transport let these lightweight clients stub in just to make a direct p2p connection for encrypted voip/messaging (if say you published your node as accepting that option).

These users want to be able to send and receive messages when their device is on, but the recipient's device isn't. Because most of the time, the recipient's device, even if they put it in their pocket 10 seconds ago, is already asleep, trying to preserve as much battery as possible.

That pretty much eliminates all designs that do direct transfer from sender to receiver, irrespective of the traffic analysis risks of doing so.

Additionally, it also means that nearly all the participant nodes are also unable to participate in a peer-to-peer overlay network, because they can't afford the network uptime (and consequent battery drain) necessary.

We're exploring ideas. What is to say we are able to develop into it some kind of automaton taho-lafs delivery storage nodes. Storing messages in transit under some expiry policy is not a huge space concern. So who knows. Maybe everyone with their uber important phones will end up VPN to their home/colo servers where the horsepower is. Predicting mobile is hard. Throw more apps out there and your $30-50/mo unlimited data plans go away. Now is everyone going to pay $150+/mo for that? Where is free open wifi going to end up spanning? And so many other things. What I think is clear is that there will for the far to indefinite forseeable future be some form of real workstation/laptop in the home and office. Phones just can't replace that. Maybe we're seeing something in how you see larger tablet/netbooks/laptops with headsets being carried about now as if it is natural. And lots of those people will want a highly secure system to communicate over with their peers in this new world of disgustingly gratuitous surveillance and databasing. I would not underestimate the demand for that sort of a comms system.

So we're back to fetching the email off of servers, and just having the paths between the servers be over this magical new peer-to-peer network. Only that's already approximately what we have now.

That could be the multimodal thing above. Or the in network thing.

Oh, and those servers can do interesting things you can't do at the receiver nearly so well, like correlate likely spam between recipients and drop it... or detect viruses before they're delivered, and drop those.

DSPAM, spamassassin, clamav and the like do fairly well enough on their own locally. I suggest not cataloging a defeatist list of what you think you can't do... but rather what you could do, what you would gain and what could happen if you build it :)

ps. And then there's the other unsolved problem: If you do actually build a popular service that lets people securely exchange messages, the government comes with an order to reveal the content of the messages, and threats to lock up the principals if those demands aren't met. I wish I could tell you more stories about this, but of course I'm subject to the same sorts of non-disclosure that everyone else who's ever gotten one of those is.

That's why you should be doing the development of these new protocols entirely within existing secure networks such as Tor and I2P. And why you should bootstrap via peers instead of clearnet authorities like Tor that can be shutdown... it's a little less secure, but you can have in network authorities wrapped in web of trust and then rejoin listening only to them later. And if clearnet get''s that bad, it becomes a freedom of speech issue which is well, SHTF time.