It is funny that you say that, because I wholly agree with this notion on the importance and structure of community, yet for a possible paradigm on automating them for the Fediverse I’ve deliberately chosen “Community has no Boundary”. But what this refers to is how society is like a ‘bubbling foam of communities’ of all different kinds, intersecting and touching, popping into and out of existence and with people participating in them in numerous dynamic conglomerations. A person’s membership to communities and their roles that relate to them are uniquely theirs and, personal.
So community in the real world is very organic, and it is a complex concept. There’s a world of sociology behind it. I want the “Community has no Boundary” paradigm to be something that tries to capture some of that in a way that lends itself to translation to the online world too. Currently across the internet - if you look at the Fediverse, but also most other platforms - we still have quite shallow, rigid notion of what Community entails.
(The social media molochs also try to capture community concepts on their platform, with e.g. FB Groups, but their incentives to maximize engagement thwarts the effort. I won’t go into that here)
This ‘shallowness’ is understandable, because as we automate things we strive to keep complexity at bay by simplifying our abstractions, and also - until the emergence of the giant traditional social media platforms - we could afford to deal with a very limited scope to defining community. Many platforms can be considered as facilitating either a single community, or at most a simple group of communities. Membership most often means you are either in or out, and membership level mostly defined as a straighforward set of permissions rather than intricate roles.
For the Fediverse specifically there are a few apps that offer Groups support, where the group is a form of community, and other than that we perceive instance membership to be community related. In other words your user account on a server makes you implicitly a community member of the instance. We only ‘officially’ support a very small set of relationships that a member (Actor) has to a community, and we use app-dependent “tricks” to do so. The member relationships are expressed as either permissions / privileges on an actor account (e.g. member, mod, admin), or determined by collections on an actor (e.g. 'if you are in a Group’s “followers” collection, then you are a member of the group"). There may be more ways in which ‘community relationships’ are currently expressed but AFAIK no implementation thus far uses as:Relationship for that.
My interpretation of the above may well be incomplete (lack of knowledge) or perceived as incorrect. Especially when measured against current reality and technical realisations. Fact is that at this moment there is no meaningful common understanding of the concept of Community. There’s no widely agreed upon Community domain, and no shared vocabulary of terminology to use.
Part of the “Community has no Boundary” investigation is trying to come up with a minimum ontology that can be standardized as a possible AP extension to adopt. It need not be the only one that goes into group structures, memberships or even community concepts, but it can be part of a pattern library of extensions to emerge from which app developers can choose the most appropriate ones that fit their use case.
And ideally this ontology will be applicable beyond fediverse, to e.g. Solid applications, and @bhaugen + @lynnfoster Valueflows (who already modeled their Agent model based on AS specs), or Matrix for that matter, etcetera. So that interoperability between these different ecosystems remains relatively straightforward. A more universal applicability would be a huge boon to the decentralized web at large.
I think this is quite do-able, and - if care is taken to focus on the smallest common denominator - need not be overly complex to adopt in basic form. More complexity can be added by supporting additional extensions on top of that.
PS. @weex I am sorry that this response to Mike’s post is once more wide-ranging and somewhat off-topic’ish to the original title. You might extract useful stuff to the gitlab issue, or I can move this to the community topic and just leave a reference here, or just leave as-is.