search

Chocobozzz / PeerTube

ActivityPub-federated video streaming platform using P2P directly in your web browser
https://joinpeertube.org/
GNU Affero General Public License v3.0
12.94k stars 1.49k forks source link

More defined roles #1294

Open McFlat opened 5 years ago

McFlat commented 5 years ago

I think we admins could benefit from having more granular permissions, groups and roles.

some good options for libraries we could use:

finding more options on NPM (there's just too many and most aren't a good fit):

We should think/talk about what is a good fit for our needs in regards to the libraries to use for frontend/client and backend/server. Something that allows to have default roles and permissions, and a good way to associate the roles/permissions to default groups, and possibly to allow users to create their own groups(to have other users be able to upload on their channels) to view videos or comment on their videos or to share them or to download them etc.

Some default groups could be:

Basically super admin can do it all, admin can do almost everything that admin can do, etc. But if we add permissions and roles then admins can create their own roles that have some permissions that others don't have

Some permissions could be:

I think you get the idea. We could make it granular and add some default groups, roles and permissions but allow admin to modify them as they see fit and allow users that create accounts to have permissions and roles they can assign and manage, this way we can have better control of who can do what and where, things like block other instances or allow other instances to comment, to view/share/embed the videos, etc. Instead of making some kind of minimal support where users can do some stuff, if we can make it granular then we give the users and admins the freedom to manage things how they want, if they want to allow or not allow something, we would just associate the capabilities to permissions, and the roles can have some permissions or not have some permissions, and roles can be associated to groups and users can be part of groups. groups not as in channels, but groups as in for capabilities, maybe in that case we'd have to rename actor Group to Channel sine that's what it really is. and introduce actor Role, Permission, Group not channel in this case, we'd have the actor channel currently named as Group renamed to Channel and add Group.

So there would be actor:

Here is some screenshots how discord.app does it:

screen shot 2018-10-16 at 8 12 57 pm screen shot 2018-10-16 at 8 14 15 pm
McFlat commented 5 years ago

can a current actor "Group" aka Channel have more than one Person to be a part of it?

rigelk commented 5 years ago

Channels belong to one user right now.

Chocobozzz commented 5 years ago

User roles and actor types (for ActivityPub) are unrelated.

We could create other roles though: https://github.com/Chocobozzz/PeerTube/blob/develop/shared/models/users/user-role.ts

But not too many, to avoid losing users.

McFlat commented 5 years ago

If we don't have ability for users/admins to create their own roles that's fine, I mainly just want more granular control of who can do what, if a user part of a group can download or not, or if they can comment or not or if they can even see a video or not.

McFlat commented 5 years ago

I'll get the work started in regards to changing the actor Group to be named Channel after that we can add Group, Role and Permission.

I think that's how it would work, if I'm not thinking about it properly please correct me.

Chocobozzz commented 5 years ago

I'll get the work started in regards to changing the actor Group to be named Channel after that we can add Group, Role and Permission.

There is not Channel type in ActivityStream, and we want to keep the Group type because in the future multiple users might own a same channel.

Again, user roles and actor types are unrelated so if you just want to have more roles just add them without changing anything in our AP definitions.

McFlat commented 5 years ago

While looking at the ActivityPub spec there doesn't seem to be a Group type either, so we can define it how we want in the application, there is a notion of a Collection or an OrderedCollection however. So Group is left up to us to implement, Person however is already defined in the spec as an actor object. We could push for adding to the spec Group, Channel, Role and Permission and the spec would be updated on the next iteration/proposition.

This without a doubt would put framasoft on the map, if framasoft is sort of take the initiative to push for updating a w3c spec, wink wink :)

[ActivityStreams] defines the collection concept; ActivityPub defines several collections with special behavior. Note that ActivityPub makes use of ActivityStreams paging to traverse large sets of objects.

https://www.w3.org/TR/activitypub/#collections

Group just doesn't make sense as a name for a Channel, we should name it Channel, and allow all the people part of a Group to be in control of the Channel. There could be a main owner of the Channel, or as part of the Group there could be a single owner of the Channel and the rest are just publishers. We could do it how github/gitlab does it. so to allow a Channel ownership to be changed and new users to be allowed to publish/upload videos on behalf of the channel.

ghost commented 5 years ago

Is there any news on this? Peertube ticks all my boxes, the only thing I need is to show Videos to different user groups.

erkinalp commented 3 years ago

I want to create a community instance where there will be multiple overlapping moderator pools that will moderate different channels and tasked on per-video basis with shift schedules. I am going to develop a plugin for moderator scheduling aspects, but the underlying permission system cannot represent per-video moderation permissions currently.

erkinalp commented 3 years ago

This is my sketch of permissions:

Applies to instance:

Applies to publisher:

Applies to team:

Applies to video/livestream:

Applies to user/team:

By the way, all the permissions above are supposed to be completely independent of each other, for example, Delete other's comments permission does not imply Delete own comment nor Comment permissions. Nor does Delete other users permission does not imply Delete own user nor Modify own user.

Argez commented 3 years ago

Hello. You can modify the code to create a new role and configure its permissions.