jdev - 2026-04-16

I made a draft of the hat-based ACL XEP. I'm not at home at the moment so I'll just type what I remember the requirements are: * The server must have a list of available permissions that can be assigned to a hat (queriable using a IQ stanza) * A user must not be allowed (even if they have the permission) to perform an action on a user or any related events (such as moderating messages) if the user in question has a higher hat than their highest-level hat * There MUST be a default hat which is invisible, that contains permissions automatically given to all users ✏

Does this make sense?

Why do we need an invisible hat? Can't they simply have no hat?

Not a hat

It's just in the XEP as a reserved "hat"

It doesn't exist as a hat but is just a container for permissions belonging to everyone

so long as this protocol comes in the form of a "well known" ah hoc command i don't mind it. Though it does seem a bit cart before the horse

(similar to @everyone role)

But I don't see why any such container is needed

How else can I mark the lowest-common denominator permissions?

It's a way to symbolise default permissions, but it outlines the underlying problem that is: hats are not a permissions system. If you want a generic permissions system then define that; if you then want to assign permissions based on hats, you can choose to do that (or not) ✏

> How else can I mark the lowest-common denominator permissions? Same way as we already do now? ↺

Server modules, right

We have a permissions system with roles and affs hats just give us new custom affs for when we need more levels (which I fully agree we sometimes do)

> We have a permissions system with roles and affs hats just give us new custom affs for when we need more levels (which I fully agree we sometimes do) While true, the role/aff system is showing its limitations ↺

It's become a mess of assumptions and opaque permissions

Cynthia: nice work

Nobody actually knows what member SHOULD grant you at this point

Sure the limitation is a hardcoded number of levels. Which is why I was glad when hats came along and let us add new levels

> Nobody actually knows what member SHOULD grant you at this point Nothing SHOULD. This is up to implementation and configuration of course. ↺

If nobody knows what it should, why should we trust roles/affs as they are

As a person who is not a server owner

The permissions of a member are currently encoded in the XEP or in the room configuration

It's plausible that servers may make their own decisions about permissions, at the direction of the server owner, but I think that's rare (usually the server owner wants to delegate that to room owners)

> It's not about server owner it's about room admin. That is why decides what every role and aff and hat means Yes ↺

It's not about server owner it's about room admin. That is who decides what every role and aff and hat means ✏

But there are still limitations

And since the room admin is also the one handing it out it seems appropriate that they get to decide what I'd means

> But there are still limitations Like what? ↺

As an example, at QS, we want to have moderators that can kick/ban/moderate but not be able to deanonymize users

Or people that can have voice but not access our bot meant for members

Sure. You can do that. Might need some code of course but if we write yet another xep we'll need the same code 🙂

That can be solved in other ways than designing a new ACL system from scratch

> That can be solved in other ways than designing a new ACL system from scratch Yes, we had to hack around it with a bot that people allowed to use it can use to kick or ban or moderate people ↺

XEPs don't implement themselves and once you implement it you'll have a much better idea of if a xep is needed and what it needs to say

I'm not going to tell anyone not to work on an ACL system, it is often annoying that XMPP doesn't have more unified access control. I'm not convinced that hats are a solution in this space (but may be integrated with it, perhaps).

The problem is that the bot relies on the member affliation

But access control is such a complex topic, personally I've somewhat avoided it for a long time

Which means moderated rooms are impossible

FWIW, my ACL ‘spec’ has hats as an allowable grouping, but doesn’t require it be hats.

> I'm not going to tell anyone not to work on an ACL system, it is often annoying that XMPP doesn't have more unified access control. I'm not convinced that hats are a solution in this space (but may be integrated with it, perhaps). Yes I wanted to integrate hats into an ACL system ↺

But the bot also could look for a hat etc if member aff is wrong for what it does

https://github.com/swift/protoxeps/blob/master/acl.md for anyone who hasn’t seen it before; maybe I should just finish that off.

Yeah I'd avoid anything that uses a bot unless absolutely necessary ✏

> https://github.com/swift/protoxeps/blob/master/acl.md for anyone who hasn’t seen it before; maybe I should just finish that off. That's similar to what I wrote ↺

Down to the "everyone group"

I wanted to write it as a set of default permissions that all users get

Probably best to see if the implementation actually calls for such a thing first :)

(not as an optional part of the ACL rules, just in case edge cases happen) ✏

> Probably best to see if the implementation actually calls for such a thing first :) I don't think people wanna write or host bots for every single limitation in XMPP they have to hack around ✏ ↺

> Probably best to see if the implementation actually calls for such a thing first :) At least for the way acl.md is written, there has to be a backstop. If that’s what you were replying to.

>> Probably best to see if the implementation actually calls for such a thing first :) > > I don't think people wanna write or host bots for every single limitation in XMPP they have to hack around Indeed. I suggest never using bots ever. This is XMPP not IRC. ↺

This is a bit madness to me, so every chat can have different names for the same permissions

in chat A "God" can kick people, in Chat B only "Superman" can kick people

I want people who don't support reactions to be able to kick users but not grab their JID

lovetox, But think of the over-engineering we can do!

> This is a bit madness to me, so every chat can have different names for the same permissions Of course? No way to even know it they are the same ↺

> in chat A "God" can kick people, in Chat B only "Superman" can kick people I mean the permissions are publicly exposed ↺

In my XEP draft at least, just for the sake of clients

yes but every user has to learn them for every single chat new

> I want people who don't support reactions to be able to kick users but not grab their JID Right. This should be not hard to build ↺

I have been meaning to do some research into Matrix's design, at least asking some people who are familiar with it on a daily basis

User research, you mean?

Yes

me! me! /j

I didn't think we did that.

The problem for me is, we should not bind permissions to free chooseable names

but yeah i use it daily

It seems like a neat design, but I was curious if it had practical limitations/annoyances

Usable protocols. Whatever next.

if you bind permissions to "Power Level" its kind of ok, you can check who has what power level and what they can do

Vegeta, what is his power level?

lovetox, So arbitrary integers good, arbitrary names bad?

> The problem for me is, we should not bind permissions to free chooseable names A bit late for that ↺

It's over 9000!!!!

dwd, I can see arguments for that, yes. It's possible to unambiguously rank users by permission level with integers, but not so with names.

MattJ, And do we need to rank them?

With integers, you can know that someone with a lower level has a subset of permissions. It simplifies both implementation and (in my mind) management.

> The problem for me is, we should not bind permissions to free chooseable names To be quite honest, anyone can do this ↺

Permissions aren't a ranking system though. There's no requirement for a linear progression

if you do it the discord way you can set products of numbers as combinations of permissions

MattJ Bitfield!

Otherwise you can have weird configurations where some people could be assigned nonsensical permissions

so you can criss-cross, rather than make it a hierarchy

> Permissions aren't a ranking system though. There's no requirement for a linear progression Also there could be some joke numbers like level 69, level 420 ↺

singpolyma, they don't have to be a ranking system, but they can be a ranking system. They can be anything the system designer decides.

With no permissions set, just as a joke

>> Permissions aren't a ranking system though. There's no requirement for a linear progression > > Also there could be some joke numbers like level 69, level 420 matrix does use 9001 and 69420 power levels, yes ↺

Clearly in Matrix they are

> singpolyma, they don't have to be a ranking system, but they can be a ranking system. They can be anything the system designer decides. Sure. if one community wants to set them up in an order that's fine ↺

I have seen some extremely over-engineered access control systems

I don't want one of those baked into our protocol if it can be avoided

i don't like matrix's power levels to be very honest. too linear. But I think it fits their platforms

> I don't want one of those baked into our protocol if it can be avoided Its not baked in ↺

It supplements the protocol

Simplification requires adding constraints, and the integer power levels is one possible constraint that is already deployed in a similar system

Like what if I just want to add or remove a single permission from some people unrelated to all other permissions? Today I can do this with hats.

If you can today with hats (when no such protocol is defined for it) then I don't see why you can't tomorrow with hats

Also there are possibilities for arbitrary permissions other than what's listed in the XEP

I agree. Unless we decide on some xep that says "don't" but of course I could probably ignore it ✏

Like a Prosody module can modify the list of available permissions and add its own

So its not just the basic set

Yes the list of possible permissions will of course be different on every implementation and community

and change very frequently

I probably write a new one myself every couple of months and that's just me

hm my thought is a powerlevel i can display beside a hat, it gives an impression of how much access this user has

also, cant names be a secondary key for hats? make the primary key a uuid4 or something

> Simplification requires adding constraints, and the integer power levels is one possible constraint that is already deployed in a similar system What if a user wants to know what does a power level mean ↺

why would I care how much "access" a user has or know what that even means?

if i join a chat and there are 20 hats defined, im not going into deep study which hat is the boss

Like people know what a hat "Super Admin" grants its users

> also, cant names be a secondary key for hats? make the primary key a uuid4 or something That is already the case ↺

What does power level 9001 give its users?

Or power level 2310

> why would I care how much "access" a user has or know what that even means? because i want to know which user is a moderator and which user is the room owner ↺

pretty basic stuff that we have righ tnow

> What does power level 9001 give its users? on matrix? basically just everything ↺

And how do I know that's the case

usually it's the default level of the room owner

i would not make the integers freely chooseable

i would say there is 1-10

>> why would I care how much "access" a user has or know what that even means? > because i want to know which user is a moderator and which user is the room owner We already have this. Hats are for extra things we don't have ↺

that should be enough

> i would not make the integers freely chooseable It'll be freely choosable in other clients ↺

> And how do I know that's the case well, compare it against the room acl. usually most room acls are for people below 100 but there are exceptions ↺

lovetox, the main problem I see in practice is that clients need to know what their own permissions are. I don't think they really need to know the permissions of others.

Or people will modify their clients to do so

And this is a problem we already have today, for example clients don't know if they are allowed to send PMs

or even speak, without trying

i don't mind if an admin refer to themself as Superman. Discord already normalized different names for roles tbh ✏

> i don't mind if an admin refer to themself as Superman. Discord already normalized different names for roles tbh Exactly, or has a stylized owner hat ↺

New xep: disco#permissions jk

Also in my XEP, hats have to be ordered in a way anyway

i mean really it's disco#items node=permissions probably

So that might be a good place to start, to be honest

So you get linear ordering + name

linear ordering seems like a step backwards

Pretty much any access control system is going to need to name the permissions, and we don't currently have that

The user can choose the order of hats (in the ACL config)

> Also in my XEP, hats have to be ordered in a way anyway like a .... power level? ↺

>> Also in my XEP, hats have to be ordered in a way anyway > like a .... power level? Like how Discord does it, user with lower hats can't affect higher hats ↺

So kinda?

Maybe?

and how do you decide if something is "lower" usually by an integer

MattJ: the problem is that permissions proliferate. Sometimes you'll still just need to try. Like "can have others see my status text" is one we have today. We can name it I guess but I'm sure I'll have 4 more this year at least

> and how do you decide if something is "lower" usually by an integer Order of the elements ✏ ↺

Instead of a number

and order can be expressed by an integer

Does your XML serializer preserve the order of elements?

if i display in the gui your hat is number 10 in the list

so you have level 10

This is all hypothetical until someone writes modules and uses them in their community for awhile :)

> and order can be expressed by an integer You can completely ignore the hat and express the order of the element as a integer I guess ↺

I'm not forcing you to do otherwise

Hopefully clients wouldn't need any special support anyway.

it's a server side permission

I was thinking users could be ordered by how high their hats are in the participant list

But not show the order itself as a number

Similar to how role/aff is ordered

i don't care about orders protocol-wise, theyre client issues

> i don't care about orders protocol-wise, theyre client issues And server issues ↺

> As an example, at QS, we want to have moderators that can kick/ban/moderate but not be able to deanonymize users but how are you gonna have hat A cant demote hat B if the permissions are criss-cross this way ↺

>> i don't care about orders protocol-wise, theyre client issues > > And server issues servers could just send them in the wrong order anyways ↺

I think even talking about a demoting b is getting quite ahead of ourselves

>> As an example, at QS, we want to have moderators that can kick/ban/moderate but not be able to deanonymize users > > but how are you gonna have hat A cant demote hat B if the permissions are criss-cross this way If hat A is higher than hat B and hat A has the ability to change the hats of users ↺

how is that NOT power levels?

for now what is desired primarily is a server module to allow people with a give hat to kick/ban/mod but not see jids

Then hat A is able to change the hats of hat B (if users of hat B don't have a higher hat than hat A)

> how is that NOT power levels? ^ ↺

If someone assigns the "highest" hat to someone, and configures that hat without permission to demote people, that person can never be demoted ever?

As I mentioned, access control is "fun" :)

> If someone assigns the "highest" hat to someone, and configures that hat without permission to demote people, that person can never be demoted ever? With or without, they cannot be demoted ↺

By some low-hatter

Yes, it's possible to get into states that can't be recovered from

> Yes, it's possible to get into states that can't be recovered from That's why the owner aff is a fallback ↺

This would be similar to MUC requiring that there is at least 1 owner

Owner would always be able to fix at least

Owner aff can modify any ACL config or hats

well fair enough, similar to rooms in matrix requiring an owner

and we're back to the old hierarchy i guess

So hats aren't a permissions system (but you could assign permissions based on hats)

> So hats aren't a permissions system (but you could assign permissions based on hats) Right ↺

> So hats aren't a permissions system (but you could assign permissions based on hats) Yes ↺

It's just a way to have a few new affs if needed

Why not just assign permissions directly?

> Why not just assign permissions directly? Because that would get tedious ↺

> Why not just assign permissions directly? You mean to users one at a time? ↺

yeah basically because that. It's useful to bundled them

The same way you assign hats to users one at a time

It is useful to have a convenient label for a set of permissions, so they can be assigned, rather than having to specify each individual permission for each individual user

also permissions don't have names but I understand you want that changed heh

Yes, I agree that bundles of permissions are useful. Just not sure why they have to be hats.

They don’t, I think. At least in acl.md you can assign to hats, but don’t have to.

They don't have to be. But why would we make yes another identical system to hats for this?

So if you want to assign to individual users instead of hats, you could.

It doesn't; as I said, develop a generic permission system first, and then assign those with hats (or anything else if you prefer)

I guess if you wanted to assign permissions without a label then that's an argument for how it is different. We don't have this kind of invisible thing commonly now but maybe

> It doesn't; as I said, develop a generic permission system first, and then assign those with hats (or anything else if you prefer) Better yet. Don't design a permissions system at all and let implementations just do it ↺

Having a standard way to do things is more useful than everyone inventing their own sub-standard ad hoc version ✏

> we don't have this kind of invisible thing commonly now Actually I see it everywhere, all the time, every day :)

A significant amount of access control in XMPP is invisible. I gave cases where it's invisible to MUC clients, that are particularly problematic.

> Having a standard way to do things is more useful than everyone inventing their own sub-standard ad hoc version Disagree. But in this case we don't have any versions yet at all. So there's not even an example to standardize on yet ↺

> A significant amount of access control in XMPP is invisible. I gave cases where it's invisible to MUC clients, that are particularly problematic. That's a bit different. Those are generally visible to anyone in the room who knows the room policies. But the client wants machine readable to disable UI etc ↺

> Why not just assign permissions directly? Also I didn't mention this, there is no hierarchy to this ↺

So in addition to granting permissions, you also have to write who that permission can't be applied to

Very carefully or they might just take over your entire room

> So if you want to assign to individual users instead of hats, you could. It would be cool if we had space-wide hats ↺

We used to

Like we have in the XSF space ;)

Indeed

Then we could have space-wide ACL

And who knows, the permission to join a specific room

> A significant amount of access control in XMPP is invisible. I gave cases where it's invisible to MUC clients, that are particularly problematic. Most of it are invisible, and getting worse ↺

This is what I mean by the opacity of things

Kev: You think I could take notes from your draft?

Yes. Or send me your draft and I’ll work it into mine, either way.

Kev: I have a question about it

read chat and i have some thoughts: * i agree with the idea that a permission system shouldn't inherently rely on hats, but i do think hats are the obvious default choice for a flexible system like this. it might be helpful to assign permissions to a role/affiliation directly, or specify a unique permission set for an individual user without making a whole new hat * matrix power levels are the worst possible way to do linear ordering. you essentially have to know beforehand how many possible roles you'll ever need, and you're just screwed if you ever need more than that. not to mention inserting a new role between two others requires adjusting the number of all other roles. an ordered list of elements would let you rearrange, insert, and delete easily with no problems * i'm not sure i agree with the idea that a user with a lower hat can't ever affect someone with a higher hat. obviously they shouldn't be able to change the higher hat's permissions, or like be able to add/remove that hat or ban users with it, but i'm sure other permissions will absolutely want or need to just work on anyone. not sure though * there's no need to guess who the boss is here if the client just shows you the ordering. discord, for example, will always put admins at the top

The everyone group is treated separately from other groups, what if there are no groups?

> Kev: You think I could take notes from your draft? i think you might've already since i'm pretty sure you got the concept from me showing you his draft 🧌 ↺

What permissions do you give the users?

>> Kev: You think I could take notes from your draft? > i think you might've already since i'm pretty sure you got the concept from me showing you his draft 🧌 Yes, shush ↺

> read chat and i have some thoughts: > * i agree with the idea that a permission system shouldn't inherently rely on hats, but i do think hats are the obvious default choice for a flexible system like this. it might be helpful to assign permissions to a role/affiliation directly, or specify a unique permission set for an individual user without making a whole new hat > * matrix power levels are the worst possible way to do linear ordering. you essentially have to know beforehand how many possible roles you'll ever need, and you're just screwed if you ever need more than that. not to mention inserting a new role between two others requires adjusting the number of all other roles. an ordered list of elements would let you rearrange, insert, and delete easily with no problems > * i'm not sure i agree with the idea that a user with a lower hat can't ever affect someone with a higher hat. obviously they shouldn't be able to change the higher hat's permissions, or like be able to add/remove that hat or ban users with it, but i'm sure other permissions will absolutely want or need to just work on anyone. not sure though > * there's no need to guess who the boss is here if the client just shows you the ordering. discord, for example, will always put admins at the top Anything that affects the state (not supplement) of another user or what they posted should require the lower vs higher check ↺

So things like moderating messages, kicking, banning should require lower vs higher checks. But adding reactions or replying shouldn't (obviously)

Reactions and replies do not affect the state of a message, it simply adds onto it

If you get what I mean ✏

i think there's an argument for allowing a lower-level hat to moderate messages from a higher-level user. i guess which permissions fall into which group would depend on the implementation? in that case it seems weird to specify anything in this regard in the document, unless its somehow encoded at the protocol-level as well (i.e. by being displayed when a user queries for permissions, so they know which ones they can apply to users higher than them, maybe?)

> read chat and i have some thoughts: > * i agree with the idea that a permission system shouldn't inherently rely on hats, but i do think hats are the obvious default choice for a flexible system like this. it might be helpful to assign permissions to a role/affiliation directly, or specify a unique permission set for an individual user without making a whole new hat > * matrix power levels are the worst possible way to do linear ordering. you essentially have to know beforehand how many possible roles you'll ever need, and you're just screwed if you ever need more than that. not to mention inserting a new role between two others requires adjusting the number of all other roles. an ordered list of elements would let you rearrange, insert, and delete easily with no problems > * i'm not sure i agree with the idea that a user with a lower hat can't ever affect someone with a higher hat. obviously they shouldn't be able to change the higher hat's permissions, or like be able to add/remove that hat or ban users with it, but i'm sure other permissions will absolutely want or need to just work on anyone. not sure though > * there's no need to guess who the boss is here if the client just shows you the ordering. discord, for example, will always put admins at the top oh also forgot to mention i do agree with the idea that this should get a real server implementation before being submitted, since this feels something where it'll be impossible to know what we need from just theorising a lot ↺

sounds way to complicated for me, you should leave permissions that are granted by the MUC spec alone

you dont want to create two competing permission schemes

so kick/ban/voice/add members/change config, should be all out of scope, such basic permissions should always be in a MUC spec in my opinion

sure, i think everyone agrees there shouldn't be two competing ways to do the same thing. in the beginning, at least, i'd assume ACLs would be used purely as an extension where roles/affiliation permissions aren't specified

> i think there's an argument for allowing a lower-level hat to moderate messages from a higher-level user. i guess which permissions fall into which group would depend on the implementation? in that case it seems weird to specify anything in this regard in the document, unless its somehow encoded at the protocol-level as well (i.e. by being displayed when a user queries for permissions, so they know which ones they can apply to users higher than them, maybe?) I mean it helps with separation of power ↺

Imagine if a low-level user was able to moderate whatever message they wanted

(though in my ideal world the use of roles/affiliation permissions would be phased out wherever possible in favour of hats, leaving them only for whatever ACL physically couldn't handle, like maybe the public vs private room distinction(?))

Or do the same with kicking or banning

>> read chat and i have some thoughts: >> * i agree with the idea that a permission system shouldn't inherently rely on hats, but i do think hats are the obvious default choice for a flexible system like this. it might be helpful to assign permissions to a role/affiliation directly, or specify a unique permission set for an individual user without making a whole new hat >> * matrix power levels are the worst possible way to do linear ordering. you essentially have to know beforehand how many possible roles you'll ever need, and you're just screwed if you ever need more than that. not to mention inserting a new role between two others requires adjusting the number of all other roles. an ordered list of elements would let you rearrange, insert, and delete easily with no problems >> * i'm not sure i agree with the idea that a user with a lower hat can't ever affect someone with a higher hat. obviously they shouldn't be able to change the higher hat's permissions, or like be able to add/remove that hat or ban users with it, but i'm sure other permissions will absolutely want or need to just work on anyone. not sure though >> * there's no need to guess who the boss is here if the client just shows you the ordering. discord, for example, will always put admins at the top > oh also forgot to mention i do agree with the idea that this should get a real server implementation before being submitted, since this feels something where it'll be impossible to know what we need from just theorising a lot I think this would be way too hard to use with just data forms ↺

I was thinking of a list with elements that the user can drag around and such to rearrange the hierarchical order

That isn't in Data Form as of right now, so the closest is a tedious text (number) field per element that specifies the order

And errors if there's more than one of the same order number

> Imagine if a low-level user was able to moderate whatever message they wanted well the argument i have here is that things like kicks, bans, configuring hats, and modifying a user's hats are all things that can change the effected user's permissions, whereas moderating a message generally won't. in that sense, i'd assume if you trust someone to moderate any messages, you'd trust them enough to moderate all of them, whereas anything that changes permissions is a _much_ bigger risk that you absolutely would want to be more restricted ↺

Which is sad because I wanted this to be an adhoc

> That isn't in Data Form as of right now, so the closest is a tedious text (number) field per element that specifies the order yeah this is what i was thinking as well, but i think its best to try and see what works best using existing stuff first, and only invent something new if we absolutely have to ↺

Yes I would want it to only be a beta thing

although i think a generic ordered list extension to data forms wouldn't be the worst thing to have :)

Or pre-release

Not something that people would actually use in production

(because of the bad UI)

well yeah considering it'd be a community module for a specification that isn't even experimental, i think people would be well aware of that much

Cynthia: I've been baking your use case in my herd for a bit and I'm wondering if an option to restrict who can see real jid to owner (or owner/admin) would be sufficient? Then role moderator matches the desired situation

> Cynthia: I've been baking your use case in my herd for a bit and I'm wondering if an option to restrict who can see real jid to owner (or owner/admin) would be sufficient? Then role moderator matches the desired situation That would be cool ↺

But the ACL is a separate thing

You can't really make a feature for every specific usecase ✏

That's why we keep things generic, so you can write a module for every case instead of being stuck with a limited list 🙂

Enable this checkbox for something Cynthia told me to implement on a Thursday

Exactly

>> Imagine if a low-level user was able to moderate whatever message they wanted > well the argument i have here is that things like kicks, bans, configuring hats, and modifying a user's hats are all things that can change the effected user's permissions, whereas moderating a message generally won't. in that sense, i'd assume if you trust someone to moderate any messages, you'd trust them enough to moderate all of them, whereas anything that changes permissions is a _much_ bigger risk that you absolutely would want to be more restricted I think that would be up to the moderation implementation ↺

I would definitely add convenience functions in Prosody like `has_permission` and `levels_compare` for other modules to use ✏

If moderations were easily auditable, I think I'd be up to it

> i think there's an argument for allowing a lower-level hat to moderate messages from a higher-level user. i guess which permissions fall into which group would depend on the implementation? in that case it seems weird to specify anything in this regard in the document, unless its somehow encoded at the protocol-level as well (i.e. by being displayed when a user queries for permissions, so they know which ones they can apply to users higher than them, maybe?) ^ i already said it'd be up to the implementation smh ↺

also send the doc when you can so i know properly what i'm actually yapping about

Alright