OStatus lets people on different social networks follow each other. It applies a group of related protocols (PubSubHubbub, ActivityStreams, Salmon, Portable Contacts, and Webfinger) to this problem in what we believe is a simple and obvious way.
OStatus is a minimal specification for distributed status updates or microblogging. Many social applications can be modelled with status updates, however. Practically any software that generates RSS or Atom feeds could be OStatus-enabled. Travel networks, event invitation systems, wikis, photo-sharing systems, social news sites, social music sites, podcasting servers, blogs, version control systems, and general purpose social networks would all be candidates for OStatus use.
The authors recognize that most of this protocol suite was intended to work together in a natural way. They claim no originality or creativity in connecting their use. The authors hope that the obviousness of some parts of this specification are an argument in favor of its use.
2. Notation and Conventions
5. Out of scope
6. Update representation
7. User representation
8. Feed representation
9. Update publication
10. User notification
12. Usage scenarios
12.1. Subscription from Subscriber server
12.2. Subscription from Publisher server
§ Authors' Addresses
As of 30 August 2010, the following persons or entities have made this Specification available under the Open Web Foundation Agreement Version 0.9, which is available at http://openwebfoundation.org/legal/agreement/
You can review the signed copies of the Open Web Foundation Agreement Version 0.9 for this Specification at http://ostatus.org/owfa/, which may also include additional parties to those listed above.
Your use of this Specification may be subject to other third party rights. THIS SPECIFICATION IS PROVIDED “AS IS.” The contributors expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the Specification. The entire risk as to implementing or otherwise using the Specification is assumed by the Specification implementer and user. IN NO EVENT WILL ANY PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS SPECIFICATION OR ITS GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
XML namespace prefixes used in this document:
- A person or organization, or a program that mimics a person or organization ("bot").
- A set of users.
- Notification of a change in a user's status or an action taken by a user. Updates can be automatically generated by software or composed by the user.
- A list of related updates. For example, a feed may consist of all updates by a user, all updates by users that are members of a group, updates that match a search query.
- A user or group that makes their updates available for others.
- A user who receives updates from one or more publishers. Also known as "follower".
- Receive updates from a publisher.
- publisher server:
- the Web-accessible server that the publisher uses to make updates available.
- subscriber server:
- the Web-accessible server that the subscriber uses to receive updates.
These are the parameters of the problem we wish to solve.
The following common elements of microblogging and status update systems are out of scope for OStatus.
- Microblogging syntax:
- Microblogging servers use a number of different idioms for adding metadata to an update. Notable examples are hashtags (#hashtag) and @-replies (@username). We defer to microsyntax.org for developing these idioms and encourage innovation. Publisher and subscriber servers should be able to process received updates without parsing the plain text content.
- Client API
- Microblogging systems typically allow many forms of communication between the publisher and the publisher server as well as the subscriber and the subscriber server. Some examples: Web interface, email, IM, SMS, and a Web API. By analogy with email, OStatus is to client interfaces as SMTP is to IMAP or POP.
- Private messaging:
- OStatus does not directly address sending 1-to-1 private messages or private streams.
- Social graph:
- OStatus does not specify a static representation of the social graph nor a protocol for retrieving that representation for a user. We defer to FOAF or XFN where this is required.
Updates are represented as Activities (Atkins, M., Recordon, D., Messina, C., Keller, M., Steinberg, A., and R. Dolin, “Atom Activity Extensions (Draft),” March 2010.) [activitiesinatom] in Atom (Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” December 2005.) [RFC4287]. Typical updates would be represented in the default Activity Schema (Atkins, M., Recordon, D., Messina, C., Keller, M., Steinberg, A., and R. Dolin, “Atom Activity Base Schema (Draft),” March 2010.) [activityschema] with activity verb "Post" and activity object type "Note", "Status" or "Comment". Servers SHOULD support these default types, and MAY support others.
A spatial location for the update object should be encoded as GeoRSS (, “GeoRSS-Simple,” .) [georss] element as part of the activity.
Attachments to an update should be represented as enclosures.
If an update represents a notice made in reply to another, this should be represented using the in-reply-to element from [RFC4685] (Snell, J., “Atom Threading Extensions,” September 2006.).
Tag information should be represented as Atom categories.
OStatus defines two custom extensions to Activity streams.
- When an update is directed to the attention of someone, or mentions someone, this link stores that user's URI.
- When an update is part of a distributed conversation, this is the URI of that conversation.
Users are identified by URIs.
Users are represented as activity objects of the appropriate object type. A typical user would have type "Person".
In the absence of additional information, a default Atom or RSS feed without additional Activity data will be represented as with activity verb "Post" and activity object type "Note", with the Atom author as the implied activity actor. In this case, the author element MUST have a unique identifier, that is, either the <email> or <uri< elements must be present.
Subscribers MUST search for the URI in the following order: the Activity object's <id> element if available, else the Atom author's <uri> element if available, else the Atom author's <email> element treated as a Webfinger acct: URI. Publishers MAY use a profile URL as the URI, but if so MUST ensure that they are stable permalinks.
Users SHOULD have a profile URL, which SHOULD be an HTTP or HTTPS reference to an HTML page including discovery information for the user's feed. The profile URL SHOULD be represented as a link[@rel=alternate,@type=text/html] in the Activity subject, actor, or object item, otherwise the URI MAY be used if it is an HTTP or HTTPS URL.
To provide additional profile information, the author or actor element can be extended with optional Portable Contacts (Smarr, J., “Portable Contacts 1.0 Draft C,” August 2008.) [poco]-structured data. Some elements worth highlighting:
- A login or username.
- Full name. If present, it SHOULD be identical to the author/name or actor/title value.
- A free text description of the user.
- A free text description of the user's current location or usual location.
- URL of a representative page for the user. Note that this is distinct from the link[@rel=alternate,@type=text/html] required for activity actors.
Subscribers MAY use other sources of profile information such as microformats on the profile page, but are not required to.
Feeds are Activity feeds per [activitiesinatom] (Atkins, M., Recordon, D., Messina, C., Keller, M., Steinberg, A., and R. Dolin, “Atom Activity Extensions (Draft),” March 2010.).
All feeds SHOULD have an activity:subject element. User feeds SHOULD have a single activity:subject or atom:author. Group feeds SHOULD have a single activity:subject representing the group.
All feeds MUST have a link[@rel=hub] to identify a PubSubHubbub endpoint URL to establish update subscriptions.
All feeds SHOULD have a link[@rel=salmon] to identify the Salmon endpoint URL to receive replies and notifications.
The publisher server uses PubSubHubbub (Fitzpatrick, B., Slatkin, B., and M. Atkins, “PubSubHubbub Core 0.3 -- Working Draft,” February 2010.) [push] to notify subscribers of new updates.
If multiple subscribers using the same subscriber server subscribe to the same publisher, the subscriber server SHOULD use the one PubSubHubbub subscription for all of them.
Servers use Salmon (Panzer, J., “The Salmon Protocol,” February 2010.) [salmon] to post social events to users or groups. Servers MUST NOT assume that updates that were modeled as activities in a PubSubHubbub-enabled feed were received by the user.
Note that sender and receiver of a notification MAY NOT have a subscriber-publisher relationship.
Important social events and related activities:
- When a user posts an update to the attention of another user or a group, their server sends the update to the salmon endpoint of that user or group. The update MUST have the ostatus:attention link set to the URI of the receiving user or group.
- When a user posts an update in reply to another update, their server SHOULD post it as a Salmon entry to the author of the original update. The reply MUST have the thr:in-reply-to element set to the URI of the original notice. The reply MAY have the ostatus:attention link set to the URI of the original update's author.
- When a subscriber starts following a user, the subscription server sends a schema:follow activity.
- When a subscriber stops following a user the subscription server sends an ostatus:unfollow activity.
- When a subscriber starts following a group, the subscriber server sends a schema:follow activity.
- When a subscriber stops following a user the subscriber server sends an ostatus:leave activity.
- When a user marks another user's update as a favorite, their server sends an update with verb schema:favorite.
- When a user has marked another user's update as a favorite, and removes that mark, their server sends an update with verb ostatus:unfavorite.
- When a user publishes a copy of an update to their own feed, their server sends an update with verb schema:share to the original verb.
Information necessary to establish a subscription or post a notification can be determined from the feed for a user or group. The profile data, salmon endpoint, and PubSubHubbub hub are all encoded in the feed itself.
There are three ways to discover the location of the feed.
There are two ways to get a profile page URL.
There are two ways to get a related XRD file for a user.
The user's XRD document MAY have an additional link template with Rel equal to http://ostatus.org/schema/1.0/subscribe to indicate the endpoint to use for initiating a subscription on the user's subscription server. The template should take a single argument, uri, for the account to subscribe to.
These are some rough scripts for some important processes in this system. They are non-normative.
|[LRDD]||Hammer-Lahav, E., “Link-based Resource Descriptor Discovery,” March 2010.|
|[RFC2119]||Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).|
|[RFC4287]||Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” RFC 4287, December 2005 (TXT, HTML, XML).|
|[RFC4685]||Snell, J., “Atom Threading Extensions,” RFC 4685, September 2006 (TXT).|
|[Webfinger]||“the WebFinger protocol.”|
|[activitiesinatom]||Atkins, M., Recordon, D., Messina, C., Keller, M., Steinberg, A., and R. Dolin, “Atom Activity Extensions (Draft),” March 2010.|
|[activityschema]||Atkins, M., Recordon, D., Messina, C., Keller, M., Steinberg, A., and R. Dolin, “Atom Activity Base Schema (Draft),” March 2010.|
|[poco]||Smarr, J., “Portable Contacts 1.0 Draft C,” August 2008.|
|[push]||Fitzpatrick, B., Slatkin, B., and M. Atkins, “PubSubHubbub Core 0.3 -- Working Draft,” February 2010.|
|[salmon]||Panzer, J., “The Salmon Protocol,” February 2010.|