Groupchat 3.0 development - 2025-07-30

> Or service-wide things, applied to a specific jid A server or component wide affiliation list would be really nice ↺

that would also move us closer to spaces = servers i think

because you can add moderators space/server wide

Yeah. That something I've wanted to implement for awhile. The code should not be hard I just haven't gotten to it

Except when we had that feature in Prosody, everyone hated it :)

Well. I didn't. But also this is slightly different I think

I think there are two distinct types of MUC service - one service == one community, and then there are "public" services

There's a difference between MUC service wide mod and server admin

Oh yeah the "public" services are terrible. I think we only have them because servers have mad adding a new service too complex so far

I don't disagree, but I don't know that every public server admin wants random strangers to be able to create subdomains on their server

But in such a case I would probably restrict to private groups if I were a public server admin

locking an affiliation list to a subdomain could also work fwiw

instead of the whole muc service

Honestly if I'm letting randos make channels why not let them make subdomains. But yeah it's probably not something most hosts want to allow in general due to moderation concerns

MSavoritias (fae, ve), not sure what you mean by that (a MUC service is typically on a subdomain)

> instead of the whole muc service A muc service is just one subdomain or domain yes ↺

> MSavoritias (fae, ve), not sure what you mean by that (a MUC service is typically on a subdomain) i was thinking of each subdomain being one "space" so that if the affiliation list wasn't server wide but subdomain wide 🤔 probably i misunderstood how xmpp works tho so never mind ↺

That's kind of how it is, but people tend to use one subdomain for more than one community today

But services like xmpp.org, joinjabber.org, etc. are community MUC services where affiliations should likely be shared

chat.yax.im is not such a service

Yeah exactly. When we say service or server we mean one domain usually. Even if there is one prosody instance behind multiple domaies

Yeah domain (or subdomain) == service, it doesn't make any difference if they are in the same Prosody or different, as far as Prosody is concerned every domain is self-contained

I think separating technical admin from owner/mod in prosody was good. Now I just need an ad hoc commands to add service wide mod

Ad-hoc? or just normal affiliation stanzas to the domain?

XEP-0045 leans towards the latter

Actually it links to https://xmpp.org/extensions/xep-0133.html#edit-admin it seems

Ad hoc would work today and be easier for users and admins imo. But other options are possible

"Why not both?"

Yes. That is my favourite

Ad hoc and then a xep for it if people want

As per that one you just linked

Makes it nice for prototype and also can add optional fields relevant to local implementation without a xep debate

I think it just gets messy when you have a global affiliation, and then change the affiliation in a room

Which one applies?

If they're service level mod then de mod in a room is probably an error

OTOH adding mod to just one room is fine

> A server or component wide affiliation list would be really nice Personally I wasn't saying this because spaces. Just that it's the same operator and it's the same policies so I wouldn't find it weird to apply service-wide moderation for this reason. ↺

> chat.yax.im is not such a service chat.yax.im probably also has such a policy and could apply service-wide restrictions

MattJ, re affiliations I'd say if there's an affiliation in a room then apply it otherwise apply service-wide?

An exception I was just thinking about is perhaps outcast. I think in a community you would want all bans to apply service-wide, right?

That may be contested. I guess all variants could work anyway, for different use-cases

I can't think of a reason you would want anything else

Even "not" as a community

But yes especially as a community

Nah, I think services like conference.jabber.org and chat.yax.im are very different

Any random person can create a room there and add anyone to the ban list of their MUC

I would expect them not to host problematic content either fwiw. Be they more public than others

You don't want that to affect all the other MUCs

otherwise it can be done maliciously

What do you mean

If you create a MUC on chat.yax.im and invite a bunch of people, but I don't like one of those people. So I create another MUC on chat.yax.im, and add that person to the ban list. That shouldn't ban them from every channel on yax.im.

But if a ban happens on a community server, it should be treated as a ban from that community (since all the admins are expected to be acting on behalf of the community, not individual MUCs)

Ah no, I expect service-wide affiliations to be handled by people with enough permissions

Right, yes, that's fine

So whether I don't like this person or not, I have been granted this permission by the operator, so I think that's alright

So I guess the propagation depends on the global affiliation of the actor

Is it worth considering having technical different lists of outcasts: one per muc, and one per service? That makes the difference explicit, rather than an implicit "ban in one room may or may not affect other rooms."

I mean I would be trusted by the operator to apply said policy

What if an actor with global permissions wants to apply the ban to only one room, not the entire service?

Guus, "what if" indeed, but as stated earlier, I can't think of a use case for that

Yeah I also don't have any use-case of the top of my head..

I'm mainly concerned that by automatically propagating actions on one room to other rooms of the service, depending on something like an authorization level of the actor, is messy/confusing and unpredictable in practice.

Affiliations in individual rooms should probably be removed when someone is outcast service-wide? If individual rooms' affiliations are prioritized?

> An exception I was just thinking about is perhaps outcast. I think in a community you would want all bans to apply service-wide, right? Not necessarily ↺

> Except when we had that feature in Prosody, everyone hated it :) Wait, is there a module maintained for prosody that adds back in that functionality? ↺

It's a configuration option

oh wow, let me reenable it then :x

It was disabled at your request :D

Which one?

> What if an actor with global permissions wants to apply the ban to only one room, not the entire service? Yes. This is something I have done ↺

I could have sworn I read the documentation about the muc module all the way through

component_admins_as_room_owners

Ah that's not what I expected

I thought we were talking about that global affiliation thing :p

Yes

> component_admins_as_room_owners Oh no, I was looking for being able to manage membership and bans component wide in general ↺

That's what that does

What do you mean

singpolyma, I believe you, and I'll take your word for it. But I'm very curious about the use case

Ah, right, it's mods only not bans as well

> singpolyma, I believe you, and I'll take your word for it. But I'm very curious about the use case For example I have banned a certain person who is annoying from one MUC in my personal community because they were nothing but annoying there. But they still contribute positively in some others so I haven't banned them in all yet ↺

So people being weird, fine :)

Maybe my personal stuff isn't tied together well enough to really be one community so maybe it's a bad example. But I'm mod in them all

Yeah that's something I'm not doing personally. If a person is annoying enough to be banned somewhere (generally going against CoC), they're probably making other people uncomfortable in other places

> Oh no, I was looking for being able to manage membership and bans component wide in general It's still a nice feature to have component wide admins, but it's a bit more limited than what I was posting about. I would also want it to dynamically update from the list instead of just when prosody is starting ↺

Well this wasn't a CoC violation per se. They weren't being abusive. Just not being constructive

Which is also why I will ban preemptively

Masked Witch, you only have to edit the config file and reload Prosody

singpolyma, well that can go against the CoC too

> Masked Witch, you only have to edit the config file and reload Prosody I've reloaded. I've even reloaded the components. It doesn't seem to update affiliation without restart. Maybe the user needs to reconnect? ✏ ↺

Or /cycle

I don't think we should have two distinct lists of affiliations (one per service, and one per room) because maintaining and applying two sets gets messy, fast. I do believe that the act of change affiliation of user X on service should be a distinct act to applying that change on a per-room basis. That should not depend on authorization only.

Yes that's also a good option. Just mass actions at service level but no storage there

If you can apply affiliations differently, doesn't that mean there's two lists?

Though then when you make a new room what do

Ah ok

(although if you want to apply a service wide affiliation change to a muc that's created later, you'd still need separate lists... Bah)

Yeah, what about new rooms

I probably would be fine for now just having an additional global banlist. But yeah for a new protocol that doesn't really make sense to pick just this one

I don't think two lists is a big deal. There may be UX considerations but that's someone else's problem (well, my problem again. But not most of you)

It's not that bad to include UX considerations when design protocols :)

> I probably would be fine for now just having an additional global banlist. But yeah for a new protocol that doesn't really make sense to pick just this one My thoughts exactly

That's what we're doing here anyway

when designing*

> It's not that bad to include UX considerations when design protocols :) Can result in over-limited protocols or implementations ↺

I don't know if it just becomes a limitation. "Depends on the use-case". Then if the use-case is not clear or if you allow too much, clients implement what they want from it and they're all different and people complain again :P

And use-cases differ and you need to split the spec anyway because they're not compatible with each other

Well they're supposed to all be different 🙂 otherwise we'd have only one

Are hats being used for extending affiliations or just for fancy labels? :P

I plan to use them for both

https://pad.nixnet.services/#Error-case-Recipient-cannot-receive-direct-messages the last paragraph in there, > If the recipient has no active sessions at all at the present time, Groups MAY reply with a type="wait" <service-unavailable/> error including the <relay-denied/> condition. I don't know if I get why "wait". If the participant doesn't support muc-pm then whether there's an active session or not, a PM gets rejected no? (I'm still reading through, and I wonder if there's an alternative to PMs, but that's a question I'll ask later)

(Ah well it's right below)

(Ah no that's different, it's still the compatiblity profile)