Standardizing on a common Community domain as AP extension?

ActivityStreams has defined and standardized a set of Social concepts, that has given rise to the Microblogging-oriented Fediverse we have today. It worked great to integrate diverse microblogging apps, model lightweight discussion threads, give Likes and Boosts, etc. It does not work so great when squeezing all kinds of entirely different apps into this business domain to facilitate interoperability.

Threat: Stretching the applicability of currently available Social concepts too much results in semantic incompatibilities

To a man with only a hammer, everything looks like a nail. “Yeah, this must be an as:Note if you want to federate.” and later on we’ll find that “Hey, my as:Note is not your as:Note.” and clients will have a hard time making sense of it all. Additionally:

Threat: Sticking to mostly Microblogging domain, not benefiting from Linked Data versatility, means we are easily disrupted.

One new ActivityStreams type we are starting to explore and adopt is the as:Group and there is not yet consensus how it should be implemented in a compatible way.

But what I notice is that - in many cases - it is more than merely a Group actor we are trying to model. It is part of a larger domain.

Observation: We are trying to model Community domains instead of merely Groups.

Communities are everywhere in our society and we all participate in many different ones at the same time. They are more than simply groups, and often have intricate and complex social organization structures.

This forum, and all Discourse forums for that matter, also define a Community, which consists of the forum members. Many other softwares (like e.g. the new and innovative PubPub Collaborative Publishing platform) also are community oriented. Are the new Fediverse applications that investigate using as:Group type also actually defining broader community concepts? If they do then each of these projects has at least one thing in common. They all:

  • Reinvent the wheel of how a Community should be defined

And as a result all of these will be incompatible with each other, creating community islands that may never share features and members of other communities / community-based softwares. Where they do share, the integrations will be bolt-ons via bridges and adapters.

As part of my Fediverse advocacy and setting up Fediverse Futures initiative I was making the case to both Discourse and PubPub that Community Has No Boundary. See the discussions I started for more background:

But I now realize that I was advocating on an application-by-application basis, and this is a common issue. The question is, shouldn’t we avoid all this duplicate work and the incompatibility?

Opportunity: Standardize a set of common Community concepts as an extension of ActivityStreams / ActivityPub.

Besides talking community there are currently many discussion on adopting more powerful Moderation tools for Fediverse instances. The outcome of these discussion may lead to the adoption of one or more Fediverse Enhancement Proposals.

Question: If Moderation FEP’s are adopted, should they be based on current ActivityStreams model, or part of a Community domain?

Standardizing a Community domain?

There are many ways to approach defining Community in a standard way. The definition can focus on just the organizational aspects, or on the complete model of how communities are usually represented in online web interfaces. I don’t know what the best approach is in this regard, though I am in favor to focus on organizational structures first.

Discussion topic: Do you see the merits in defining a Community domain, and if so then what should it contain?

I will present some prior work I found that may inspire the discussion.

Sociocracy 3.0: Evolve Effective Collaboration At Any Scale

That a community organization structure is more than just a group is very well demonstrated by Sociocracy 3.0. This CC-BY-SA pattern library that advertises itself as “free social technology for growing agile and resilient organizations”. Here are group structures supported by it:

The group structures lend themselves well to model communities, but the pattern library itself defines many organization patterns / different domains that can be modeled on top of them. Here’s the overview of its patterns:

Important: The idea of the pattern library is that you only adopt what you need. Nothing less, nothing more.

SIOC: Semantically-Interlinked Online Communities

SIOC defines an entire range of RDF classes on how communities might be represented online.

On the Fedeproxy forum of @anon20068248 someone pointed out the SIOC project linked data ontologies. This is an example of a Forum-oriented model that can be defined based on the ontology (though it lacks SIOC classes like Community and Thread):


These are some additional classes that can be used (there are more):


In addition to the above I would like to remark that…

Best-practice: ActivityStreams should be considered more as a Core Ontology and not as THE ontology of the Fediverse.


Interesting :slight_smile:

We are doing the same project at the #OMN though we clearly let the users/producers define the community growing from the grassroots use. If you don’t trust the people you cannot have real democratic institutions and are left with feudal (#mainstreaming traditional open-source dev), capitalism (the #dotcons) or #geekproblem (most radical tech) as a path, none of these are the world we need to be building is my view.


Obviously there should be certain specific properties of a group like it’s header image (to represent it graphically) and who it’s owner(s) are, etc, but equally as important I would suggest that groups not only contain a list of persons, but also another list of “Group Parents”. Very simply, a group would be able to be a “part” of another group. This means we’re talking about a parent/child relationship with groups so that groups can be on a ‘tree’ (directed graph). Not necessarily an acyclical-graph, but still a graph (optinally). Groups won’t be “required” to have “parent(s)” but it should be an option.

This kind of hierarchy would allow large organizations to subdivide groups in such a way as to exactly match their existing organizational structures right off the bat, and provide huge value at very little cost to any implementers, because this “parent group” doesn’t need to be anything more than a simple list of strings (like an array of Actor objects in AP for example).

And just as a wild idea, since AP Actors already have the contept of “Followers”, it does make you wonder if there’s some easy way to extend the Actor object itself (with new optional parameters to the existing spec) that can allow Actors to “solve” the “group problem”, simply by stating one type of Actor is a Group, and by doing so require very little change to existing AP code. I’m not sure if Actors are so dramatically different than what a “Group” would need to be that the Actor object would be a square peg in a round hole (if used to define a Group), but I’m sure the benefits are self-evident regarding this concept (i.e. extending Actors to become Groups).

A first approximation at this kind of idea would be to simply allow Actors to contain a list of “Members” and in that way a “Group” simply becomes “Any Actor with a Members array”. Once an Actor then becomes a group in that way, each Actor could also have a similar array called something like “Parents” (or OwnerActors, or SuperActors) which would be the list of other Actors which this Actor is a member of, category of, or subordinate of (to achieve the ‘tree’ organizational hierarchy).

1 Like

The community model should allow you to define any type of community structure that fits your needs. There’s nothing in the above that would hamper any kind of grassroots growth. The simplest form would be one big group with an ever growing member base, where everyone is equal. But even then you might want to subdivide into topics / themes etc. If you have some form of moderation, the need for a nested group may arise (which you also have e.g. on this Discourse forum).

Yes, this is one possibility. You see this in Sociocracy with hierarchy and fractal organization. As for the technical implementation, I am insufficiently qualified atm to be very useful there. In ActivityStreams we have at our disposal the Actor types (where Group is already an actor) and the Relationship object. The community domain best build on top of that, I guess, where possible.

Note that defining a property for a group header image follows the approach of defining a vocabulary for the online representation of groups. I does not follow the domain-driven design approach that I’m in favour of, which would focus on the real-world concept of groups / communities (like IRL when you group up with ppl, there’s no header image floating above you :slight_smile: )


(I gave this a separate header, because it goes beyond Community domain, into Organization domain)

The AS spec examples use PURL Relationship ontology to define relationships between people. That does not cut it for orgs. Also a “parent_of” indicator of some kind is not enough. I’d like like to specify “partner_of”, “subsidiary_of”, “headquarters_of”, etc. Maybe the PURL Participation vocabulary - for describing the roles that people play within groups - can be used. Or maybe there can borrowed from the W3C Organization ontology.

Some other Community-related resources I found …

A Community Network Ontology for Participatory Collaboration Mapping: Towards Collective Impact

“Addressing societal wicked problems requires collaboration across many different community networks. In order for community networks to scale up their collaboration and increase their collective impact, they require a process of inter-communal sensemaking. One way to catalyze that process is by participatory collaboration mapping. In earlier work, we presented the CommunitySensor methodology for participatory mapping and sensemaking within communities. In this article, we extend this approach by introducing a community network ontology that can be used to define a customized mapping language to make sense across communities […]”

A reference profile ontology for Communities of Practice

“Communities of Practice (CoP) integrate people in a group in order to learn in a collaborative way. In these communities it is necessary to establish a formal and standardized representation of the interests and the knowledge that emerges from the CoP. With this scenario in mind, this paper presents a reference ontology for a user profile representation in a CoP framework. The main idea of this framework is to realize that a foundation for the semantic web is feasible to aggregate on virtual communities in the context of collaborative learning. The concern of this work is to establish a reference ontology for the general profile that can be used as guidelines to build a computational CoP framework for realizing such a foundation.”

Social Participation Ontology: community documentation, enhancements and use examples

“Participatory democracy advances in virtually all governments and especially in South America which exhibits a mixed culture and social predisposition. This article presents the “Social Participation Ontology” (OPS from the Brazilian name Ontologia de Participação Social) implemented in compliance with the Web Ontology Language standard (OWL) for fostering social participation, specially in virtual platforms. The entities and links of OPS were defined based on an extensive collaboration of specialists. It is shown that OPS is instrumental for information retrieval from the contents of the portal, both in terms of the actors (at various levels) as well as mechanisms and activities. Significantly, OPS is linked to other OWL ontologies as an upper ontology and via FOAF and BFO as higher upper ontologies, which yields sound organization and access of knowledge and data. In order to illustrate the usefulness of OPS, we present results on ontological expansion and integration with other ontologies and data. Ongoing work involves further adoption of OPS by the official Brazilian federal portal for social participation and NGO s, and further linkage to other ontologies for social participation.”

I agree with the idea of standardizing on at least enuf community-organization vocabulary so ActivityPubs can interoperate.

But I also agree with the people who want communities to define it themselves.

So that means a fairly minimal set of primitives that any community can use to define themselves and their organizational relationships.

Several of the research findings seem way too prescriptive to me. SIOC, for example.

Valueflows has a pretty minimal set of primitives that allow almost everything to be user-defined. Bonfire extended them a bit based on experience in Moodlenet. @lynnfoster of Valueflows and @mayel of Bonfire are discussing how to make it all even more minimal and should have something to report soonish. I’m pinging them here to suggest that they report in this thread when they are ready.

Yes, this also has my preference…

In the above I was just collecting some stuff that is already out there, and that we may borrow from or build upon. If there were an existing vocabulary that we can subset and reuse, then that might be better in terms of standardization than creating something entirely new.

I feel that the ideas behind Sociacracy (though it provides a specific take on organization structure, with double-linking and such) are an attractive starter, i.e.

  • Show the community models as simple diagrams.
  • Describe how they work in comprehensive short texts.
  • Make those a pattern library, where you are free to choose from as you expand with additional community concepts.
  • And give each pattern a vocubulary snippet to adopt.

Update: Oh, and I think the ability to define relationships between communities, have overlapping cross-sections i.e. the whole “community has no boundaries” paradigm is something to think about. How do you integrate with other communities?

TL;DR: To describe a Community, what is the minimum we need? We need a Group with a user-defined classification of “Community”. We need all the Persons (or other Groups) with a relationship to the Group. These relationships (roles) are also user-defined.

Excrutiating detail

Valueflows has a pretty minimal set of primitives that allow almost everything to be user-defined. Bonfire extended them a bit based on experience in Moodlenet. @lynnfoster of Valueflows and @mayel of Bonfire are discussing how to make it all even more minimal and should have something to report soonish.

Haven’t had a chance to work through this recently with @mayel . He’ll be able to speak to implementation details way better than I can. In the meantime, I’d like to give a short history of what we decided earlier, and why I’d like to change that a bit, as one contribution to the ongoing discussion here.

History: Valueflows uses foaf:Agent, with subclasses foaf:Person and org:Organization. VF uses Agent as “economic agent” for its purposes, and has also inherited the name Agent from an ontology called REA (Resources Events Agents), which it is based on. ActivityStreams of course has as:Person, as:Organization, as:Group, all of which are actors (there is no actual Actor class, but specific protocol is defined in AP). Mayel and I decided in an initial discussion of how to map VF and AS (we were thinking of it as extending AP with VF for economic networking) by defining vf:Person and as:Person as equivalent, vf:Organization and as:Organization as equivalent, and using as:Group. Organization would be defined as having economic agency, and Group would be defined as not having economic agency. (We did not find the AS definitions to be very helpful.) In any case, in the mapping, an agent is always an actor, but not all actors are agents.

What I later discovered I don’t like about our earlier decision is that if a non-economic Group decides it wants to start acting as an economic agent, so as an Organization, it now wants a different type. Not so good in many technologies, and exposes that really economic agency is more a role than a type.

What I do like about our earlier decision is that we added a classification property to Organization and Group that gives users a chance to name and define these for themselves. So, for this thread topic, people could define an as:Group classifiedAs “Community”, which could come from an existing public taxonomy. Or not. (In general, our experience working with different groups/organizations is that it is important to them to be able to name these things for themselves, to express nuance that is important to them. There are always new ways people name types of groups/organizations - “Distributed Cooperative Organization (DisCO)” or “Open Value Network” come to mind. Incidentally this also applies to the names of the relationships between them. For example one group within 2 weeks of implementation changed “member” to “affiliate”. Thus the attempt to keep the standard model as minimal as possible.)

Some general thoughts about what to do: I’d like for VF to be able to keep Agent, but consider the definition more loosely (which foaf does actually). That wouldn’t affect social-only networks not using VF. I’d like to have agents (and that kind of actor too) be either a Person or a [some name that covers all agents that are not a person]. That last thing merges Organization and Group. Really if a Group even has a name, it has something like agency. Unfortunately, it might be hard to merge those because AS (and FOAF) already has them as separate concepts.

And then more specific kinds would be handled by user-definable classifications, not more classes or types. This is really the important part, we could do this and keep both as:Organization and as:Group, since they are already defined.

This is getting kind of long, I’ll make a separate comment with more thoughts about relationships, and a suggested diagram, probably tomorrow though.

1 Like

Wow, what a wonderful feedback. I truly :heart: love this @lynnfoster, thank you! I will - with my still very limited expertise on vocab modeling - try to provide some useful additional observations…

  • Keep concepts as low-level as possible in order to achieve greatest versatility in the model.
  • Many / most concepts can be tailored by means of user-defined classifications.
  • ValueFlows vs. AS/AP compatibility will probably mostly be defined in terms of model equivalency.
    • (Note: In AS this requires e.g. "type": ["Person", "foaf:Person"] which most apps don’t support currently)

Group is the central idea for this extension. In terms of AS I’d say:

  • An as:Group has members, which can be any concrete class representing any Actor type (this is standards-compliant).
  • The membership of an Actor is expressed by its roles, and that may use (one or more) as:Relationship.

The above already comes a long way, but is a bit different to ValueFlows in the types of actors / agents it allows.

Note that the AS definition of Group (“Represents a formal or informal collective of Actors.”) is already a specialization of the universal concept of Group (“Any Group of Objects”) and does not take roles into account, but also doesn’t define how membership must be modeled, which is fine.

In terms of AP and this Community extension I wonder if a special as:Collection type should be defined to represent membership. If feel followers / following doesn’t cut it. Maybe as:Group has a ‘members’ collection. But it would be quite breaking with what’s out there at present. In current group modeling efforts (e.g. here), we are trying to fit everything in the existing standard specs with as:Join, as:Follow, etc. (and having no consensus how this should be done interoperatively).

Some examples

Community in software (Discourse)

Discourse considers itself community software, and I have pitched the “[discourse] community has no boundary” paradigm there. I’ll use their software (e.g. this forum) as example when looking at various actor types being part of Community (as:Group):

  • First of all one Discourse installation (currently) represents one Community (the top-level as:Group).
  • Person actors are not directly represented, but represented by one or more user accounts they create.
    • OT: Bit of a problem here. At admin level the forum knows something about this, but it might be okay to map accounts directly to Persons. Alternatively there might be an implicit Person that has Relationships representing accounts, which raises new problems. Or Account can be a separate custom Actor type. Or… [feedback welcome]
  • Group actors exist in Discourse to represent sub-groups of the top-level Community group, and cannot be nested.
    • Communities in general may have nested groups (conceptually staffmoderatorsadmins are implicitly nested).
  • Application actors participate in the community too. There’s @system account interaction on behalf of the application.
    • There’s also @discobot community ‘butler’ bot. This can be an Application actor (though Service fits too).
    • Many softwares with membership concepts have bots, think e.g. IRC. There might a custom Bot actor type.
  • Service actors may be provided by various Discourse plugins, where the service reports / listens to the forum.
    • Think of Github, Discourse, Mattermost, Opencollective integrations.
    • Some of these are a bit of a stretch. In general I think certain (SaaS) Services can act as full-blown members.
  • Organization actors, like Persons are not directly represented, but there can be organization accounts.

It is interesting to think of what would happen if Discourse adopted the “community has no boundaries” paradigm…

  • There would be membership relationships between Communities (instances of discourse).
  • There’d probably be truly a concept of nested groups to be supported.
  • There might be additional requirements to define community intersections/overlap (“we only share these categories”).

And currently there would be limitations in the way cross-community membership can be defined. Identities are tied to instances and we lack SSO, identity providers, roaming identity or whatever other mechanism to provide this. Solving the Identity problem on fedi would be fantastic, but goes way beyond this topic.

Real-world communities

When representing communities as they exist in the real world, things come closer to ValueFlows. In that regard I’m wondering the following:

  • If a non-incorporated Community is funded by donations (e.g. via an OpenCollective), is it an economic agent? I think it is.
  • Given a paid SaaS Service can it be considered an economic agent? Or do you fall-back to the Organization that offers it?
  • What does it mean if an Organization is community member? Probably only some representatives participate in the community.

Shouldn’t VF also generalize to having any agent possibly be an ecomic agent? (Maybe you already do so, idk)

Just to be sure: You shouldn’t consider AS/AP as particular to social-only apps. Though it is now primarily used and presented for the social space, application is much broader. I make this argument in Positioning ActivityPub: De-Emphasize "Being Part of the Fediverse" as primary USP and the #fediversity:fediverse-futures category is about exploring these broader application / business domains. E.g. #software:forgefed is an example of a non-social application to extend AS/AP.

(PS. In your REA reference the REA Ontology Paper link is dead, here’s the latest [DOC] version)


This is a sidelight to the main topic, but every economic network we’ve seen is also a social network. And if their economic and social interactions can be integrated, they work much more smoothly.

For example, these folks recruited an engineering college class to fork some of our older economic network software for their high school fablab network, and one of the features they recently added was chat. Everybody went, “yay! now we can chat about this stuff!”

(P.S. that’s why we want to build economic network software on top of social network software.)


@aschrijver wow back. A few responses; more later.

If a non-incorporated Community is funded by donations (e.g. via an OpenCollective), is it an economic agent? I think it is.

Yes it is. Anything that can perform economic activity, including giving/receiving/exchanging resources, or producing/changing resources, is an economic agent.

Given a paid SaaS Service can it be considered an economic agent? Or do you fall-back to the Organization that offers it?

If I understand you correctly, you fall back to the Organization. Services (the kind that are actors) for example I don’t think are economic agents. I don’t think we can say “the bot made me do it”. But I’m not sure everyone would agree… @bhaugen ? I can see a place for agents that are ecosystemic possibly, but don’t really know.

What does it mean if an Organization is community member? Probably only some representatives participate in the community.

Organizations can be community members, if allowed by the community. But yeah, we think there are Person roles and permissions in an Organization that will allow a Person to “act on behalf of” an Organization.

Shouldn’t VF also generalize to having any agent possibly be an ecomic agent? (Maybe you already do so, idk)

Yes I think so, thanks. That was what I was trying to accomplish by merging non-agent Groups and agent Organizations somehow - but we don’t need to do it that way, any agent-y thing could be an economic agent just by engaging in economic behavior. In VF, we haven’t had to worry about it yet because we have only needed to care about economic agents. When we try to map and interconnect with AP (or any social networking) then we need to think more broadly. Which is good.

1 Like

It is broader than bots. Any SaaS service counts. I.e. invoking an API on a paid subscription plan or a pay-per-use. You might have a situation where an Organization offers many such services with different payment plans. Or even theoretically that the service of some standardized API can be fulfilled by multiple back-end parties (don’t have examples of that though). Since you are not dealing with the Organization directly but only with its Service, you might consider the service to be the economic agent, and when obtaining multiple services it is easier to distinguish them.

In this situation the Organization starts to have group-like characteristics too, where the representatives are the real community members. The other case is where the Organization is a single entity and when e.g. posting to it, it is opaque how it is handled within the organisation.

I like this insight. I was clear to me in the real-world meaning, but also nice that it applies to online social media use cases as well.

This is a half-baked thought. Will bake it more as we continue this and related discussions.

I think for a bot or a service that participate in economic activities, the Economic Agent is the agent that runs the bot or service, and, (for example), if the bot or service provides economic resources, the “real” provider is the agent that the resources came from.

An example where the bot created the economic resources unaided by humans? At this stage of AI development, there’s always some humans in the chain. When the robots can design and create their own robots, we have hit the Singularity, and all bets are off. But not yet…

I was referring to things that are not (AI-driven) bots. If I obtain a SaaS service that auto-bills me on each API call then, there’s no human involved in the chain, and - though it goes to the back-end Organization in the end - payment is even handled in the transaction (e.g. via a Stripe payment provider, also a SaaS service, that is integrated in the exchange). The value comes from the Service directly.

(Question is more related to VF, because in many occasions it is not directly community-related. But I guess there might be an ‘accounting’ bot that reports on SaaS transactions that occurred → on Github you have a bunch of services that interact with issues and pull requests, that might be examples of this)


I don’t know too much about VF, so this may be off the mark, but…

Github is actually a good example. It offers various ways for 3rd-party service integrations, most important is Github Actions, and online marketplace. Many of these are paid services. Now suppose that Github handled the payment via a single subscription, or it offered an enterprise plan providing free access to a portfolio of popular 3rd-party services.

You’d have (fictitious) dependabot, stalebot, qualitybot etc. that automatically jump in during your development workflow at specific stages and do their work. No human intervention, apart from initial activation of the bot and maybe some config settings.

The Organization that you pay (Github) is different from the 3 Organizations that provide the bot. Furthermore, suppose you also have Gitlab which doesn’t offer this package directly, you might want to obtain these bots from their separate providers. I have to read up to VF, though, because if “economic agent” means ‘where-the-money-goes-to’, my argument is void :slight_smile:

(PS. There are a whole bunch of bots providing interesting services)

ValueFlows vs. AS/AP compatibility will probably mostly be defined in terms of model equivalency

Yes. Hopefully not too OT, but wouldn’t it be wonderful if we could create a separate spec for people, organizations, groups, their relationships, user accounts, etc.? That everyone could use? Seems like a lot of people are working on this piece of their particular puzzle, you mention some, also seeing it in Holochain and Hylo for example. And it seems like if people could create person-centric apps where the person could have an identity outside and across user accounts and different distributed technologies (fediverse, solid, holochain, etc.), it could solve a lot of problems relating the real world to applications. And groups could have a globally unique identity too. I speak only theoretically, but would love to try it. Another day though I guess.

[edit: I posted this without seeing the last 2 comments, so I am behind the discussion around bots.]

Since you are not dealing with the Organization directly but only with its Service, you might consider the service to be the economic agent

I think of it as who is responsible in the real world. But I could be wrong, my head doesn’t wrap well around tech with agency…

You might have a situation where an Organization offers many such services with different payment plans.

In that statement, the Organization is the agent, the services are economic resources, with a little-r. And there would be some agent behind the SaaS itself I would think, even if it is a consortium of some kind. And agents fulfilling could be different agents. But again, very willing to be wrong as use cases develop.

Moving on to thinking about relationship models, this is what VF has now, just as food for thought. It borrowed some of the naming from AS, but needed a few more pieces. And could be changed to be more AP friendly by figuring out the whole agent/actor mapping piece. (Sorry about the UML / relational representation, hope that communicates OK.)


I think User Account (or similar) would be connected to Person, one person can have many user accounts, whether across instances, across technologies, or over time.

The Role Behavior gives some “hard-coded” types of roles, thus freeing up the AgentRelationshipRole to be completely user defined otherwise. It would be something like “member”, “sub-organization”, “trading partner”, maybe a few others, the list is not well defined yet.

In AP, maybe the agent relationship roles in use by a group or organization could define new collections, similar to the followers collection in the spec? Or maybe just standard defined collections for the behavior roles, which can be agreed on? I’m speaking without any experience on an AP implementation, so may be totally off base.

Fully with you on that! It’d be :heart: lovely, and much needed too.

In the software development pipelines example with which I updated my previous post (Github as example), developers / IT orgs integrate services without ever contacting a human at the organization that provides them, possibly even without ever visiting the organization website.

Quite okay, familiar with it.

This is how Relationship object is defined in ActivityStreams:

  "@context": "",
  "summary": "Sally is an acquaintance of John",
  "type": "Relationship",
  "subject": {
    "type": "Person",
    "name": "Sally"
  "relationship": "",
  "object": {
    "type": "Person",
    "name": "John"

The relationship property has some additional info in that the relationshp defines an RDF-like subject predicate object pairing, where the property is the predicate and defined as Object. So it might hold the URI to a `vf:AgentRelationshipRole I would think.

I am also not where I want/need to be in terms of experience level, and hope other experts will jump into the thread :blush:

This is how Relationship object is defined in ActivityStreams

Yes thanks, we took inspiration from AS naming there, hoping for some merging some time. :slightly_smiling_face:

Seems like that could work. As you point out, the range is Object, so it seems intended to be defined pretty generally.

1 Like

@grishka in #software:smithereen has implemented true as:Group support. Thinking that whatever this extension should turn out to be it should be backward-compatible, or at least easily mapp-able, to group solutions currently out there in the wild.

Right now for Smithereen a decision has to be made how to represent the role of group members, where there can be Admins and Moderators. Quoting from this toot and subtoot:


Still not sure how to represent these group admins in #ActivityPub objects tho. PeerTube uses a similar construct for its channels and uses attributedTo to link a channel with its managing user. But I can have multiple admins per group, that’s the point :thinking:

Actually, I don’t make any efforts to make it compatible with existing microblogging software. And it indeed isn’t, because it relies heavily on walls. Those that I wrote a FEP about.

Mastodon does show a “group” tag next to it, and you can join it (I recognize both Join and Follow), and that’s about it. You can’t interact with it because that requires sending activities that Mastodon knows nothing about.

And, IMO, that’s fine. You can’t exactly reconcile all the problems that arise when you try to interoperate disparate software. People usually understand that. You can’t make a microblogging server participate in a forum network without it all looking ugly to the user on the microblogging side and to the developer on the forum side. I’m very much against perpetuating such legacy workarounds, like “mention this account and it boosts”, to make conceptually incompatible systems compatible at the expense of UX.