1.1 Contents

This is an overview of the current state of specifications of the Social Web Working Group. This document also describes Social Web Working Group specifications in context of other W3C recommendations and relevant drafts from other communities outside of the W3C. 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.

Due to the diversity of viable technical approaches proposed within the Working Group, several specifications on the recommendation track provide overlapping functionality through differing mechanisms. This document exists to provide informative guidance on how and when to implement the various specifications, as well as guidance to implement bridges between recommendations with overlapping functionality.

1.2 Social Web Working Group Specifications

ActivityPub (Candidate Recommendation)

JSON-based APIs for reading, publishing, updating, deleting, subscribing, delivery and profiles.

ActivityStreams 2.0 (AS2) (Core, Candidate Recommendation, Vocabularly, Candidate Recommendation)

The syntax and vocabulary for representing social activities, actors, objects, and collections in JSON and RDF.

Linked Data Notifications (Proposed Recommendation)

An RDF-based protocol for delivery.

Micropub (Candidate Recommendation)

A form-encoding and JSON-based API for publishing, updating and deleting.

WebSub (Candidate Recommendation)

A protocol for subscription to any resource and delivery of updates about it.

Webmention (Recommendation)

A form-encoding-based protocol for delivery.

1.3 Social Web Working Group Drafts

JF2 (First Public Working Draft (Note))

An alternative JSON serialization for representing objects and feeds of social data.

Post Type Discovery (Working Draft)

A protocol to bridge implicitly typed objects and explicitly typed objects.

1.4 Other specifications

ActivityStreams 1.0 [External]

The predecessor to [ActivityStreams2].

Annotation Protocol [WAWG CR]

Transport mechanisms for creating and managing annotations on the Web.

Linked Data Platform [LDP REC]

A protocol for reading and writing Linked Data.

1.5 Requirements

This table shows the high level requirements according to the Social Web Working Group charter and the Social API Requirements, and how the specifications of the Working Group overlap with respect to each.

1.6 How do these specifications relate to each other?

As a quick reference, some key relationships between specifications are as follows:

• ActivityPub and ActivityStreams 2.0: ActivityPub uses the AS2 syntax and vocabulary for the payload of all requests.
• ActivityPub and Linked Data Notifications: ActivityPub specialises LDN as the mechanism for delivery of notifications by requiring that payloads are AS2. Inbox endpoint discovery is the same. LDN receivers can understand requests from ActivityPub federated servers, but ActivityPub servers can't necessarily understand requests from generic LDN senders.
• ActivityStreams 2.0 and Linked Data Notifications: LDN MAY use the AS2 syntax and vocabulary for the payload of notification requests.
• Webmention and Linked Data Notifications: Overlapping functionality that needs to be bridged due to different content types of requests. An LDN request MAY contain the equivalent data as a Webmention request, but not necessarily vice versa.
• ActivityPub and Micropub: Overlapping functionality that needs to be bridged due to different vocabularies and possibly different content types of requests. Micropub specifies client-to-server interactions for content creation; ActivityPub specifies this, plus side-effects and server-to-server interactions.
• Micropub and Webmention: Are complementary but independent. Content could be created with Micropub, then Webmention discovery can be commenced on any URLs in the content.
• Micropub and Linked Data Notifications: Are complementary but independent. Content could be created with Micropub, then LDN discovery can be commenced on any relevant resources identified by the server.
• Micropub and WebSub: Are complementary but independent. Content could be created with Micropub, then passed to a WebSub hub for delivery to subscribers.

2.1 Content representation

[ActivityStreams2] is the recommended syntax and vocabulary for social data. ActivityStreams 2.0 represents content and interactions as Objects and Activities. The ActivityStreams vocabulary defines a finite set of common Object and Activity types and properties, as well as an extension mechanism for applications which want to expand on or specialise these.

ActivityStreams 2.0 content MUST be served with the Content-Type application/activity+json or for JSON-LD extended implementations, application/ld+json; profile="https://www.w3.org/ns/activitystreams". Consumers should recognise both of these Content-Types as ActivityStreams 2.0.

In order to claim ActivityStreams 2.0 conformance, a data publisher MUST use ActivityStreams 2.0 vocabulary terms where available, and only use other vocabularies in addition, or where no appropriate ActivityStreams 2.0 term exists.

[Activitypub] uses ActivityStreams 2.0 for all data, and also extends ActivityStreams 2.0 with additional terms. Thus, ActivityPub requires requests have the Content-Type application/ld+json; profile="https://www.w3.org/ns/activitystreams".

To make content available as ActivityStreams 2.0 JSON, one could do so directly when requested with an appropriate Accept header (eg. application/activity+json or application/ld+json), or indirectly via a rel="alternate" type="application/activity+json" link . This link could be to a different domain, for third-party services which dynamically generate ActivityStreams 2.0 JSON on behalf of a publisher.

2.2 Objects

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.

2.3 Streams

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.

3.1 Creating

The publishing endpoint of [Activitypub] is the outbox. Clients are assumed to have the URL of a (ideally authenticated) user profile as a starting point, and discover the value of the https://www.w3.org/ns/activitystreams#outbox property found at the profile URL (which should be available as JSON). The client then makes an HTTP POST request with an [ActivityStreams2] activity or object as a JSON payload with a content type of application/ld+json; profile="https://www.w3.org/ns/activitystreams". The URL of the created resource is generated at the discretion of the server, and returned in the Location HTTP header. This is an appropriate protocol to use when:

• You want to send/receive a JSON or JSON-LD payload.
• Your data is described with [ActivityStreams2] (optionally extensible via JSON-LD).
• You want serves to carry out a known set of actions upon content creation.

Side-effects of creating content with ActivityPub are for the most part adding things to various different collections collections (likes, follows, etc); but also include requirements about blocking users, and a hook to enable federated servers.

The publishing endpoint for [Micropub] is the micropub end point. Clients discover this from a user's URL via a rel="micropub" link (in an HTTP Link header, or an HTML element). Clients 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, and returned in the Location HTTP header. Clients and servers must support attributes from the Microformats 2 [h-entry] vocabulary. Micropub also defines special reserved attributes (prefixed with mp-) which can be used as commands to the server. Any additional key names sent outside of these vocabularies 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:

• You want to send/receive a form-encoded or JSON payload.
• Your data is described with the [h-entry] syntax and vocabulary.
• You can rely on out-of-band agreements between clients and servers for vocabulary extensibility.

3.2 Updating

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 send an HTTP POST request to the outbox containing an [ActivityStreams2] Update activity. The object of the activity is an existing object, and the fields to update should be nested. If a partial representation of an object is sent, omitted fields are not deleted by the server. In order to delete specific fields, the client can assign them a null value. However, when a federated server passes an Update activity to another server's inbox, the recipient must assume this is the complete object to be replaced; partial updates are not performed server-to-server.

[Micropub] clients perform updates, as either form-encoded or JSON POST requests, using the mp-action=update parameter, as well as a replace, add or delete property containing the updates to make, to the Micropub endpoint. 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.

3.3 Deleting

Content 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 either replace the object of this activity with a tombstone and return a 410 Gone status code, or return a 404 Not Found, 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 .

4.1 Subscribing with as:Follow

[Activitypub] servers maintain a Followers collection for all users. This collection may be directly addressed, or addressed automatically or by default, in the to, cc or bcc field of any Activity, and as a result, servers deliver the Activity to the inbox of each user in the collection.

Subscription requests are essentially requests to be added to this collection. They are made by the subscriber's server POSTing a Follow Activity to the target's inbox. This request should be authenticated, and therefore doesn't need additional verification. The target server then SHOULD add the subscriber to the target's Followers collection. Exceptions may be made if, for example, the target has blocked the subscriber.

This is a suitable subscription mechanism when:

• The subscriber wants to request updates from a specific actor (rather than objects, streams or threads).
• The subscriber and publisher both speak ActivityStreams 2.0.
• The publisher is aware of who has subscribed, and capable of delivering content to subscribers itself.

Since delivery is only a requirement for federated servers, prospective subscribers will not be able to POST their Follow activity to the inbox of a profile which is on a non-federated server (expect a 405 Method Not Allowed), and thus are not able to subscribe to these profiles. In this case, prospective subscribers may wish to periodically pull from the publisher's outbox instead.

4.2 Delegating subscription handling

[WebSub] provides a mechanism to delegate subscription handling and delivery of content to subscribers to a third-party, called a hub. All publishers need to do is link to their chosen hub(s) using HTTP Link headers or HTML <link> elements with rel="hub", and then notify the hub when new content is available. The mechanism for notifying the hub is left deliberately unspecified, as publishers may have their own built in hub, and therefore use an internal mechanism.

The subscriber discovers the hub from the publisher, and sends a form-encoded POST request containing values for hub.mode ("subscribe"), hub.topic (the URL to subscribe to) and hub.callback (the URL where updates should be sent to, which should be 'unguessable' and unique per subscription). The hub and subscriber carry out a series of exchanges to verify this request.

When the hub is notified of new content by the publisher, the hub fetches the content of the topic URL, and delivers this to the subscriber's callback URL.

This is a suitable subscription mechanism when:

• The subscriber wants to request updates from any resource (not just user profiles), and of any content type.
• Subscription requests are not authenticated, so you need a way to verify them.
• The publisher wants to delegate distribution of updates to another service (the hub) instead of doing it itself.

5.1 Targeting and discovery

The target of a notification is usually the addressee or the subject, as referenced by a URL. The target may also be someone who has previously requested notifications through a subscription request. Once you have determined your target, you need to discover where to send the notification for that particular target. Do this by fetching the target URL and looking for a link to an endpoint which will accept the type of notification you want to send (read on, for all of your exciting options).

Bear in mind that many potential targets will not be configured to receive notifications at all. To avoid overloading unsuspecting servers with discovery-related requests, your application should employ a "back-off" strategy when carrying out discovery multiple times to targets on the same domin. This could involve increasing the period of time between subsequent requests, or caching unsuccessful discovery attempts so those domains can be avoided in future. You may wish to send a User-Agent header with a reference to the notification mechanism you are using so that recipient servers can find out more about the purpose of your requests.

Your application should also respect relevant cache control and retry headers returned by the target server.

5.2 Generic notifications

[LDN] provides a protocol for sending, receiving and consuming notifications which may contain any content, or be triggered by any person or process. Senders, receivers and consumers can all be on different domains, thus this meets the criteria for a federation protocol. This is a suitable notification mechanism when:

• Notifications need to be identifiable with their own URLs and exposed by the receiver for other applications to discover and re-use.
• Notifications are represented as a JSON-LD payload (ie. a 'fat ping').
• You need to advertise constraints on the type or contents of notifications accepted by a receiver.

[LDN] functionality is divided between senders, receivers and consumers. The endpoint to which notifications are sent is the inbox. Any resource (a user profile, blog post, document) can advertise its inbox so that it may be discovered through an HTTP Link header or the document body in any RDF syntax (including JSON-LD or HTML+RDFa). To this Inbox, senders make a POST request containing the JSON-LD (or other RDF syntax per [Accept-Post] negotation with the receiver) payload of the notification. The receiver returns a URL from which the notification data can be retrieved, and also adds this URL to a list which is returned upon a GET request to the Inbox. Consumers can retrieve this Inbox listing, and from there the individual notifications, as JSON-LD (optionally content negotiated to another RDF syntax). An obvious type of consumer is a script which displays notifications in a human-readable way.

The payload of notifications is deliberately left open so that LDN may be used in a wide variety of use cases. However, receivers with particular purposes are likely to want to constrain the types of notifications they accept. They can do this transparently (such that senders are able to attempt to conform, rather than having their requests rejected opaquely) by advertising data shapes constraints such as [SHACL]. Advertisement of such constraints also allows consumers to understand the types of notifications in the Inbox before attempting to retrieve them. Receivers may reject notifications on the basis of internal, undisclosed constraints, and may also access control the Inbox for example by requiring an Authorization header from both senders and consumers.

[WebSub] publishers deliver content to their hub, and hubs to their subscribers using HTTP POST requests. The body of the request is left to the discretion of the sender in the first case, and in the latter case must match the Content-Type of and contain contents from the topic URL.

5.3 Activity notifications

[Activitypub] uses [LDN] to send notifications with some specific constraints. These are:

• The notification payload MUST be a single [ActivityStreams2] Activity.
• The notification payload MUST be compact JSON-LD.
• The receiver MUST verify the notification by fetching its source from the origin server.
• All notification POST requests are authenticated.

[Activitypub] specifies how to define the target(s) to which a notification is to be sent (a pre-requisite to [LDN] sending), via the [ActivityStreams2] audience targeting and object linking properties.

[Activitypub] also defines side-effects that must be carried out by the server as a result of notification receipt. These include:

• Creating, updating or deleting new objects upon receipt of Create, Update and Delete activities.
• Reversing the side-effects of prior activities upon receipt of the Undo activity.
• Updating specialised collections for Follow, Like and Block activities.
• Updating any other collections upon receipt of Add and Remove activities.
• Carrying out further delivery to propagate activities through the network in the case of federated servers.

5.4 Mentioning

[Webmention] provides an API for sending and receiving notifications when a relationship is created, updated, or deleted between two documents by including the URL of one document in the content of another. It works when the two documents are on different domains, thus serving as a federation protocol. This is a suitable notification mechanism when:

• You have a document (source) which contains the URL of another document (target).
• The owner of the endpoint has access to view the source (so the request can be verified).
• The only data you need to send over the wire are the URLs of the source and target documents (ie. a 'thin ping').

If a Webmention is received and this is the first time this source and target combination has been seen by the receiver, this indicates a relationship between the source and target has been created. If the receiver has seen these values before, the receiver can fetch and parse the source to determine what has changed; either the content of the source has been updated (in which case the receiver can update local copies of the content, if it stored them in the first place), or the entire source has been deleted (expect a 410 Gone response).

There are no constraints on the syntax of the source and target documents. Discovery of the [Webmention] endpoint (a script which can process incoming webmentions) is through a link relation (rel="webmention"), either in the HTTP Link header or HTML 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.

Webmentions are verified by the server dereferencing the source and parsing it to check for the existence of the target URL. If the target URL isn't found, the webmention MUST be rejected.

[Webmention] uses x-www-form-urlencoded for the source and target as parameters in an HTTP POST request. Beyond verification, it is not specified what the receiver should do upon receipt of a Webmention. What the webmention endpoint should return on a GET request is also left unspecified.

5.5 Delivery interop

This section describes how receiver implementations of either Webmention or LDN may create bridging code in order to accept notifications from senders of the other. This can also be read to understand how a sender of either Webmention or LDN should adapt their discovery and payload in order to send to a receiver of the other.

{
  "@context": "https://www.w3.org/ns/activitystreams#",
  "type": "Relationship",
  "subject": "https://waterpigs.example/post-by-barnaby",
  "object": "https://aaronpk.example/post-by-aaron"
}

{
  "@context": "https://www.w3.org/ns/activitystreams#",
  "type": "Relationship",
  "subject": {
    "id": "https://waterpigs.example/post-by-barnaby",
    "name": "Hi Aaron, great post."
  },
  "object": {
    "id": "https://aaronpk.example/post-by-aaron",
    "name": "Aaron's first post."
  },
  "relationship": "inReplyTo"
}

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

• Activitypub: When a server receives a Follow Activity in its inbox, the subject is added to a Followers Collection, which is discoverable from the subject's profile.

6.2 Authorization and access control

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

• ActivityPub: see auth
• Indieweb: see private posts, private webmention
• Solid: see acl