trwnh.com/unified.test.hugo/content/kb/activitypub/confusion/audience-and-addressing.md

AS2-Vocab provides three properties for addressing certain audiences, and AP specifies that servers deliver to all three of these properties:

to

Identifies an entity considered to be part of the public primary audience of an Object

cc

Identifies an Object that is part of the public secondary audience of this Object.

audience

Identifies one or more entities that represent the total population of entities for which the object can considered to be relevant.

There are also two properties for "private addressing", which are used for delivery but will be stripped before delivery. Consequently, they are not visible to consumers, and thus do not have to be interpreted.

bto

Identifies an Object that is part of the private primary audience of this Object.

bcc

Identifies one or more Objects that are part of the private secondary audience of this Object.

Spec guidance

Per AS2-Vocab 5.1 Audience Targeting:

Conceptually, every Object has both a Primary and Secondary audience. The Primary audience consists of those entities directly involved or owning the object. The Secondary audience consists of the collection of entities sharing an interest in the object but who might not be directly involved (e.g."followers").

For instance, suppose a social network of three individuals: Bob, Joe and Jane. Bob and Joe are each friends with Jane but are not friends with one another. Bob has chosen to "follow" activities for which Jane is directly involved. Jane shares a file with Joe.

In this example, Jane and Joe are each directly involved in the file sharing activity and together make up the Primary Audience for that event. Bob, having an interest in activities involving Jane, is the Secondary Audience. Knowing this, a system that produces or consumes the activity can intelligently notify each person of the event.

While there are means (based on the action type, actor, object and target of the activity) to infer the primary audience for many types of activities, heuristics do not work in every case and do not provide a means of identifying the secondary audience. The to, cc, bto and bcc properties MAY be used within an Object to explicitly identify the Primary and Secondary audiences.

[...]

Audience targeting information included within an Object only describes the intent of the object creator. With clear exception given to the appropriate handling of bto and bcc, this specification leaves it up to implementations to determine how the audience targeting information is used.

There is also 5.1.1 about audience and context which is non-normative, but says this:

Activities are rarely isolated events. Often, multiple individual activities will be performed around a similar context or audience. For instance, a collaborators working on a shared project might perform multiple related activities in the process of achieving some goal. Such activities can be logically grouped together using the context property, and scoped to a particular audience using the audience property.

For instance, the following shows two related activities that share a common context and audience:

Issues and interpretations

It is unclear what distinguishes "primary audience" from "secondary audience" from "audience". Delivery according to AP aside: When should a producer use to/cc/audience? What should a consumer do with to/cc/audience?

The only wording used, normatively or not, is that:

• [normative] the primary audience (to) is "directly involved"
• [non-normative] an object using audience is "scoped to a particular audience"

Per Evan: Audience is not for addressing; it's for defining the people it might be interesting to [...] The fact that it's called out in AP is a bug.

My thoughts

None of the wording above is clear or precise enough to establish a distinction, nor is there any practical difference between using to/cc/audience aside from implementation-specific rules and heuristics, such as:

• Mastodon treating cc: [Public, ...] as "unlisted", a visibility scope which excludes the post from public timelines (which is itself a mastodon-specific UX abstraction).
• Many implementations ignoring audience entirely.

For a compliant Server implementing C2S, there is no issue in delivering activities where the activity or the object contains an audience, although producing Clients should be aware that this will likely not be understood widely by consumers which generally expect only to/cc.

Idea: Use audience to signal who can fetch an object via cross-domain authentication/authorization?

Based on the (non-normative) wording for audience as being "scoped to a particular audience", we may interpret this as deciding who can fetch an object, even if it was not delivered to them with to/cc/bto/bcc?

Idea: Use to/cc on activities, and audience on objects?

Maybe prefer to/cc on activities since this will be used for delivery, and audience on the object? Caveats: the activity may need to be fetchable; the object may benefit from having primary/secondary audiences;

Idea: Use to to signal intent to generate a notification, cc or audience to signal intent to not generate a notification?

It is possible to notify someone differently based on whether they were in the primary or secondary audience. Primary audience may be interpreted as intent to generate a notification, whereas secondary audience may be interpreted as purely intent to deliver.

Idea: AP Errata to remove requirement to deliver to audience

This would drop audience to being optional metadata like tag or inReplyTo, and further enshrine only to/cc/bto/bcc as valid addressing properties. [Why, though?]