lemmy
lemmy copied to clipboard
LemmyNet
Add community privacy oriented settings
- Split out private, only mods can:
- view
- submit
- vote
- comment
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
One complication is that currently, mods can only be added from comments. But if its a locked community, this won't work, so it'll need a mod page that shows mods, blocked users, and ability to add / remove mods and block users from that page.
Are there plans to have more fine grained access control in general? It would be useful to have private subs that only certain groups can access, so we could use it as a company-internal communication tool (like Slack or Teams).
Yes, we've just had other priorities for a long time. But adding the privacy settings above will have to come at some point.
Its on our plan for 2021, fingers crossed that we'll be able to get to it.
This would also be a very interesting topic for me. e.g. to create a news area in which only admins/mods can open topics but users can comment.
I think a good place to start working on this issue ia too see how this is implemented in existing projects like phpBB.
Here is a test site where you can have a look, its extremely extensive
I saw in the matrix chat that you were looking for an MVP overview.
A granular permissions system as stated above is an ideal endpoint, but I think a simpler first step is possible: pending follower requests for community actors combined with follower-only communities.
Mastodon already has support for pending follower requests and I believe the biggest amount of work here would be some sort of UI for moderators to see and approve follow requests. And maybe something to add to the "Joined" button to show it's pending. It's possible another db table would be necessary, but ActivityPub explicitly supports this use case and the effects should propagate on their own.
As far as subscriber-only communities go, there is already logic for filtering different feeds based on subscriptions. Activities from these communities would need to be omitted from feeds even when type_=All. Direct links for posts/comments would return 403 for unsubscribed users. The API endpoints would need similar behavior. And then when a user is subscribed, everything proceeds as normal.
A question I'm not sure about is how mastodon handles global feeds and private accounts. Combining this feature with instance-only communities would be a good idea since ActivityPub is kind of notorious for being hard to enforce security with, but that wouldn't be necessary for an MVP. Just a thing with the connotation of "private" communities being difficult to square if other instances aren't respecting your filters.
Overall, I think this implementation feels less like adding a whole new system to interact with and more like adding some checks to existing ones. Lmk if it makes sense.
Thank you @GithubAccountOfDanielDavis! Dessalines and i wont get to this anytime soon, so contributions are very welcome.
About federation, i wouldnt worry too much how Mastodon does this. Being compatible with them requires a lot of reverse engineering and additional compatibility code, which just isnt worth the effort (at least not for the first version).
Has there been any work or planning around this in the past year?
Having a mix of federated and non-federated communities on an instance, account groups, communities limited to an allow list of accounts and account groups, an invitation and application system for the limited access communities, and giving accounts the ability to block entire instances would all be great additions. These all seem related and require more planning than a bugfix or adhoc change.
The part of my comment related to account level blocking of instances seems to be related to another open issue. https://github.com/LemmyNet/lemmy/issues/2397
I've been thinking about this in terms of access control in general.
Any update on the option to appoint mods and admins from anywhere other than comment and posts?
