Standardizing on ActivityPub Groups

aschrijver · September 13, 2021, 9:02am

Thank you both @macgirvin and @yala. You two have deeper technical and theoretical knowledge than I possess, but I’ll do my best to follow-up with some elaboration and musings. The notion that we may not be far from realizing this already is great.

We have Groups, a rather concrete concept that always has been in the specs. And we have Communities, a much more abstract idea that uses groups to model social interactions more like they exist in the real world.

Current scope of discussion?

First requirement is: Analyse existing Group implementations, and see if there’s a common model we could start with that requires the minimum amount of rework, and avoids breaking changes where possible.

In the discussion thus far I found most of the focus to be on this requirement, and envisioned groups support in apps to be how we commonly experience them in most software. In summary our discussed requirements / functionality seemed to boil down to:

We have groups (Group actors are exposed on the network) and people (Person actors) that participate in them.
Person actor either Follows or Joins a Group, but the mechanics and difference between them need to be clearer defined still.
Groups themself have certain characteristics, e.g. Open or Closed, but we need to discover how to define these best.
Participation in a group comes with privileges and some kind of permission model. This may or may not be in scope.

That’s a great start, and in the ‘maturity model’ I mentioned this could be the basis, the foundation for groups support. Conceptually what we no have are:

Deliverable: People can follow and join Groups across the Fediverse.

A Follow relationship probably relates to a passive participation, where they just want to be informed, while a Join relationship is established to allow them more active participation. You might label them as following and member_of relationships, maybe.

All-in-all two relationship types in the above. I don’t know how well they fit in current implementation of actors, and how you’d discern between a follower and a member. Maybe current implementations make an either/or choice in what they support. In the model I imagine both Guppe (followers) and Smithereen (membership) have a convenient way to implement. Both are supported.

Support more intricate relationships?

I don’t know what use cases we want to facilitate that need more mature levels of Groups support, and some of them may require other parts of the specs to be extended first, e.g. by having Capability Negotiation or something like that.

But let’s just brainstorm a bit… some random thoughts follow:

Take this Discourse forum. It represents the SocialHub community, and we have membership via our account. The software automatically places us in groups. We start in trust_level_0 and based on interaction we are also added to trust_level_1, trust_level_2, etc. And we gain privileges that correspond to policies attached to these groups. Similarly, if you make someone Moderator, they are auto-added to a moderators group, and also a staff group. And custom groups can be defined.
- → There’s a topology to groups which allows them to be nested and span overlapping subsets of members from their parent.
On the Fediverse we consider instances to be communities. But other than some apps having an actor that represents the server, we don’t have a Group actor that represents this community. What if we had? Take for instance Lemmy. I might join Lemmygrad, a community for people interested in communism. Then I’d join other Lemmy communities, some owned by Lemmygrad, some elsewhere. The ones on Lemmygrad might again indicate a need for nested groups (currently unnecessary as Lemmy doesn’t give special meaning to such relationship right now)
- → Instances defined as groups means they’re now 1st-class citizens of the fedi.
- → “instance” is now a technical concern. The instance community / group actor(s) have their own Profile to characterize them.
- → There’s still the need to have instance / server actors. Nothing much changes wrt what they are used for.
We have a couple of standard actor types, but can also define custom actors. What does it mean if they participate in a Group? What if e.g. a community allowed both individual people and organizations to join? Would the organization have the same agency as a person? Or would there be representatives that also join the community group?
- → There seems to be a need to support different relationship types in addition to standardized types.
- → Custom relationship types need not be understood, but they need to be supported.
- → Extensions defined on top of Groups model provide meaning for a particular domain (e.g. eCommerce, Government, etc.)
Consider specialized federated applications that go beyond offering familiar social features. We don’t have many of those yet, but take for instance FedeProxy. Let’s say they want to offer a Teams functionality. A team can be associated to an Organization, a Project, or a Repository. But Teams can also completely roam freely, offering their services on the fediverse. After all FedeProxy’s goals are to liberate software development. Now these teams are multi-disciplinary and there are Developers, Testers, Techwriters, etc. There are multiple ways to model this. 1) Subgroups. Team parent_of Developers. 2) Custom actors. Member is a Developer. 3) Custom relationship types. E.g. member develops object. Or some combination of these.
- → How well could this fit a common Groups model?
What if in some future Fediverse our identities would be fully decoupled from a server instance? It would have many implications. But not just for Person actors… any actor type potentially. A community may span multiple servers, and I can spin up another server that facilitates e.g. a subgroup within such community. Other servers may be added to support just my subgroup. Or compose other group intersections. A conglomeration of groups is formed that can be navigated as a graph.

These are just some considerations my foggy brain could come up with this morning. They might indicate further requirements for a second maturity level:

Groups support arbitrary relationship types to other actors.
Besides following and membership there may be a need to standardize some more relationship types.
An actor can have multiple relationships to a group at the same time.
Custom relationships are only meaningful in specific domains and can be safely ignored otherwise.

Now my loose brainstorm might all seem to imply tremendous complexity, but I think the core model need not be all that complex. And as you say we may be already almost at the stage to have it realized. I defined my naive conceptual diagram with the above requirements in mind. Including once more:

In my mind all we need to do is define:

The ontology. The entity-relationshp diagram as it were.
The vocabulary. The detailed property definitions, JSON-LD formats.
The behavior. The message exchanges patterns, rules needed for interaction.

Some things may not be directly in scope, but relate to further capabilities we’d like to see added to AS/AP, e.g.:

Capability negotiation / compliance profiles?
Group discoverability maybe?
…

Idk, I’m not the expert here

What does all this bring us?

A foundation on which to build very rich semantically meaningful interactions across the fediverse.
A means to benefit more of the Linked Data aspects of the AS/AP protocols (while you can still use plain JSON, of course).
A pathway that eases more specialized applications to bring their business domain to bear in well-supported manner.
An opportunity to finally create an abstraction layer that avoids all the technical terms that confuse non-technical people.

@yala’s description hints at how deep this may go, and I find that exciting to consider.

In the above there are two maturity levels to be defined, and the scope of that seems well within reach. With these in place federated app developers can go wild and develop tons of extensions on top of Groups that may become de-facto or official standards in turn.

Over time new domains can be come native to the fediverse. They have groups at their core. Some random examples:

Crowdfunding: funds, sponsors, donates, …
Collaboration: owns, supports, contribute, reviews, advises, …
Organization: manages, steers, partners, supervises, subsidiary of, …
Ecommerce: offers, buys, sells, supplies, …
(…etcetera)