I'll agree with most of those but the re: the last point I'll throw out a half-hearted nay-say and reply with "sort of". The guys at keybase.io is trying real h

I'll agree with most of those but the re: the last point I'll throw out a half-hearted nay-say and reply with "sort of". The guys at keybase.io is trying real hard to let "Johnny have crypto" + https://www.mailpile.is/ https://www.mailpile.is/ makes it pretty easy for a Mac user to enable GPG and Gmail. My concern is primarily user-adoption - i.e., Johnny doesn't know why he needs crypto, even after Snowden. The NSA et al are counting on that apathetic attitude to make their jobs easier. Out of the box Mailpile is a easy stop-gap solution while more appropriate ones come out. You're totally right re: DHT and cryptohashes for identification being a fairly ideal solution. PeerJS/WebRTC (part of HTML5 -- supported by Chrome and Firefox) support NAT-busting and are fairly secure. I'm slowly piecing together a comm-project addressing the larger issue because I'm tired of being complacent, with the intention of funding it eventually off of Exchange add-ins dual-licensed as open as I can while ensuring organizations above the size of 250 employees have to pay licensing fees. That being said, what protocol isn't over-complex which has worked out well? Either you have things like SMTP which are just spec'd out by one or two dudes and submitted as an RFC where tons of stones were left unturned (leaving such a mess w/r/t maildir vs mbox not to mention the whole end-user problem of authentication, if you remember the sysadmin hell of trying to configure pop-before-smtp and a bunch of other problems during the late 90s, my god, it was horrid) -- or you have an over-spec Java2EE situation where everything is over-specified to an insane degree that implementations take teams and teams to get full compliance. I ask this sincerely, with no snark - what protocol should one build crypto into?