Join activity is fine and we should use it

[evanp]

The Follow/Accept/Reject issues listed in section B.1 are mostly due to not having collections for pending followers/following. That's what FEP 4ccd is for.

We could use the same model as FEP 4ccd for groups. An actor can have a collection of the join activities they have sent which have not been accepted or rejected; a group actor can have a collection of join activities that have been received and not accepted or rejected.

Best of all, it gives us a clean upgrade path from the Follow-based groups of FEP 1b12.

[trwnh]

"Pending" collections don't fully solve the problems with using activities to represent both a pending action and a completed action, or the problems with needing to be aware of all future activities to know whether a Join was Accepted or Rejected. This is an existing problem with Follow activities that implementation experience has shown to be problematic, for the reasons currently cited in https://swicg.github.io/groups/#join-requests:

This design from ActivityPub has the following shortcomings and issues:

• Lack of atomicity. The Follow activity does not describe an actual event until it has become the object of a future Accept, while also not being the object of any future Reject or Undo.
• Lack of consistency. A Follow activity being referenced as the object of both an Accept and a Reject leads to undefined behavior and indeterminate state. Having an Accept Follow activity is not enough to infer a following relationship.
• Lack of isolation. More than one Follow activity may exist, and it is not possible to establish which Follow activity is the currently "pending" one without unbounded knowledge of all relevant activities, including future activities.
• Lack of durability. Losing track of a Follow activity can mean you are no longer able to Accept, Reject, or Undo it. In practice, the implicit existence of a "follow state machine" with that state distributed between both peers has led to many bugs and implementation errors that can be impossible to recover from without manual intervention from one or both service administrators. Attempts to work around this involve "partial follower collection synchronization", which is complicated and not implemented widely.

It can seem appealing to mirror the Follow activity flow and its side effects, but with the Join activity instead of the Follow activity -- perhaps assuming that familiarity with the existing Follow flow will make it easier to implement a parallel Join flow. However, doing so inherits all of the aforementioned issues and would lead to a repeat of the implementation errors faced in practice.

If we use Join to represent both "a request to join a group" and also "actually joining a group" at the same time, then not only do we have ambiguity, but we also have to be aware of all possible future Accept/Reject activities, which is not feasible. On the other hand, having the Join activity reserved for "actually joining a group" removes this ambiguity and doesn't need knowledge of the prior Accept or a future Reject.

The use of a separate Membership entity/class (#47) gets rid of the other problems around state management.

[trwnh]

I think the way to best illustrate the divide here is to consider what a Join activity means outside the group context vs inside the group context.

Outside the group context, you can imagine it as a "Join" button, or possibly an "Accept Invite" button.

Inside the group context, you can imagine it as a Join activity:

If we adopt this mirroring the existing Follow flow, we get a flow like this:

1. InviteToGroup¹ -- the group actor² offers you membership
2. Accept(InviteToGroup) -- you confirm your membership with the group actor
3. Join(Group) -- inside the group, the other group members are made aware that you joined

But we've seen multiple ways in which the Follow activity has led to implementation and UX bugs. Even Accept/Reject is not enough to make it work correctly, and all it ends up doing is introducing a state desync potential, which I've personally encountered multiple times and had to report several bugs to projects like Mastodon, Akkoma, and Misskey, and the follow management flow is still buggy, with irreconcilable state desyncs in some cases.

This is why I strongly believe the group itself should be responsible for managing its own state, instead of having it leak into the message-passing protocol layer. At the very least, the distinction between "request to join" and "actually joined" needs to be made. Activities that are actually requests to manipulate the state should be handled differently than activities that represent the state change.

Footnotes

1. Here, "InviteToGroup" can be expressed in multiple more-or-less functionally-equivalent ways: it could be Offer(Membership); it could be Invite(Group, Person); it could be a standalone activity -- the exact representation is left open for now. (There's a potential ambiguity with Invite to an Event, which could be resolved by multi-typing with a more specific type, but I'm leaving that out of scope of this issue.) ↩

2. The way that you initiate the group sending you an InviteToGroup is also left open, but can be triggered by any agent knowing your inbox (to send you the InviteToGroup directly), or by any client knowing your outbox (sending some activity requesting an InviteToGroup be sent back to you). ↩