IIRC the Mastodon plan is to not have mentionable groups at all. Instead, Mastodon groups exist in their own context and all posts/replies are hard-coded addressed to the group. They are completely separately scoped, and will not show up in the main timelines at all.
As far as Webfinger is concerned, @groupname@domain may be required, but there is less reason to do this compared to user profiles.
re: definition, most of it makes sense.
This is an implementation detail. For Mastodon, it probably should be.
*yet? I imagine this should be possible in the future, especially if Add is used instead of Create.
re: initial implementation, this also makes sense, bearing in mind that it is initial implementation.
re: ActivityPub:
Group type is fine, but perhaps some extra extension properties or types should be used to signal how the Group works on the backend. There are some existing projects that already use Group actors for mailing-list-like use cases. Some thought will be necessary to differentiate those āgroupsā from Mastodon-compatible āgroupsā. The use of @type = as:Group is not enough.
There needs to be a way to signal that a Group is a ājoinableā Group and not a āforwardingā Group. Or it may be both. Perhaps an extension type like toot:Group instead of as:Group? Perhaps an extension property like toot:joinable?
I somewhat favor the first of these two options, as it makes clear the distinction between the typical ActivityPub delivery model (Follow, inbox forwarding, get from outbox) and the proposed mechanism here (Join, distribute an Add, get from wall). Projects that support both models may declare a type array like @type = [as:Group, toot:Group]. This would signal that the Group may be both Followed and Joined.
The downside to using a property like toot:joinable instead is that any implementation that does not understand this property may attempt to send a Follow rather than a Join, which may not be understood. But on the other hand, it is more generic, and could be used to signal (for example) that an as:Organization follows the same Join-based semantics.
It may actually be a good idea to use both.
Join, Accept/Reject Join, Leave, thatās all fine too.
Sending posts and replies to the group for redistribution is fine too and probably necessary for the proper UX. But there should be some way to signal that a post is authoritatively owned by the Group, maybe? FEP-400e (or similar) is certainly one way to do this, as a group āwallā is assumed to be managed by the Group actor, and Add/Remove into that āwallā simplifies both distribution of activities and also avoids semantic issues about what it means to Delete someone elseās object. My only concern with FEP-400e as currently written/finalized is in its use of āabbreviated objectsā, which doesnāt seem JSON-LD compliant to me.
re: open questions:
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?
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.
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?
Sending a GET to the group wall with an HTTP Signature should return at minimum any posts authored by the owner of the signature. If the signer is also a member, the GET should return all group posts as well. This should allow prior members to view their old posts and delete them if they wish.
Replies should be visible if they are publicly dereferenceable via the replies collection?
Add/Remove to the members collection, if it matters (and group membership is publicly visible). The members collection should maybe use the same HTTP-Sig mechanism as the wall, so that anyone can check if they are a member by whether they are included in the partial Collection returned. Or you could rely entirely on keeping track of the history of Join / Accept Join. Thereās also your follower collection synchronization FEP that could help in shared server scenarios.
Actor tokens could work, bearcaps could work if fetching the wall is the primary method of interfacing with a group. And one other option is, if you implicitly trust the group to verify everything and not commit forgeries, then it can forward activities without a signature. But for verification it would probably be a good idea to use bearcaps. Iām not sure what that implies for scaling.
Either with Offer Remove, or as an implementation detail you could have the Group send out a new Remove attributed to itself if it was received from a member with the appropriate permissions.
Looks best option of the two, and has positive side-effect that itāll encourage fedi apps to support type arrays. However, wondering about toot:Group. The namespace prefix ātootā more or less indicates: This only applies to a Microblogging domain. But what you are modeling is Membership. A generic concept.
In ActivityStreams-Core par. 4.3: Actor is mentioned:
This specification intentionally defines Actors in only the most generalized way, stopping short of defining semantically specific properties for each. [ā¦] External vocabularies can be used to express additional detail not covered by the Activity Vocabulary. VCard [ vcard-rdf] SHOULD be used to provide additional metadata for Person, Group, and Organization instances.
VCard spec has a vcard:Group, but also mentions that since it became recommendation other ontologies have appeared, such as The Organization Ontology (highlights mine):
This ontology is designed to enable publication of information on organizations and organizational structures including governmental organizations. It is intended to provide a generic, reusable core ontology that can be extended or specialized for use in particular situations.
This ontology is widely used, well understood. Though it has kinda of an intricate modelā¦ it defines Membership, Roles and more:
Now I donāt know how that would look like as AS msgs. Where the diagram says FOAF we have Actors. We might have @type = [as:Group, org:Organization] and some membership construct to indicate a āGroup with Membershipā (group and organization arenāt disjoint). In a similar way there may be a use of org:Role to model - in the case of a Microblogging domain - Moderators and Admin members. (While e.g. in a federated forge app the same ontology is used to define a role of Project Maintainer).
Biggest downside to me seems that now you are using a custom property to basically state that this is a different type of Groupā¦ one that supports Membership. Within the context of the Microblogging domain of ātootā vocabulary that may be acceptable, if everyone consents with it, but to my untrained eye it looks not to be a mechanism that scales well for broad interoperability (though a combination of a toot:Group in the type array with this property may be perfectly fine).
no, the toot namespace has no such meaning. it means nothing at all outside of being a shorthand for the https://joinmastodon.org/ns# namespace, which is for vocabulary defined by the Mastodon project.
in any case, the namespace really doesnāt matter. we just canāt use the as namespace because thereās no proper viable path for extending the ActivityPub core spec at this point in time. toot is fine for Mastodonās purposes.
Agreed. I formulated like that because it has become more or less a de-facto standard if you wanna have a microblogging-compliant app AFAIU.
(OT: It does bring up the use of namespaces in vocab extensions that are predominantly used, where currently there are only/mostly app-specific ones in use)
If there was some kind of organization or working group that could adopt extensions into a common namespace, then sure, you might have a point, but right now the development of extensions is led by individual projects and implementations. There was LitePub for a while, but that was more about dropping JSON-LD and adopting HTTP Signatures. Perhaps the FEP process could manage its own JSON-LD context file, which could make it easy for projects to adopt all the FEPs at once by simply including one additional context. But this isnāt strictly necessary. It would also save having to add toot, pixelfed, sm, misskey, and so on, thoughā¦ and it could be a more neutral/agnostic way to handle extensions that are developed by multiple projects in collaboration, so that no one project claims the definition unilaterally. But this isnāt really important or significant at the end of the day.
Yea. It is OT on this thread anyway, but I think it is very relevant and some better process ultimately needed.
(Apologies, I have injured my hands yesterday and I might write less and slower than I might have wanted)
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.
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:
And the restrictions @macgirvin suggested:
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).
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.
Yes, thatās why, as much as possible, I want group posts to be incompatible with group-unaware software.
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.
Iām not sure I understand.
This absolutely doesnāt have to be done on first iteration, but I imagine crossposting in groups to work much like Reddit crossposting. You could arguably do this with an Announce and then reply to the Announce instead of to the original Note, kind of like how in really early Mastodon you could reply to boosts due to a bug. Iād much rather not worry about that right now, though. But I will point out that FEP-400eās answer to this is to use the target property on the Note itself, to signal that the Note is part of the wall collection? I still have concerns about 400eās use of stub objects and how that interacts with JSON-LD processing, though. So there might be a better solution here. I kind of wish we could use partOf from the CollectionPage properties hereā¦ Iāll think about it later.
There was some later discussion in this thread about possibly putting things under an FEP-managed namespace that would be defined by a proper JSON-LD context document, perhaps that would be worth pursuing at some point? That context document could also alias existing properties for compatibilityā¦
attributedTo as an array could include the Group? IDK if this is the best solution, though. And maybe itās not the kind of thing we can entirely prevent, as it is always possible to author an activity and deliver it to both a Group and to other recipients.
I mean, you canāt guarantee anything as soon as there are other actors and other software involved. But if āthe group is responsible for distributing everythingā is an already-decided-upon constraint, then you donāt really have much choice.
Depends on how much you trust the Group actor and the software itās running on? It may be that someoneās security model allows for implicitly trusting the Group and its software to not be malicious, although having better verifiability is always nice, and you can get that verifiability by fetching with bearcaps I guess as a 3rd option.
re: āWhat about replies to posts by people who have left a groupā: If the replies collection is provided and publicly accessible to non-group members, then replies are visible. But the person who left the group will not be notified of new replies, because the Group will not deliver Add activities or forward anything to them. Unless some software addresses the author of the post in addition to the group, that is? The challenge seems to be in deciding whether or not the ex-memberās replies should be distributed to the group members or not. If not, then it would be possible for people to reply to an old post, but the author of that post wouldnāt be able to respond in anything other than what is effectively a regular DM outside the group. If yes, then thatās an exception to āonly group members can post in the groupā.
Yes, thatās what FEP-400e suggests (SHOULD), and that seems fine to me.
Same.
It could work, though the semantics sound a bit muddy to me: would that mean the group is a co-author of the post? Is that something we want to represent this way?
Well, weāre discussing making group-unaware software not process the object so that even if they receive it, they wouldnāt interact with it. Now, if someone deliberately crafts two versions of the activity or something, I donāt think itās a situation worth concerning ourselves with.
How would that work?
I think every proposal so far forbids that.
re: 400e and target on objects: nothing new to say, havenāt thought of anything better yet, it might still be enough to have addressing to the group and forego the use of target unless it provides something useful.
re: delivering to a group as well as additional recipients: i meant more that you could send one activity that would be interpreted differently in aware and non-aware impls, and the āfallbackā would be a regular status. thatās not technically impossible or disallowed, to post to a group and to your followers (in a non-Mastodon implementation, anyway). it might even be explicitly intended to have the Note play ādouble dutyā in that way. you could also author an activity representing posting into multiple groups. i donāt think thereās a way to restrict such usages ā we can only recommend against them with SHOULD / SHOULD NOT, if itās deemed worthwhile.
re: attributedTo arrays including the Group: yes, it would imply semantically that the Group co-authored the post. this may or may not be a good idea, given that it might allow for Create/Delete/Update/etc based on the authority of the Group rather than the original author.
re: bearcap verification flow, it would be similar to the āpublic dereferenceableā option, but with fetching a bearcap URI instead of an HTTPS URI. Itās essentially just one step below public, since you need a token (which is provided by the bearcap, much like leaving a key under the front doormat). This could be āgood enoughā for non-pirvate groups. I imagine private groups will want LD Signatures or something similar, as they would want to not be fetchable under most (if not all) circumstances.
I mean weāre defining extra vocabulary, its meaning and their expected behavior. Of course we canāt prevent an implementation from producing documents that go against what we define, but that seems beside the point? Weāre defining group posts, and Iām talking about defining them in such a way that implementations that do not support this extension do not fall back in an unexpected way. We can decide to require group posts to not āplay ādouble dutyāā. Of course an implementation could decide to do otherwise but it would then not be compliant with our extension and should not expect its behavior to be supported.
Iām not sure what use bearcap would be for public posts. Iām also not sure how it would help you with verifying that a Delete has been properly distributed to group members. What would you even try to fetch to make sure of that?
What form of language would this take? āImplementations MUST NOT address actors other than the groupā? Or would that be a SHOULD NOT? āImplementations SHOULD NOT address actors other than the group, as this would cause undesired behaviour in non-aware implementationsā? If itās a SHOULD NOT, then thatās basically what I was suggesting earlier ā a recommendation for behaviour. I can still see how someone would want to post into a group and also to their followers, though they would have to be aware of the consequences of such an activity.
In actuality, I think it might not be so important to forbid this or guard against it, if the undefined behaviour can instead be defined. You could say that the group has its own rules for distributing posts and replies (to members only), and this can coexist with the classic direct-distribution method. There will just be some replies that the group will not be aware of, and there will be some replies your followers are not aware of, and thatās probably okay.
The relevant required behaviour for the group is to distribute anything received from its members, to other members. As long as it does that, is there necessarily a problem with anything else? After thinking about it a bit more, Iām inclined to say that there isnāt. The only issue is that if Mastodon wants to ensure its expectations are met, then other implementations SHOULD NOT address to other than the group. And this issue is basically only an issue because of prior versions of Mastodon checking for as:Public as the first thing when attempting to determine scope/visibility.
Maybe it would be a good idea for group-aware impls to adopt the zot/nomad replyTo property? This way, if they see the replyTo property present on the object, they should completely ignore to/cc/audience/inReplyTo when calculating the addressing, and just copy the value of replyTo verbatim into the to property of the activity. Essentially, this would allow group-aware impls to not leak posts to non-aware impls.
The potential downside to replyTo is that you would need to add some logical checks so that it doesnāt get abused. I can imagine someone crafting an activity with a replyTo set to someone else completely unrelated, and implementations start DM-spamming that other person. Iām not sure which logical checks make sense hereā¦
Maybe the value of replyTo must be either in attributedTo or audience? That would still allow setting an audience of someone else and replyTo of someone else, though. Definitely needs more thought here.
Maybe this should be combined with FEP-400e and the logical check would be if replyTo == target.attributedTo? That would leave the usage of replyTo on its own as undefined behaviour, thoughā¦ Maybe while defining replyTo we could just have a generic āimplementations MAY apply their own spam-filtering policiesā?
Maybe instead of a logical check, this should be exposed in the UI to the user, so they know who they are replying to? Then, the user can decide if their reply would be āspammyā or not. (I think this is how Reply-To headers work in email.)
Maybe the property isnāt necessary, and all you need is the SHOULD/SHOULD NOT guidance on addressing the group?
Is distributing the Delete necessary, or is it enough to Remove the post from the wall? I think we still need to figure out how posts should be distributed by the group. I was assuming that the primary mechanism would be Add/Remove to wall, and Iām not entirely sure how to handle deletes and edits.
Thereās two parts here: the first is what to send to the Group, and the second is how the Group should respond.
Actually, thereās another thought I just had:
And another thought:
I think having type = toot:Group and having your outbox be full of āAdd/Remove to wallā activities might be enough to guarantee a separated UX. This way, non-aware impls will fail to parse the actor when resolving them, and even if they did manage to resolve and successfully Follow a toot:Group, they wouldnāt know what to do with any of the activities they received unless they added support for walls. Thereās no need to break from the āmailing listā metaphor if it still works. It would just be a slightly different interpretation of it (with Add/Remove instead of Announce).
My point is that maybe this should be a MUST NOT rather than a SHOULD NOT, as suggested in Standardizing on ActivityPub Groups - #48 by macgirvin
That would lead to a fractured and confusing user experience, especially in a āposts and commentsā approach. Another issue is software that does not understand groups but will do so in a subsequent version: for instance, if current Mastodon would be to understand āgroup postsā as regular public posts, there would be nothing in the database that would allow a migration to re-interpret it as a group post. As a result, once updated to group-aware Mastodon, the instance would behave differently for group posts and their replies based on whether they were discovered before group support was added, or after the fact. Some other software does store enough information to possibly re-interpret the posts after an update, but Iād wager that even in these cases, the sheer logic and computational complexity required for doing that would be prohibitive.
The same question applies if itās a Remove. How do you ensure the Remove has been distributed to other group members?
Join and Leave seem more semantically explicit than Follow and Undo Follow, Iād say the only reason to use the latter is to keep compatibility, but we want to explicitly avoid that, soā¦
Considering the requirements for Mastodonās initial implementation to:
What about the following proposal?
type: "toot:Group" (the intent is to explicitly break compatibility with existing Mastodon versions)sm:wall collectionaudience attribute with either as:Public or the members collectionJoin and Leave (replying with Accept or Reject)sm:members collection that SHOULD be dereferenceable by at least group membersattributedTo
There should also be something to tell whether members are to be manually approved, and something to tell whether non-members are allowed to post, but Mastodon can still make safe assumptions which will only degrade UX a little if they donāt match reality.
target
audience set to the groupās members collection (for group-private posts) or an array with (as:Public and the groupās members collection). The purpose is to make sure the post is intended to be publicattributedTo the group actor and the postās author (the intent is to explicitly break compatibility with current Mastodon versions)To be honest, I am not too sure about using attributedTo for that, but it seems to be a good way to break compatibility with the current implementation. Iām also not sure about using sm:wall for replies: it sounds like itās not what posts-and-replies implementations would want, but Iām not sure any other mechanism has been proposed for that.
One interesting issue is what should happen if a groupās privacy model changes other time? If such a thing is allowed, and a group switches from public to private, what does it mean for existing posts? And what does it mean for the Mastodonās initial implementation plan of only handling public groups?
if the group goes āprivateā then it could be disabled in mastodon? āThis group is a private group. Mastodon currently only supports public groups.ā And then grey out the Join button, and disallow current members from posting into the group? Optionally, do not show the wall. If/when Mastodon supports private groups, simply re-enable the UI around them.
On a protocol level the only practical consequence is whether the sm:wall[items] is publicly accessible or not (and similar logic extends to sm:members too, probably).
One small point of deliberation about whether itās really necessary to be setting audience on the group, wall, and post, and what each use of audience implies.
audience on the wall: could be used for hinting who has full access to the wall.audience on the post: not strictly necessary but nice to have for if the post is discovered on its own, outside of the group wall.audience on the group: this could be general visibility expectation of the group metadata?Otherwise Iām a little worried about how many MUSTs are in there ā can any of them be turned into SHOULD instead? Maybe sm:members is better as a SHOULD.
Also, is it necessary to set the audience to the sm:members collection? Why not setting the audience to the Group actor directly? The Group is the one in charge of distributing everything, anyway, so you donāt need to explicitly address its members for delivery.
This discussion seems to be the topic of the year and became quite large and impractical to follow. Maybe the #software:mastodon implementation specifics should move there, especially as it only concerns public groups.
Maybe the third point could then become:
audience attribute. When audience is unset, it SHOULD be assumed to be the Group actor. An explicit audience of as:Public MUST be set for public group activities.OR
type: toot:PublicGroup
So that the audience is expected to and assumed to be as:Public. This would also save the shorter Group label in the namespace for a more common definition that could be shared across implementations, building on the as:Group specification.
I am unsure about point 5 and 6. They both introduce quite heavy privacy concerns. In a publish-subscribe mechanism, what is the point of having the sm:members collection? Subscribers should be enough. Listing the administrators in attributedTo call for āresponsible peopleā that could be targeted by authorities, and you probably donāt want to turn a group into a liability for its administrators. Addressing the group in case of an issue with that group should be enough. One issue I foresee when using AttributedTo administrators, is that people tend to leave things behind, and if the list is not updated, some group activity could then be attributed to someone who has nothing left to do with the actual group. Note that the āadministratorsā could as well be a Service actor or something not tied to an individual, but then it should be thought about beforehand, not to encourage implementations to default to pointing fingers at people.
Could this be an extensible set of flags? Would this be better handled as a single membership binary field that would include approval and posting privilege, or would it be better to use specific boolean fields?
And to comment on the original suggestions by @macgirvin:
I suppose this is because members from multiple groups would then receive multiple copies. It could also potentially dereference to thousands of targets and cause DOS. Etc. But then you would require specifying which group will be receiving the messages when more than one is mentioned. E.g., the first one mentioned. Would the others then be dropped from the activity itself? What happens if one group is private and the next one public: the message would fail to propagate at all?
The reasons for this are a bit unclear. I would totally go for the first sentence, and forget about the rest, unless thereās a good reason for it, but the simpler the better: if you post to a group, that group receives the activity, period.
Iām still unsure about the benefit of adding Join/Leave instead of using Follow/Unfollow. As mentioned before:
In summary, I think this discussion should be summarized a bit and a few directions explored:
Follow/Unfollow vs. Join/Leave
I know #fedicamp and recent meetings online have been discussing groups as well. Some synthesis might be in orderā¦
But still possibly get new posts (depending on the protocol details)? The two reasons for limiting ourselves to public posts for now are implementation complexity, and having groups that can be effectively moderated by instance administrators without breaking privacy expectations.
I guess sm:members could be a SHOULD. The reasons for requiring sm:members are UX expectations (seeing who is in the group before joining it) as well as Mastodon implementation details (mentions are still tied to visibility/notifications/ā¦ so the in-progress implementation does allow mentions but only to group members; that really is an implementation detail, though, and eventually, weād probably want to decouple mentions from their side-effects).
Distribution and audience do not necessarily match, and there are occurrences where you can fetch a group post rather than it being directly distributed. In this case, how does server software decide who it can show it to? The post having the group in its audience could be interpreted as group members having access to the post, but the group collection is semantically clearer.
Why not! This prevents the use cases where you change a groupās privacy settings, but thatās a use case that is difficult to make sense of, so why not!
Knowing who is part of the group is usually expected from group members and would-be group members. Also, for short-to-middle-term Mastodon, implementation details described earlier in this post.
What do you mean by āaddressing the groupā? My proposal does not include any mechanism to write āto the groupā rather than āin the groupā, and the latter may require membership.
Iād say individual fields.
Neither his nor my proposal includes mentioning a group as a core mean to write in a group (although his proposal leaves the door open to that).