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.

Status of This Document

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 public-socialweb@w3.org (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.

Table of Contents

1. Overview

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:

1.1 Contents

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.

1.2 Relationship to other WG drafts

Spec Status Relationship
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!):

2. Profiles

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.

2.1 Relationships

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.

2.2 Authorization and access control

Servers may restrict/authorize access to content however they want?

3. Reading

3.1 Content representation

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.

3.2 Objects

All objects must have URLs which return the properties of an object in an appropriate format.

3.3 Streams

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"

Issue 1
Need examples

4. Subscribing

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).

Issue 2
Lots of ways of doing this, what to use?

Here are some options…

A server may also receive notifications of changes to content it has not subscribed to: see mentioning.

5. 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.

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.

6. Creating content

POST a JSON object (see content representation) to the appropriate endpoint.

6.1 Updating

Updating an object SHOULD have the side effect of notifying those subscribed and mentioned.

6.2 Deleting

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