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 First Public 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 First Public 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 componants 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.
This provides the core building blocks for interoperable social systems.
This specification is divided into parts that 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 specification tells you:
This is an overview of the current state of specs that are inputs to the WG: ActivityPump, Micropub, Webmention) and SoLiD; all of which are subject to ongoing development. Arranged based on Social API Requirements.
The WG may produce several small ‘building block’ specifications, or one unified document. In the former case, this document serves as a guide for implementors to demonstrate how the pieces fit together, and could be published as a note. In the latter case, optimistically, this has the potential to become the location for convergence of the alternatives. Ultimately an implementation of any subsection of this spec should be compatible with the equivalent subsection of one of the aforementioned specs. Subsections which have multiple implementation routes listed are work-in-progress.
|ActivityStreams2||WD||The expected representation of JSON data mentioned here|
|ActivityPump||ED||Most parts correspond with a subsection here|
|Webmention||ED||Corresponds with Mentioning|
|Micropub||ED||Corresponds with Creating content|
|jf2||ED||as AS2 where applicable|
|Post Type Discovery||ED||No overlap|
For comparison of the subsections, the aforementioned specs are restructured according to the structure of this document (work-in-progress, pending feedback from spec authors/editors!):
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.
Content MUST be available as ActivityStreams JSON and MAY additionally be served as an alternative syntax. The JSON format may be accessible via a typed rel=alternate link.
Content SHOULD be described using the ActivityStreams vocabulary, but MAY use other vocabularies in addition or instead.
All objects must have URLs which return the properties of an object in an appropriate format.
Each stream MUST have a URL which MUST result in the contents of the stream (according to the requesters right to access, and could be paged), and MAY include additional metadata about the stream (such as title, description).
Each object in a stream MAY contain only its URL, which can be dereferenced to retrieve all properties of an 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. Eg.
<link rel="feed" href="http://rhiaro.co.uk/tag/socialwg">
HTTP/1.1 200 OK .... Link: <http://rhiaro.co.uk/tag/socialwg>; rel="feed"
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 the stream).
Here are some options…
urn:ietf:params:pushlink relation to the target’s Push Service, and then Subscribes for Push Messages
FollowActivity (JSON object) to the target’s
inboxendpoint, and adds the target to the subscriber’s
FollowingCollection. The target’s server adds the subscriber to the target’s
FollowersCollection, and subsequently
POSTs all new activities of the target to the subscriber’s
inboxendpoint. (See ActivityPump 7.4.2, 8 and 9.2.4)
subfollowed 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. (See SoLiD - Live Updates)
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)
POSTcontaining values for
targetto the target’s webmention webmention endpoint. The target verifies the link and includes a link back to the subscriber’s source on the target content. The target sends form-encoded
POSTrequests containing values for
targetto the webmention endpoint of every link in the content, including that of the subscriber, to indicate that there has been a change. (See webmention and salmentions)
A server may also receive notifications of changes to content it has not subscribed to: see mentioning.
A user 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.
outboxendpoint, the server checks for values of
bcc; discovers the
inboxendpoint of any objects found, and
POSTs the Activity to the discovered
inboxendpoints. Servers receiving such an Activity proceed to do the same for the target object to propagate the update further. (See ActivityPump 8.2)
rel="webmention". The source sends a form-encoded
POSTrequest containing values for
source(the URL of a webpage with a link to the target) and
target(the URL of the webpage being linked to). The target MUST validate that the source really does link to target, and proceeds to do with this information as desired. (See webmention)
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 Mentioning.
POST a JSON object (see content representation) to the appropriate endpoint.
"outbox": "..."(See ActivityPump 7.4.1)
POSTto an LDP container (See SoLiD - Creating new resources)
Updating an object SHOULD have the side effect of notifying those subscribed and mentioned.
UpdateActivity to the
PATCHthe resource being updated.
Deleting an object SHOULD have the side effect of notifying those subscribed and mentioned.
When an object is deleted, it SHOULD be replaced with a ‘tombstone’ containing its unique identifier, deleted (or last updated) date, and optionally replacement content (eg. “this post was removed”). Its URI SHOULD return a 410.
Note: using SHOULD not MUST to allow for silently deleting objects
DeleteActivity to the
DELETEon the resource being deleted.