Standardizing on a common Community domain as AP extension?

[aschrijver]

@grishka

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

[aschrijver]

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.

[aschrijver]

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

[aschrijver]

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

[lynnfoster]

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

[aschrijver]

Thanks a lot @lynnfoster!

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

@lynnfoster

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

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

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.

[bhaugen]

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

[aschrijver]

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

[aschrijver]

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

Exploring the «Community Has No Boundary» paradigm

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

[aschrijver]

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

[lynnfoster]

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.

[lynnfoster]

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.

[aschrijver]

@lynnfoster

Or maybe propose something in the context of the fediverse, and see who else sees it as useful.

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.

[lynnfoster]

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?]

[cjs]

@lynnfoster

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

[aschrijver]

@cjs

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.

@cjs

Or, in the ideal case, coordinate with each other on one conventional understanding.

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

@lynnfoster

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.

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.

[aschrijver]

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

Modular Politics: Toward a Governance Layer for Online Communities

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

[Sebastian]

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

[Sebastian]

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 https://w3id.org/empathi/ : 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": "https://www.w3.org/ns/activitystreams",
  "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": "https://redaktor.me/wonderfulMovieId"}
}

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": "https://www.w3.org/ns/activitystreams",
  "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": "https://redaktor.me/myArticleAPid"},
    {"id": "https://redaktor.me/myTimelineAPid"}
  ]
}

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.'
  }], // https://schema.org/contentLocation
  ['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.'
  }], // https://schema.org/locationCreated
  ['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:''}}]
]; // https://schema.org/spatialCoverage

[aschrijver]

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.