Standardizing on a common Community domain as AP extension?

How many of the Types in those models could be inferred from records of Interactions? How many of them are actually Roles?

One of the patterns we’ve seen is using Types for things that change, and then the Type becomes rigid.

For example, we’ve seen more than one model where Agents were either Customers or Suppliers, which meant that the same Agent could not be both. If Agent relationships had Roles, then the same Agent could have more than one Role in relation to another Agent. Moreover, whether an Agent was a Customer or a Supplier or both could be inferred from their history of Interactions. And then some other Interaction could emerge that was neither Customer nor Supplier but something else again.

I would need to get much deeper into that model as used in practice to understand if they are using Types too rigidly or not, but I’m suspicious.

[edited] Another question: in Valueflows, the Roles are user/community-defined Type Objects and more can be added as they emerge. The number of hard-coded Types are minimal.

1 Like

Thank you for that information. That model may well be too rigid indeed. It may be because it is mostly still mostly conceptual.

Your mention of Type Objects leads me to bring up something that’s a bit off-topic, though still interesting. I will address this in a separate forum topic in due time.

Pattern libraries

I’ve long been thinking that - as we extend the Fediverse to more and more different domains - we may define reusable solutions / vocab extensions / designs etc. as Patterns that other implementers can relatively easily adopt to create interoperable solutions.

As it happens I was just reading one of Aldo de Moor’s latest papers New Community Research and Action Networks (PDF), which also mentions creating pattern libraries:

A pattern in this sense is a generalized description of a problem and a solution. And they are called “patterns” because they are repeatable in a general way. The originators of the pattern approach state that each pattern they identified “…describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over without ever using it the same way twice.”Thus, patterns can be used to help provide general approaches to problems that can be tailored to specific situations.

Note that Sociocracy 3.0 mentioned above is a pattern library too. Along with the paper is the Public Sphere Project pattern library as an example (though these patterns are very generalized).

1 Like

I published the First draft of Fedi Foundation website yesterday, and one the pages I created was:

This page is just a sketch, but the idea is that the Fedi Foundation site will contain a library of Pattern documents for various domain-specific extensions that can be built on top of ActivityPub. This page already has some text of how that may look like, but should be further extended (as well as refined and with improved layout).

1 Like

FYI @lynnfoster @bhaugen see here and here (and - unrelated - @bashrc is adding Sharing features to Epicyon based on DFC interop standard)

1 Like

Thanks @aschrijver , and sorry for the silence, things got busy. I’ll dig back in, and respond by tomorrow. And nice to see Epicyon’s use of DFC.


OK, there are a lot of pieces to this. Here are a few thoughts this generated. But, if you have some other piece that it would be good to discuss, please ask again.

And ideally this ontology will be applicable beyond fediverse [,…] 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.

This certainly would solve a lot of problems. Can we just do this? (Whoever “we” is.) I suppose this is a giant effort, maybe through W3C, if it is to go anywhere with the diverse ecosystems. Or maybe propose something in the context of the fediverse, and see who else sees it as useful. Don’t know, but am happy to participate in a working group.

Leading to another set of options. “We” could create one flexible extension that we think would work for the fediverse (or across every ecosystem we know about), with lots of configurability. Or are you thinking about an approach that creates choices of more defined extensions, of which Community would be one? (Ref. Exploring the «Community Has No Boundary» paradigm |

A specific piece: I’ve been thinking that it might be good conceptually to not equate the actor types of Person, Organization, Group with actual people or organizations or groups. One thing is I understand people are interested in many new kinds of things as actor types, making use of the basic messaging and following protocols - so my mental definition of actor has become something more like that, kind of “whatever wants to use the actor model,” i.e. send and receive messages, and manage those messages. (The actual AS definition is “Actor types are Object types that are capable of performing activities.”) This might also help in separating out Account or User from real people or groups/organizations, since in practice I think it is often equated with an AP actor. For example, a real person might have several AP actors for different reasons, like keeping aspects of their life separate.

@aschrijver do you see Community as an actor type or something outside of that, which could relate to actor types? I’m picking up the latter, but am not sure I understand.

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:

  1. Core specs (e.g. ActivityPub 2.0) → W3C SocialCG / SocialHub, formal process
  2. Protocol enhancements → SocialHub, Fediverse Enhancement Proposal (FEP) process
  3. 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:participantIn relationship is added to relationships collection.
  • “Community has sub-groups” → Add{Relationship} → nested groups defined using rel:childOf and rel: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.

1 Like

I’m happy to go down whatever process path you think best; and see where others might fold in, etc. I don’t feel like I have the experience here to know what is best. But I’m happy to talk “model” with you.

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.


I realize Community isn’t a type or anything, but can you/we define it conceptually as a pattern? What are the goals, what does it cover? I’m thinking rather broadly, as I think we need a complete but simple model for groups/organizations and their relationships. Are you thinking that, or something narrower? Although I’m also thinking more narrowly in another direction, as I see Service, Application, and whatever else gets defined in that direction, as something else than part of a Community. (Forgive me if you have already defined all of this!)

I’m still puzzling over if this wants to be inside the actor model, but need to keep thinking. And I feel like I need to read all the previous Group discussions again too.

I used existing AS objects, and gave Group an additional relationships collection:

Is this actually already covered in AS here? Activity Vocabulary [edit: Or maybe you mean it isn’t explicitly defined in AP?]

Your edit is correct: ActivityStreams gives us the “words” to express ideas. But everyone’s app wants to use it in a different “sentence structure” (grammar), which risks folks having to understand N different Group constructions or just ignore each other. Or, in the ideal case, coordinate with each other on one conventional understanding.

This is not just a problem with Groups, and will be a recurring theme for different vocabularies. There is no standard process to resolve it (to the delight of some and chagrin of others).

To the delight of:

  • Those only interested in own project and/or ignorant how it fits in the larger whole and necessity to collaborate.
  • Those who’d like to become the dominant players on the fediverse, for selfish reasons.
  • To any competitors, who are greatly satisfied by our self-imposed “divide and be conquered” weak spot.

One or more possible understandings, to make it more practical. See Point 3) in my comment above, where there is a process for creating commonly used patterns to choose from when building applications. E.g. for groups you might have a pattern for “Forward-Only Groups” and one for true FB-like “Group Membership”.

Yes, defining as a pattern. I imagine that a Pattern in general adheres to a common document layout (just like e.g. OOP design patterns do). A document template might have “Problem statement”, “Requirements”, “Common solution” and “Open issues” paragraphs, or similar structure that makes most sense.

In the case of Community - according to the diagram above - the pattern describes “Any group with well-defined associations to other actors”, as well as common ways of managing these associations.

The type of actor doesn’t really matter. It is up to the implementer to designate a Group as a Community. Examples of Service and Application actors in a community might be a ChatBot or a decision-making system that posts outcomes to the group.

A paper I wanted to mention in this thread is “Modular Politics: Toward a Governance Layer for Online Communities” by Nathan Schneider, Primavera De Filippi, Seth Frey, Joshua Z. Tan, and Amy X. Zhang. 2021

It highlights among others how modular sets of Policies could be modelled on top of Community, so you get Community Governance.

Hey Lynn,
this is helpful.
I am adding our example which is “A network based around journalism and Creative Work”.
All of the relators re. Creative Work can be found in this file: widgets-preview/_VOCAB.js at 797216734a4c1a569f81fcf6a5ad0e17ac2b0ff9 · redaktor/widgets-preview · GitHub
A Movie is quite a Beast of Roles :slight_smile:
We did also try to include the Library Of Congress relators (mainly for Books and Articles) MARC Code List for Relators Scheme - LC Linked Data Service: Authorities and Vocabularies | Library of Congress

Just wanted to add that the posted example of a Relationship is a very simple one-to-one relationship. many-to-one / one-to-many / many-to-many can simply be done by having a “type”: “Collection” in subject / object / both …
Also very important is what we discuss in the next meeting, context - this groups all the things and makes a Relationship in AP complete.

Two more examples:
[all examples are international in redaktor and name is a multilanguage nameMap, summary = summaryMap etc.]
The empathi namespace prefix is the namespace : empathi: An ontology for Emergency Managing and Planningabout Hazard Crises Specification

Example 1
A simple example from {type:["Video", "schema:Movie"]}
First relation is the ‘Profession’ of a ‘Person’ in a ‘Movie’.
But a Movie also has a “Cast”-concept, the relation would be:

  "@context": "",
  "summary": "Ruth Gordon plays Maude Chardin in “Harold and Maude (1971)”",
  "type": ["Relationship", "Person"],
  "subject": {
    "type": "Person",
    "name": "Ruth Gordon"
  "relationship": "redaktor:leadPerforms",
  "object": {
    "type": ["redaktor:Character", "schema:Person"],
    "name": "Maude",
    "schema:givenName": "Maude",
    "schema:fullName": "Chardin"
  "context": {"id": ""}

The context here is the Movie cause the Relation from Actor to Character might mainly differ per Movie but context can also be a simple Note or describing the performed empathi:ageRange of the Character or whatever.

Example 2
In one of my article about the Tsunami 2004 I did an Article about 5 “main actors” like Rajeswari, the nurse (one of my photos, was for “GEO”):

The Article had a timeline to describe strictly consecutive by time the situations of the actors but also by states or authorities.

This could be an OrderedCollection of ["Relationship", "Event"] -
now cheap software can parse Note with only summary, better software might do Event with summary/startTime while scientific softwares can parse the whole Relation.
In a journalistic software, the wikipedia paradigm “Everything is a Claim” is important too.

Assume that the following example also has a location property.
I will describe it later cause of complexity.
I left out concrete times – cause I wish, the whole thing didn’t happen.
Here, the hrefs used in summary are the HTML representations of subject and object and this way also handled by e.g. “microblogging-software” - some more link-rel left out…

  "@context": "",
  "summary": "A <a href='...' rel='type'>Tsunami warning</a> for {location} was issued at {startTime} caused by <a href='...' rel='about'>Earthquake 9.1 Mw XSF</a>",
  "type": ["Relationship", "Event", "Note"],
  "startTime": "…",
  "subject": {
    "type": ["ntwc:TsunamiWarning", "Note"],
    "name": "…", 
    "summaryMap": {...},
    "startTime": "…"
  "relationship": "empathi:causedBy",
  "object": {
    "type": ["empathi:Earthquake", "Event", "Note"],
    "name": "…", 
    "summaryMap": {...},
    "startTime": "…",
    "endTime": "…",
  "context": [
    {"id": ""},
    {"id": ""}

We could now have it’s own attributedTo to specify which authors made the claim for the Relationship.
Many other Relationships derive from this and each context also specifies who made the subject and object claims (technically the nwtc:TsunamiWarning can have its own attributedTo but there is a difference, the relator for Author - this is the same than rel="author" in html). It should just have the Author-type if the information came directly in the markup by a system of the ntwc.
Otherwise the Author in the context is responsible
(US “accountable” or Germany “Verantwortlich im Sinne des Presserechts” / “V.i.S.d.P.”).

And location is hard.
The team in my publishing house had compared lots and lots of Thesauri, Ontologies, Vocabularies (e.g. wikidata, Library of Congress and Deutsche Nationalbibliothek etc.)
Locations can have so many meanings.
Let’s say I am at a camera in this place and take a photo, then it might show the moon in full size but I am still in the youth center on earth, so what would location for the Image mean? The youth center or the crater?
So, the problem is with complex location examples, we might need 2 explicit Relation because of course, I will use the Place which I already defined (useful here, cause users can click through until Events, software reasons “Upcoming” by startTime, user sees that they can learn astro-photography there, user Accept, yay).
So to not specify the same Place again, we use Relationship with extra relators:

  ['LocationCreated', {
    loc: 'evp', pref:{en:'',de:''}, alt:{en:'Event place',de:''},
    note: 'The location where the CreativeWork was created, which may not be the same as the location depicted in the Work.'
  }], //
  ['LocationContent', {
    loc: 'prp', pref:{en:'',de:''}, alt:{en:'Production place',de:''},
    note: 'The location depicted or described in the content. For example, the location shown in a photograph or painting.'
  }], //
  ['LocationPublication', {
    loc: 'pub', pref:{en:'',de:''}, alt:{en:'Publication place',de:''},
    note: 'The location where a resource is published.'
  ['LocationManufacture', {
    loc: 'mfp', pref:{en:'',de:''}, alt:{en:'Manufacture place',de:''},
    note: 'The place of manufacture (e.g., printing, duplicating, casting, etc.) of a resource in a published form.'
  ['LocationUniOrLibrary', {
    loc: 'uvp', pref:{en:'',de:''}, alt:{en:'University place',de:''},
    note: 'A place where a university that is associated with a resource is located.'+
    'E.g., a university where an academic dissertation or thesis was presented or a library where it is available.'
  ['LocationDistribution', {
    loc: 'dbp', pref:{en:'',de:''}, alt:{en:'Distribution place',de:''},
    note: 'A location from which a resource, e.g., a serial, is distributed.'
  ['SpatialCoverage', {pref:{en:'',de:''}, alt:{en:'',de:''}}]
]; //
1 Like

Thank you! This is ultra interesting and I need to look at this more closely. I really like the way you are going into the Linked Data parts and extension mechanisms of the specs.

A Movie is quite a Beast of Roles :slight_smile:

Indeed, thanks for those links, always good to see real examples!

1 Like

Currently I would be mainly interested in the “Mutual Aid” vocabularies.

And I’d like to add that when I looked at mainstream vocabularies, I was a bit disappointed to not see “cultural or religious concepts” at the top level.
A simple example, a “Restaurant” – I would expect it to describe first if that is
kosher, halal, vegan, vegetarian, lacto-vegetarian and if alcohol is sold.
There are many people which can’t deal with other restaurants and are lost if that is not described …

I like that but I’m a bit irked by “cultural or religious” when it comes to vegan being lumped in with the others. Veganism is about ethics and not culture or religion.

I can’t readily think about how this relates to my extensive research into restaurant and food delivery metadata, something which I’ve put 1000s of hours into, but…

Generally I would say veganism stands out from the others because it is not based on dietary choice.

It is based on ethical choice. It is more closely related to metadata about carbon footprint, ecology of packing materials, and fair treatment of workers and so forth. It is so much more than just a dietary choice.

Currently I would be mainly interested in the “Mutual Aid” vocabularies.

Might be of interest: @mayel has worked on a general taxonomy that would have its own pub in the fediverse, available to others. Not sure of the current status.

One other thought about standardizing roles: Seems like a lot of domains will have some standard role names that most people use, like your movie example. These probably describe real things that people do. But some groups like to make up their own. In that case, I think it is all part of the current experimentation in new organizational forms and governance and relationships in groups.

1 Like

@mayel Please, please – update us :slight_smile:

These probably describe real things that people do. But some groups like to make up their own.

Oh, yes, forgot to mention: The things, I do are just to set a base.
Groups can make their own. We are really liking the approach which skohub does (see page or videos below) and we think that we can take it further.
If the group vocabulary itself is an ActivityPub Collection, the software would just either take this as a source for skohub (instead of a common git repo) or the software can just sync the Collection and the repo …

In another thread, I wrote:
The people are powering a large portion of the infrastructure for german universities, e.g. the System where I find the books in uni libraries nearby, they know what they are doing - to learn about the benefits watch the short Demo Video or Conf Video

Just a quick update.
We have published the first part of the Vocabulary at the page
[ repo ] following the approach.
Search is not working yet, it’s just a temporary place there …
Now we also did a mapping to and will also enrich it with some wikidata concepts.
I had just asked how to …

Every term is an ActivityPub Actor (skohub). Now if the Vocab is a Collection then any Person, Group… can extend it.