The Ostatus protocol solves the following problem:
- An update may be represented with plain text in UTF-8 encoding.
- An update may be represented with HTML.
- An update may include one or more attached files.
- An update may be a response to another update.
- An update can be a forwarded or shared copy of another update. ("repeat", "retweet").
- An update can be about a topic.
- An update can be directed to the attention of a particular recipient. ("mention").
- An update can be related to a location on Earth.
- Anyone can mark an update as a "favorite", or remove that mark.
- Users have a unique identity.
- Users have profile information like name, location, nickname or username, bio, related URLs.
- Users can be represented with a image ("avatar").
- Subscriber can receive Publisher's updates very soon after publication. ("Real time", "near real time")
- Publisher server can store a list of all Subscribers for a given Publisher, including identities and profile data.
- Subscriber server can store a list of all Publishers for a given Subscriber, including identities and profile data.
- Publisher server can store a list of all responses to an update by a publisher.
- Publisher server can store a list of all forwarded copies of an update by a publisher.
- Publisher server can store a list of all "favorites" of an update by a Publisher.
- Servers can determine update context and metadata without parsing the plain text according to a particular syntax.
- Subscribers can subscribe to a feed with multiple authors, such as a group, a search feed, or a tag feed.
This is from the current (10/2012) Ostatus draft. The problem of a social network protocol is hereby dived into two parts. There have to be (publisher) servers which store the content users provide, and there have to be subcribers server which gather the content from the distributed sources into one view for other users.
The first ting that is needed to solve the problem is a ontology/schema/language with which the servers can describe each other what happend. This language is activitystreams (http://activitystrea.ms/). Its describes the content produces by one or multiple users as a flow of activity objects. So the complete data set of the social net is simple one stream of stuff like: "Alice posted lalala, Bob liked Alices post, ..." The language covers a wide variety of things that can happen on social networks, like comments, events, locations, ratings, mood, ...
Because the social net is distributed, this data is distributed, too. Every server (subscriber and publisher) stores some overlapping fragment of the data. This isn't a problem because the streams are mergable as long as the identities are unique. For this reason webfinger (http://code.google.com/p/webfinger/) is also part of the ostatus protocol. This protocol states that your username in the distributed net allways has and @ and then the domainname of the publisher server at the end. So now the stream reads: "email@example.com posted lalala, firstname.lastname@example.org liked the post of email@example.com"
The idea is that the primary source of the content is the publisher server of the author. If I want to know what alice shared, I go to alices server. But theres is a problem. How should i then know that bob liked alices post if i dont go to bobs server and ask? For that there is the salmon protocol, which lets bobs server deliver the "bob liked alices post" object of the activity stream in a secure way, so that alices server can be sure that it really was bobs intention to like the post. So with the salmon protocol reactions to posts, like comments and likes can propagate "upstream" to the original source. (There fore the name: salmon swim upstream.)
That last important part of the ostatus protocol is Pusubhubub (PuSH) (https://code.google.com/p/pubsubhubbub/) which is simply push for RSS/atom-feeds. So the servers do not allways have to ask wheter there is something new, but they get notified if something happens at the other servers.
One issue that is not yet tackled is privacy, no to confuse with security of identity. Currently the protocol does not describe how to restrict access to content. Currently subscribes don't need any identity. A good candidate for restricting access to web resources is Oauth (http://en.wikipedia.org/wiki/OAuth), which can be combined with PuSH and webfinger. So everytime you subrcibe to some content, the publisher server looks up your Oauth provider through webfinger and triggers the Oauth protocol to probe your identity. If Oauth is completed successfully the subscription gets activated. So now youre publisher server delivers certain content only to those that you whitelisted beforehand, by adding their webfingers to their recipients.
The second issue that is not tackled in Ostatus is hosting of media data. If you want to share a photo in Ostatus you simply share the link to the photo. The problem then again is access restriction. So in the current model you would have an additional media server, like the twitter photo services, where you upload you photo and get a link which you then share. If you want to restrict access to that photo you would have to pair the media server and the publishing server again. Again webfinger and Oauth are good for the job, but the details have to be standardizes.
Ostatus allready covers a fair amount of the functionalitly of a distributed social network, and is extendable to completeness. Because of the splitting of the network in publisher and subscriber, which can but must not be the same, it also provides a full featured API, with which clients (web, desktop or mobile) can be built that are compatible with every Ostatus publisher server. However building on top of that API is much harder than building for Twitter and Facebook. Libraries for PuSH and salmon are not readily available. Writing such a client right now is hard work.
Another chock block are the userbase, which is quite low at the moment. There are a lot of people scattered over several distributed social networks, unable to talk to each other because their developers all had to invent the weel by their own. (http://en.wikipedia.org/wiki/Distributed_social_network) Now they have accumulated truckloads of legacy code, which kind of works, but is not flexible enough to adopt Ostatus easily. Right now they don't have the manpower to make this change. Also the adaption of Ostatus would mean that functionalities get lost, so they are afraid that they may loose some of their userbase on the way.
I can only hope that more developers start using Ostatus for their projects and build libraries and documentation to push the protocol.