Hi, I’m one of the architects of the Tent protocol.
Our primary goal is to build a generic, extensible framework for data storage and communication that is developer friendly. This protocol encompasses both server to server communication, as well as app to server communication.
Here are some of the requirements we started with:
- All features must work if every entity is on a different server.
- Developers must be able to create new content types without modifying the protocol or servers, and they should be able to adopt these new content types organically.
- Data and relationships must be portable. This means the protocol must handle changing identifiers and data export/import.
- Users need comprehensive, granular privacy controls.
- Data should be pushed between servers, not polled.
- If a server is down, all content that was previously sent by that server should be cached.
- Content must be easily linked and referenced.
- Reposts of content are references, not copies.
- Users must be able to use many applications with a single server, and applications do not act as servers.
- Apps should only talk to a user’s server, the server is responsible for talking to other servers.
- Server to server, and application to server communication must be encrypted.
What we ended up with is a protocol built on HTTP, TLS, and JSON and based around the concept of posts.
A post has metadata, JSON content, and optional binary attachments. The metadata includes a post type, timestamps, permissions, and version information. Each post has one or more versions. These versions build a graph of modifications, similar to how git and other distributed version control systems work.
Apps create posts on the server, and then the server handles sending these posts out to other entities and apps via webhooks (and in future versions, a streaming connection).
Servers render feeds of posts to apps based on query parameters that allow filtering based on metadata such as the post type, publishing entity, etc.
We evaluated just about every related protocol and specification when designing Tent, and chose building blocks that did not limit our goals.
We did not use OStatus because it did not meet our requirements. OStatus is designed for microblogging, not generic content storage and communication. It also does not support private posts, and does not specify an application API. In short, it doesn’t really meet any of our design goals.
We also evaluated other existing prototype federation and decentralized social networking systems, but found that their designs were limited to specific interactions common to “social media” and did not meet our requirements.
As we’ve mentioned previously, Diaspora would make a great Tent app. It has a usable UI for rich social communication, and shouldn’t need to be responsible for robust federation, which is solved by Tent. Diaspora would be a Tent app, and relies on a user’s Tent server for reliable federation and data storage.