View source for 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 [https://www.w3.org/TR/activitystreams-vocabulary/#dfn-to 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 [https://www.w3.org/TR/activitystreams-vocabulary/#dfn-bto 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 <code>bto</code>.

== cc ==

Activity Streams 2.0 [https://www.w3.org/TR/activitystreams-vocabulary/#dfn-cc 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 [https://www.w3.org/TR/activitystreams-vocabulary/#dfn-bcc 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 <code>bcc</code>.

== audience ==

Activity Streams 2.0 [https://www.w3.org/TR/activitystreams-vocabulary/#dfn-audience 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 <code>audience</code> 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 <code>bto</code> and <code>bcc</code> property should be stripped out of activities by the sending server for remote delivery.

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

Delivery to a remote recipient actor identified by the <code>bto</code> or <code>bcc</code> property should be made to the <code>inbox</code> endpoint for the actor, not the <code>sharedInbox</code>. 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 <code>bto</code> or <code>bcc</code> 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 <code>bto</code>  or <code>bcc</code> property, the property should be stripped by the server, unless the client is authenticated as the <code>actor</code> or <code>attributedTo</code> 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 <code>Note</code> is created with an an <code>inReplyTo</code> 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 (<code>to</code>, <code>cc</code>, and <code>audience</code>) should be maintained verbatim from the object being replied to. The <code>attributedTo</code> or <code>actor</code> (for activities) should be added to one of the addressing properties, usually <code>cc</code>.

For replies from remote servers, the private addressing properties (<code>bcc</code>, <code>bto</code>) 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 <code>Mention</code>, 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 <code>Public</code> collection and adding a <code>followers</code> 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 <code>followers</code> addressee but adding the <code>Public</code> 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 <code>content</code>, this can cause privacy or security issues, embarrassment, or other social ills.