Topics in the #threadiverse

Matthias Pfefferle

i will catch up on the discussion, but I am not sure, I can be helpful here... I am relatively new to the Groups idea and try to figure out how to support it as best as possible and to be as compatible as possible...

a

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: content: "I said something." to: [] # this should be interpreted as notifying john cc: [as:Public, ] # this is interpreted as an "unlisted" post in mastodon parlance, and is necessary for delivery to mastodon currently audience: [, as:Public, ] # 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: cc: [as:Public, ] audience: [as:Public, , , ] in this case because 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.

[email protected]

An "Addressing" FEP would be very helpful. Public and private groups, followers-only and other limited visibility modes, circles and lists - implementers need a unified framework that will guide the development of these features.

[email protected]

In Lemmy each post belongs to single Group which is specified in audience. Having multiple audience values would be valid according to Activitystreams, but there is no way that Lemmy could support it. If I understand right, you are discussing about categories or tags here (where a single post can have more than one). Wouldnt it make more sense to use a different field for that case, such as tag which is used for hashtags?

julian

I think we're in a bit of a fortunate point in time where audience it's not used widely, so there are limited unintentional side effects to using it.

To expand on what I said earlier, while technically there is nothing stopping a context in NodeBB from being a part of multiple audiences, our UI is largely built around them only being a part of one.

To give additional context (ha!), private groups on NodeBB do not have their own space to talk (e.g. Facebook groups), they are literally a grouping of users. If you wanted to have a private space to discuss within group members, you'd create a category and limit it's access to that group. At least for me, it makes it much easier to think of when there are fewer moving parts.

So to that end, if we were to support federated private group discussions, the audience would just be the category (with access restrictions) those objects and contexts are posted to, exactly how 1b12 expects.

julian

The idea of whether or not to put the public collection in as:audience is semi-related. When @[email protected] mentioned it in-thread, I thought it made a lot of sense.

We are already iterating through to and cc for collections, but the public address always seemed like a one-off exception that needed special handling. I dislike special handling.

Jenniferplusplus

@julian On this topic, I whole heartedly vote that everyone be the change they want to see in the (de facto) spec.

`audience` for the Collection(s) of actors to whom the object is expressly available is the only thing that has ever made sense. `to/cc/etc` as the set(s) of actors to whom the object was specifically delivered is also the only thing that ever made sense.

Emelia 👸🏻

@jenniferplusplus @julian how do you decide on notifications? to/cc/bcc or tag -> Mention?

julian

@[email protected] @[email protected] typically two ways:

If mentioned in an object
New object encountered in a context that you "watch"

The latter is implementation-specific and is not available on Mastodon due to the lack of context.

Emelia 👸🏻

@julian yeah, I don't think anyone uses to/cc/bcc as a mechanism for notifications — I think everyone's settled on tag->Mention as being the “way”

julian

@[email protected] if coming from outside ActivityPub, the whole concept of addressing is foreign. It's only really used in the context of email... so trying to bolt on newer concepts like visibility and private collections may be challenging.

Jenniferplusplus

@julian @thisismissem It genuinely never occurs to me to use tags as a means of controlling notifications. In fact, the very idea that the sender has more control over notifications than the recipient is mind boggling.

a

julian:

audience it's not used widely, so there are limited unintentional side effects to using it.

julian:

technically there is nothing stopping a context in NodeBB from being a part of multiple audiences, our UI is largely built around them only being a part of one.

julian:

So to that end, if we were to support federated private group discussions, the audience would just be the category (with access restrictions) those objects and contexts are posted to, exactly how 1b12 expects.

I'm not sure those three things add up exactly. Having multiple items in audience sounds like by your own admission as something that would cause at least UI issues for NodeBB, and also probably bigger issues for 1b12 implementations such as Lemmy:

nutomic:

In Lemmy each post belongs to single Group which is specified in audience. Having multiple audience values would be valid according to Activitystreams, but there is no way that Lemmy could support it.

Now, this isn't an argument against having multiple items in audience. But it is something that needs more thought before pursuing it.

For what it's worth, I remain mostly unconvinced that the best application of audience is to list a bunch of taxonomies. I'm also not sure it should be a single Group actor. I could maybe see it being a private collection including all to/cc/bto/bcc; I could also see it being something that you copy over from the context.audience to your own object/activity audience. So I guess the next question is, how do you include or exclude yourself from an audience? If there were an actor for you to Follow or Undo Follow, then that seems straightforward enough... but addressing and audience doesn't really follow that kind of paradigm. So something else is needed.