Great post!
Yes it's all very generic, what makes my proposal reasonable (hopefully) is the combination of features. Once again, I want to build a secure messaging analogous to email with all its features but without any centralization and asymmetric encryption ingrained in the system.
1. You have to exchange keys with current PGP setup. Also you need to have SMTP and POP servers to actually process your messages. If they want to mess with your messages they can.
The proposal is to use public keys as receiver addresses, so no keys should be exchanged. And build a strict peer-to-peer system.
2. The problem with storage can be solved more or less as it's sometimes done with Bittorent private trackers - if you wanna use the system you have to give back, that is you have to store messages too. People store tones of multimedia files at their home PC's, probably storing 100 mb 1 GB of data is all right. Bitcoin block chain is 6 GB now.
Another way to approach this is the nodes who store the data for a fee, this also would be a way to monetize the system. For example heavy users would be required to pay a fee through bitcoin which will be redistributed between storing nodes.
3. The way to approach the spam problem would be PoW, analogous to the way its made in Bitmessage. Also a peer would be allowed to block messages from certain nodes. in this case the messages will be dropped from the system
4. This is more like crypto twitter. Actually the spam problem won't be so drastic here since you need to know the public key of the node if you want to subscribe to its messaging stream, it can't message you directly.
5. Appropriate DHT setup is able to solve the problems of peers going offline, as it is proven in practice by various P2P systems. As for central servers - I believe that complete decentralization is the way to go, Internet is inherently decentralized system which certain parties always try to centralize.
There have to be countermeasures to this. Just imagine a sheer amount of private information any webmail provider has access to. I'm not sure that this is the ideal setup of human communication, when a third-party always has access to anything it wants. It creates a new hierarchy, which actually is not necessary, all communication CAN be peer-to-peer indeed.
Freenet is cool but it's more file sharing application. Also there won't be an explicit blockchain here, everything can be done through correct DHT setup.
once again thank you for very insightful comments!
While such a combination of features would be useful, I just think that they may be impractical together.
1. I'm not sure what you mean here, if a server alters an encrypted message it (should be, depending on the encryption scheme) is rendered unreadable. It's possible to cause the message to be unreceivable, but not to alter a message after encryption during transit. If you mean MITM because of poor key exchange, then that's a fundamental problem with key distribution not PGP in particular. The same problem (having to make sure key exchange is secure) would exist in any scheme.
2. Bittorrent users derive direct benefit from storing and sharing material. On public trackers you have the perpetuated availability of material the peer wanted in the first place. On a private tracker it maintains ration in addition to the previous. While there is also altruism (which would be all I can see this relying on), it's not infinite, and given only 100mb (or any finite quantity) per peer you will still eventually run out of space. The blockchain is useful to anyone who stores it because that's how you prove what has happened and already there a large number of "light" nodes that only store the block hashes and verify things separately as needed and don't store many blocks at all as well as several implementations (including the satoshi client) that are looking to prune the spent tx data to reduce the storage requirement (pruned data would be ~120 MB right now if memory serves). For larger file storage clients like Freenet (while file storage you can just think of files as binary messages (see: Usenet file sharing)) the incentive is that you store some extra data so others will save your extra data, though no strict parity is enforced and there is a certain reliance on altruism (and for this reason I don't think this sort of project is anywhere close to impossible, just harder). Since I brought up Usenet, there are basically superpeers that act as peers with each other and central servers for end users; end users normally pay for large data storage provided by central servers.
3. PoW does help, but the higher you make it the harder (relatively) it is for a normal user to send a message, the lower you set the bar the easier it is to spam. So while there is a tradeoff but it's definitely a solid place to start; allowing a user to establish how hard it is to send them messages might work. Rejecting messages from a node may be somewhat meaningless, you want to allow new users to be able to participate reasonably quickly and there's no way to select between a new user and a new identity for a malicious node. In addition to all that routing messages through the p2p portion means the physical source node might not be important, the identity of the sending node is all you can conserve on a practical level.
4. I was thinking this was along the lines of a PM system with optional twitter-like broadcasts, but if it's twitter and includes direct messaging a few things shift priority, but overall allowing any messaging TO an identity opens up all the same problems if it's the most common behaviour or not. Sounds kind of like most of the forums on Freenet though, everyone publishes their board posts to their personal broadcast stream and based on your direct trust level or indirect trust through WoT you choose whether or not to download their messages. The expensive part of creating a new identity is bootstrapping yourself into the network and announcing your presence so other people begin to download your messages to begin with. If you wanted to apply a similar mechanic at all you could start with a heavy PoW problem to announce your identity to other peers.
5. I'm used to seeing DHT as a lookup method, but you can easily tie that to looking up where to find/who to ask about a certain message certainly. I'd say the central servers archetype evolved before p2p was necessary or practical; if you wanted to share something you hosted it, if you wanted mail you sent it to the mail server (similar to the post office I suppose) and it was also easier to manage and there was no reason for it to go away. A lot of hosted platforms (especially closed source hosted sites like google, centralized mining pools, or anything requiring any central authority or a protected/hidden database to run) are either easier or only possible inside a centralized environment. Some things can be moved easily to a decentralized setup (file sharing from FTP to Bittorrent, central mining pools to P2Pool, etc) and some things are harder to move over (Anything abusable, anything that requires strong input checking, required hidden or protected databases). I'd also say that part of the reason webmail providers have so much information they don't need to have access to is that it's easier and established. There's no established default email or text encryption standard for transmission and the default is plaintext. If you could switch everything to encrypted transmission by default the webmail providers wouldn't have anything to begin with (other than sender/receiver and timing, which is also what the NSA was collecting on phone calls and is still powerful information and not eliminated in a p2p setup) but it's harder for end users, grandma doesn't care about PGP and grandma couldn't use PGP and wouldn't be able to use email if it were the default and the only option for her would likely be a webmail provider either receiving plaintext or decrypting it for her server side which means they have the contents anyway (you could do it client side, but then grandma has to carry her private key around and she can't do that either, also it's easier server side).
All told you've definitely addressed a lot of things, I'm having to insert a fair amount of qualifiers to things now, and a lot of problems can be considered corner cases (that I'd still personally like to see addressed in an active implementation, now is too soon for some of them before larger details are finalized). The biggest problem I still have is storage, I'm not sure the balance between indefinite holding and total potential storage is there yet, at some point it just runs out. Though I don't know that a two day window is enough for everyone either :-) If nothing else I can keep playing devil's advocate at least if you want to try to flesh things out more.
