jdev - 2026-03-21

Is the order of hats (when created or updated with the ad-hoc form) explicitly preserved? ✏

The XEP doesn't mention anything about the order

So I think an implementation that scrambles the order is still compliant

that's what i would've assumed anyways

Assumption does not mean it's what happens in implementation :P ✏

Some server could just store hats in an unordered map for performance reasons

yeah i mean i don't recall seeing anything about order mattering last i read it, nor do i really see a reason why it would

I wanna replicate a hat hierarchy for a permission model

i wonder what the default assumption is meant to be in cases it isn't specified. i guess to be safe you would preserve the order yourself, but also assume others won't 🤔

If a implementation that does not preserve the order of the hats is still compliant, it would really ruin my plans

> I wanna replicate a hat hierarchy for a permission model thats a cool idea

> I wanna replicate a hat hierarchy for a permission model someone here or in xsf sent a draft protoxep about this; it opts to store the hierarchy in the permissions configuration itself, rather than being inherent to hats ↺

here we go: https://github.com/swift/protoxeps/blob/master/acl.md

does it have any implementations? are you even legally allowed to use it?

> someone here or in xsf sent a draft protoxep about this; it opts to store the hierarchy in the permissions configuration itself, rather than being inherent to hats Why store the order of the hats within another list ↺

accepted XEPs have IPR turned over to XSF so that you know the answer is yes

> does it have any implementations? are you even legally allowed to use it? no the very first paragraph says this is meant more in the context of GC3 and its a rough draft so i don't imagine you _should_ use it. i mainly sent it as an example that hats being unordered doesn't prevent the concept ↺

> Why store the order of the hats within another list well you have to define the groups and their relationship somehow, especially since this document expects that hats aren't necessarily the only way to identify groups ↺

Maybe if Hats was slightly tweaked to enforce order, we wouldn't need that ✏

i really don't think hats should be ordered by default. they're meant to be a baseline to build upon; extensions can always add their own ordering if they need, but removing the ordering if needed seems much harder

Wouldn't that just result in the order of the hats being fragmented across many extensions

> here we go: https://github.com/swift/protoxeps/blob/master/acl.md Also this ProtoXEP doesn't answer what kinds of powers what someone at the middle or near the bottom of the hierarchy has on the members below them ✏ ↺

Like say, if I give someone at the middle the ability to kick members, are they able to kick members above them or only below them ✏

normal acl rules would say only below but of course you can do whatever you like I suppose

thought about this more while i was out for a bit. if the base hats xep enforces an ordering, what happens if a possible extension needs different rules for ordering than is required, such as if it needs to be able to say two hats exist on the same level, but the base xep said no two hats can be equal? or if you want to exclude some hats from being ordered entirely (decorative hats shouldn't need to be shoved into a permissions hierarchy), but the base xep forces all hats to be included? what happens if two or more extensions need completely independent hat orders, such as an order for room configuration and an order for display priority (i.e. the highest-priority hat might get shown next to a user's name in messages, and a muc for a game wants to display player rank hats which exist independently of room permissions)? which extension gets to use the built-in hat ordering, and which one is forced to define their own? it seems wrong for a specification which is designed to group users into generic categories to force any kind of relationship semantics thereof, or dictate what those relationships apply to

i'd be fine if hats were specifically designed to replicate discord roles (discord roles have all of the shortcomings i mentioned), but they're meant to be a generic way to group people, and explicitly expect the semantics for what those groups mean to be defined in the xep that'd actually be using those semantics