XMPP Council - 2026-05-06

MattJ: I understand that there are interesting breaking changes to explore. I'm not even sure I agree with changing the addressing or specifically that it's worth the effort and that we couldn't achieve the goals behind without doing so. As an example Jitsi Meet "changed the addressing" in a way that's not breaking (clients choose a random id as "nickname" and then use the 0172 element to actually specify the nickname, that way they can change the nickname within a session without that affecting their occupant jid)

The question to me is: why should we make other improvements depend on changing the addressing? What issues are we actually solving with that? which issues are not solved with that? what downsides does it have?

I already had the example of allowing nick collisions. Changing the addressing would solve it for MUC2, but only if there's no MUC1 compatibility. If we consider MUC1 compatibility mandatary, we have to solve the issue also for MUC1. If we solve the issue for MUC1, maybe the solution for MUC1 also solves some of the issues we tried to fix with changing the addressing in first place (because both are about decoupling the displayed nickname from the resource, they actually are related)

All that said, I'm not against a new c2s protocol syntax for MUC. But I think it would be better if the motivation for that is that the old protocol syntax became ugly because of the features we added to it, not because we add new features to the new protocol syntax. And effectively, switching where in a MUC stanza we have occupant id and nickname is just that: syntax.

Jitsi could make that change because they control the clients. It sounds like they didn't change the addressing as such, it all relies on the client being trusted to do the right thing. Server-side enforcement of stable in-room addresses for each joined bare JID provides much stronger guarantees that clients in an open ecosystem can rely on.

PMs are one thing we need to fix (I want to send a message to this occupant, not whoever currently has this ephemeral nickname)

Well, there's a bunch to consider when sending PM to a MUC participant, the addressing is really not the issue (the same could be done by sending to the room bare jid and have something in the body to instruct the room server to forward)

What I meant with Jitsi is that they solved that, within a session, a nickname change does not result in a new JID and they solved that there can be nickname collisions

I'm going to write a message to the list on PMs etc. I have "ideas" there. Loosely, in '45, an occupant started off as a simple forwarder. Jid sharing has complicated (and in some ways broken) that, and it's poor for privacy as well. I'd like to explore the concept of an occupant jid being a "thick" proxy, so it can respond to PEP, Jingle, etc. I'll expland in an email though.

larma, You certainly can band-aid all sorts onto '45. The problem - and I think this is the angle Kev and MattJ are coming from - is that layers of band-aid add, rather than remove, complexity.

Forward to account or full JID, is the question

dwd: I think the best solution is a protocol to request revealing a bare jid of another participant. If you want privacy, that could be a burner jid

> Forward to account or full JID, is the question It absolutely is the question, and I think a "thicker" proxy would help answer that. ↺

larma, I'm unconvinced that's the optimal approach. It makes things like PEP extremely awkward.

dwd, FWIW the "simple forwarder" hasn't been a thing for a very long time. We already handled vCard and today we handle PEP

and by "handle" I mean simply, "send to bare instead of full"

It's not delightful, and I don't think it's in XEP-0045

MattJ, Yes, absolutely. But I think the general approach is a naive forwarder that switches between one or more full jids and a bare jid.

Also we never really resolved to-full when there are multiple sessions behind one nick

It's extremely hacky and has a number of edge cases where it just breaks

MattJ: you mean you broke privacy of semi-anonymous participants by making their pep nodes available to users not knowing their bare jid?

MattJ, Right, entirely 100% agreed.

larma, yes, I'm aware of your opinions on this aspect :)

I think if you publish a PEP node with the configuration that it can be accessed publicly, it can be accessed publicly

> MattJ: you mean you broke privacy of semi-anonymous participants by making their pep nodes available to users not knowing their bare jid? How many PEP nodes out there the reveal the bare JID of the user? ↺

Cynthia, none that I know of, but OMEMO keys allow for fingerprinting and correlation of users across semi-anon MUCs

However my position on this is that vcards already do this, and the alternative is no OMEMO anyway

*and* it's all controllable by the client

I suspect the argument isn’t whether open pep nodes should be accessible to anyone (clearly they should), but whether they should be able to be used to tie a semi-anonymous room occupant to a bare JID. Although I’m not coming down on either side of that.

But historically we’ve already done this through vcards anyw…what Matthew says.

> However my position on this is that vcards already do this, and the alternative is no OMEMO anyway OMEMO is not useful in semi-anonymous MUCs anyway ↺

Maybe this could be solvable with a new access control model for PEP nodes?

To the user's home server, a MUC is just a regular user. ✏

Cynthia, it's certainly one option. But it's not clear exactly what that access control model would do.

It basically changes the privacy properties of semi-anon MUCs significantly

I mean one that the MUC server follows

Basically "open to everyone, except in semi-anonymous MUCs" ✏

Without a regular use being able to tell before joining the room.

Okay, so you trust the MUC server to implement the access control on your behalf (which is reasonable, it's already trusted not to reveal your JID)

I mean it already has my JID

larma, Unfortunately, it does not change the privacy of semi-anon rooms, which is the problem...

Previously anything that goes to a room occupant jid is forwarded to the participant's full jid. The client thus decides if they want to reply and the client does have the necessary context.

"Previously" was ~2003

larma, That's not been the case for decades.

Yeah, that’s not been true since… as long as I can remember, which is about 2001 :)

vcards have always gone to bare JID, traditionally. That's why adding PEP doesn't change much.

No

I agree with you that this is not ideal, and it should be user-visible

Ejabbed answers vcard requests to the full JID

Certainly when I first implemented XEP-0045 (or rather, worked on an implementation), the vCard thing was very well established.

Zash, didn't they fix that?

Dunno

Zash, Oh, I'd forgotten about that.

I *think* they fixed it some years ago, but not 100% certain, I haven't tested for a long while

MattJ, I think they have; I don't see the vCard requests coming into my client session from ejabberd MUCs now.

Yeah, but really they had two bugs: intercepting vcard requests to the full JID, and their MUC implementation requesting to the full JID

They had to fix the MUC implementation because Prosody didn't intercept, so you would never see Prosody user avatars in MUCs

So I'm 95% sure they fixed that part, I'm less certain about the interception part

larma, I don't generally disagree with you that this situation could be improved. But I disagree that just adding PEP significantly changed much, and we possibly disagree about where the fix should lie. I'm leaning towards giving the client more control over what happens when stuff is sent to their bare JID. That's precisely of the reasons why I'm pushing to move vcards to PEP, so we can remove that loophole which we've had for so long.

(vcard-temp has no access control at all)

A client could handle this today by keeping their nodes in whitelist mode, and optionally (i.e. with user consent when adding a new group to bookmarks) grant the MUC access to specific nodes

MattJ: I would want to just have MEP or whatever you want to call it: store the avatar or whatever the user wants to share in a specific room with that room.

I've never been a big fan of the room becoming a place for storage of external users

I prefer a model where there is a single source of truth for this (the account), and it gets pulled on demand. Instead of having your data spread everywhere (as a user), and having to host arbitrary data from third-party users (as an operator).

MattJ, Which is why I lean toward controlled proxying. But, I can entirely be persuaded, to be clear.

MattJ: the single truth is equivalent to single identity

If you have an identity per room and manage to keep perfect record of everywhere you used that identity, then yeah. Personally I have an identity per account, because it keeps this and everything else cleanly separated.

I can't imagine having to change my avatar in each of the ~100 MUCs I'm in. And if my client supports doing that automatically, I can't imagine wanting several of those MUCs to not update to my new avatar because the MUC server was temporarily unreachable at the time I updated my avatar.

MattJ, I think knowing which MUC I want my avatar to be shown in and configuring the occupant jid accordingly seems fine. Especially if that can (eventually) be a one-off configuration because of bare jid occupancy.

MattJ, Also because things like Jingle don't fit precisely into PEP-shaped holes, so PEP alone won't cover us. I think.

Yes, we already have some per-account stuff on the MUC side (affiliation, nick, etc.), I'm fine with some configuration stuff

I could even stretch to an avatar hash perhaps

MattJ, But I think we agree we don't want data storage? ✏

It seems we agree

If storing an avatar hash is fine, why is storing a link to the avatar file (avatar metadata node) so bad ✏

Link to?

IP loggers?

Especially if you can serve different PEP nodes to different users

dwd: HTTP URLs, what we already do for high res avatars

larma: I'd be fine with storing a reference to the avatar hosted somewhere else

larma, We do?

We do, but it's understandably controversial 🙂

Privacy for HTTP is an adjacent issue that needs solving for all kinds of stuff.

Is there a way to proxy the avatar link?

Not our problem to solve, surely.

Also what XEP is HTTP Avatars?

IIRC it's in the normal avatar XEP? It always mentioned HTTP support but it wasn't really used

https://xmpp.org/extensions/xep-0084.html#table-1

Cynthia: see this thread: https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/thread/W5DAHICDMX5ZCS6R6JRV5QWKHHMV4WIO/#HPGV4T5N6KJAULUL5CWPFPOXHNIG3OGK

> IIRC it's in the normal avatar XEP? It always mentioned HTTP support but it wasn't really used I think the kids describe my current feeling as "the ick". ↺