The W3C Social Web Working Group ran from June 2014 to December 2017, published seven recommendations and some notes. This is one of the notes, and it describes the work at the time of the group closing.
This work is by no means done, and the various communities involved have by no means gone to sleep. The endeavour continues in the Social Web Community Group, in which you are warmly invited to particiate.
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 decentralised social systems.
Each of these components 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.
The Social Web Working Group Charter proposes the following deliverables, which have been met by the Group, and will be referred to throughout this document:
This is an overview of the specifications of the Social Web Working Group.
Due to the diversity of viable technical approaches proposed within the Working Group, several specifications reached recommendation which 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 some hints towards routes to bridging between similar specifications.
This document is divided into five sections, pertaining to the components above, and derived from the Social API Requirements. The various Social Web Working Group specifications implement different combinations of these requirements (see ) so for clarity the requirement are defined here.
These are the specifications produced by the Social Web Working Group. New implementation reports and feedback are always welcome (details for where to submit these are at the top of each document).
Specifications which are not Social Web Working Group recommendations, but which are nonetheless relevent to the charter deliverables, are described in .
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.
This table lists the requirements met by the core functionality of each specification. Some specifications may additionally touch on or make suggestions about other requirements, which can be useful when deciding how to combine specifications, and is highlighted as appropriate throughout this document.
| Data syntax | Social API | Federation Protocol | ||||||||
| Vocabulary | Syntax | Profiles | Read | Create | Update | Delete | Subscription | Delivery | ||
|---|---|---|---|---|---|---|---|---|---|---|
| ActivityPub | X | X | X | X | X | X | X | |||
| ActivityStreams 2.0 | X | X | X | |||||||
| Linked Data Notifications | X | |||||||||
| Micropub | X | X | X | |||||||
| Webmention | X | |||||||||
| WebSub |
X | |||||||||
As a quick reference, some key relationships between specifications are as follows:
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.
ActivityStreams 2.0 is the recommended syntax ([[activitystreams-core]]) and vocabulary ([[activitystreams-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 is 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; they should be treated as equivalent.
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.
ActivityStreams 2.0 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 ActivityStreams 2.0.
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.
When sent as JSON-LD, ActivityStreams 2.0 must be compacted, and must not use the @graph keyword. This is because an ActivityStreams 2.0 document requires a single Object as the root. To serve multiple resources, you can instead nest them.
The ActivityStreams 2.0 JSON-LD context (https://www.w3.org/ns/activitystreams#) aliases @id and @type to id and type respectively.
[[Activitypub]] uses ActivityStreams 2.0 for all data, and also extends ActivityStreams 2.0 with additional terms. Thus, ActivityPub requires responses to have the Content-Type application/ld+json; profile="https://www.w3.org/ns/activitystreams". Publishers are however expected to also respect requests with the application/activity+json Accept header.
If you don't like ActivityStreams 2.0, there are still some specifications you can use for particular tasks.
[[LDN]] notification contents can use any vocabulary, so long as the data is available as JSON-LD. Thus notifications MAY use ActivityStreams 2.0, but don't have to.
[[Micropub]] clients which expect to read data (this would usually be clients for updating) are expecting it as JSON in the parsed microformats2 syntax ([[microformats2-parsing]]).
[[WebSub]] is agnostic as to the Content-Type used by publishers; hubs are expected to deliver the new content to subscribers as-is produced by the publisher, at the publisher's topic URL.
All ActivityStreams 2.0 objects have URLs in the id property, which return the properties of an object. The response may vary depending on the requester's right to access the content.
Each ActivityStreams 2.0 collection has a URL in the id property which returns the contents of the stream (according to the requester's right to access). This could be paged - ActivityStreams 2.0 provides a paging mechanism. It may include additional metadata about the stream (such as title, description).
Each object in a collection contains at least its URL (id), as well as optionally other properties of the object.
Collections may represent changing streams of objects, or fixed sets. One profile may be associated with 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 profile may include links to multiple streams, which a consumer could follow to read or subscribe to.
[[Activitypub]] specifies two streams that MUST be accessible from a profile via the following properties:
inbox: A reference to an ActivityStreams 2.0 collection comprising all the objects received by the actor.outbox: An ActivityStreams 2.0 collection comprising all the objects produced by the actor.ActivityPub also specifies further properties for accessing additional streams; following and followers are expected, and the rest are optional:
following: An ActivityStreams 2.0 collection of the actors that this actor is following.followers: An ActivityStreams 2.0 collection of the actors that follow this actor
liked: An ActivityStreams 2.0 collection of every object from all of the actor's Like activities (generated automatically by the server).streams: A list of supplementary Collections which may be of interest. preferredUsernameendpoints: A mapping of additional (typically server/domain-wide) endpoints which may be useful either for this actor or someone referencing this actor:
proxyUrl, oauthAuthorizationEndpoint, oauthTokenEndpoint, provideClientKey, signClientKey, sharedInbox.[[Activitypub]] permits arbitrary collections to be created through specifying special behavior for the server when it receives activities with types Add and Remove. When a server receives such an activity in the outbox, and the target is a Collection, it adds the object to the target (for Add) or removes the object from the target (for Remove).
An Inbox is an endpoint to which new objects may be delivered. It also serves as a collection whose contents may be read. The Inbox endpoint is used by both ActivityPub and LDN, and can be discovered through the properties:
ldp:inbox (http://www.w3.org/ns/ldp#inbox)as:inbox (https://www.w3.org/ns/activitystreams#inbox)In terms of JSON-LD, the latter is an alias of the former.
For how and when to write to an Inbox, see delivery.
The contents of this collection may also be read. While ActivityPub and LDN align for writing to an Inbox, due to irritating but ultimately unavoidable compatibility requirements with AS2 and LDP respectively, they use different vocabularies when Inbox contents are returned for reading. Fortunately for consuming clients to check for both vocabularies or for publishers to publish using both is not a huge implementation hurdle, so bridging is fairly trivial.
OrderedCollection, and link to their contents with the items property.Container (providing an explicit type is optional), and link to their contents with the contains property.In addition, ActivityPub has more constraints on the format of the JSON-LD returned. The two lists to follow describe how to bridge the small differences between ActivityPub and LDN conformant Inboxes.
ActivityPub servers wishing to be read by LDN consumers:
items for everything in the collection, an ldp:contains (http://www.w3.org/ns/ldp#contains) relation.ActivityPub clients wishing to read from LDN Inboxes:
application/ld+json. Running it through JSON-LD compaction should help to format the respone in a more friendly way.ldp:contains property (rather than AS2 items).@id property.LDN receivers wishing to be readable by ActivityPub consuming clients:
application/activity+json as equivalent to application/ld+json; profile="http://www.w3.org/ns/activitystreams".Collection, where each notification is related to the inbox with the AS2 items property.@graph, serving the Inbox collection as the root of the document.LDN consumers wishing to read from Inboxes on ActivityPub servers:
application/activity+json and missing an @context, apply the default AS2 context, and treat it as JSON-LD.items property (rather than ldp:contains).Publishing in this context refers to modifying the outgoing feed associated with a particular profile. This incorporates creating new content, as well as updating or deleting existing content. Content generated through a client (such as a web form, mobile app, sensor, 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), in human- and/or machine-readable forms. Clients and servers may independently support creating, updating and deleting; there are no dependencies between them.
While delivering notifications or responding to subscription requests may trigger creating (or updating or deleting) something on the receiving end, the intent is different. These cases are called out as side effects in subscription and delivery where appropriate.
For notes about authentication and authorization between clients and servers, see
The two specifications recommended by the Social Web Working Group for publishing are [[Activitypub]] and [[Micropub]]. They use similar high level mechanisms, but differ in requirements around both the vocabularies and content types of data.
ActivityPub contains a client-to-server API for creating ActivityStreams 2.0 objects and activities, and specifies additional responsibilities for clients around addressing objects, and for servers around the side-effects of certain types of objects.
Micropub provides a basic client-to-server API for creating blog-post-type content and is intended as a quickstart for content creation, on top of which more complex (but optional) actions can be layered. Micropub also provides a media endpoint for uploading files.
Neither ActivityPub nor Micropub define APIs for publishing based on HTTP verbs. If you're looking for something more RESTful, you may like the Linked Data Platform [[LDP]].
The publishing endpoint of [[Activitypub]] is the outbox. Clients are assumed to have the URL of a (ideally authenticated) 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 ActivityStreams 2.0 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:
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 endpoint. Clients discover this from a profile URL via a rel="micropub" link (in an HTTP Link header, or an HTML <link> 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 Microformats2 [[h-entry]] vocabulary. Micropub also defines four reserved attributes (access_token, h, action and url) as well as reserves any attribute prefixed with mp-; these are 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 [[microformats2-parsing]].
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.
[[Activitypub]] clients send an HTTP POST request to the outbox containing an ActivityStreams 2.0 Update activity. The object of the activity is an existing object, including its id, 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.
In the case of ActivityPub federated servers, updates should be propagated to the inboxes of recipients of the original objects. 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.
An Undo with the object of the previous Update can be used to revert changes.
[[Micropub]] clients perform updates as JSON POST requests, using the "action": "update" directive, 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.
If a server also implements [[Webmention]] it should propagate the updates to anyone who received Webmentions for the original.
If a server also implements [[WebSub]], and the updated resource is part of a topic, the server should notify the hub of an update to the topic URL.
Content is deleted when a client sends a request to delete an existing object.
[[Activitypub]] clients delete an object by sending an HTTP POST request containing an ActivityStreams 2.0 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.
An Undo with the object of the previous Delete may be used to restore the object.
[[Micropub]] delete requests are two key-value pairs, JSON: "action": "delete" and "url": url-to-be-deleted, sent to the Micropub endpoint. Posts may be resotred with "action": "undelete".
As with updating, servers implementing ActivityPub federation, Webmention or WebSub should propagate deletes accordingly.
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. Specifications which contain subscription mechanisms are ActivityPub and WebSub.
Receiving notifications does not need to rely on implementation of a subscription mechanism. That is, implementations may set themselves up to receive notifications without always being required to explicitly ask for them from a sender or publisher: see delivery.
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. As a result, federated servers deliver the Activity to the inbox of each profile 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:
outbox (rather than objects, streams, feeds, collections, conversation threads).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.
[[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.
A mechanism for communcation between publishers and hubs may be standardised in future as an extension.
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 sends this to the subscriber's callback URL via a POST request. The body of the request is the content of the topic URL, and the Content-Type must match. A rel=hub Link header should be included.
This is a suitable subscription mechanism when:
LDN Receivers can be used to receive deliveries from WebSub hubs by using the inbox URL as the hub.callback URL and either only subscribing to resources published as JSON-LD or accepting content-types other than JSON-LD.
A user or application may wish to push a notification to another user that the receiver has not explicitly asked for. For example to send a message or some new information; because they have linked to (replied, liked, bookmarked, reposted, etc) their content; because they have linked to (tagged, addressed) the user directly; to make the recipient aware of a change in state of some document or resource on the Web. The Social Web Working Group specifications contain several mechanisms for carrying out delivery; they are listed here from general to specialised.
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.
The target of a notification is usually the addressee or the subject, as referenced by a URL. The target may also a resource which 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. Discovery is 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.
[[LDN]] is a federation protocol for sending, receiving and consuming notifications which may contain any content, and be triggered by any person or process. Senders, receivers and consumers can all be on different domains. This is a suitable notification mechanism when:
[[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 (see ). 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.
An existing [[LDP]] implementation can serve as an [[LDN]] receiver out of the box; publishers simply advertise any ldp:Container as the inbox for a resource.
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.
[[Activitypub]] uses [[LDN]] to send notifications with some specific constraints. These are:
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 [[activitystreams-vocabulary]] 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:
Create, Update and Delete activities.Undo activity.Follow, Like and Block activities.Add and Remove activities.ActivityPub actor profiles are linked to their inboxes via the https://www.w3.org/ns/activitystreams#inbox property. This is an alias (in the AS2 JSON-LD context) for LDN's http://www.w3.org/ns/ldp#inbox. Applications using a full JSON-LD processor to parse these documents will see these terms as one and the same. Applications doing naive string matching on terms may wish to note that if you find an ldp:inbox it will accept POST requests in the same way as an as:inbox.
[[Webmention]] provides an API for sending and receiving notifications when a relationship is created (or updated, or deleted) between two documents. A webmention sender is triggered by the creation (or modification) of content which includes the URL of another document. It works when the two documents are on different domains, thus serving as a federation protocol. This is a suitable notification mechanism when:
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.
In practice, Webmention receivers tend to fetch and store the webmention source. It is often displayed, for example as a reply underneath the target blog post.
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).
This section describes how implementations of Webmention, ActivityPub and LDN may create bridging code in order to send and receive notifications from the others.
A webmention may be represented as a persistent resource with the ActivityStreams 2.0 vocabulary. This could come in handy if a Webmention sender mentions a user known to be running an ActivityPub federated server, and wants a generic (ie. not ActivityPub specific) way of notifying about this. In this case, the sender can use an AS2 payload and deliver the notification per .
{
"@context": "https://www.w3.org/ns/activitystreams#",
"type": "Relationship",
"subject": "https://waterpigs.example/post-by-barnaby",
"object": "https://aaronpk.example/post-by-aaron"
}
A receiver or sender may want to augment this representation with the relationship between the two documents, and any other pertinent data. In the receiver's case, this could be gathered when they parse the source during the verification process. For example:
{
"@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"
}
Webmention receivers wishing to also accept LDN POSTs at their Webmention endpoint must:
rel="http://www.w3.org/ns/ldp#inbox" in addition to rel="webmention" (in the Link header, HTML body or JSON body of a target).POST requests with the Content-Type application/ld+json. Expect the body of the request to be:
{
"@context": "http://www.w3.org/ns/webmention#",
"@id": "",
"source": { "@id": "https://waterpigs.example/post-by-barnaby" },
"target": { "@id": "https://aaronpk.example/post-by-aaron" }
}
Use the source->@id and target->@id values as the source and target of the Webmention, and proceed with verification.201 Created, it MUST return a Location header with a URL from which the contents of the request posted can be retrieved. 202 Accepted is still fine.LDN senders wishing to send to Webmention endpoints basically just need to implement Webmention sending. The Webmention endpoint is at rel="webmention" (either in an HTTP Link header or HTML <link> element).
Note that Webmention endpoints will only verify a received notification if the source is publicly retrievable and contains the URL of the target.
LDN receivers wishing to also accept Webmentions to their Inbox MUST:
rel="webmention" in addition to rel="http://www.w3.org/ns/ldp#inbox" (in the Link header, HTML body or JSON body of a target).POST requests with a content type application/x-www-form-urlencoded. Convert these requests from:
source=https://waterpigs.example/post-by-barnaby&
target=https://aaronpk.example/post-by-aaron
to:
{
"@context": "http://www.w3.org/ns/webmention#",
"@id": "",
"source": { "@id": "https://waterpigs.example/post-by-barnaby" },
"target": { "@id": "https://aaronpk.example/post-by-aaron" }
}
and proceed per [[LDN]]; receivers MAY add other triples at their discretion.201 Created with a Location header or 202 Accepted.Webmention senders wishing to send to LDN Inboxes need to send a JSON-LD payload. Discover the Inbox endpoint through a relation of http://www.w3.org/ns/ldp#inbox between the target and the Inbox. A typical Webmention can be represented as JSON-LD per this example, or as ActivityStreams 2.0 JSON per this example.
Look out for Webmention-ActivityPub bridges as services. These will provide endpoints to do the heavy lifting of the spec you don't want to implement yourself. You can use these endpoints as your Webmention or Inbox endpoint respectively. Brainstorming and implementations of such bridges can be found on the Social Web Community Group and the IndieWeb community.
The subject of a profile document can be a person, persona, organisation, bot, location, or other. None of the specifications described here prescribe particular relationships between real-world entities and online profiles. That is, one person can have many profiles, and one profile may be controlled by many people. How/if/when multiple profiles are linked together is implementation specific, and not specified anywhere here.
Most specifications expect that profiles are identified by and retrieved from a URL, and that attributes of the subject of the profile are available from the URL. Ideally they also return a link to at least one stream of content associated with the profile (or embed the content directly), for example activities or blog posts.
ActivityPub profiles are JSON-LD documents containing any appropriate ActivityStreams 2.0 properties, as well as links to various endpoints and collections (see ).
ActivityStreams 2.0 has various Actor types, which may be used to represent individuals or groups, and also includes Profile.
Micropub has a notion of a profile page (URL) that represents a user, but does not specify the format of that page, except for the link to the Micropub endpoint and authorization endpoints for clients to discover.
Webmention does not specify any particular profile format, but in practice Webmention implementations typically publish and consume [[h-card]] profile information to display authors of webmention sources (see examples in the Webmention spec).
Semantics and representation of personal relationships are implementation specific. These specifications deal with relationships only when distribution of content is affected, for example when 'following' triggers a subscription request from one server to another. Lists of other relationships may be discoverable from a user profile, should be represented according to the ActivityStreams 2.0 syntax and may (and are likely to) use extension vocabularies as needed.
Follow Activity in its inbox, the subject is added to a Followers Collection, which is discoverable from the subject's profile. Federated servers use this collection to deliver updates when new content is created by the owner of the collection.Authentication and authorization mechanisms were out of scope for the Social Web WG. Please follow the Community Group for development in this space. Meanwhile, some of the WG specifications contain non-normative notes on the topic: