Hacker Newsnew | comments | show | ask | jobs | submit login

What I'd really like to see is a P2P, encrypted, bittorrent-based mail system, basically something that works similar to bitcoin, but used for sending encrypted mail instead.

No central servers, just a single blockchain recording all encrypted messages on the network and shared over a bittorrent network, and an easy-to-use client that doesn't make normal people think too hard.

Encrypt a message with your recipient's public key, submit it to the network, it's accepted into the blockchain, and they decrypt it on the other end with their private key when the msg propagates to their client. Private (at least until computing power catches up with the encryption algorithm), decentralized email without ads, popups, etc.

Give it a nice Apple-ish/fluent.io-ish/sparrow-ish interface, transparent encrypting and decrypting, and some way of optionally associating email addresses with public keys so normal users don't have deal with intimidating hashes (optional only though, still want the ability to send directly to more anonymous public keys).

While you'd still need some method of preventing block chain forking, you wouldn't have to worry as much about double spending and transaction verification since you don't care whether someone sends the same message multiple times to different recipients (as you do with bitcoin).

One of the biggest problems would be dealing with exponentially increasing blockchain size. Bitcoin already has this problem and its transactions consist only of relatively terse amounts of data. With full emails (and attachments?) you'd have to implement a method of cropping and perhaps archiving the blockchain, or otherwise solving that problem, or it will quickly become unweildy and destroy the user experience (esp for people with slow connections).

Perhaps clients store the blockchain a certain number of blocks back, and then beyond that they only store their own sent and received messages? Not sure...

The genius of bitcoin is that it is a solution to a difficult algorithmic problem in distributed systems [1] which can be repurposed for other implementations. It is already being repurposed for a distributed DNS [2] and distributed voting systems for elections [3], why not a distributed encrypted email system as well?

Just throwing this out there without really thinking it through thoroughly atm... Thoughts? Feasible? Probably the biggest problem is knowing that one day all your emails would essentially become public domain when hardware catches up...

1. http://en.wikipedia.org/wiki/Byzantine_fault_tolerance#Origi...

2. http://dot-bit.org/

3. ddg-fu failing me atm, will add this later.

When all you have is a hammer, everything looks like a distributed decision problem...

But seriously, this would not scale. Using a central block chain as you suggest means that every node in the system receives a copy of every email. It's also trivial to DOS - just send tons of multi-megabyte messages to nonexistent receivers. The messages hang around in the block chain forever and the entire system dies.

Email is not a decision problem (unlike bitcoin, or potentially a DNS replacement). It is a delivery problem, and is local in nature. There are no global decisions to be made, unlike in bitcoin - there's just a sender and a receiver, and they need to find each other to exchange the message. Once they do, nobody else needs to know about any of this.

When you view things in that light, SMTP is a reasonable protocol for the job. It just lacks sender authentication, hence the spam problem, and is cleartext-by-default. It also relies on the DNS protocol for endpoint location, and is a 7bit protocol (making attachments needlessly inefficient). All of these things can be fixed without any kind of radical change to the protocol; just tack on a DHT (keyed on recipient public key hash?) for endpoint location, mandate 8bit-cleanliness, authenticate the sender somehow (this is a HUGE problem and one your hash chain system also fails to address), and mandate encryption.

If you want to also mask IP addresses as well, just toss in a standard mixnet, such as tor or I2P. This gives you endpoint location for free, as well.

As for sender authentication, mandating message signatures is an easy first step, but authenticating the sender key is a hard problem (key management always is). You need to have some kind of vetting process or spammers will just mint millions of keys; but at the same time people like to receive messages from people they haven't exchanged keys with. This here is the fundamental problem with spam, and not one that any purely technical solution can fix.


Email per se doesn't have centralised servers. You can run your own. The only registration issues (DNS) are related to addressing (your server needs to be able to find the destination to send the email).

Your proposal basically sends all email to everyone (encrypted), which avoid the need for a DNS entry.

That model already exists, it's NNTP (a.k.a USENET). This basically sends an email (RFC822 body) to all participating servers in an efficient 'flood fill'. (A usenet post is almost identical to an email body).

So PGP+NNTP gives you the protocol side of what you want today.

The issue will be that "sending all email to everyone" probably won't scale, for NNTP or your system.


I really do not want my message metadata being recorded in a globally available distributed block chain forever.

Namecoin's .bit domains already support Tor. Throw in some S/MIME or PGP on the actual messages and you're mostly done I think.

Other than the sexy UI of course :)


You would lose interop with existing email infrastructure. the problem is that hosted email brings everything back to being too centralized (for eg. most of the email I send doesn't leave the google servers). Take a product that implements its own smtp server, nice PGP integration and a nice interface over it like the one in OP. users may be more likely to want something like that (I know I do - I can't wait to switch away from Gmail) rather than an entirely re-invented messaging system.


>You would lose interop with existing email infrastructure.

Yeah, when I mentioned the ability to associate email addresses with public keys, I wasn't very clear. I did't mean regular email addresses, but was actually thinking of bitmail-only email addresses. Perhaps ones based on Namecoin .bit domains.

But I wasn't suggesting interop with existing email infrastructure, this would be completely separate. In fact, the idea would be to disrupt and supplant the regular email we all know and love, at least for some use cases where privacy is paramount.

Everyone would have their bitmail client which they could use to send encrypted email, as well as their regular Gmail addresses and whatnot. Most people have multiple emails anyway, this would just be one more.

One nice thing about bitcoin, which would carry over to bitmail, is that despite the core technology (the official client) being completely outside and orthogonal to the current financial system, it's very easy to use for its fundamental purpose. Sending and receiving bitcoins is just simple. I envision the core bitmail client would work similarly and be similarly simple. No need for interop as long as there are specific optimal use cases for it (say, Arabs and others coordinating against oppressive regimes, stuff like that).


> You would lose interop with existing email infrastructure.

I think you could perhaps make it work with a bridging service between the networks?


Problem: instead of having to sniff my servers' connections, an attacker (say, a government) can just download the blockchain - which is easily accessible - to have a list of everyone who has sent me email and everyone I've sent email to.

Besides, what's the point of the blockchain there anyway? Why not just have a distributed naming system (like namecoin) for the addresses and then simply integrate an MTA with the client, allowing simple P2P between users?


Email is good enough for most people most of the time.


Good idea, but I personally don't want to have to download and process terabytes (petabytes?) of data every day in order to be able to read a few kilobytes of my own email.

Maybe in a few decades time when it's normal for people to have static IPv6 allocations and permanently online machines in their homes, it will be trivial for people to run their own mail systems using existing protocols.


Bitcoin wasn't designed with the multi-gigabyte sized mailboxes that marketing officers and managers seem to accumulate...


Distributed voting systems for elections? Tell me more!


There have been some threads about it on bitcointalk.org, but the site is down tonight for some reason. But this ddg search [1] turns up some hits:


1. http://duckduckgo.com/?q=bitcoin+based+voting+system


This is an amazing idea. I have been thinking how to do webmail + proper privacy for ages. By proper I mean it ought to completely cryptographically protect participants from any kind of orwellian search and seizure policy as well as just fix the inherent problems of plaintext storage in e-mail. I don't even think that hardware catching up to the main crypted spool is really an issue as we're well past the point where we can use encryption algorithms requiring computationally infeasible energy to decrypt by bruteforce, even granting absolutely unlimited compute resources.

The only problem I could see with this is one bitcoin will also eventually run into, but even moreso, which is scale. Average email size is going to be a lot larger than your average bitcoin transaction. That said there may be ways around it, perhaps using the usenet infrastructure as an underlying transport mechanism and piggybacking off that. It already has ridiculous amounts of data flowing through and being stored on it. Something to think on more, thanks for chiming in.


Yeah, the data size is a big problem, but the bitcoin dev team is working on a bitcoin-lite client to solve that problem. Their eventual solution might be repurposable for bitmail.

And here's another thought about that - just delete all messages from the blockchain after they're read, and only store them locally in the clients. As soon as the receiving client unencrypts the message, store it locally, then delete it completely from the blockchain. Unlike bitcoin, this wouldn't be an accounting ledger with the necessity of storing all transactions in perpetuum. All that needs to happen is the message get delivered to its recipient, once that is verified to have happened, it can be deleted. The clients can keep copies and organize them into conversations or whatever.

That wouldn't quite solve the issue of hardware eventually being able to brute force the encryption though, since an interested party could store a running record of everything put into and deleted from the blockchain. But it would have to be a very interested party to store that amount of data in the hopes of being able to decrypt it years or decades later.

Bitcoin wasn't really designed for deletions though, and that would also double the rate of blockchain diffs, so would have to think more about how or if that would work...


Size is unfortunately completely unimaginable....

A small marketing firm I happen to admin the email servers for... sends 15 million marketing emails per month (all opt-in, CAN-SPAM / Australian Spam Act compliant). This alone is nearly 1.5TB of data. We only send marketing campaigns for about 8 national brands and about the same number of regional brands to a country of twenty something million people.

Now It might be suitable for a conversation or private chat room. It would work really well in an IRC / small group situation. But I can't imagine a single global system ever scaling past a few dozen people without some significant hardware.

As far as deleting things, the problem there is who is responsible for deleting and what if I don't? The number of bounces we get from campaigns from defunct mail boxes that have filled to quota is quite high. Who removes this email that no one reads? At the moment the storage problem is isolated, but a central chain makes it impossible.

The more I think about this makes me think you might get it to work with a block chain per domain... but then whats the point over simply setting up your own email server you trust and using encryption?


Actually if you go with the concept of pointers to messages detailed here http://news.ycombinator.com/item?id=3615862 you enormously cut down on the size needed to store those messages (one message with a million recipients is just one message + a million recipients, not one million copies). Also with regards to deletion you could leverage the economics to pay for size, for example a user with a 1tb mailbox store will have to pay more mailcoins than a user with a 200kb mailbox store.


The pointers method is used by most commercial mail archival software that I've seen (the kind big companies deploy for SabOX compliance).

The problems with Pointers & de-dupe is that at least marketing emails are personalised, each are sent independently often with at least a minimum of personalisation, for example calling you by your name (people are more likely to read it if it calls them by name). You can do de-dupe, but your limited to the efficiency and overhead of your block size. Compression would also take the storage required down to ~ 1/10th (excluding attachments), but I don't think thats still enough. Even if deduping and pointers gave you a 500x storage saving, the data size for a few days email is still so unfathomable that it won't work as a single global system.

As far as trying to solve it with economics, its been tried (as a method to stop spam) but the question is who has to pay who and for what? Every such scheme has failed because you end up missing one of the big groups of users as it becomes un-economical for their mail pattern to continue. If you make the senders pay, few comercial entities want to play, and few people will provide free email. If you have to pay to store then how do you stop being billed for someone flooding you.


I think if we throw away the direct similarity between the blockchain as a transaction log vs a spoolchain as a massive collective megaspool and instead go with the concept of a spoolchain being a log of pointers to storage bins which are the actual distributed storage for a destination group, we get rid of most of the problems with storage size.

Eg. I am user@provider.com, I want a storage bin for this account. A storage bin could then be either someone who just has user@provider.com (say on a massive scale, the u shard for the provider.com domain) or someone who has the entire storage bin for provider.com, or someone who has the entire storage bin for .com

Couple this with open access to the storage bins from any and all (the more the better, the heavier replicated they are the easier / faster end users have access to their mail) and an economic incentive to participate in storage propagation (mailcoin? n mailcoins per n mb of storage, charge mailcoins for access to the storage bin, whatever model makes the most economic sense) and we might be onto something. It also handles deletion and allows users to "un-send" mail by deleting the mail from the storage bin it exists within. The blockchain in bitcoin does not allow for transaction deletion operations, but that does not by any means rule out the possibility of deleting the position in a storage bin where the spoolchain in mailcoin points to.


Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact