Overlapping taxonomies and the audience property

ActivityPub Threadiverse Working Group
11

synthesis time

i think the use of audience is basically “here’s everybody that can/should see this in a feed”. whereas to and cc are for notification policies (with to being intended to actively generate a notification). delivery happens for all of them, but after delivery, the consuming application needs to reconstruct possible intentions.

BUT

this doesn’t chime with the current usage by mastodon et al. with mastodon, audience is generally ignored, only to and cc are considered, and notifications are instead determined by the presence of a Mention in the tag array. (which imo shouldn’t generate a notification at all? you should be able to mention someone passively if desired.)

so we have the intended ideal of audience being used for delivering to, well, audience… and to/cc for generating active/passive notifications. but instead, we have a situation where to/cc are used for delivering to an audience, and Mention tags are used for generating notifications (and audience is ignored).

If we want to have a compatible migration path forward, then for now:

  • to should include anyone you want to notify
  • cc should include everyone else you want to deliver to
  • audience should include the sum total of both of these? (but if you want to support bto/bcc, then it realistically needs to be a private Collection)
    • alternatively, audience should include any actors whose feeds / activity-streams should include this activity/object. (this still works out in practice to anyone mentioned, plus your followers, plus probably as:Public – which is likely the union of to and cc anyway)

sample object/activity targeting for a basic (read: microblogging) use case:

content: "So here's what I have to say..."
inReplyTo:
  - attributedTo: <john>
    content: "I said something."
to: [<john>] # this should be interpreted as notifying john
cc: [as:Public, <your followers>] # this is interpreted as an "unlisted" post in mastodon parlance, and is necessary for delivery to mastodon currently
audience: [<john>, as:Public,  <your followers>] # this is interpreted as showing in john's home timeline, as well as your follower's home timelines, and also being accessible to anyone without authentication

so maybe the use of audience can address mastodon’s fears of showing “group” posts in home timelines? i know this is a big concern that mastodon brought up with their current groups PR, they very explicitly do not want group posts showing up in home timelines… perhaps some heuristic can be designed so that newer versions of mastodon can filter out posts from home timelines if someone is not included in audience?

sample object/activity targeting for a more complex (read: forum/discussion) use case:

content: "synthesis time. i think the use of audience..."
context: <this thread>
cc: [as:Public, <my followers>]
audience: [as:Public, <socialhub/threadiverse>, <socialhub/threadiverse/followers>, <this thread/context's followers/audience>]

in this case because <my followers> are not in audience, an updated/newer mastodon et al can know not to display this post in my followers’ home feeds. there’s still the sticking issue for mastodon in how they can get older, non-updated mastodon servers to drop the post, although i really think this is foolish, personally… you could still do it by using only audience and then older mastodon will drop the activity because it doesn’t understand the recipients.

1 Like