I&#x27;ll agree with most of those but the re: the last point I&#x27;ll throw out a half-hearted nay-say and reply with &quot;sort of&quot;. The guys at keybase.io is trying real hard to let &quot;Johnny have crypto&quot; + <a href="https:&#x2F;&#x2F;www.mailpile.is&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.mailpile.is&#x2F;</a> makes it pretty easy for a Mac user to enable GPG and Gmail. My concern is primarily user-adoption - i.e., Johnny doesn&#x27;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.<p>You&#x27;re totally right re: DHT and cryptohashes for identification being a fairly ideal solution. PeerJS&#x2F;WebRTC (part of HTML5 -- supported by Chrome and Firefox) support NAT-busting and are fairly secure. I&#x27;m slowly piecing together a comm-project addressing the larger issue because I&#x27;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.<p>That being said, what protocol isn&#x27;t over-complex which has worked out well? Either you have things like SMTP which are just spec&#x27;d out by one or two dudes and submitted as an RFC where tons of stones were left unturned (leaving such a mess w&#x2F;r&#x2F;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.<p>I ask this sincerely, with no snark - what protocol should one build crypto into?