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.
Yes, exactly, I mean key exchange problem. If you use a public key as a messaging address then you don't have to exchange anything.
I'm not sure that fixes anything, you still have to get the address somehow. If the service giving you the address is compromised or malicious it could just give you an address/key it controls and forward the mail through using another address of its own as the reply-to address and intercept communication both ways. Alice -> Eve as Bob -> rewrite reply address to Eve as Alice -> Send to Bob. Return works the same way but switching the addresses back again. Eve still comprises all the back and forth through MITM. Generating enough addresses on the fly gets a little harder if creating a new identity is expensive (cost or computation), but would probably still be possible.
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.
Yes, there are two ways to solve this, actually I don't quite disagree with you here - either you make users contribute in order to use the system,
or you make them pay supernodes. Supernode would be a usual peer with unusual storage capacity, but no other additional features. Also these solutions can be combined.
Two ways is probably a minimum, there's always plenty of ways to work it out. I'd argue that supernodes at any point does or can lead to centralization and all the things you're looking to avoid by making it decentralized. So of those two solutions just relying on donated resources might be required. Implicit supernodes that are just well connected with lots of space and bandwidth might pop up, but are a nice possibility not a requirement of the protocol.
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.
Once again, I mostly agree. Actually it's a subtle trade off between system usability and spam protection. Let's take bitmessage - you need 4 minutes to send the message. Looks like it's fine, but it actually is not - from a large botnet you can send millions of messages a day still. So probably the solution would be combining PoW with ability to reject messages from certain nodes. Also a node should have the ability to receive messages only from trusted notes if it wishes so.
I'm not sure how much filtering would be possible using a DHT/broadcast/everything public system. The source node not being connected when the message is eventually retrieved is nearly a protocol requirement I would think. Storing spam forever is also a PITA because people who aren't receiving it can't spam check or do anything to figure out if anyone wants the mail. Someone sending mail back and forth to themselves could theoretically DoS the network, or at least take up a lot of space. You can control who you connect to, but in a practical sense someone has to be willing to connect to new peers and most people will eventually be connected through some series of nodes to every other peer, friendly or not.
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.
Yes, I'm thinking mostly about twitter-like system for now. That is you announce your address and interesting parties subscribe to it. So this is the messaging FROM identity so to say. General network-wide announcements to all peers are too prone to spamming I fear.
I do think that's a more manageable system overall, everyone polls for messages of users they care about. Messages are signed for public messages or encrypted to the receiver and then signed (all the headers on the inside, source may still be leaked/public possibly) for private messages. Doesn't work like any traditional system I'm familiar with, but there's no central server so it works. Does sound pretty similar to FMS on Freenet though, could be a good reference.
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).
Yes, it would be cool if everyone used PGP, but it exists since decades and didn't really pick up with mainstream audience. Also key exchange problem still exists here. Also central servers make things easier techically that's for sure. Probably you'll never be able to approach features which
central architechure can bring, like fast access to huge mediafiles and such. But we can try to make it as usable as possible, and the benefits are obvious - you do not allow everyone and his dog to eavesdrop on you. I'm not a privacy freak, actually don't care much for privacy per se,
this is the question of society structure and equal access to information.
Also DHT setups can be very different, basically you can achieve very much with DHT, this approach has already been tested practically, and it sure
works.
It's usually a tradeoff between easy and private. No one writes down notes and encrypts them in public because it's a pain, you just talk, the best you can do is whisper or go somewhere more private.
Files, including video, audio, etc, can all be represented in printable characters across text messaging systems, and give it ten minutes of existence and I'm sure someone will be transferring files and they'll slowly get as big as people care to send. yEnc on usenet, base64 more generally. Binary data is still just data.
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.
Your input is very insightful, I would be glad if you could continue providing it! As for the storage - intuitively I feel that it's doable, storage is cheap and gets even cheaper now. Also, a feature when a sender wants to drop its messages from the network after ceratain time would also help to reduce the load. If you want to store the messages indefinitely - you can do it by default, if not - choose for how long they should be stored after the receiver has read it.
Storage is cheap by some metrics, a large company can have exabytes (Megaupload, Google, Facebook, etc), but the home user can and will fill up his harddrive and want space eventually, or may only care to dedicate so much of it. Add to that junk mail, large file transfer, data redundancy, and all the rest and eventually it will run out. Even if it's not in the plans, assume any corner case will happen and have some plan for it. The problem with opt-in deletion (sender or receiver explicitly deleting things) is that if they forget to or lose they keys to do so then it's stuck there. Theoretically the receiver could delete it once received or the sender could put a destroy-at timestamp, though I don't think you could do it based on time read; you don't really want to let the public know when a message is read, I don't at least. Being able to re-send a message into the swarm (as the sender, or receiver even) isn't too difficult I'd imagine, just keep passing around the block of data containing the message. I would certainly be highly in favor of some mechanism that eventually expires data being included from the beginning, even if there's no expectation to use it.
