Standardizing on a common Community domain as AP extension?

@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.

Yes, I agree with you on that. There shouldn’t be a “compatibility-at-all-costs” and cramming everything in a microblogging jacket. But still an investigation of current practices is in order followed by considerations of adopting what makes sense.

The standardization does not necessarily lead to the ugliness, and regardless of the beauty and elegancy of any extension, implementers always can make the decision to mold stuff in their project so it microblogs, however awkwardly.

Thanks for pointing to the FEP (and for writing it! :pray: ). Though I’m not the expert that knows all the AP intrinsics and complexity I may have some useful feedback (need to find some time, though :woozy_face: ).

I had a chat with @darius based on interesting toot on how “local only” posting contributes to community vitality, and Darius mentioned planning an extension to Hometown to add support for “Neighborhoods”. Very interesting concept, and related to this topic:

Friend Camp has about 50 active users and I just noticed we have more than half a million posts here since August 2018! I mean that’s 11 a day per person on average but still. That seems wild to me.

Last I checked something like 75% of our posts are unfederated. That’s still 125 thousand posts sent to the fediverse. I think local-only posting increases the vitality of community, increasing the volume of overall activity, and contributing more to the fediverse than a less vital instance would.

In other words: if Friend Camp never had local only posting, we would not have cohered as a community, and we would have contributed far less to the fediverse as a whole than we do with the ability to post unfederated.

Here is the a GH gist outlining the Neighborhood idea:

Hometown Neighborhoods

I am now working on a third layer of communication: a medium-trust layer. This layer (which is actually pretty high trust as far as these things go) is called a “neighborhood”. Let’s say that the users of have decided that the users of are really amazing and they want to share more with them. The coolpeople and the awesomepeople mutually decide to join a “neighborhood”, which means that neighborhood-level posts on either server can be seen by everyone on both servers.

This means that when you make a post on Hometown there will be three choices in a little dropdown toggle:

  • local (just the people on your server)
  • neighborhood (just the people on your server and a small group of other servers)
  • federated (the whole world)

[…] I do plan to publish neighborhoods as a specification.

I follow-up to the Neighborhood discussion with @darius I posted a great article I found (co-authored it appeared by a collegue of Darius). The article is interesting from two aspects:

  • First of all for game design, as the title suggests (anyone apply it in a Fantasary PoC for @cwebber? :wink: )
  • But in a larger context the concepts can be applied to Communities (i.e. this topic)

Design Practices for Human Scale Online Games [ and Communities! ]

When researching what it meant to make human-scale systems, we found several key concepts from social psychology. Each provides a set of constraints for social design. Social game design operates within the physical and mental constraints of the human animal, so it pays to understand these constraints and build them into our designs.

@lynnfoster @bhaugen do you have more good examples to look at of different relationship networks you encountered in practice?

@aschrijver here are some collected examples of agent relationships in economic networks that have used or are using our old software. These are all bi-directional because that’s all we supported, although I understand that we need to support uni-directional relationships like Follower. Hopefully this is answering your question; if you want more or different info, let us know, very happy to talk more about this.

An R&D open value network:
Representative (member)
Affiliate (member)
TechShop User (member)
FabLab Member (member)
Exchange Firm (sub-organization)
Supplier/Customer (trading partner)
Project (sub-organization)
Custodian (sub-organization)

A local herbal exchange network:
Grower (member)
Harvester (member)
Drying Site (member)
Seller (member)
Administrator (member)

A high school fablab network:
Customer/Supplier (trading partner)
District School (member)
Drop-off Point (member)

A network based on a crypto currency:
Coordinator (member)
Participant (member)
Support (member)
Self Employed Member (member)
Customer/Supplier (trading partner)
Local Node (sub-organization)
Child (sub-organization)

A local food network that is a multi-stakeholder co-op:
Farmer (member)
Distributor (member)
Administrator (member)
Processor (member)
Institutional customer (member)


Thanks a lot @lynnfoster!

While you were typing I was too. Re-reading a paper posted before…

The paper offers a full-blown conceptual model, something more related to what I’d like to have in my own future federated app…

The community network conceptual model

Though I don’t want to move away from finding the minimal definition to work with, the aforementioned A Community Network Ontology for Participatory Collaboration Mapping: Towards Collective Impact paper by Aldo de Moor of CommunitySense specifies the entirety of the community concept and for relationships has a number of different types:

Association-connections Member Of (5); Owner Of (2); Beneficiary Of; Has Client; Involved Partner; Research Partner Of; Stakeholder Of
Involvement-connections Involved In (15); Organizes (6); Informedness (2); Sponsor Of (2); Responsible Partner;
Access-connections Supports (3); Used In (2); Enables; Has Capability; Has Resource; Uses
Production-connections Strengthens (6); Weakens (6); Has Result (4); Produces (4); Located In (3); Story About (2); Used In (2); Case About; Dialogue; Followed By; Generates; Gives; Has Capability; Has Contract; Country of Origin; Country of Work; Data Source About; Involved Organization; Question/Issue About; Uses; Working On
Contribution-connections Contributes To (7); About (5); Aimed At; Has Domain; Has Impact; Has Theme
Structural-connections Part Of (16); Related To (3); Type Of

Just putting this out there, as maybe when extending our own concepts, we may be entering terrain where the additional semantics may start to make sense. Btw, with what Valueflows already provides a lot of this can already be captured, though less explicitly.

Update: Much of what is in the model above I would - for may own purposes - model in separate domains e.g. Governance, Collaboration, etc.

1 Like

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).

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

1 Like