Standardizing on ActivityPub Groups

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)
1 Like

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.

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

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

Could you explain what the problems are with the “Announce model of group federation”, and what you would suggest instead? We are using Announce for Lemmy federation, and so far its working perfectly (for public groups).

Announce fails when you have privacy and permissions involved. Downstream recipients can’t fetch and may not have permission to comment on the root object so the entire model breaks. I’ve also outlined elsewhere the issues with using OCAP to get around these limitations. You can no longer thread conversations because everybody is reacting to personalised/different id elements than other members of the conversation.

Aside: I guess most of the disconnect here is that I seem to be the only person pushing for privacy and permission to be fundamental properties of the fediverse. Not to mention account cloning/migration in case your instance admin goes rogue.

I do agree, everything is far simpler if you simply discard these concepts - especially on a decentralised platform where they are much harder to implement in the first place. At least to me, a fediverse without these qualities as foundational elements has zero appeal.

In this respect I’m definitely not alone.

1 Like

As I left Facebook a very long time ago, perhaps you could share what kinds of negative things you attribute to private groups on that platform. Looking it up on the interwebz I can only find some posts about Facebook’s recommendation engine recommending inappropriate group content, and some hints that these private spaces might be used by extremist organisations in the same way tools like Tor and cryptocurrencies might be used by some to sell drugs online. The former would appear to be a breach of privacy by Facebook and the latter a matter of people using privacy for its intended purpose; which is to have some direct control over who you share things with. I’m very interested in your perceptions and experiences in any case.

I think that is only a problem if it is possible to create child objects with laxer privacy/permissions than the root object. I know thats a problem on Mastodon, if a discussion is “followers only” and you only follow some of the participants, then you only see half the conversation.

In case of Lemmy, we will probably only provide privacy options on a per-group basis (eg public group or private group), with no privacy options per post or per comment. In that case I dont think it will be a problem.

Welcome @Gargron and thank you for bringing focus to the kind of private group that users in the real world expect. A public group is simulated fairly well with the hashtag modulo spammers but if you want to chat with your buddies and joke around, you don’t want to do it up on stage for the whole world to critique.

Also agree with your point about local-only posts because what follows is a desire to lock down the server and then admins have to stress over choosing between privacy and federation. As I said here I think groups are victim to a federation or nothing mindset so hope we can remove that and any other blockers to giving users such a valuable feature.

This is a similar concern to discussion I’ve seen around e2ee where message franking allows admins/mods to step when their help is required. Private groups are similar and I think as long as moderators exist, there will be ways to keep harmful activity in check.

FB’s problem is that their incentive (and duty to shareholders) to make money means they allow way more activity than is economical to moderate.

In the interests of moving past the current impasse, let me re-iterate that the only reason why one needs to consider private groups is so that we don’t end up with multiple ways of posting to them in the future that will be different. We require a mechanism which works for both. So I’ll propose a simple set of basic requirements and see if we can move forward:

  1. A group MUST provide an actor type of ‘Group’ so we can determine how to address it.
  2. Posting to a group MUST support FEP-400e as a mechanism and MUST use that mechanism whenever posting to a group remotely. Implementations are free to support additional mechanisms (hashtags, mentions, DMs, wall-posting, etc.) as desired.
  3. A message MUST NOT be cross-posted to multiple groups.
  4. Followups to the group MUST be sent to the group actor and SHOULD only be sent to the group actor. They MUST NOT include any external actors (non group members) unless it can be determined in advance that the audience for this particular group conversation is public.
  5. Groups MUST support ‘Join’ for group membership. They MAY support ‘Follow’ or other methods.

This is just a proposal. Feel free to suggest changes. Under the covers, as long as your group implementation abides by this or a similar basic set of conventions it actually doesn’t matter how it works under the hood or whether it is public or private.

2 Likes
  • Reading FEP 400e, it seems to be about collections. How does this translate to use with Group actors?
  • What do you mean by “Followups”? Wouldn’t sending things only to the group actor make them invisible to everyone?

Posting to a group is essentially adding the object to the group outbox rather than to its inbox. This procedure can be accomplished in C2S for your own resources, but not necessarily in S2S. FEP-400e simulates this behavior using a remotely initiated “wall-to-wall” post, which is Facebook terminology for this mechanism; meaning that if somebody posts onto your personal homepage (i.e. your wall), it is delivered to all your followers. This is the mechanism behind how Facebook groups used to be implemented (through a wall-to-wall post to the group homepage) - I don’t know if it is still done that way.

As for followups, please see section 7.1.2 of the ActivityPub spec. This is what we call the “conversational delivery mode” in which privacy is maintained throughout the conversation and thread completion is accomplished by sending comments to the sender (not necessarily the author) of the top-level post; who may have secret knowledge about who is included in the conversation audience (private lists/circles/aspects, bcc and bto recipients, etc.). This actor (e.g. the group in this case) then redistributes the comment to all the original participants. I would go so far as to say that this is the only actor who should ever receive comments if you wish to provide a privacy respecting platform.

4 Likes

I would go so far as to say that this is the only actor who should ever receive comments if you wish to provide a privacy respecting platform.

Poor choice of words for a technical audience. Mea culpa. It should probably read “… the only actor who you should ever send comments to …”. Every member of the group/list/aspect/circle still receives the comments, but the owner (who is not necessarily the author) of the top-level post is solely responsible for distributing them to the intended audience.