Given how hard it is to get people to cooperate at all, let alone across communities, this has my preference. And in terms of how things are created, personally this seems most feasible:
- Core specs (e.g. ActivityPub 2.0) → W3C SocialCG / SocialHub, formal process
- Protocol enhancements → SocialHub, Fediverse Enhancement Proposal (FEP) process
- ActivityPub extensions → SocialHub, Fediverse Extension Vocabs process, pattern libraries
Three processes, ranked by formality. The first two exist, but are stalled. The third can be created.
In that last process a Community extension then becomes a pattern in the library. There could over time be multiple flavors and versions of it, depending on needs by individual federated projects. The patterns answer simple questions, like: “How do I model Community in my app?”. There could be compound, more complex patterns, but on the whole patterns are flexible because of their simplicity, i.e. leaving things out. Ideally one pattern models one concept really well, and then becomes like a Lego brick. A building block for diverse federated apps.
Patterns describe Domain concepts, yet not full business domains. They are like bounded contexts in DDD terminology, or parts thereof. They define some (micro-)ontology in Linked Data, the vocab, plus ways to interact with it.
In due time a mechanism can be formalized to discover what extensions an app supports, but this is something that is part of FEP processes. Think of Capability Negotiation and/or Conformance Profiles, that @grishka and others have talked about before.
What is the Community extension, then? I think of it as the design patterns that allows us to take Community concepts online to the next level, and be able to better represent how they exist in the real world. I call it the “Community has no Boundary” paradigm, because in society we have complex and dynamic community structures that are interconnected in all kinds of ways (@michielbdejong is an expert in this field, and might be able to help?)
The Community is a domain’s bounded context, so it is not an actor in itself. It provides a model. The core actor is an ActivityStreams as:Group and it has as:Relationships to other actors defined in its vocab. I was inspired by the Valueflows model you provided above, but that defines Agent-to-Agent graphs, so is too broad.
In my - possibly naive - conceptual diagram draft I used existing AS objects, and gave Group an additional relationships collection:
The actors shown here, particularly Person, Organization, Application and Service are just the actor types available in ActivityStreams spec. “Actor” itself is abstract and not a concrete type. But any custom actor could be part of a Community.
There can be many relationship types in a Community group that define its ‘membership’ (not correct terminologies, as it is broader than that). There can be multiple relationships to the same actor, and relationships to different actors that represent the same entity (e.g. a person).
Some of these relationship types can be standardized, so they are universally supported. Others can be fully app-specific and custom. Standard types might be e.g. chosen from the PURL Relationship vocabulary e.g. rel:participantIn, or it may be foaf:member, etc.
What we have now, with the diagram is a basic vocabulary. In addition to that there should be some standard ways to interact with it. Just brainstorming:
- “Person joins Community” →
Join{Group}→rel:participantInrelationship is added torelationshipscollection. - “Community has sub-groups” →
Add{Relationship}→ nested groups defined usingrel:childOfandrel:parentOf. - (… bunch of other common use cases)
One thing to model is the role(s) of persons within a community. In Groups discussions I often see “My Group feature supports admin, moderator and regular members”, while this is a completely arbitrary, app-specific implementation. Nonetheless they are common roles, so they may be defined in a standardized manner using relationships.
If the Community pattern is sufficiently covered, we now have a Lego brick as input to app design. If I wanted to implement Community Governance in my project I might combine with a Policies pattern from the library. And even my Community Governance might become a compound pattern that other people can readily reuse.
So here is some of my thinking currently. I think I will have to make the parts outlining process a separate forum topic as it ties in into many other stuff we need to dedicate attention to, like @dansup Pixelfed Groups.