The Social Web Protocols are a collection of standards which enable various aspects of decentralised social interaction on the Web. This document describes the purposes of each, and how they fit together.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document was published by the Social Web Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to email@example.com (subscribe, archives). All comments are welcome.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 1 September 2015 W3C Process Document.
People and the content they create are the core components of the social web; they make up the social graph. This document describes a standard way in which people can:
regardless of what that content is or where it is stored.
These components are core building blocks for interoperable social systems.
Each of these specifications can be implemented independently as needed, or all together in one system, as well as extended to meet domain-specific requirements. Users can store their social data across any number of compliant servers, and use compliant clients hosted elsewhere to interact with their own content and the content of others. Put simply, this document tells you, according the recommendations of the Social Web Working Group:
This is an overview of the current state of specifications of the Social Web Working Group: ActivityStreams Core and vocabulary, Activitypub, Micropub and Webmention. This document also describes Social Web Working Group specifications in context of W3C recommendations and relevant drafts from other communities outside of the Social Web Working Group. As many of these specs are under ongoing development, this document is subject to change alongside them.
You might also want to take a look at the Working Group's Social API Requirements to understand the division of concerns.
This document is on track to become a Working Group Note to provide guidance on how and when to implement the various specifications produced.
The high level requirements according to the Social Web Working Group charter and the Social API Requirements.
If you are a content publisher, this section is about how you should publish your content. If you are a content consumer, this is what you should expect to consume.
Content MUST be available as [ActivityStreams2] JSON and MAY additionally be served as an alternative syntax. If a URL does not return [ActivityStreams2] JSON, consumers SHOULD look for the JSON format via a
rel="alternate" type="application/activity+json" link (which could be to a different domain, for third-party services which dynamically generate [ActivityStreams2] JSON on behalf of the publisher). [ActivityStreams2] content MUST be served with the Content-Type
application/activity+json or, if necessary for JSON-LD extended implementations,
Content MUST be described using the [ActivityStreams2] vocabulary, and MAY use other vocabularies in addition or instead, per the [ActivityStreams2] extension mechanism.
[ActivityStreams2] builds upon [AS1] and is not fully backwards compatible; the relationship between AS1 and AS2 is documented in the AS2 spec. If you have implemented [AS1], you should transition to [ActivityStreams2].
[Activitypub] exposes all content as [ActivityStreams2] JSON.
All objects MUST have URLs in the
id property, which return the properties of an object according to content representation, and depending on the requester's right to access the content.
Each stream MUST have a URL which MUST result in the contents of the stream (according to the requester's right to access, and could be paged), and MAY include additional metadata about the stream (such as title, description).
Each object in a stream MUST contain at least its URL, which can be dereferenced to retrieve all properties of the object, and MAY contain other properties of the object.
One user may publish one or more streams of content. Streams may be generated automatically or manually, and might be segregated by post type, topic, audience, or any arbitrary criteria decided by the curator of the stream. A user profile MAY include links to multiple streams, which a consumer could follow to read or subscribe to.
[Activitypub] specifies four feeds that MUST be accessible from a profile via the following properties:
inbox: A reference to an [ActivityStreams2] collection comprising of all the messages received by the actor.
outbox: An [ActivityStreams2] collection comprising of all the messages produced by the actor.
following: An [ActivityStreams2] collection of the actors that this actor is following.
followers: An [ActivityStreams2] collection of the actors that follow this actor.
[Activitypub] also specifies a further property for accessing additional feeds, which MAY be included in a profile:
streams: A list of supplementary Collections which may be of interest.
Activitypub discovery mechanism for this to be specified, likely link relations per issue 50.
[Activitypub] specifies special behavior for activities with types
Remove. When a server receives such an activity in the
outbox, and the
target is a Collection, it MUST add the
object to the
Add) or remove the
object from the
Content generated through a client (such as a web form, mobile app, smart device) is created when it is sent to a server for processing, where it is typically stored and usually published (either publicly or to a restricted audience). Clients and servers may independently support creating, updating and deleting; there are no dependencies between them. Authentication and authorization for creating content is left out of scope.
[Activitypub] clients discover the
outbox of the authenticated user from their JSON profile, then make an HTTP POST request with an appropriate [ActivityStreams2] activity as a JSON payload. [Activitypub] requires use of the [ActivityStreams2] vocabulary and syntax, which may be extended with JSON-LD. The URL of the created resource is generated at the discretion of the server. This is an appropriate protocol to use when:
[Micropub] clients discover the Micropub endpoint from the current user's homepage (likely entered by the user as part of authentication) from a
rel="micropub" link, then make a
x-www-form-urlencoded POST request containing the key-value pairs for the attributes of the object being created. The URL of the created resource is generated at the discretion of the server. Micropub requires use of the Microformats 2 [h-entry] vocabulary, as well as a set of reserved attributes as commands to the server. Any additional key names sent outside of this vocabulary may be ignored by the server.
[Micropub] requests may alternatively be sent as a JSON payload, the syntax of which is derived from the Microformats 2 parsing algorithm. This is an appropriate protocol to use when:
[LDP] servers are written to by sending an HTTP POST request to a
Container (any resource on the server which returns
Link: <http://www.w3.org/ns/ldp#Container>; rel="type"), containing an RDF payload with attributes of the object being created. An identifier for the created resource is generated at the discretion of the server. The URL is created by appending the identifier to the URL of the
Container that was posted to. [Solid] and [AnnotationProtocol] both use slightly altered [LDP] to create content; [Solid] restricts use to only Basic Containers, while the [AnnotationProtocol] specifies the [AnnotationVocab] and primary syntax as JSON-LD. This is an appropriate protocol to use when:
Content is updated when a client sends changes to attributes (additions, removals, replacements) to an existing object. If a server has implemented a delivery or subscription mechanism, when an object is updated, the update MUST be propagated to the original recipients using the same mechanism.
[Activitypub] clients replace the complete object by sending an HTTP POST request containing an [ActivityStreams2]
Update activity to the
outbox of the authenticated user, where the
object is a nested object, including an
id, which serves as the replacement.
ActivityPub currently only supports updates of a whole object at once. Issue 85 for partial updates.
[Micropub] clients perform updates, as either form-encoded or JSON POST requests, using the
mp-action=update parameter, as well as a
delete property containing the updates to make, to the Micropub endpoint (discovery described in creating).
replace replaces all values of the specified property. If the property does not exist already, it is created.
add adds new values to the specified property without changing the existing ones. If the property does not exist already, it is created.
delete removes the specified property; you can also remove properties by value by specifying the value.
[LDP] clients perform replacement-style updates by sending an HTTP PUT request to the URL of the object to be updated. Partial-style updates are performed with an HTTP PATCH request.
ontent is deleted when a client sends a request to delete an existing object. If a server has implemented a delivery or subscription mechanism, when an object is deleted, the deletion MUST be propagated to the original recipients using the same mechanism.
[Activitypub] clients delete an object by sending an HTTP POST request containing an [ActivityStreams2]
Delete activity to the
outbox of the authenticated user. Servers MUST replace the
object of this activity with a tombstone, and return a
410 Gone status code from its URL.
[Micropub] delete requests are two key-value pairs, in form-encoded or JSON: `mp-action`: `delete` and `url`: `url-to-be-deleted`, sent to the Micropub endpoint (discovery described in creating).
[LDP] deletes are performed by sending an HTTP DELETE request to the URL of the object to be deleted.
An agent (client or server) may ask to be notified of changes to a content object (eg. edits, new replies) or stream of content (eg. objects added or removed from a particular stream). This is subscribing. A server may also receive notifications of changes to content it has not subscribed to: see delivery.
Working group has yet to discuss this in depth, subject to significant change.
[Activitypub] servers distribute the activities of an actor by sending POST requests containing the activities as JSON payloads to the
inbox of all actors in an actor's
Followers collection. For subscription requests, special behavior is defined for servers when an [ActivityStreams2]
Follow activity is appears in an actor's
outbox(an outgoing subscription request): The activity is delivered as usual to the
inbox, and additionally the
objectis added to the actor's
inbox(an incoming subscription request): The recipient's (the
Followactivity) server adds the
Followactivity to the recipient's
Followerscollection, to which all new activities of the recipient are subsequently delivered.
It works when the publisher and subscriber are on different domains, thus serving as a federation protocol. This is a suitable subscription mechanism when:
[Solid] uses websockets to allow client-side applications to subscribe to changes in objects ([LDP] Resources) and streams ([LDP] Containers). The websocket endpoint is advertised in the
Updates-Via HTTP Link Header. The subscriber sends the keyword
sub followed by an empty space and then the URI of the resource, to the target’s websockets URI. The target’s server sends a websockets message containing the keyword
pub, followed by an empty space and the URI of the resource that has changed, whenever there is a change. It works when the publisher and subscriber are on different domains, thus serving as a federation protocol. This is a suitable subscription mechanism when:
[Webmention] can be deployed as a subscription mechanism through the [Salmentions] extension. Documents contain links to the sources of received webmentions along with the content. Every time the document is updated, including when new incoming webmentions are added, the server (re-)sends webmentions to every link. Thus, all documents which originally sent a webmention receive a webmention back, enabling them to parse the document for changes, and detect new replies in a thread, as well as changes to the original document. It works when the publisher and subscriber are on different domains, thus serving as a federation protocol. This is a suitable subscription mechanism when:
Other options yet to be debated...
urn:ietf:params:pushlink relation to the target’s Push Service, and then Subscribes for Push Messages
POSTrequest containing values for
hub.callback. When the target posts new content, the target’s server sends a form-encoded
POSTto the hub with values for
hub.urland the hub checks the URL for new content and
POSTs updates to the subscriber’s callback URL. (See PuSH 0.4 and How To Publish And Consume PuSH)
Nothing should rely on implementation of a subscription mechanism.
A user or application may wish to push a notification to another user, for example because they have linked to (replied, liked, bookmarked, reposted, …) their content or linked to (tagged, addressed) the user directly, or to make the recipient aware of a change in state of some document or resource on the Web.
[Webmention] provides an API for sending and receiving notifications when a relationship is created between two documents. It works when the two documents are on different domains, thus serving as a federation protocol. This is a suitable notification mechanism when:
Discovery of the [Webmention] endpoint (a script which can process incoming webmentions) is through a link relation (
rel="webmention"), either in the HTTP Header or body of the target. This endpoint does not need to be on the same domain as the target, so webmention receiving can be delegated to a third party.
x-www-form-urlencoded for the source and target as parameters in an HTTP POST request. This means a webmention can be triggered from a web form or from the commandline with
curl. Integration with existing applications is straightforward through translating this form-encoded data into JSON, RDF (namespace), or another preferred syntax at the recievers end if necessary. There are no constraints on the syntax of the source and target documents.
[Webmention] can be extended by adding additional parameters to the POST request; applications must have prior agreement in order to understand them, and there is potential for collision of extension terms.
[Activitypub] provides a JSON-based API for sending and receiving [ActivityStreams2] activities as notifications. It works when the two documents are on different domains, thus serving as a federation protocol. This is a suitable notification mechanism when:
The endpoint which processes incoming notifications is a user's [Activitypub]
inbox, discoverable from the target user's profile. The recipient user may be addressed directly (through
bcc), and/or inferred as the owner of another resource which is addressed (through
An [Activitypub] server delivers the entire activity to all discovered endpoints as a JSON payload of an HTTP POST request.
An [Activitypub] server receiving such an activity must verify the notification is accurate (by fetching the source, or some prior trust arrangement with the sender, eg. through an authentication token or digital signature).
[Activitypub] delivery can be extended through the [ActivityStreams2] extension mechanism, with JSON-LD.
Add Solid Notifications for pure RDF usage.
Note: we need to leave it open for users to refuse content they have not explicitly subscribed to, ie. nothing else should rely on implementation of Delivery.
Stub, needs expansion
The subject of a profile document can be a person, persona, organisation, bot, location, … the type of the subject of the profile is not required. Each profile document MUST have a URL which SHOULD return attributes of the subject of the profile; SHOULD return at least one link to a stream of content and MAY return content the subject has created. A JSON format MUST be available; other content types MAY be returned as well.
Semantics and representation of personal relationships are implementation specific. This specification deals with relationships only when distribution of content is affected, for example if one user ‘friending’ another triggers a subscription request from the first user’s server to the second. Lists of other relationships MAY be discoverable from a user profile, SHOULD be represented according to the ActivityStremas 2 syntax and MAY (and are likely to) use extension vocabularies as needed.
FollowActivity in its
inbox, the subject is added to a
Collection, which is discoverable from the subject’s profile.