Comment by Arathorn | Hacker News Reader

Comment by Arathorn | Hacker News Reader

Parent Full thread

What would you say the delta is between Element's current video-rooms and Discord-style voice-rooms (if you go and mute video for everyone), ooi? The only reason Element hasn't implemented precisely the same UI as Discord is because it's not (currently) trying to be a Discord competitor, but more a "run your own encrypted Teams alternative", given that's what Element customers are asking for right now, and we're having to follow the money to try to get sustainable. However, what we're trying to do is to ensure that Discordish features still work, despite having to focus more on Teamsish features.

In terms of permissions: I'm a bit surprised that folks feel limited by Matrix's freeform hierarchy of permissions. Every user can have a 'power level' from 0 to 100, and you can then customise the threshold required for literally permission (e.g. you need power level 54 or higher to kick users, or whatever). The only difference with Discord is that Discord lets you pick entirely arbitrary combinations of permissions (e.g. have one user able to kick but not ban, but another user able to ban but not kick, or whatever). How useful really is this in real life usage though?

I'm trying to work out whether the problem is if Element's UI for configuring permissions is too basic, or whether folks really do need a full RBAC permission matrix, and if so, for what use case?

The power level model of permissions feels to me a bit overly simplified. It’s so easy to imagine scenarios where you need exceptions to the rule of permissions existing on a single axis that it seems very limiting from the outset.

The idea of ever increasing and overlapping scopes I don’t think maps well to most people’s mental model of who should be allowed to do what. People mostly want to define an arbitrary role; admin, user, team leader, whatever, and just pick what that role is allowed to do in isolation. It’s marginally more work to setup initially picking all of the permissions again, but it removes all of the overhead of having to monitor what permissions are being adopted from lower scopes on the power level axis.

I also think the power level system makes it much harder to “refactor” permissions for specific roles without affecting permissions for everyone “above and below”

In my experience with running Discord servers you setup a couple of hierarchical roles (admin, moderator, user etc) when you first setup the server and never again.

However I'm constantly adding new roles which are really just groups of users. I would say 90% of all the Discord roles I've ever created have no permissions associated with them at all and just exist to ping a group of users (or act as a tag for bots).

Maybe that's served by a different feature in Matrix for user groups. If so, that's still not quite as useful, because sometimes later on you decide the group needs a permission (e.g. a casual gaming group has grown enough to justify having it's own channel).

Right - this matches my hunch; that folks want to define groups of users (which you can already in Matrix in 'spaces', but the UX in most clients is awful) - and what they really want is group-based permissions (which isn't part of the protocol, and instead gets layered on at the application layer today.

So the problem here isn't that folks want contradictory access levels (e.g. Admins can kick people but can't set topic, but Mods can kick people but can't set topic) but the ability to set them via group?

the discord style permissions are simply easier to understand. it's classic role based. you define the roles, and assign the roles to users. matrix permissions forces a hierarchy that is awkward and more difficult to apply because i have to force permissions into a hierarchy. on discord i don't have to think about the hierarchy.

this comment was proofread by the department of redundancy department.

Real life usage is messy.

Idc about permissions, but the usability difference is astronomical.

Reply on news.ycombinator.com