ActivityPub/Primer/Addressing

The ActivityPub specification includes a number of addressing properties to use from Activity Streams 2.0, with somewhat different purpose.

to

Activity Streams 2.0 defines this property as: Identifies an entity considered to be part of the public primary audience of an Object.

The addressees are primary; that is, the object is specifically directed to their attention. They are also public; other addressees can see their IDs.

This is an important property to use for visible, directed communications.

bto

Activity Streams 2.0 defines this property as: Identifies an Object that is part of the private primary audience of this Object.

The addressees are primary; that is, the object is specifically directed to their attention. They are also private; other addressees cannot see their IDs.

This is a somewhat unusual property, not least because it is not common in other communications systems, like email. However, a good analogy with email is doing a private distribution of an invitation or other message to many recipients.

See #Delivery to private recipients for issues in delivering to recipients defined in bto.

cc

Activity Streams 2.0 defines this property as: Identifies an Object that is part of the public secondary audience of this Object.

The addressees are secondary; that is, the object is not specifically directed to their attention, however, they are welcome to view and/or respond. They are also public; other addressees can see their IDs.

This is roughly analogous to the CC field in email messaging.

bcc

Activity Streams 2.0 defines this property as: Identifies one or more Objects that are part of the private secondary audience of this Object.

The addressees are secondary; that is, the object is not specifically directed to their attention, however, they are welcome to view and/or respond. They are also private; other addressees cannot see their IDs. ActivityPub servers have special responsibility to remove BCC addresses to protect privacy.

This is roughly analogous to the BCC field in email messaging.

See #Delivery to private recipients for issues in delivering to recipients defined in bcc.

audience

Activity Streams 2.0 defines this property as: Identifies one or more entities that represent the total population of entities for which the object can considered to be relevant.

The audience property was not intended to be used for addressing in the Activity Streams 2.0 vocabulary, but was included in the addressing fields in ActivityPub. Its behaviour for primary/secondary addressing or public/private addressing is not well-defined.

Clients and servers that are creating Activity Streams 2.0 objects should not use this property.

Clients and servers that receive objects with this property should process it like an address as defined in AP. Because its semantics are not well defined, the principle of least harm suggests treating this property as private and secondary.

Delivery to private recipients

The bto and bcc property should be stripped out of activities by the sending server for remote delivery.

The bto and bcc property should also be stripped from any objects that are properties of the activity, like object, target, or origin.

Delivery to a remote recipient actor identified by the bto or bcc property should be made to the inbox endpoint for the actor, not the sharedInbox. There's no way for the remote server to determine which actor to deliver the activity to if the addressing property has been stripped.

If a recipient server receives an activity with a bto or bcc property, it should strip out the property and not show the property to local actors.

When a client or remote server fetches an activity or object with a bto or bcc property, the property should be stripped by the server, unless the client is authenticated as the actor or attributedTo actor.

The stripped-out properties can invalidate digital signatures if the signature was made before the properties were stripped.

Addressing in replies

When a content object like a Note is created with an an inReplyTo property, as a reply to another content object (usually), the addressing properties should reflect those of the object being replied to.

In general, as a mainline case, all of the public addressing properties (to, cc, and audience) should be maintained verbatim from the object being replied to. The attributedTo or actor (for activities) should be added to one of the addressing properties, usually cc.

For replies from remote servers, the private addressing properties (bcc, bto) will usually not be available to the server, so can't be included.

Changing addressing in replies

Changing addressing in replies is possible, but there are social, security, and privacy implications.

One common practice is to "tag" an actor into a conversation, by adding them as an addressee (and adding a Mention, often).

Another possibility is restricting the addressee list. For example, if two actors have been conversing directly in a thread that includes many other actors, it is often considered polite to drop the non-participants from the addressing list.

Using more restrictive collections, like removing the Public collection and adding a followers collection, also happens.

There are also changes that are considered less polite, but still possible within the structure of ActivityPub. One is using more permissive collections, like replying to a post with a followers addressee but adding the Public addressee also.

This makes the existence of a non-public post visible to a wider audience, against the express wishes of the author. If contextual information is included in the content, this can cause privacy or security issues, embarrassment, or other social ills.