bluesky-social / ozone

web interface for labeling content in atproto / Bluesky
https://atproto.com
Other
285 stars 24 forks source link

Granting access to accounts #56

Open livfreeorcry opened 7 months ago

livfreeorcry commented 7 months ago

Granting access to accounts is (seems to be?) currently done by adding DIDs to a comma-separated environment variable, with no apparent control over privileges, nor any UI visibility.

This process needs improvement, generally. Granted access should be stored in the database rather than in environment variables. Control and visibility through the UI over which accounts have access and what permissions they have would be much more usable than manually editing text files.

bnewbold commented 7 months ago

Yup!

For what it is worth, there are a couple existing levels of authorization ("triage", "moderator", "admin"). These may not be how we want to categorize permissions going forward though, so these aren't documented/recommended in the setup docs.

We have a batch of work coming down the pipe to implement OAuth, and we might make this more configurable through the interface at that time. I suppose that isn't actually a blocker for adding/removing accounts to the server-side permission list though.

baatl commented 7 months ago

Not sure what systems exist for this, but I think Discord's define-your-own-roles ACL approach, with granular permission deny/apply/inherit switches (and per-channel/label visibility/interaction permissions) for a hierarchy of roles, is what I'd aspire to, especially if I wanted moderation for a labeler to, say, be tied to the existing moderation structure of a Discord server.

baatl commented 7 months ago

And of course, Discord also lets you set these permissions/restrictions on a per-user basis: perhaps roles and permissions could be derived from something that works the same way as account labels, or even (in interaction with) labels themselves?

baatl commented 7 months ago

To continue about what use cases an ACL solution ought to provide for (I briefly had this on #59 because I read "mod list" and got it mixed up with "access control list"): it should be possible to mark a user / role as having access to only a subset of labels / reports (the categorization of reports itself being a concept that needs revision, per what I was just describing at https://github.com/bluesky-social/ozone/issues/77#issuecomment-2024671558).

For one simple example: not all moderators for the Phobia Labeler are interested in handling reports for images with Spiders. Not only should it be possible for non-Arachnophobia moderators to filter out all Spider reports, it should be possible to make it so that users who are not on Arachnophobia Team are not even authorized to apply the arachno label (this would also help with the potential UI bloat described at https://github.com/bluesky-social/ozone/issues/77#issuecomment-2024694860).