Standardizing on ActivityPub Groups

Me too. I’d be interested to join a discussion on standards process. RFCs, FEPs, re-implementable specs I’m all about.

FEPs go here and you can sign up there.

Can I strongly suggest that any Fediverse-wide group format take a cue from Twitter’s new group format - which they all Communities.
To
It requires users to join a group to interact or engage with the content, and if you aren’t a group member no group posts show up on anyone’s main feed… BUT no Twitter groups are private…there is no such thing as an unsearchable or invisible group or post in a group.

To my view, this transparency would make Fediverse groups far better than the cesspools of disinformation or worse that Facebook groups have become from day one of their existence.

1 Like

So those of us that actually desire privacy and private spaces will have to leave the fediverse or create a parallel fediverse where these things are permitted?

Way ahead of you mate.

1 Like

As I’m following VK with my groups UX, there will be two kinds of groups in Smithereen:

  • Open. Searchable and joining is optional. All content is visible to everyone. You can interact regardless of membership status.
  • Closed. Without joining you only see metadata and the member list. You can send a request to join that must be approved by group admins. Once you’re a member, you can see and interact with everything.

VK also has third group type, “private”, which mostly pretends to not exist unless you’re a member, but that isn’t very possible to implement with ActivityPub.

What you want is basically closed groups. Maybe with automatic approval, but that would defeat the purpose of them being closed.

Hi Tim, thanks for following-up to the discussion. As all the posts in this thread indicate: everyone has their own requirements when it comes to implementing Groups. In the examples you gave you weigh how 2 applications implemented them (TW and FB), and prefer one to the other. As Mike says, reformulated: “my requirements are different, and Privacy is important in my use case”, and Gregory also has different use cases implemented.

As Fediverse is the ‘social fabric’ or interoperability infrastructure for any kind of application the challenge is:

Requirement: Find the simplest model that covers the broadest set of use cases.

I suggested above that we should start to document these in another manner than an ever growing discussion thread. I propose:

  1. We start with a wiki post and collect use cases, requirementes and other considerations.
  2. Once things are a bit structured, we can organize a meetup to discuss the ins and outs.
  3. Based on 1) and 2) we then begin the process to come to a good FEP document.

Unless there are objections I will create and pin the wiki post.


I would also like to ask your feedback on the conceptual model I outlined above, as I think it is very flexible in the way it allows arbitrary (and some standardized) relationship types to other actors. Is it too naive? Or is it too much of an extension with the additional relationships collection (so that following gets its original intention back)? Too complex to implement? I added some more background in the Community discussion here.

Re:Smithereen, just as an example… implemented are a very interesting set of Group features. But they are still very application-specific, and universal requirements and use cases should be further distilled. Consider:

  • Open / closed / (private) does not cut it. In my app I may define Open as read-only, or e.g. define a new state Public for that.
  • There’s the notion of ‘membership status’ or roles with currently I believe admin / mod / member privilege levels.
2 Likes

For what it’s worth we identify both the different group types and member roles as an extensible list of permissions. So your relationship with a group can take on any of over 65000 unique dimensions (currently). While it’s convenient to try and fit these into 7 or 8 named types+roles, permission discovery might prove to be more useful; as it most concisely encompasses both concepts. It’s easy enough to mock up in any case.

1 Like

Thank you, yes I agree with that. I was thinking the model at least needed some standard relationship types to have well-defined meaning and behavior when encountered. Other relationship types are then app or domain-specific and can be ignored when encountered.

Other than that I wonder if permissions and permission discovery mechanism - and some other common dimensions - should be another AP extension altogether. Separately defined and not tied to the Groups extension. So that all these extensions become like ‘micro building blocks’ that can be combined together or build on top of one another, to add some capability. For instance, for my own purposes I’d like to build on Groups and Permissions to enable Governance models.


Groups vs. Communities?

Something else I wanted to highlight. I find our overall approach to adding ‘Groups support’ to be overly technical. We look at adding as:Group in our individual apps in a standards-compliant way, rather than imagining how universal group support more broadly enriches the fediverse. This while we all recognize that empowering people and their social interactions is key. We strive to model real-world concepts and make them work online. And be innovative with that: Social networking reimagined.

I see my draft diagram not as ‘Groups support’, but rather as (the MVP of) a Community concept. In more technical terms it is a sub-domain. While I did not name my Community AP extension topic as such, I imagine it enables a paradigm shift for the Fediverse which I call “Community has no Boundary”. Not just the community is important, but the space between communities that allows them to interact. This is where the Fediverse shines. Our community model should break barriers between app / instance silo’s, and be more versatile than just offering follow and join capabilities.

Looking with this mindset shouldn’t mean that adding groups support suddenly becomes much more work, and we get stuck in ‘analysis paralysis’. It would allow us to lay the proper foundation to the paradigm shift, an MVP if you will, and maybe a maturity model to gradually expand on that. And I think it would be greatly inspirational to adopt this broader perspective.

In this Community extension post I already mentioned the work of Aldo de Moor, focusing on relationship types in his community vocabulary. But I highly recommend  reading the entire paper and imagine how the Fediverse could be supportive to realizing its goals.

And see also:

(PS. I tooted a link to this post in: Humane Tech Now: "I just wrote a plea on #SocialHub to think broade…" - Mastodon )

3 Likes

Please help me understand what actual deliverable or outcome you’re seeking. The fediverse has several implementations of groups and we do our best to make them compatible while allowing some to have a wider range of permissions and privacy features than those which see little or no value in these principles. Perhaps your personal favourite platform doesn’t provide groups natively today and can’t agree on how best to provide them and doesn’t like any of the existing implementations, but that’s a problem only that or those platforms can fix.

How do you actually propose reaching this magic space between communities? With a bill of rights? With an ontology? OK, so we let groups and sites (the other de facto organising principle for projects that don’t yet have groups) publish a taxonomy in their actor record to declare their affiliations and alliances and purpose. So, hashtags. Categories perhaps. And let people follow those hashtags and/or categories. And/or those sites. And/or those groups. Several projects already provide various combinations of the above as organising principles and tools. We’re actually very close to letting sites follow other sites which then implements all of them; and all of these organising principles can be as closed or open as the entity creators desire and you can pick and choose which organising principle or principles suits your individual needs.

But apparently this is not enough and we still don’t get it. Please help us get it. Tell us a story about what this fediverse of yours looks like and more precisely how it differs from the fediverse we have.

2 Likes

After reading the document per request, it seems the tipping point is the scaling fractality that is described in the text. This is something that we know from the Holo*-world, or which can be perceived by using one of these networked notebooks that offers backlinks and transclusion.

Another point that is made in the article is one about how in socio-technical design we cannot only perceive the technical environment alone through its implementation details, but also need to account for the actual use of knowledge epistemologies, and in a higher order ontologies, in the everyday.

This is to say, that existing categorisations, neither in hierarchic or flat namespaces, can often not replicate the actual intertwingularity of social processes. Whereas in a web of directly connected peers, supported by a and supporting the Creative Commons, pieces of knowledge (“epistems”) wander freely between domains.

I can say that, because I have been using the federated wiki for the greater part of the last decade, which employs a more “passive” type of federation. Other forms of interaction become possible, beyond the commonly known ones, beyond those replicated by the ActivityPub protocol family. Feel free to dig deeper into that rabbit hole, which can hardly be explained, and must be experienced:

What you are asking for is sometimes named inbetweenness in philosophical discourse:

This space, this “inbetweenness,” […] will then be governed by the laws of probability and uncertainty characterizing all unstable systems.
https://journals.ku.edu/jdtc/article/download/1785/1749/2113

We shall stop here, because that’s another rabbit hole to avoid for the moment.
If we allow ourselves to conceive the Web as an Atlas, an atlas of human knowledge and interaction, for example, the following words might apply as well:

An atlas (the Web) can connect space and time in new ways. An atlas (the Web) can articulate the coalescence and collision of local and global trajectories, described by the late Doreen Massey as ‘throwntogetherness’. Massey describes how different elements and trajectories – human, more-than-human, social, cultural and political – come together to define a here and now. In this understanding, space is not limited to specific areas or points on a map, instead it is produced by the encounter of multiple local and global trajectories which have also a temporal dimension.
https://www.mappingedges.org/projects/the-green-square-atlas-of-civic-ecologies/what-is-an-atlas/

I think it is this kind of random encounters, and greater-than-the-sum-of-its-parts experiences, that would render the space between communities, the space inhabited by “borderless” communities with semi-permeable membranes, into one beneficial to social plasticity. Ultimately realised through interaction, and recorded as data desiderates, before constraining our imaginaries with what is already there, this is what we morally will want to design (gestalten) our shared public space, the Web, for.

If we allow ourselves to consider the Web also as a place, than all theory around Third Spaces (Bhaba, Soja) also applies here:

The MDPI article also contains a paragraph about the nature of federation and asks:

Still, this organic process is haphazard at best. Unclear is how to more systematically boost such a self-organization process of a ‘federation of locals’ grounded in such a ‘relational epistemology’ and ‘scaling fractally’. How do we begin to realize these necessary but abstract goals at scale? This is where the literature gets fuzzy and few operational methods are offered.

Here we want to find new ways of mediating social interaction, in so unexpected forms of sociomes become possible. This is already part of establishing technical protocols. And understanding their implications and limits may help us to think around the box, to give way for the much larger, interdependent contexts of each community’s stories:

Given that communities all have their own interests, characteristics, culture, and language, how to make sense across their boundaries in order to explore and expand their common ground?

To pick up your earlier question regarding an actual proposal, let’s forget about this ontology thing and that mapping process for a moment, and focus on their hypotheses and offered pathways for resolution:

My intuition tells me an inferred proposal could be, that some kind of fuzzy search (recommendation algorithms, based on NLP and automatic classification of media?) will have a higher chance to open up “the space between” the spread (technically federated) but isolated (socially embedded) side-effects of digitally encoded social interaction, than explicitly modelled structured data, even if we’re talking about folksonomic approaches like tagging and social binning through categories/groups.

Please feel invited to recapitulate my summary and discuss the text further in its annotations

For a critical review and conversation around the paper, I have skimmed the Introduction and Conclusion and highlighted (to me) notable sections that make up the text’s core findings (for me):

1 Like

Thank you both @macgirvin and @yala. You two have deeper technical and theoretical knowledge than I possess, but I’ll do my best to follow-up with some elaboration and musings. The notion that we may not be far from realizing this already is great.

We have Groups, a rather concrete concept that always has been in the specs. And we have Communities, a much more abstract idea that uses groups to model social interactions more like they exist in the real world.

Current scope of discussion?

First requirement is: Analyse existing Group implementations, and see if there’s a common model we could start with that requires the minimum amount of rework, and avoids breaking changes where possible.

In the discussion thus far I found most of the focus to be on this requirement, and envisioned groups support in apps to be how we commonly experience them in most software. In summary our discussed requirements / functionality seemed to boil down to:

  • We have groups (Group actors are exposed on the network) and people (Person actors) that participate in them.
  • Person actor either Follows or Joins a Group, but the mechanics and difference between them need to be clearer defined still.
  • Groups themself have certain characteristics, e.g. Open or Closed, but we need to discover how to define these best.
  • Participation in a group comes with privileges and some kind of permission model. This may or may not be in scope.

That’s a great start, and in the ‘maturity model’ I mentioned this could be the basis, the foundation for groups support. Conceptually what we no have are:

Deliverable: People can follow and join Groups across the Fediverse.

A Follow relationship probably relates to a passive participation, where they just want to be informed, while a Join relationship is established to allow them more active participation. You might label them as following and member_of relationships, maybe.

All-in-all two relationship types in the above. I don’t know how well they fit in current implementation of actors, and how you’d discern between a follower and a member. Maybe current implementations make an either/or choice in what they support. In the model I imagine both Guppe (followers) and Smithereen (membership) have a convenient way to implement. Both are supported.

Support more intricate relationships?

I don’t know what use cases we want to facilitate that need more mature levels of Groups support, and some of them may require other parts of the specs to be extended first, e.g. by having Capability Negotiation or something like that.

But let’s just brainstorm a bit… some random thoughts follow:

  • Take this Discourse forum. It represents the SocialHub community, and we have membership via our account. The software automatically places us in groups. We start in trust_level_0 and based on interaction we are also added to trust_level_1, trust_level_2, etc. And we gain privileges that correspond to policies attached to these groups. Similarly, if you make someone Moderator, they are auto-added to a moderators group, and also a staff group. And custom groups can be defined.

    • → There’s a topology to groups which allows them to be nested and span overlapping subsets of members from their parent.
  • On the Fediverse we consider instances to be communities. But other than some apps having an actor that represents the server, we don’t have a Group actor that represents this community. What if we had? Take for instance Lemmy. I might join Lemmygrad, a community for people interested in communism. Then I’d join other Lemmy communities, some owned by Lemmygrad, some elsewhere. The ones on Lemmygrad might again indicate a need for nested groups (currently unnecessary as Lemmy doesn’t give special meaning to such relationship right now)

    • → Instances defined as groups means they’re now 1st-class citizens of the fedi.
    • → “instance” is now a technical concern. The instance community / group actor(s) have their own Profile to characterize them.
    • → There’s still the need to have instance / server actors. Nothing much changes wrt what they are used for.
  • We have a couple of standard actor types, but can also define custom actors. What does it mean if they participate in a Group? What if e.g. a community allowed both individual people and organizations to join? Would the organization have the same agency as a person? Or would there be representatives that also join the community group?

    • → There seems to be a need to support different relationship types in addition to standardized types.
    • → Custom relationship types need not be understood, but they need to be supported.
    • → Extensions defined on top of Groups model provide meaning for a particular domain (e.g. eCommerce, Government, etc.)
  • Consider specialized federated applications that go beyond offering familiar social features. We don’t have many of those yet, but take for instance FedeProxy. Let’s say they want to offer a Teams functionality. A team can be associated to an Organization, a Project, or a Repository. But Teams can also completely roam freely, offering their services on the fediverse. After all FedeProxy’s goals are to liberate software development. Now these teams are multi-disciplinary and there are Developers, Testers, Techwriters, etc. There are multiple ways to model this. 1) Subgroups. Team parent_of Developers. 2) Custom actors. Member is a Developer. 3) Custom relationship types. E.g. member develops object. Or some combination of these.

    • → How well could this fit a common Groups model?
  • What if in some future Fediverse our identities would be fully decoupled from a server instance? It would have many implications. But not just for Person actors… any actor type potentially. A community may span multiple servers, and I can spin up another server that facilitates e.g. a subgroup within such community. Other servers may be added to support just my subgroup. Or compose other group intersections. A conglomeration of groups is formed that can be navigated as a graph.

These are just some considerations my foggy brain could come up with this morning. They might indicate further requirements for a second maturity level:

  • Groups support arbitrary relationship types to other actors.
  • Besides following and membership there may be a need to standardize some more relationship types.
  • An actor can have multiple relationships to a group at the same time.
  • Custom relationships are only meaningful in specific domains and can be safely ignored otherwise.

Now my loose brainstorm might all seem to imply tremendous complexity, but I think the core model need not be all that complex. And as you say we may be already almost at the stage to have it realized. I defined my naive conceptual diagram with the above requirements in mind. Including once more:

In my mind all we need to do is define:

  1. The ontology. The entity-relationshp diagram as it were.
  2. The vocabulary. The detailed property definitions, JSON-LD formats.
  3. The behavior. The message exchanges patterns, rules needed for interaction.

Some things may not be directly in scope, but relate to further capabilities we’d like to see added to AS/AP, e.g.:

  • Capability negotiation / compliance profiles?
  • Group discoverability maybe?

Idk, I’m not the expert here :grinning_face_with_smiling_eyes:

What does all this bring us?

  • A foundation on which to build very rich semantically meaningful interactions across the fediverse.
  • A means to benefit more of the Linked Data aspects of the AS/AP protocols (while you can still use plain JSON, of course).
  • A pathway that eases more specialized applications to bring their business domain to bear in well-supported manner.
  • An opportunity to finally create an abstraction layer that avoids all the technical terms that confuse non-technical people.

@yala’s description hints at how deep this may go, and I find that exciting to consider.

In the above there are two maturity levels to be defined, and the scope of that seems well within reach. With these in place federated app developers can go wild and develop tons of extensions on top of Groups that may become de-facto or official standards in turn.

Over time new domains can be come native to the fediverse. They have groups at their core. Some random examples:

  • Crowdfunding: funds, sponsors, donates, …
  • Collaboration: owns, supports, contribute, reviews, advises, …
  • Organization: manages, steers, partners, supervises, subsidiary of, …
  • Ecommerce: offers, buys, sells, supplies, …
  • (…etcetera)

So much theoretical discussion when everything has been invented 10+ years ago. There’s nothing left to invent. It’s not like groups on social media are an alien concept to people. You have to copy the UX from existing centralized platforms and the rest follows from that. That’s it, that really is it. Storage, federation, relationships, you name it. UX is where you start, not where you arrive when you’re done with the other parts. Doing it backwards like this is a sure way to end up with something that’s very unpleasant to use at best and impossible for a newbie to figure out at all at worst.

3 Likes

We actually had major huge chunks of your vision in Hubzilla years ago. While there are still some fans, most fedizens hated it. People outside the project couldn’t get their head around what it meant, and they still can’t. This was one of the driving forces behind Zap - to distill this somewhat advanced functionality down to something normal humans can get their head around in a social media setting.

We have groups (Group actors are exposed on the network) and people (Person actors) that participate in them.

So far so good.

Person actor either Follows or Joins a Group, but the mechanics and difference between them need to be clearer defined still.

You join a group. Period. Why do we also support “follow”? Because that’s how it works in some project visions of groups and we’re trying to retain compatibility. You shouldn’t need to know or care what happened under the hood. At the end of the day you click a button to indicate you’d like to have this group in your life and this starts a chain of events which either results in Accept or Reject.

Groups themself have certain characteristics, e.g. Open or Closed, but we need to discover how to define these best.

If they are open, anybody can theoretically join (*) and messages are by default public (they also are shared with the network timeline). If they are closed, membership requires approval and messages are restricted to the group “circle/aspect” by default. There can also be a lot of different shades of grey between these two settings. It isn’t something that can be mandated or specified because everybody’s requirements are different.

(*) Anybody can be ejected from a group as well.

We also support an additional role called “private” where the existence of the group is hidden to outsiders and you require an invitation to join. The ActivityPub protocol does not provide the basic opsec necessary to support this role; so these groups currently only exist in the fediverse underground.

Participation in a group comes with privileges and some kind of permission model. This may or may not be in scope.

So in some groups you might be assigned as a moderator and in some you may be moderated and in some groups you can upload media and create events and polls. Some you can’t. This is mostly orthogonal to the discussion and does not influence the primal group behaviour which is to broadcast group posts to the group members and optionally to the public. To implement these roles you first need to implement somewhat granular and possibly extensible permissions. And again, we provide this as part of the project foundation. It has nothing to do specifically with groups. Everybody has this permissions and privacy infrastructure behind them and can force any of their connections to be moderated or prevent others from uploading media to their space (etc.)

Deliverable : People can follow and join Groups across the Fediverse.

I believe we’ve met this brief. We’re waiting for other projects that rejected our implementation to propose and implement something – anything that works. The “Announce” model of group federation doesn’t work well with permissions/privacy. So groups built on this model have a number of pre-imposed limitations. This is OK, but developers need to be aware of it.

A Follow relationship probably relates to a passive participation, where they just want to be informed, while a Join relationship is established to allow them more active participation. You might label them as following and member_of relationships, maybe.

This definition has not been adopted anywhere to my knowledge. Again, we join groups that allow join, and we follow groups that don’t implement join and only allow follow - such as gup.pe, which is a technically valid but limited group construction based on Announce relays. If you are proposing that we enshrine this difference as a difference in behaviour, let’s think about what behaviours you wish to attach to a follow relationship which are different from a join. Currently the only difference is that some group implementations support follow and some support join. We implement both and I suspect this means that everybody else will also need to, since developers can’t agree on anything.

Take this Discourse forum. It represents the SocialHub community, and we have membership via our account. The software automatically places us in groups. We start in trust_level_0 and based on interaction we are also added to trust_level_1 , trust_level_2 , etc. And we gain privileges that correspond to policies attached to these groups. Similarly, if you make someone Moderator, they are auto-added to a moderators group, and also a staff group. And custom groups can be defined.

Granular permissions. Ticked that box a decade ago. Other projects may never implement this fully - it might require a complete rewrite of their product to support anything beyond Mastodon’s four basic scopes. But we support it today.

There’s a topology to groups which allows them to be nested and span overlapping subsets of members from their parent.

Circles/aspects. Tick.

On the Fediverse we consider instances to be communities. But other than some apps having an actor that represents the server, we don’t have a Group actor that represents this community.

Many of our sites actually do. That’s usually the first group that gets created on a site. I’ve been working on enhancing the “site actor” role in depth for a few weeks now. Will have something to show others hopefully in a couple more weeks.

Site actors (aka ‘Service’) can make connections and have friend suggestions just like Person actors and Group actors do. Friend suggestions are currently based on social graph distance and actor taxonomy correlation. This works well without getting spooky and ethically questionable.

Teams. How well could this fit a common Groups model?

That’s really all it is. It’s a group with members and they can discuss things as a cohesive group rather than as individuals curating their own timelines. I think the way MS implements it is more like Yahoo groups or Groups@AOL (which I was development manager FWIW); where a group can also have a number of group resources attached to it. Photo albums, event calendars, chat rooms… and we provide these also.

What if in some future Fediverse our identities would be fully decoupled from a server instance? It would have many implications.

Nomadic identity. Again, we have it today.

Crowdfunding: funds, sponsors, donates, …
Collaboration: owns, supports, contribute, reviews, advises, …
Organization: manages, steers, partners, supervises, subsidiary of, …
Ecommerce: offers, buys, sells, supplies, …
(…etcetera)

And yet there’s nothing on this list which we aren’t already doing in the fediverse today. I’ll stop now.

2 Likes

Wow, love your feedback once again, Mike. Encouraging indeed to see how much of this is already worked out, and we now have opportunity to standardize more of this across the board. I’ll try to give a structured follow-up, but first…

Do you really think that? I agree that groups on traditional social media are nothing new, but have the feeling that what we have on the fediverse goes a bit beyond that. First of all we are federated which comes with its challenges, but most importantly we want to achieve as much interoperability as possible for a wide range of different application types and ‘business domains’. The UX’es for each of these will also very much depend on the use case they implement.

I quoted 3 snippets together. I understand that fedizens might hate it, but their confusion stems from how the UX/UI exposes the underlying model. Bringing more flexibility to the model, while retaining as much backwards-compatibility with what’s already out there means that no renewed confusion or dislike will occur, as the UX in current apps can remain unchanged.

Wrt the last part of the quote I am curious. Looking at my diagram above is “A Group has a Collection of Relationships to other Actors” already implemented in some way, or commonly done a different way? For instance the Valueflo.ws model (not AS/AP, but Linked Data) is “Actor has Relationships to other Actors”, i.e. much more generic. But maybe too generic was my thinking, hence I added a relationships collection to Group.

I don’t mind if the model we adopt is very different than what I imagined, but to me most important is to be able to deal with rich semantic relationships in some way or other. In a Communities subdomain I see these relationships as core to providing the “magic space between communities”.

Follow and/or Join?

You are right to say that currently one or the other can be chosen, and for current use cases Join seems to me to be the better choice too. But from a functional perspective I see merit in supporting both Join and Follow, as they have a meaningful semantic difference.

  • Follow would be exactly similar to how stuff works when a person follows another person, no changes in behavior for groups.
  • Join would indicate the person wants to have a deeper level of involvement, and its app-specific what that means.

I am a would-be federated app dev, and have a use case where this difference is used. The project Outreach (not yet started) allows people / orgs in the commons to target campaigns at traditional social media via their own channels. In Outreach there may be “Climate change” and “Privacy” communities, and then for a fedizen that’s passionate for privacy:

  • If you Follow the “Privacy” community you may receive this on your timeline: “Privacy International has started the campaign ‘Easy privacy practices to adopt’. Join the community to participate.”
  • If you Join the community you’d get way more messages, e.g. like “Starting preparation of campaign ‘Easy privacy practices to adopt’ by Privacy International. Participate in the Outreach app to enlist your help.”

In my conceptual model it would be easy to distinguish between followers and members, as they are tracked in different collection, with the latter in relationships. (Note that it need not contain just Relationship objects, it might also contain Actor objects directly which corresponds to a member_of relationship, a default).

Privileges, permission model → out of scope

I agree with your notion that this is orthogonal, was my feeling as well, and same for granular permissions. (Note that my Discourse example probably boils down to granular permissions + circles/aspects).

An important topic to separately address, but can be out of scope wrt basic groups support.

Group topology → circles / aspects?

I think it is very interesting to this discussion to delve deeper into the mechanism you are using, and consider it for standardization.

Instances, site actor, community actor?

Propose: Make this a separate topic, for the definition of an additional FEP.

Delighted to hear about your work in this regard. Another case where Zap et al is probably ahead in exploring stuff. Though this topic goes a bit beyond the scope of basic groups support, it is important for discovery and interop. We may address it in a new topic, and eventually address a separate FEP for this?

I don’t know about your impl and ideas, but will provide some thoughts of my own. I compare actor model a bit to how Akka works. The instance / server can be considered as providing the actor system, and it has a root actor which corresponds to the ‘site actor’.

I don’t know what site actors are currently all being used for, but in my mind it deals only with technical concerns & responsibilities. E.g. involved with server health, admin/moderation and availability for federation (if I actually used Akka in the codebase I’d probably have a child actor ‘federation’ to delegate to). The details of this are beyond scope wrt this discussion.

The ‘Community’ actor (name doesn’t matter much, but it is a group) I referred to would be a child actor to the site actor. It doesn’t have a technical but a functional role. It provides insights into the member base that is available on the instance, and information about topics, rules, CoC, ToS. And the top-level access point to drilldown into group topology, if the instance provides more than a single group. A site actor would have 0…N community actors.

Groups decoupled from instances → out of scope?

Groups that are not tied to the single instance where they are created is an ‘advanced feature’ that may be out of scope for now. Unless its implementation later on - e.g. based on Nomadic Identity - would lead to breaking changes to the basic model we define now.

The problem with defining Join vs Follow is that in doing so you break or technically “outlaw” software which is currently using the Follow construct e.g. Friendica, Gup.pe (perhaps others). This is no longer about defining a specified behaviour but managing the transition of those projects that would be affected by the change. And in case you haven’t noticed, project developers in this space tend to resist authority.

I’ve outlined a possible solution to circles/aspects in Mastodon elsewhere. It involves binding a conversation to one of the two available addressing/delivery models using ‘replyTo’. Once bound, cooperating user agents would not providing addressing or privacy scope fields on followups if/when the conversational “top-down” delivery model was in effect (e.g. the recipients and privacy scope of the entire thread were pre-determined by the thread creator). I believe that is currently the only thing preventing that project and other microblog projects from playing nicely with conversational systems and also supporting groups/aspects. Playing nicely is a good thing. We support all of Mastodon’s non-standard privacy scopes. Is it too much to ask that they support ours, especially since ours is actually written into the ActivityPub spec? Granted, the spec left out a couple of things that are absolutely critical to making it work correctly.

I can only laugh that some would consider permissions/privacy and identity/data redundancy to be out of scope in a social network environment. I consider them to be the only things that really matter; and will continue to walk this path mostly alone it seems.

2 Likes

Thanks!

I don’t know if with this you refer to mastodon, or my paragraph “Privileges, permission model → out of scope” above. If the latter, rest assured I only mean wrt this groups forum topic and with Privileges / permissions having broader scope. I consider the subject itself more important than groups. so I am with you there.

Update: I edited the post above to make it more clear that mentions of scope just refers to current discussion.

The main reason not to use LD-Signatures is the difficulty of revocation, e.g. a signed activity remains cryptographically valid even after the original activity has been deleted; this allows replay attacks that have to be combatted by permanently storing IDs of deleted activities (we call them “tombstones”). While we still use LD-Signatures in a limited capacity (for public posts) in Mastodon, that is the reason we’re not pushing for that mechanism to be used any further. However, if I remember correctly, nested and partial signatures are possible.

We have to think about how groups would fit into the landscape of the fediverse and whether this approach would serve people adequately. Currently, theme-focused servers are used as defacto groups – and this is a source of some friction, such as people feeling like they need to create and manage multiple accounts on different servers, and forming server identity that leads to server vs server “us vs them” conflict, that in turn leads to community burnout and other social and technical issues. One of the most requested features on the Mastodon feature tracker, and a popular fork feature are “local-only posts”, which for all intents and purposes means posts that are only visible to the “group”. The only thing is that (in my opinion) the group is on the wrong application layer, a layer that is simply too rigid for that purpose. So to me it seems like the real group feature that is being discussed here should have the ability to have posts that are only visible to the group, since I believe and hope it should replace servers-as-groups and alleviate the issues that come from that.

For what it’s worth, I do not think that we should hold onto group implementations that use Follow/Announce (I’ll call them “relay groups”, some even operate above Mastodon’s REST API layer through a bot). They are path-of-least-resistance approaches that in my opinion would leave much to be desired for the average end-user. Over-complicating the “real” group implementation by concerns of backwards-compatibility with them does not make sense considering how long these “relay groups” have existed vs. how long the “real” groups will exist. I do not consider my voice to be authoritative on the matter but it makes sense to me that you would Join a Group and that Group actors should not engage with the whole follower model at all.

4 Likes

Am I understanding correctly that lots of different ideas about what a group is are floating around in this discussion?

Like

  • An informal discussion group
  • A group that you might have a defined relationship with (eg membership)
  • A group that you might need permission to be a member of, or that you could be kicked out of, indicating that the group itself has some agency. So how is that agency executed?
  • Another level of agency where a group take public actions as-a-group, like schedule a meeting or make an agreement to do something with another group.
  • etc.

Somebody mentioned Teams upthread. That’s an example of a group that usually has some agency as-a-group.

How far do people want to go, in which direction? And especially how far to start with?

(P.S. I know this started out as Pixelfed groups, but I think the thread has already been hijacked by being posted in the fediverse, and here, as a standardization effort about groups-inp-general.)

1 Like

Yes, indeed. I post to put my hat strongly in the ring that the damages and dangers of fully private groups are not worth it, and should not be designed into the standard. Facebook has shown us what those bring, and let’s not recreate that.

Another level of agency where a group take public actions as-a-group, like schedule a meeting or make an agreement to do something with another group.

For example, I am a member of social.coop, which hosts its own fediverse instance, for which I pay something like dues, but it also holds meetings and makes agreements as a group, including an agreement with meet.coop so that social.coop members can use meet.coop online meeting facilities. Meet.coop also has an identity in the fediverse which I follow, but they do not host their own fediverse instance (yet).