Groupchat 3.0 development - 2026-03-05

Hi everyone! Is there some kind of draft specification for GC3, besides presentation from the XMPP summit?

Not yet

There are some things written, but it's spread out and incomplete

GC3 is mostly at the idea/prototype stage at the moment, a specification will come

Oki thank you

Do you have a rough idea how much time will take for that to happen? Just curious.

Depends on many things. Is there a reason you're interested?

Nothing important. I recently started getting into XMPP and reading the specs. I find the whole idea quite interesting, however comming from Discord, I am intrested to see if it will be possible to implement someting like Discord's role permission system with XMPP. ✏

Nothing important. I recently started getting into XMPP and reading the specs. I find the whole idea quite interesting, however coming from Discord, I am interested to see if it will be possible to implement something like Discord's role permission system with XMPP. ✏

XMPP probably already has what you are after but if not yes it's possible to add

Was it here I shared my protoprotoXEP for Discord-style hats-based ACLs the other day?

Don't know about before, but you sent it to XSF Discussion this Tuesday when I asked a few questions there. ✏

You’ve seen it, at least, then :)

Yep, I read it, I'm looking forward to see it complete :)

don't wait, implement it

The spec isn’t complete yet :)

Although I think completing it is probably mechanical at this point.

no spec is ever complete without an implementation

There are degrees of incompleteness :)

Do you think it would be possible to make it compatible with current MUC specification?

Yes

I think it would be possible to use it in an implementation that also does MUC. MUC has its own (simple) ACL system, so it depends exactly what you mean.

MUC already has roles and hats

The aim was for it to be a clean migration from MUC ACLs to this system.

If I understood correctly, current MUC ties permissions to it's own roles and affiliations. So, to connect it with this new permissions system, I guess you could map MUC affiliations to required hats. This way normal operations with affiliations would work. But what would you do about roles?

Roles are basically particular permissions a participant has at the moment. So a hat could confer a role or not but this is up to implementation

So, would it be a problem if implementation ignored roles and assigned for example participant to everyone?

The MUC you mean? No that's definitely allowed

In that case, could implementation also ignore requests to change role of a user? So that all users always have a role of participant?

yep

Great, just one more thing. Since implementation is free to grant any privilege set to each role, how current client implementations know if the client is allowed to, for example, send messages?

Btw, if I'm bothering you or diverging from the room topic too much, just say, I'll stop :)

Generally privileges are bundled with a role, as specified in the xep. I would guess current open clients would think they have these privileges and will get an error from the muc if they try something they can't do

A role is not the same as an affiliation

for example "visitor" role means "can read but can't send" it's maybe best to not think of it as a role but just as "how the server tells you if u can write"

Well, in that case I guess that, in the context of these hat based permissions, it would be the best to map user's role to the first role that covers all of user's permissions (granted by hats).

Anyway, thanks for all the answers!