Standardizing on a common Community domain as AP extension?

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": "https://www.w3.org/ns/activitystreams",
  "summary": "Sally is an acquaintance of John",
  "type": "Relationship",
  "subject": {
    "type": "Person",
    "name": "Sally"
  },
  "relationship": "http://purl.org/vocab/relationship/acquaintanceOf",
  "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:

smithereen-group-roles

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 coolpeople.social have decided that the users of awesomepeople.social 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)
Sponsor
Donor
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)
Employee
Donor
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)

2 Likes

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:

CONNECTION TYPE CATEGORIES CASE CONNECTION 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.
https://gameprogrammingpatterns.com/type-object.html

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

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.

2 Likes

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

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

:+1:

Some of these relationship types can be standardized, so they are universally supported. Others can be fully app-specific and custom.

:+1:

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.