IMO the Tent design is going to become obsolete with the arrival of WebRTC. With WebRTC, there is not going to be any reason to have servers running, as long as some of your friends are online. You can do everything by using public key cryptography and store-and-forward. You can authenticate with SRP/zero-knowledge password proofs. You don't need to have your private key with you, you can recover it from a quorum of your friends. Combine this with a public status/"who's online" server - could be any XMPP/web gateway for example - for bootstrapping the initial connection, and you can log in from any library/internet cafe computer. You can use broadcast encryption to address the privacy concerns of store-and-forward designs.
Why would you try to implement this with WebRTC? WebRTC is for real time communication. It's in the name. Social networks don't have to be real time. How would you do persistence in a WebRTC-run social network? E.g. how can I visit your profile when you're offline?
WebRTC is about direct peer-to-peer connections between web browsers. The real-time stuff refers to the video/audio codecs that come as part of the spec.
Persistence is handled by storing-and-forwarding your profile information to your friends. Privacy is ensured by broadcast encryption. If you want people unconnected to your network to find you, you could publish public profile information on a directory server (this could also be the status server that's needed for bootstrapping a connection if you're logging in from a public computer at the library or wherever).
I feel so behind when reading comments like this, so behind that this could have been a sarcastic parody and I wouldn't even notice. Is there anyone who understood this comment fully? is this something any developer should know? I'm fighting the urge to Google every term (or read the blog) but I'll probably won't understand much of it. Can anyone translate this to plain English?
Understanding what modern cryptography techniques can do is worthwhile for every developer, because it enables entirely different kinds of system architectures. A good example is the Tahoe-LAFS distributed filesystem: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/FAQ
I included links to definitions and further information about all the terms used in that series of blog posts. I'm definitely not an expert on cryptography but I'll be happy to try to answer any questions.
P2P (especially the cypherpunk wet dream that you're talking about) is at least 10x more complex than S2S architectures like Tent, which themselves are more complex than client-server aka Web 2.0. Also, server hosting has known business models while cypherpunks don't.
The proposal I put forward is far simpler than the kind of engineering that goes into making Facebook work. You're confusing novelty with complexity.
There's nothing complex about taking some data, encrypting it, and sending it to another computer. P2P/F2F public-key cryptography networks have been around for about a decade (see Justin Frankel's WASTE http://waste.sourceforge.net/). Putting this together with some advancements into an unhosted browser app is not a huge leap. The problem isn't going to be the technical complexity, it is going to be the UI and slow upload speeds.
The business model for this kind of network is going to be the same as the business model for BitTorrent - advertising on public directory web sites.
If you don't care about the web browser, there is absolutely no need for WebRTC and everything is much simpler. Justin Frankel's WASTE (http://waste.sourceforge.net/) did everything you could want in a P2P social network (messaging, chat, file sharing) in 2003 (it obviously lacked a Facebook-like front end). The only thing it didn't have that my proposal does is broadcast encryption for "unfriending" people.
WebRTC is cool because it will be in web browsers everywhere, and you'll have the "log in from the library computer" ability even for P2P networks, as long as there is a status web server you can bootstrap off of.
It seemed more like a chat client than something I could run any application over. It was more an application for doing certain defined things accessible in menus (the ones you mentioned) instead of being a generic means to create peer-to-peer networks.
If you want to do a different application, you can always take the WASTE code and do something else with it. Freenet is about as generic as P2P gets because it only handles storage. WebRTC should actually be a pretty good way to make P2P networks because you get a channel for sending data, doing realtime chat, audio/video codecs, all the HTML5 stuff for the UI, and JavaScript as a scripting language. As far as protocols and data standards go, I think the only reasonable thing is a protocol for status info, public key exchange, authentication, and listing the application protocols a peer supports. Everything else is too application-dependent.
As far as data standards go, I like Ethernet. I guess we all have our own preferences on how to do peer-to-peer. That's just the one I like the most. As for protocols and exchanging public keys, how about face-to-face or by postal letter? It's just a blob of text. Again, if the social networks involve only friends and family, why do we need to do everything over the public web? Does everything have to be complicated?
For networks with strangers, it's an entirely different ballgame. I have little interest in that can of worms. Way too complicated. That's for the geniuses who can create stuff like Freenet.
I guess I could look at the WASTE code, but I doubt I would find it simpler than the approach I've settled on. As I say, we all have our preferences. I like things very simple.
I wrote a series of blog posts about how such a system would work: http://carcaddar.blogspot.ca/search/label/ClearSky