Unfortunately the documentation for the federated social projects I'm aware of is always severely lacking (believe me, my own included). It makes some key points very difficult to understand. With that caveat aside, this is what I think I understand about the general system architecture of Diaspora, Hubzilla, and Tent:
* Everyone runs their own server. Data on the server is plaintext at rest, but encrypted in transit.
* The protocol (only text-based?) governs communications between servers. It describes the kind of things you would expect social websites to need to do: make comments, have profiles, etc. Examples of protocol outputs: Tent, Hubzilla, Diaspora
* Internally, the servers deal with privacy, sharing, etc. Your personal server and their code together determine what data is acquired, stored, shared, etc.
If this mischaracterizes any of the above protocols, I would be really grateful for corrections. It's to everyone's benefit to understand the high-level technical details of these projects. However, the system architecture described above is not, in my mind, a tenable approach to distributable social applications. Simply put, this kind of "private server as my digital avatar" + "protocol so avatars can talk" paradigm completely misses the appropriate choice of abstractions and division of concerns for social applications.
First and foremost, this is still yet another example of "privacy by promise". It just so happens that the promise is given to you by the servers of whomever you're sharing with. But then, as data is decrypted at rest, you must also trust their coding ability, their deployment ability, their... this gets very messy, very quickly. The security footprint for implementing these protocols is immense.
Secondly, this approach focuses on one specific use case: websites. The vast majority of publicly-networked applications will, at some point, have a need to perform identity, sharing, or content management. However, they may not necessarily have anything to do with text: for example, a distributed sensor network might communicate only using binary messages, but that doesn't make it any less social. Since bytes are the more basic unit, any general-purpose social protocol should therefore support them natively.
A much more robust approach is to address the "social protocol" at a much lower level: to provide only the bare minimum that any social application will need, giving transport-layer bytestreams cryptographically-enforced privacy with many-to-many capability. Only then can you escape requiring everyone to operate their own web service, which is, I firmly believe, an unrealistic goal.