This is a discussion thread for FEP-5219: Groups and permissions
Summary
This document describes a permission system for ActivityPub groups.
It is inspired by XEP-0045: Multi-User Chat, which defines a comprehensive permission system for XMPP group chats.
The group actor itself is considered to have an
adminaffiliation.
I would make the case against this as follows:
The Group actor itself is not a human, nor a participant, if this clause was not there the Group Actor would need to make sure there remains at least one (human) external Actor as admin. Making group control loss a thing of the past. And voiding the need to ‘log in on the server and manually edit group permissions’.
It would also open the door to having more than one admin on the group.
Group actors should have the maximum privileges because some actions may need to be performed by a Group actor rather than an admin or moderator actor. This may be necessary to protect moderators from retaliation, for example. Another use case for this is anonymous groups where all posts are attributed to a Group actor (example: Telegram channels).
Multiple admin actors are already allowed - in this FEP and in FEP-1b12.
Then that should be a very explicit requirement for someone ‘super’ admin to execute. Which makes the onus rely on a server, or if done manually on someone possibly outside of the group.
To me it would make more sense when the Group Actor is know to have its limitations, so people can actually manage the reality of adversarial actions in a group. In stead of trying to fix social issues in a FEP. (something I’ve become intimately aware of 
)
Is this a product of the Groups TF? Since you're the author I'm assuming that isn't the case.
It may be worth asking them to see what things they've converged on.
The super admin is a server operator (or the controller of a DID if group's id is an 'ap' URI).
The last time I checked, not much progress had been made there. However, they are welcome to provide feedback on this FEP.
@silverpill @julian @feps I'm happy to look over this FEP, but we'll continue the work in the Groups TF. Would you be willing to submit it under the W3C community group CLA so we can include it in that Task Force's work?
@evan It depends on the terms of the agreement.
No agreement should be necessary, though - FEPs are in public domain, they can be implemented by anyone and can be included in other documents without restrictions.
Also, it is not clear what is the benefit of submitting a FEP to W3C. I already submitted it to the FEP repository, and this was always enough for everybody, including major players like Mastodon and Lemmy. These task forces look like totally unnecessary bureaucracy, I don't really have time for that.
@silverpill @feps @julian great question!
The W3C Community Group contributor license agreement goes beyond copyright -- it also covers patents and other intellectual property.
https://www.w3.org/community/about/process/cla/
It's great that FEPS are CC0 -- that makes it possible to redistribute the text freely verbatim or modified. However, it doesn't protect implementers from patents and other claims.
Preliminary look: The use of Relationship sounds kind of similar to the proposal for a Member or Membership entity to track properties of a Group’s members. It’s possible for something to be both a Member(ship) and a Relationship.
We want to support roles and permissions beyond just a hardcoded notion of “admin”, “moderator”, and so on, but we want to also cover a mapping from these concepts to the roughly equivalent permissions you might expect them to have (but with the recognition that different people have different expectations for this).
In this FEP, roles are not limited to "admin", "moderator", .... Custom roles and permissions are also allowed.