Table of Contents

• 1. Overview
  • 1.1 Contents
  • 1.2 Relationship to other WG drafts
• 2. Profiles
  • 2.1 Relationships
  • 2.2 Authorization and access control
• 3. Reading
  • 3.1 Content representation
  • 3.2 Objects
  • 3.3 Streams
• 4. Subscribing
• 5. Mentioning
• 6. Creating content
  • 6.1 Updating
  • 6.2 Deleting

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:

• connect with other people and subscribe to their content;
• create, update and delete social content;
• interact with other people’s content;
• be notified when other people interact with their content;

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:

• how to expose/consume social content (reading).
• what to post, and where to, to create, update or delete content.
• how to ask for notifications about content (subscribing).
• how to send notifications about content or users (mentioning).
• how to expose profiles and relationships.

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.

3. Reading

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

Here are some options…

• Web Push Protocol: The subscriber follows the urn:ietf:params:push link relation to the target’s Push Service, and then Subscribes for Push Messages
• ActivityPump: The subscriber posts a Follow Activity (JSON object) to the target’s inbox endpoint, and adds the target to the subscriber’s Following Collection. The target’s server adds the subscriber to the target’s Followers Collection, and subsequently POSTs all new activities of the target to the subscriber’s inbox endpoint. (See ActivityPump 7.4.2, 8 and 9.2.4)
• SoLiD: 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. (See SoLiD - Live Updates)
• PubSubHubbub: The subscriber discovers the target’s hub, and sends a form-encoded POST request containing values for hub.mode (“subscribe”), hub.topic and hub.callback. When the target posts new content, the target’s server sends a form-encoded POST to the hub with values for hub.mode (“publish”) and hub.url and 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)
• Salmentions: The subscriber creates content that links to the target (eg. a reply) and sends a form-encoded POST containing values for source and target to 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 POST requests containing values for source and target to 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.

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.

• ActivityPump: When an Activity is posted to a user’s outbox endpoint, the server checks for values of object, target, inReplyTo, to, cc, and bcc; discovers the inbox endpoint of any objects found, and POSTs the Activity to the discovered inbox endpoints. Servers receiving such an Activity proceed to do the same for the target object to propagate the update further. (See ActivityPump 8.2)
• Webmention: The target publishes a link to their ‘webmention endpoint’ via rel="webmention". The source sends a form-encoded POST request 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.

6. Creating content

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

• ActivityPump: POST to "outbox": "..." (See ActivityPump 7.4.1)
• Micropub: POST to rel="micropub" (See Micropub)
• SoLiD: POST to an LDP container (See SoLiD - Creating new resources)