How do we handle Groups (Reconciling FEP-400e and FEP-1b12)?

Angus McLeod

This is a topic to track the FEP-400e and FEP-1b12 reconciliation, aka "How do we handle Groups". I've made this a wiki to let implementers describe their current status quo

https://codeberg.org/fediverse/fep/src/branch/main/fep/1b12/fep-1b12.md

https://codeberg.org/fediverse/fep/src/branch/main/fep/400e/fep-400e.md

Implementations

https://docs.google.com/spreadsheets/d/159_K48ICn53IYOIr0KT39luVJCqBBmmpLeL6Puc7XLE/edit?usp=sharing

See also

https://socialhub.activitypub.rocks/t/developers-meeting-2-groups/2302 https://socialhub.activitypub.rocks/t/how-to-use-groups/1005 https://socialhub.activitypub.rocks/t/groups-implementation/591 https://socialhub.activitypub.rocks/t/lets-discuss-groups/519 https://socialhub.activitypub.rocks/t/standardizing-on-activitypub-groups/1984

a

Adding on a complication: there is nothing actually special about the Group type in Activity Streams 2.0. It is an anti-pattern to assume support for specific protocols based solely on whether the actor is a Group or not. With that said: You can generally assume 400e or some variant if the actor contains the wall property from Smithereen's namespace. This property is used by Smithereen (which uses 400e) and also by the Mastodon PR for Groups (which in its current state uses 400e against the Sm…

[email protected]

To my knowledge FEP-400e is only implemented by Smithereen which has a total of 25 monthly active users. FEP-1b12 describes the mechanisms used by the vast majority of the Fediverse, namely Lemmy, Friendica, Hubzilla, Lotide Peertube, KBin and more. So there is really nothing to discuss, FEP-1b12 is the de-facto standard. Though it only describes the core mechanism, there are some aspects which arent documented yet. For example Lemmy support…

Angus McLeod

I agree with some of what you've said, insofar as FEP-1b12 is a good description of how Group actors are typically used, indeed that's why I followed it in the Discourse plugin (and appreciate you writing it!). However I would note that: FEP-400e is not just limited to Smithereen. For example it is the basis of Mastodon's outstanding Group implementation: https://github.com/mastodon/mastodon/pull/19059; FEP-400e is not in direct c…

Angus McLeod

@trwnh Those sound like good solutions! And I would second @silverpill's observations. To step back a bit, the thing we're attempting to do here - and this is more of a continued response to @nutomic's query about what the point of this discussion is - is to work through the practical implementation of the existing Group-related specifications, and their implications. As an implementor, the current set of FEP relevant to groups (FEP-1b12, FEP-400e and, indeed, FEP-7888) can be a bit confusing to…

Julian Lam

angus: @devnull One thing this is making me think is that the W3C task force could produce “implementation guidelines” that exist at a more “product” level, describing how to navigate the FEP landscape in an area like this, perhaps with some examples. Agreed, I feel like submitting a normative/prescriptive report would just lead to existing implementors actively ignoring them. That's why I mentioned (offline) that we should conduct surveys to make sure we know what the implementation land…

a

angus: If those groups of users were to be turned into ActivityPub actors, it is not yet clear to me how that would be disambiguated from the use of Group actors for taxonomies. I think there may be analogous issues in other platforms. In RDF you would use a class or type for this. So for example imagine a hypothetical type https://w3id.org/fep/1b12/Group which is distinct from https://www.w3.org/ns/activitystreams#Group in that the former has the semantic meaning of "this actor implement…

[email protected]

Exactly, the purpose of standards and FEPs is to describe how these things are already handled in practice. Not prescribe how it should be done, because implementers wont know and it may not actually work. And like I mentioned before, FEP-1b12 describes the way half a dozen major Fediverse projects work, there is no way they will all switch to a different implementation for zero practical benefit.

Angus McLeod

Absolutely! We're not trying to create a different implementation. We all have adopted FEP-1b12 already The goal is to understand how that works with the other standards which handle different, but related, concepts.

[email protected]

I'm not sure what all of this has to do with the original topic (reconciling FEP-400e and FEP-1b12). If you want to use FEP-1b12, that's fine. Others might prefer a different mechanism if it works better for their application. My question was specifically about private groups. Implementations based on FEP-400e already exist in the Fediverse. As far as I can tell, private groups based on FEP-1b12 exist only in a form of an RFC. So, unless there is some architectural flaw in FEP-400e, I don't real…

Angus McLeod

silverpill: Regarding FEPs: they do not describe how things are handled in practice. FEPs are proposals, and can be about anything, as long as it is related to Fediverse. I think what @nutomic meant was that FEP-1b12 attempts to summarise the most widely used approach to federation by Group actors, which I think it does. Nevertheless, as an implementor you're still faced with some questions like @silverpill's (i.e. about private groups), or how to deal with Mastodon's pending implementation, or how to think about this with respect to FEP-400e and FEP-7888. Navigating that thicket in a consistent way across the various implementations in #meeting:threadiverse-wg is the goal here. We definitely don't want to create another standard (que xkcd comic about a standard to standardise the existing standards).

[email protected]

It is true that many implementations of public groups used Announce activity to distribute posts before FEP-1b12, but FEP-1b12 also introduced additional protocol features. I don't know how widely these features are implemented today (perhaps this is something the working group could include in the report?).

a

angus: Navigating that thicket in a consistent way across the various implementations in #meeting:threadiverse-wg is the goal here. We definitely don’t want to create another standard silverpill: I don’t know how widely these features are implemented today (perhaps this is something the working group could include in the report?). devnull: we should conduct surveys to make sure we know what the implementation landscape looks like at current before attempting to write any guidelines. So I have to raise a tangential point here, which @devnull will probably be interested in as well: this is kind of what I set out to do in the WIP FEP i set out to start writing a week or two ago; at first it was 9988 "Federated Forums" to try to develop UX guidelines and map them to protocol affordances, but this eventually morphed into 8007 "A conformance profile for social networking services" (both titles pending of course). The general idea is that we all do certain things, and they map onto certain concepts, so we should map those common abstractions and primitives and try to concisely bound behavior of implementations such that you can actually know what to expect. I talk about this in 7888 a bit more, but there isn't actually a difference between the various spins of fediverse software. They're all just specific presentations of generic data. Or at least, on a protocol level, the abstractions of one specific presentation shouldn't leak in. What you have is objects or links, activities, collections. Those building blocks are then transformed into local entities, sure, but the primary focus should be on the protocol level building blocks and not on what any one platform assumes at a UX level. This is how you build commonalities. Practically speaking, a Note can be presented as a social media status or microblog entry or chat message or forum post or comment or whatever. And a Collection of Notes can be presented as a profile, thread, timeline, category, chat room, topic, et cetera. If the grouping is done with an explicit purpose, it ought to be declared as the context. With that said, there isn't really anything to "reconcile" about contextual grouping and distribution of activities. They're mostly orthogonal. The one point of intersection is whether any given actor will send out an Add or an Announce. And given that this is a working group for threaded conversations, it makes sense to me that the working group ought to describe how conversations are constructed. My personal opinion is that these conversations should be explicit based on context rather than implicit based on inReplyTo. Case in point: Consider the common forum use-case of "splitting a thread", which involves moving a post to another thread. That post may be a reply to a post from the original thread. It's important to be able to specify the intended grouping as a separate thing from who you're responding to.

julian

@[email protected] said:

My personal opinion is that these conversations should be explicit based on context rather than implicit based on inReplyTo.

Yes, that makes a lot of sense. The building of a context via inReplyTo is decently reliable but suffers from scaling issues. Given a superior method of deriving context (that is, having one provided by the object) would make things simpler, and more complete, if combined with a good backfill method.

Angus McLeod

@trwnh Thanks, this is very helpful. I agree with pretty much everything you've said. So from a practical perspective, for the purposes of implementation, this topic (i.e. reconciling FEP-400e and FEP-1b12) essentially boils down to trwnh: The one point of intersection is whether any given actor will send out an Add or an Announce I think it would be helpful to work through an example of where this particular point of intersection may become an issue. trwnh: Consider the common forum use-case of “splitting a thread”, which involves moving a post to another thread. That post may be a reply to a post from the original thread. It’s important to be able to specify the intended grouping as a separate thing from who you’re responding to. So, this would result in something like: You receive Note 2 (with context A, a collection) which is inReplyTo Note 1 (with context A) You receive an Update to Note 2 and it now has context B (a collection)? OR perhaps you receive an Add of Note 2 to context B? In both 2 and 3, the inReplyTo would still be to Note 1, which would still have context A. @trwnh something like that?

a

Yeah, pretty much. angus: I think it would be helpful to work through an example of where this particular point of intersection may become an issue. Say you encounter an actor of type Group. You Follow the actor. You can't expect it to behave in any one particular way, but it will generally behave in one of these ways: It is a "normal" publishing actor. You will receive Create Object, Announce Object, Like Object, and so on. It is a boost bot. You will receive Announce Object for any object sent to it, mentioning it, etc. It is a 1b12 actor. You will receive Announce Activity, and other activities described in 1b12. It is a Smithereen-style actor. There will be a wall property, and it will send out Add activities where the target is that wall. The Add.object will also have a target, and this will match the Add.target as per 400e. Bonus: It is a context moderator. You will receive Add activities where the target is the object.context. It may also additionally be a "normal" publishing actor. So for any given "post", it might be a Create/Add/Announce/Announce-Create. This isn't limited to Group actors, but it is most prevalent in Group actors because of the popular (erroneous) interpretation of Group as equivalent to Facebook Groups. One final thing to note is that "normal" publishing actors and context moderators may be any type, not just Group -- there is no specific type dependency for these mechanisms, as they are the intended mechanisms. angus: So, this would result in something like: You receive Note 2 (with context A, a collection) which is inReplyTo Note 1 (with context A) You receive an Update to Note 2 and it now has context B (a collection)? OR perhaps you receive an Add of Note 2 to context B? In both 2 and 3, the inReplyTo would still be to Note 1, which would still have context A. @trwnh something like that? Yup. id: type: Note attributedTo: context: content: "I'm posting in a thread" --- id: type: Note attributedTo: inReplyTo: context: content: "This post is in a different thread but still replying to the first" --- id: type: Article attributedTo: inReplyTo: name: "Some Article" summary: "In which I reply to a forum post with an entire blog post. This is not part of any context." content: "

Lorem ipsum dolor sit amet...

"

Michael

silverpill:

My question was specifically about private groups. Implementations based on FEP-400e already exist in the Fediverse. As far as I can tell, private groups based on FEP-1b12 exist only in a form of an RFC.

Friendica, which follows FEP-1b12, does support private groups as well. We implemented them just like the public groups. The only addition is that the author system fetches the list of the group members, so that the access can be controlled.

[email protected]

How the list of group members is represented (some property on a group actor I guess)?Do you fetch announced activities from the server of origin when that server is different from the group actor's server?

Michael

The list of group members is retrieved via the "followers" endpoint of the group with a signed request. Only if the signer is a member of the group can they retrieve the data. The permissions in the sender's post are then set to all group members. The server makes a regular "announce" activity. The other servers then make a signed request to the sender's server so that only members of the group can retrieve the post.

julian

The server makes a regular "announce" activity. The other servers then make a signed request to the sender's server so that only members of the group can retrieve the post.

I think this makes sense, even if it's not as explicitly segregated as @[email protected]'s conversation containers. There is one concern in that an announce would still mean that the existence of the post would be known, even if not retrievable by members outside of the group.

Not necessarily a concern when you consider that the announce would only be addressed to group members, but when you use shared inboxes, then it gets a little more confusing... or does Friendica's implementation of private groups via 1b12 explicitly not target shared inboxes?