Standardizing on ActivityPub Groups

[Claire]

(Apologies, I have injured my hands yesterday and I might write less and slower than I might have wanted)

@silverpill

What address format you’re going to use for groups in Mastodon, @group@server or !group@server, or something else entirely?

Group posts are not going to work by mentioning a group but by selecting the group in the UI, so there is no specific syntax for mentioning a group. However, at least in the current state of my (unfinished and unmerged) implementation, groups are actors that are in the same namespace as users, and also require webfinger (we might be able to lift this restriction, but it would require changes i haven’t started working on yet), so searching them would use @group@server.

@trwnh

*yet? I imagine this should be possible in the future, especially if Add is used instead of Create.

I am not sure. I think it’s way easier to reason about both UX and protocol if posts are restricted to only one group. It also falls in line with your own concerns:

@trwnh

But there should be some way to signal that a post is authoritatively owned by the Group, maybe?

And the restrictions @macgirvin suggested:

@macgirvin

A message MUST NOT be cross-posted to multiple groups.

@trwnh

Some thought will be necessary to differentiate those “groups” from Mastodon-compatible “groups”. The use of @type = as:Group is not enough.

I definitely agree here, and your suggestion of toot:Group seems fine to me, although I’m not sure whether that should be a toot thing (especially since, annoyingly, the toot namespace points to the general project website, not any protocol-specific page with readily-available documentation).

@trwnh

as:audience can contain either the Group IRI or an array of Group and as:Public. There is a slight pitfall in that some implementations may copy audience into to/cc and therefore copy as:Public, causing a group post to “leak” into the regular timeline for Mastodon 3.5 and below, but this is why I favor using an extension type as described above. Non-group-aware implementations will probably ignore the existence of toot:Group entirely, no?

How would the toot:Group not being recognized prevent the posts from being processed, though? Since the posts themselves would be regular as:Note or similar objects, and as:Public would be in the audience, the recipient does not need to know how to handle toot:Group to process the post.

@trwnh

Implementation detail: drop all interactions from non-members (inside the group context). If a post leaks out of the group context, then those interactions may be delivered to the inbox of a regular Person actor, but this is not much different than the issue presented by blocked actors/domains, or by non-reply-control-aware implementations in a FEP-5624 world. There is always the chance that a separate conversation may be taking place outside your control, and all you can do is ignore it or filter it out.

Yes, that’s why, as much as possible, I want group posts to be incompatible with group-unaware software.

@trwnh

Inbox forwarding? Although I’m not sure how to “guarantee” that inbox forwarding was performed or took place. I guess maybe Accept/Reject can be used to signal processing side effects?

Yeah, inbox forwarding seem like the natural way to do it, but this means you rely on the group actor distributing it, which you can’t guarantee. A malicious group actor could also send you an Accept and not forward anything. Forwarding also requires either LDSigning or making the whole activity publicly dereferenceable.

@trwnh

Replies should be visible if they are publicly dereferenceable via the replies collection?

I’m not sure I understand.