I'm trying to make sense of how audience is supposed to work in #ActivityPub and it feels like something is missing in the specification here both for AP and #ActivityStreams.
The documentation from AP:
Never uses audience targeting even in its audience targeting example.
Uses it almost identically to "to" or "cc"
On the part of AS it gets somewhat alluded to in 5.1.1, but not in the main section actually titled "Audience Targeting" (5.1) and says very little about it, just one example
@hrefna Letterbook uses audience in the way I think you're expecting. We would generally expect it to be a set of Collections (or links to Collections) for which the activity and/or its transitive object could be visible. Most often as:public and/or the actor's Followers. And we'll produce messages that look like that. We would expect the specifically addressed recipients to be in one of the To or Cc fields.
"The scope indicates that the audience for the note is only members of the Organization."
But it seems likely that something got lost in the shuffle, because the final #ActivityStreams says that it is the audience it might relevant to (which is not the same thing) and gives only a peripheral example contrasting its use with context, and not mentioning it otherwise, and in AP it is the same as to/cc.
This is irksome, because a) I already have to/cc b) I don't want the to/cc behavior when I specify an audience c) nothing specifies the behavior I do want, which is the behavior in the aforementioned ticket d) I can't tell how exactly audience is supposed to be used in #ActivityPub or how implementations may have interpreted all of the above.
But it seems like knowing this would be important
When people talk about the challenges of interoperability here, this is the sort of thing they mean
In actuality, I'm not even sure how you would use it in the way that it looks in the one example in #ActivityStreams, where it exists without any sort of attached unique identifier.
The example is descriptive, but not usable as written to infer behavior or meaning. I don't even have a good way to talk about who might be in said group: which actors or objects might be members?
I could use a collection, maybe, but what if I want to scope it to members of a server?
But since I want the functionality for my own purpose I have options.
I can ignore AP's use entirely, be noncompliant there, use it per the documentation in the original bug and hope that no one tries to parse it incorrectly later as part of forwarding-from-the-inbox
I can add a scope attribute which no one will read because they don't recognize it, so at least I don't get the incorrect behavior and can remain compliant
I can attempt to modify the spec and get frustrated w/ everyone
So to conclude my thinking-out-loud-rambling here, after reading the various docs:
I think that (2) is the best route forward overall. Basically define an extension or a standard around this, going back to the original "scope" language.
If I like it and can suitably define it I can publish it as a FEP, which I don't think would actually do anything but would make me feel better.
Then if the spec ever changes and a version handshake is introduced then I can modify accordingly.
Add comment