Proposed XMPP Extension: New MUC
The XMPP Extensions Editor has received a proposal for a new XEP. Title: New MUC Abstract: This document specifies an enhanced Multi-User Chat protocol that is broadly backwards compatible with that of XEP-0045, but adds a number of key improvements. URL: https://xmpp.org/extensions/inbox/new-muc.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.
Hi, First, thanks Dave for starting this work. I generally appreciate someone again making an effort to fix issues with MUC. 👏 As I had expressed before, I feel that the things listed in this proposal are somewhat adjacent and combining them in a single proposal will make development in the experimental phase significantly more complicated. This proposal has essentially four parts to it: 1. Join mode where less presences are received 2. Ability to reveal jid in semi-anon rooms and to block join if the room (unexpectedly) is not semi-anon 3. Switch position of nickname from resource in occupant jid to payload xml element and occupant-id from payload xml element to resource in occupant jid 4. Stay joined while offline / MUC-PAM I consider 1 and 2 pretty easy to implement both on servers and clients. Both have a pretty clear motivation and usecase. I am also well aware of immediate interest of 1 in the community. In contrast 3 has all kinds of things to consider, especially on the server side when thinking about compatibility with MUC1. The motivation for this significant change is less obvious ("when the nickname changes so does the JID", why is this bad?) and in practice there likely won't be a lot of user-visible improvements. I agree it would be nice if we had that, but maybe directly going there is the wrong way and likely some experimentation is needed/wanted. Notably, I would want to have nicknames collisions made possible (which is needed for large rooms to become practical), which is explicitly excluded in the current proposal. Regarding 4, there is a bunch of complexity to it, both on clients and servers. And again it's unclear how big the practical improvement is for clients over using MUC-MAM and being temporarily offline. I would therefor opt to split this into independent XEPs (with independent namespaces not affecting each other), so they can be developed and tested independently. Especially because I could imagine for 1 and 2 to reach a reasonable stable state pretty quickly. Having them depend on the more complex stuff being ready means to keep things from improving in practice. Marvin On Fri, 2026-04-24 at 10:26 +0000, Daniel Gultsch wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: New MUC Abstract: This document specifies an enhanced Multi-User Chat protocol that is broadly backwards compatible with that of XEP-0045, but adds a number of key improvements.
URL: https://xmpp.org/extensions/inbox/new-muc.html
The Council will decide in the next two weeks whether to accept this proposal as an official XEP. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
On Tue, 28 Apr 2026 at 16:02, Marvin W. via Standards <standards@xmpp.org> wrote:
As I had expressed before, I feel that the things listed in this proposal are somewhat adjacent and combining them in a single proposal will make development in the experimental phase significantly more complicated.
I think that's a reasonable option. My concern would be that we will (eventually) need a profile to unify them into a "New MUC" baseline.
This proposal has essentially four parts to it: 1. Join mode where less presences are received 2. Ability to reveal jid in semi-anon rooms and to block join if the room (unexpectedly) is not semi-anon 3. Switch position of nickname from resource in occupant jid to payload xml element and occupant-id from payload xml element to resource in occupant jid 4. Stay joined while offline / MUC-PAM
There's another part, which is limitations of '45, and requirements for New MUC. I think these are probably the most important part - if we can collate and agree those, then we can work to solve them.
I consider 1 and 2 pretty easy to implement both on servers and clients. Both have a pretty clear motivation and usecase. I am also well aware of immediate interest of 1 in the community.
Right. 1 is fairly obvious (and exists in several quasi-MUC implementations in some form). 2 is a direct lift from MIX, I think.
In contrast 3 has all kinds of things to consider, especially on the server side when thinking about compatibility with MUC1. The motivation for this significant change is less obvious ("when the nickname changes so does the JID", why is this bad?) and in practice there likely won't be a lot of user-visible improvements. I agree it would be nice if we had that, but maybe directly going there is the wrong way and likely some experimentation is needed/wanted. Notably, I would want to have nicknames collisions made possible (which is needed for large rooms to become practical), which is explicitly excluded in the current proposal.
Right, so you have to have nicknames be unique in a room if you want '45 compatibility. And we absolutely require that, I think, at least in the early phases. The way '45 combines a variable name with an address is problematic, and causes us to do various workarounds in several places. As an example that's recently been raised, we can't block by full jid on our home server because the blockee can simply change their nickname. But also, resource strings are canonicalized and restricted in ways that nicknames are not - and vice-versa. As a less esoteric example, a 'DM' in a MUC from someone who changes their nickname is just annoying to handle cleanly in a client. I think if we were designing MUC from scratch right now, we'd simply use this addressing.
Regarding 4, there is a bunch of complexity to it, both on clients and servers. And again it's unclear how big the practical improvement is for clients over using MUC-MAM and being temporarily offline.
It's intentionally very little, and that might seem weird so let me explain: If we want to include offline presence and similar for bare jid sessions from the outset, then I think we need something here. The included concept is close to the absolute bare minimum I could think of. I came up with something even smaller to begin with, but I felt it was too error prone (it was essentially "server doesn't bounce groupchat and advertises that, and client joins with an iq"). However, once we have this basic construct in place, we can start to build quite a bit more on it, for example, push notifications, better handling of references/mentions/etc, and even the long-forgotten inbox concept, and so on. I think these are really important to get right, and having a framework early on that we can experiment with is useful.
I would therefor opt to split this into independent XEPs (with independent namespaces not affecting each other), so they can be developed and tested independently. Especially because I could imagine for 1 and 2 to reach a reasonable stable state pretty quickly. Having them depend on the more complex stuff being ready means to keep things from improving in practice.
I don't wholly disagree as far as 1+2 are concerned - I think those feel fairly straightforward to pull out ifthat's what Council want. I suspect 3 and 4 more or less have to go together, and probably alongside the requirements part. Dave.
Marvin
On Fri, 2026-04-24 at 10:26 +0000, Daniel Gultsch wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: New MUC Abstract: This document specifies an enhanced Multi-User Chat protocol that is broadly backwards compatible with that of XEP-0045, but adds a number of key improvements.
URL: https://xmpp.org/extensions/inbox/new-muc.html
The Council will decide in the next two weeks whether to accept this proposal as an official XEP. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi, On Tue, 2026-04-28 at 18:38 +0100, Dave Cridland wrote:
There's another part, which is limitations of '45, and requirements for New MUC. I think these are probably the most important part - if we can collate and agree those, then we can work to solve them.
That's a good point, so let me go through them:
2. MUC1 occupant addressing is also the nickname - this is bad, because when the nickname changes so does the JID, and it also restricts the form of nicknames in unexpected ways.
"is bad" as I said is not really a good motivation. I agree that if we were to redo MUC from scratch right now, we likely would use the occupant id in the resource, mostly because it feels the right way to do it. Can you outline that "restricts the form of nicknames in unexpected ways"? Is that referring to clients and servers still relying on resourceprep when the RFC is clear that resource is a PRECIS OpaqueString (which has almost no limitations other than forbidding control characters, which seems sensible for nicknames). Can you outline issues that are caused by nickname changes causing JID changes which are fully resolved by not having that? I think those should be in the requirements (e.g. allow MUC participants to block other participants individually), because there might be other, potentially better ways to fix those issues.
5. Presence-based joining is not (comfortably) compatible with "sparsely online" clients such as mobile; when not online a client is not an occupant - long-term engagement with a chatroom is complicated as a result, so we should fix this.
In my experience, my mobile is actually the least sparsely online client, at least from a MUC perspective. I might be temporarily disconnected due to network unavailable like in tunnels, but that's just for a short time and either TCP is still alive or I can resume the sessions using XEP-0198. But even if those short disconnects would result in being disconnected from the room, I would certainly want to fix this also for when I joined a room ephemerally. In contrast, it's my desktop computer that is typically offline for half of the day, which results in heavy use of MUC-MAM. But at least for me, this seems to be working reasonably well.
9. The same room JID and state should be usable by both MUC1 and MUC2.
Fully agree on state, not so much necessarily on JID. I could perfectly imagine MUC1 and MUC2 to use different JIDs internally, but then discoverability becomes an issue to solve. Given that your current proposal achieves the same room JID by adding restrictions to the users' nicknames, I'm also not sure that this is really necessary. Maybe one might want to rephrase this
10. MUC1 presence is very noisy; MUC2 should provide a way to reduce or elide presence entirely.
Fully agree. Now the remaining points either describe status quo and mention it as explicitly desirable (1, 3, 4, 7) or describe status quo without a clear indication if that's meant to stay this way or changed as part of MUC2 (6, 8).
Right, so you have to have nicknames be unique in a room if you want '45 compatibility. And we absolutely require that, I think, at least in the early phases.
Except if we allow for an additional nickname outside the resource, even for MUC1. I bring this up because if we solve this for MUC1 (e.g. by using something like the XEP-0172 MUC support removed in version 1.1 of that XEP but still used in the wild by some clients, notably Jitsi Meet), that solution almost automatically reduces the importance of the resource in the JID and thus makes a transition to occupant id in resource an easier step. ===
As a less esoteric example, a 'DM' in a MUC from someone who changes their nickname is just annoying to handle cleanly in a client.
That's not the only issue with DM in MUC and we might also want to ask the question (similar to <iq> in MUC) if that's needed or wanted at all, or if rather a protocol to allow an occupant to discover another occupants real bare jid (with their consent) is reasonably suitable for what DM in MUCs could be used. Marvin
Hi,
Is that referring to clients and servers still relying on resourceprep when the RFC is clear that resource is a PRECIS OpaqueString Is that supposed to allow all emojis? If the lib I use says 🎉 is forbidden, is it because it does resourceprep instead of doing PRECIS? 🚓 (which has almost no limitations other than forbidding control characters, which seems sensible for nicknames). I am not saying we should, but FWIW discord and telegram (maybe other networks too) do allow control characters in nicknames. XEP-0172 MUC support removed in version 1.1 of that XEP but still used in the wild by some clients, notably Jitsi Meet)
Some other implementations I know of that use XEP-0172: - Cheogram <https://wiki.soprani.ca/CheogramApp/Nickname> - Slidge (compatible with Cheogram to encode nicknames that are not valid resource parts — at least according to the libs I have used, cf above) - Maybe gajim some day if I ever find the energy to rebase and finish <https://dev.gajim.org/gajim/gajim/-/merge_requests/999> Now, the question that has been burning my lips: is "New MUC" the new codename of "GC3" or are those supposed to be different things? -- nicoco
On Wed, 29 Apr 2026 at 13:04, Nicolas Cedilnik <nicoco@nicoco.fr> wrote:
Hi,
Is that referring to clients and servers still relying on resourceprep when the RFC is clear that resource is a PRECIS OpaqueString Is that supposed to allow all emojis? If the lib I use says 🎉 is forbidden, is it because it does resourceprep instead of doing PRECIS? 🚓
It'll certainly be doing resourceprep.
(which has almost no limitations other than forbidding control characters, which seems sensible for nicknames). I am not saying we should, but FWIW discord and telegram (maybe other networks too) do allow control characters in nicknames.
What sort of control characters?
XEP-0172 MUC support removed in version 1.1 of that XEP but still used in the wild by some clients, notably Jitsi Meet)
Some other implementations I know of that use XEP-0172:
- Cheogram <https://wiki.soprani.ca/CheogramApp/Nickname> - Slidge (compatible with Cheogram to encode nicknames that are not valid resource parts — at least according to the libs I have used, cf above) - Maybe gajim some day if I ever find the energy to rebase and finish <https://dev.gajim.org/gajim/gajim/-/merge_requests/999>
Now, the question that has been burning my lips: is "New MUC" the new codename of "GC3" or are those supposed to be different things?
As far as I know, GC3 has no published specification and is not an XSF activity; I've avoided that name to (hopefully) avoid confusion with it. Dave.
On Wed, 29 Apr 2026 at 14:31, Dave Cridland <dave@cridland.net> wrote:
On Wed, 29 Apr 2026 at 13:04, Nicolas Cedilnik <nicoco@nicoco.fr> wrote:
Hi,
Is that referring to clients and servers still relying on resourceprep when the RFC is clear that resource is a PRECIS OpaqueString Is that supposed to allow all emojis? If the lib I use says 🎉 is forbidden, is it because it does resourceprep instead of doing PRECIS? 🚓
It'll certainly be doing resourceprep.
(which has almost no limitations other than forbidding control characters, which seems sensible for nicknames). I am not saying we should, but FWIW discord and telegram (maybe other networks too) do allow control characters in nicknames.
What sort of control characters?
XEP-0172 MUC support removed in version 1.1 of that XEP but still used in the wild by some clients, notably Jitsi Meet)
Some other implementations I know of that use XEP-0172:
- Cheogram <https://wiki.soprani.ca/CheogramApp/Nickname> - Slidge (compatible with Cheogram to encode nicknames that are not valid resource parts — at least according to the libs I have used, cf above) - Maybe gajim some day if I ever find the energy to rebase and finish <https://dev.gajim.org/gajim/gajim/-/merge_requests/999>
Now, the question that has been burning my lips: is "New MUC" the new codename of "GC3" or are those supposed to be different things?
As far as I know, GC3 has no published specification and is not an XSF activity; I've avoided that name to (hopefully) avoid confusion with it.
Okay, I'll take the bait... :) Apart from being hashed out by multiple XSF members, including at a sprint, and presented and discussed at an XSF summit... But yes, I know you *really* want a XEP even before we figure out what should go in it. Hence you've submitted something that doesn't seem to take into account any of the work we've done so far and doesn't seem implementable (yet). The submission says it is offered "offered as a discussion point", but we already had discussion points you've ignored. I don't currently have the bandwidth for arguing any of these points, which is why I wasn't saying anything about the XEP submission. If you actually have time to dedicate to getting a MUC successor over the finish line, something I want quite badly, then I'm not going to stand in the way! But I think it's silly to start parallel work. We certainly don't need multiple new group chat protocols in our repertoire. So to answer Nicolas's question: they seem, needlessly, to be different things at the moment. Regards, Matthew
On Wed, 29 Apr 2026 at 15:20, Matthew Wild <mwild1@gmail.com> wrote:
On Wed, 29 Apr 2026 at 14:31, Dave Cridland <dave@cridland.net> wrote:
As far as I know, GC3 has no published specification and is not an XSF activity; I've avoided that name to (hopefully) avoid confusion with it.
Okay, I'll take the bait... :)
Apart from being hashed out by multiple XSF members, including at a sprint, and presented and discussed at an XSF summit...
I don't think that's the right definition of an XSF activity, is it? By that set of metrics, other XSF activities include Modern XMPP and the Jabber.org XMPP service. In fact, that even suggests Prosody is an XSF activity, doesn't it? Clearly that cannot be the case. An XSF activity has various factors attached, most notably the Code of Conduct and the IPR Policy - the latter includes copyright assignment as well as change control - and ultimate control by the membership (usually via the Board or Council). The Summits are an XSF Activity, but they often discuss things that are not (this year, the IETF work for example). Meanwhile, our XEPs are often submitted and worked on by people who aren't XSF members, and the code worked on at Sprints is certainly not owned by the XSF. So I think your definition is flawed on every count. This ProtoXEP is offered to the XSF, no strings attached, with copyright assigned to the XSF and change control surrendered as per XEP-0001 upon publication. That's definitely an XSF activity, I think we can agree. And I think we also agree that Modern XMPP, jabber.org, and Prosody are definitely not XSF activities. But I don't follow why GC3 would be an XSF activity for more or less the same reasons. And I do think this is extremely important. A newcomer to the XSF would be entirely unaware of GC3 except in occasional passing references, and would be unable to participate. I'm only aware of it at all because I happened to make the 2025 Summit, and I'm not exactly a newcomer. That's not how an Open Standards organisation should work, surely?
But yes, I know you *really* want a XEP even before we figure out what should go in it. Hence you've submitted something that doesn't seem to take into account any of the work we've done so far and doesn't seem implementable (yet). The submission says it is offered "offered as a discussion point", but we already had discussion points you've ignored.
No, I'm not ignoring anything, I'm simply unaware of them. Please do post them to the list, I'd welcome the discussion. If I don't respond, *then* you can tell me I'm ignoring them. The only thing I remember from the GC3 presentation at the 2025 Summit was the addressing, and I think I captured that. Also, I'm pretty sure the ProtoXEP is implementable, or at least nearly so. It's probably not very good, and almost certainly has some rough edges. It's probably missed some great ideas you, Kev, or whoever else is working on GC3 has had. Experimental XEPs are not officially gated on implementation, or even implementability, but if you'd like an implementation I can probably knock out a PoC relatively quickly - I'll undoubtedly find improvements and perhaps outright errors in thespec by doing so. And make Guus have nightmares by the code quality, of course. And you're right, I would like a XEP, even a rough one, to work on - I think it's useful to focus discussion aside from anything else. I suspect Marvin will end up asking for the XEP to split out various cases, too, so we'll have multiple XEPs - not my choice but it could work. I entirely understand that other people would rather start with the discussion, and again I can live with that - but I do feel very strongly that we are an open standards organisation, and as such that discussion absolutely must occur on our venues (such as this list). This list - or more formally, the Standards SIG - very much is an XSF Activity (if not *the* XSF Activity).
I don't currently have the bandwidth for arguing any of these points, which is why I wasn't saying anything about the XEP submission. If you actually have time to dedicate to getting a MUC successor over the finish line, something I want quite badly, then I'm not going to stand in the way! But I think it's silly to start parallel work. We certainly don't need multiple new group chat protocols in our repertoire.
I have some bandwidth available. If I get busy, there's a large number of very clever people on the mailing list who can take over and probably do a better job then I can - and you're certainly included in that. Honestly, everyone should be hoping I get busy. But if you're saying that I should not have submitted a ProtoXEP because of GC3, or that everyone should ignore this because of GC3, then I must disagree very strongly indeed.
So to answer Nicolas's question: they seem, needlessly, to be different things at the moment.
Please do take the time to explain why, and why your approach is better. Dave.
On Wed, 29 Apr 2026 at 17:48, Dave Cridland <dave@cridland.net> wrote:
On Wed, 29 Apr 2026 at 15:20, Matthew Wild <mwild1@gmail.com> wrote:
On Wed, 29 Apr 2026 at 14:31, Dave Cridland <dave@cridland.net> wrote:
As far as I know, GC3 has no published specification and is not an XSF activity; I've avoided that name to (hopefully) avoid confusion with it.
Okay, I'll take the bait... :)
Apart from being hashed out by multiple XSF members, including at a sprint, and presented and discussed at an XSF summit...
I don't think that's the right definition of an XSF activity, is it?
By that set of metrics, other XSF activities include Modern XMPP and the Jabber.org XMPP service. In fact, that even suggests Prosody is an XSF activity, doesn't it? Clearly that cannot be the case.
I think this is a pointless debate because the line can be drawn wherever someone wants it to be drawn, and you've demonstrated it can be taken to extremes. I would argue that your classification of GC3 as not an XSF activity was taking it to the opposite extreme.
An XSF activity has various factors attached, most notably the Code of Conduct and the IPR Policy - the latter includes copyright assignment as well as change control - and ultimate control by the membership (usually via the Board or Council). The Summits are an XSF Activity, but they often discuss things that are not (this year, the IETF work for example). Meanwhile, our XEPs are often submitted and worked on by people who aren't XSF members, and the code worked on at Sprints is certainly not owned by the XSF. So I think your definition is flawed on every count.
I don't see how the IPR policy is relevant in determining whether something is an XSF activity - it applies to documents entered into the standards process, but I think anyone would reasonably agree the XSF has activities beyond that (including discussion and collaboration on documents prior to their initial submission).
This ProtoXEP is offered to the XSF, no strings attached, with copyright assigned to the XSF and change control surrendered as per XEP-0001 upon publication. That's definitely an XSF activity, I think we can agree.
I don't know... you as an individual just submitted it without (as far as I know) any of the XSF being involved at all.
And I do think this is extremely important. A newcomer to the XSF would be entirely unaware of GC3 except in occasional passing references, and would be unable to participate. I'm only aware of it at all because I happened to make the 2025 Summit, and I'm not exactly a newcomer. That's not how an Open Standards organisation should work, surely?
I agree, it would be hard for a newcomer to discover. But if they are interested in a MUC successor, ideally they would say so and people could help them out. Ideally they wouldn't just invent a group chat protocol and submit it without researching existing efforts or bringing it up at a summit. I get the impression that you think GC3 is some specification that is being withheld from the XSF standards process. The only reason "the GC3 XEP" hasn't been submitted is because it doesn't exist. To make it exist, someone needs to collate the notes from the discussions at the sprint, summit and online and write it up in XEP syntax. There are still some unsolved questions about the approach (but, from a skim, probably fewer than the document you have submitted). Personally I'm not a fan of submitting unimplemented/unimplementable protocols (I've fixed up so many "TODO"-ridden XEPs in recent years), and that's partly why I haven't prioritized this work above getting some basic prototype code to prove it out a bit. But I'm not saying a XEP absolutely cannot come first, just explaining my personal time prioritization. If someone wants to help with the XEP side of things, I'm not going to complain.
No, I'm not ignoring anything, I'm simply unaware of them. Please do post them to the list, I'd welcome the discussion. If I don't respond, *then* you can tell me I'm ignoring them. The only thing I remember from the GC3 presentation at the 2025 Summit was the addressing, and I think I captured that.
I have some bandwidth available. If I get busy, there's a large number of very clever people on the mailing list who can take over and probably do a better job then I can - and you're certainly included in that. Honestly, everyone should be hoping I get busy.
I'd have liked to say the same about the GC3 work, but the clever people are preferring to start their own thing from scratch :)
But if you're saying that I should not have submitted a ProtoXEP because of GC3, or that everyone should ignore this because of GC3, then I must disagree very strongly indeed.
I'm not saying that at all. I don't think any unrealized XEP (such as GC3) should prevent someone from submitting an actual XEP. That would hinder progress and wouldn't be good for anyone. However, progress is also hindered if work is done in the community and then completely ignored.
So to answer Nicolas's question: they seem, needlessly, to be different things at the moment.
Please do take the time to explain why, and why your approach is better.
I don't especially have time right now (I literally have a child pulling my arm as I type this). However I can dig up the relevant links from the summit notes and post a new thread about GC3 shortly (I don't particularly want to hijack this thread, which is probably best reserved for feedback on the submission itself). Regards, Matthew
On Wed, 29 Apr 2026 at 18:28, Matthew Wild <mwild1@gmail.com> wrote:
On Wed, 29 Apr 2026 at 17:48, Dave Cridland <dave@cridland.net> wrote:
On Wed, 29 Apr 2026 at 15:20, Matthew Wild <mwild1@gmail.com> wrote:
On Wed, 29 Apr 2026 at 14:31, Dave Cridland <dave@cridland.net> wrote:
As far as I know, GC3 has no published specification and is not an
XSF activity; I've avoided that name to (hopefully) avoid confusion with it.
Okay, I'll take the bait... :)
Apart from being hashed out by multiple XSF members, including at a sprint, and presented and discussed at an XSF summit...
I don't think that's the right definition of an XSF activity, is it?
By that set of metrics, other XSF activities include Modern XMPP and the Jabber.org XMPP service. In fact, that even suggests Prosody is an XSF activity, doesn't it? Clearly that cannot be the case.
I think this is a pointless debate because the line can be drawn wherever someone wants it to be drawn, and you've demonstrated it can be taken to extremes. I would argue that your classification of GC3 as not an XSF activity was taking it to the opposite extreme.
Not really, I used your definition, which you used to suggest GC3 was an XSF activity. Modern XMPP, jabber.org, and even Prosody are all worked on by XSF members, including at a sprint, and presented and discussed at an XSF summit. My argument was that that your definition was demonstrably incorrect since none of those are XSF activities; I didn't take anything to extremes. I didn't even pose a strawman. I did explain why each of your criteria were flawed both individually and as a whole, though, and since this was your argument for why GC3 is an XSF Activity, I felt that demonstrated that at the very least, if it is an XSF Activity it's not for the reasons you suggested. Anyway, if you still insist it's an XSF activity, it doesn't really change matters.
An XSF activity has various factors attached, most notably the Code of Conduct and the IPR Policy - the latter includes copyright assignment as well as change control - and ultimate control by the membership (usually via the Board or Council). The Summits are an XSF Activity, but they often discuss things that are not (this year, the IETF work for example). Meanwhile, our XEPs are often submitted and worked on by people who aren't XSF members, and the code worked on at Sprints is certainly not owned by the XSF. So I think your definition is flawed on every count.
I don't see how the IPR policy is relevant in determining whether something is an XSF activity - it applies to documents entered into the standards process, but I think anyone would reasonably agree the XSF has activities beyond that (including discussion and collaboration on documents prior to their initial submission).
Sure, I can concede that bit (though I think there's a strong argument to be made that it is a flaw in our IPR policy).
This ProtoXEP is offered to the XSF, no strings attached, with copyright assigned to the XSF and change control surrendered as per XEP-0001 upon publication. That's definitely an XSF activity, I think we can agree.
I don't know... you as an individual just submitted it without (as far as I know) any of the XSF being involved at all.
I'll assume this is just a joke. Unless I've missed my reapplication window somehow.
And I do think this is extremely important. A newcomer to the XSF would be entirely unaware of GC3 except in occasional passing references, and would be unable to participate. I'm only aware of it at all because I happened to make the 2025 Summit, and I'm not exactly a newcomer. That's not how an Open Standards organisation should work, surely?
I agree, it would be hard for a newcomer to discover. But if they are interested in a MUC successor, ideally they would say so and people could help them out.
People have asked about GC3 both in the chatrooms and on this list and received no response. On this mailing list, Nicolas, Singpolyma and Goffi have been the only ones mentioning it, and only since September. Goffi explicitly asked you for an update, and there was no response. I have to say evidence is against your assertion there. In addition, other people have more generally mentioned new MUC features (including whole threads), and GC3 hasn't been explained in any of them. To be absolutely clear, I'm not suggesting you're doing anything wrong here. People get busy, life gets in the way, and this is all a volunteer thing. I have certainly dropped out for months at a time and been unresponsive. But having documents (if they exist) published, and discussions in the open, means that other people can (and have, thanks!) picked up work in my absence, and newcomers have joined, seen older dormant work, and raIsed it again. In other words, our way of working is resilient in the face of people getting busy, and that's an excellent reason to stick with it. Even when people pick up my dropped ball and throw it in a different direction to the one I expected.
Ideally they wouldn't just invent a group chat protocol and submit it without researching existing efforts or bringing it up at a summit.
I didn't want to wait another 10 months, and also I didn't write the XEP without reviewing existing MUC options. In particular, I've spent roughly the past 3 years working with ejabberd's muc-sub, and MongooseIM's muclight, and I think I've a reasonable grasp of the benefits (and shortfalls) of both. I've also written a client, from scratch, partly in order to understand what the best practice was for MUC, and better understand its limitations with mobile. I have done my homework, though of course you may disagree with the result. Again, I have no visibility on GC3, and didn't actually think it was actively being worked on; there have been no status updates in well over a year, and there's no other suggestion of ongoing activity.
I get the impression that you think GC3 is some specification that is being withheld from the XSF standards process. The only reason "the GC3 XEP" hasn't been submitted is because it doesn't exist. To make it exist, someone needs to collate the notes from the discussions at the sprint, summit and online and write it up in XEP syntax. There are still some unsolved questions about the approach (but, from a skim, probably fewer than the document you have submitted).
You have the wrong impression. Certainly I think GC3 is outside of the standards process we have in the XSF, and outside of its venues for discussion, and I think that's a shame. I didn't think any specification existed, in fact I didn't think any work had been done for over a year. I assumed that if it were in good enough shape for a specification, one would have been written and submitted. I did ask you and Kev, back at the Summit in 2025, to publish a XEP of some form, and I think I asked you to raise it on the mailing list. The XEP I was told couldn't be written because there were too many disagreements about what it would contain. I have a vague recollection that it couldn't be discussed on the list for fear of overwhelming the list? In any case, I took this to mean it was to be done outside of the XSF for the time being. That's allowed, of course. Lots of things happen outside of the XSF. I do wish that some of them (including GC3, but also other things) were done within the XSF, but I lost those arguments years ago. But it does make it awkward to run things outside the XSF then argue that I shouldn't do something within the XSF as a result. Besides, standards work on XMPP outside of the XSF or IETF feels wrong to me - if it were anyone else, I'd find it outright suspect. I don't know where GC3 is being discussed (if it still is). There was a chatroom address on your presentation back in the Summit in 2025, but I definitely cannot recall what that was, I don't know where to find it now, and it has never been posted to this mailing list as far as I can find. As for the protoXEP, if you think it's missed things - and I'd readily agree - then pick out those specifics to the list. I appreciate this margin is too small to contain GC3, but if GC3 has something to offer at this point it'd be great to understand what.
Personally I'm not a fan of submitting unimplemented/unimplementable protocols (I've fixed up so many "TODO"-ridden XEPs in recent years), and that's partly why I haven't prioritized this work above getting some basic prototype code to prove it out a bit. But I'm not saying a XEP absolutely cannot come first, just explaining my personal time prioritization. If someone wants to help with the XEP side of things, I'm not going to complain.
Personally, I agree. If I thought for a single moment I could write a successful MUC update/replacement of this magnitude on my own, I'd code first and XEP later. But I don't think I can do this alone, and so I'm drawing on the collective expertise. I already noted I don't think I've even got the requirements right yet. Where we disagree, I think, is how we get that expertise. I don't think we get it effectively by trying to assemble a team outside of the XSF (or alongside, or however you wish to put it). I think CG3 is, if anything, a demonstration of that not working. Again, I have reasonable confidence that the specification I've written is implementable. It's a conrete specification. It's probably not right - but I think it's got legs.
However, progress is also hindered if work is done in the community
and then completely ignored.
I cannot ignore something I don't know anything about; please stop saying that, I've asked you already. The trouble with this argument is, in any case, that the very concept of GC3 actually slows things down. Of the four (!) mentions of GC3 on this list, two are discussing other work predicated on GC3. Progress is hindered by the threat of future conflicting work. It's like the dream of the perfect MUC replacement, it becomes the enemy of the good MUC replacement, or something.
So to answer Nicolas's question: they seem, needlessly, to be different things at the moment.
Please do take the time to explain why, and why your approach is better.
I don't especially have time right now (I literally have a child pulling my arm as I type this). However I can dig up the relevant links from the summit notes and post a new thread about GC3 shortly (I don't particularly want to hijack this thread, which is probably best reserved for feedback on the submission itself).
Feel free to hijack this thread. I would be delighted to have my ideas shot down by something more sensible. I would happily incorporate them into the XEP, rename the thing to GC3, and hand the whole thing over and remove my name. Ideal outcome. And if you don't have time, that's absolutely fine too. I have had periods where I do not have time to read the mailing list, and missed people asking me things, and I do dimly recall when my children were young enough to drag me by the arm (and they're still able to distract me with parenting duties even now). This is a volunteer organisation, and must always take second place to actual life. I would caution, though, that everyone else does get to carry on without you. Dave.
On Wed, 29 Apr 2026 at 23:06, Dave Cridland <dave@cridland.net> wrote:
On Wed, 29 Apr 2026 at 18:28, Matthew Wild <mwild1@gmail.com> wrote:
On Wed, 29 Apr 2026 at 17:48, Dave Cridland <dave@cridland.net> wrote:
On Wed, 29 Apr 2026 at 15:20, Matthew Wild <mwild1@gmail.com> wrote:
On Wed, 29 Apr 2026 at 14:31, Dave Cridland <dave@cridland.net> wrote:
As far as I know, GC3 has no published specification and is not an XSF activity; I've avoided that name to (hopefully) avoid confusion with it.
Okay, I'll take the bait... :)
Apart from being hashed out by multiple XSF members, including at a sprint, and presented and discussed at an XSF summit...
I don't think that's the right definition of an XSF activity, is it?
By that set of metrics, other XSF activities include Modern XMPP and the Jabber.org XMPP service. In fact, that even suggests Prosody is an XSF activity, doesn't it? Clearly that cannot be the case.
I think this is a pointless debate because the line can be drawn wherever someone wants it to be drawn, and you've demonstrated it can be taken to extremes. I would argue that your classification of GC3 as not an XSF activity was taking it to the opposite extreme.
Not really, I used your definition, which you used to suggest GC3 was an XSF activity.
Modern XMPP, jabber.org, and even Prosody are all worked on by XSF members, including at a sprint, and presented and discussed at an XSF summit.
My argument was that that your definition was demonstrably incorrect since none of those are XSF activities; I didn't take anything to extremes. I didn't even pose a strawman. I did explain why each of your criteria were flawed both individually and as a whole, though, and since this was your argument for why GC3 is an XSF Activity, I felt that demonstrated that at the very least, if it is an XSF Activity it's not for the reasons you suggested.
Anyway, if you still insist it's an XSF activity, it doesn't really change matters.
My point, if anything, was that "XSF activity" is vague enough to be whatever anyone decides it is. See below, where you bring XSF membership into the equation, but earlier you discounted XSF membership status of individuals in determining whether something is an XSF activity. As I said a couple of emails ago, this branch of the discussion is only going to be circular.
I don't know... you as an individual just submitted it without (as far as I know) any of the XSF being involved at all.
I'll assume this is just a joke.
Unless I've missed my reapplication window somehow.
See above :)
People have asked about GC3 both in the chatrooms and on this list and received no response.
I can only apologize if I've missed queries, that was obviously unintentional. I'll see if I can find where this happened. But I also don't see why the whole thing has to depend on me - multiple people with XSF experience have been involved, and could also be addressed questions, and could also carry this forward.
On this mailing list, Nicolas, Singpolyma and Goffi have been the only ones mentioning it, and only since September. Goffi explicitly asked you for an update, and there was no response. I have to say evidence is against your assertion there.
It seems that only the multiple people mentioning GC3 are the only people mentioning it, indeed.
In addition, other people have more generally mentioned new MUC features (including whole threads), and GC3 hasn't been explained in any of them.
To be absolutely clear, I'm not suggesting you're doing anything wrong here. People get busy, life gets in the way, and this is all a volunteer thing. I have certainly dropped out for months at a time and been unresponsive. But having documents (if they exist) published, and discussions in the open, means that other people can (and have, thanks!) picked up work in my absence, and newcomers have joined, seen older dormant work, and raIsed it again.
All this is true, and it would be amazing if people actually did that.
Ideally they wouldn't just invent a group chat protocol and submit it without researching existing efforts or bringing it up at a summit.
I didn't want to wait another 10 months, and also I didn't write the XEP without reviewing existing MUC options. In particular, I've spent roughly the past 3 years working with ejabberd's muc-sub, and MongooseIM's muclight, and I think I've a reasonable grasp of the benefits (and shortfalls) of both. I've also written a client, from scratch, partly in order to understand what the best practice was for MUC, and better understand its limitations with mobile. I have done my homework, though of course you may disagree with the result.
Again, I have no visibility on GC3, and didn't actually think it was actively being worked on; there have been no status updates in well over a year, and there's no other suggestion of ongoing activity.
There has been some progress, but not significant and not on any specification.
I get the impression that you think GC3 is some specification that is being withheld from the XSF standards process. The only reason "the GC3 XEP" hasn't been submitted is because it doesn't exist. To make it exist, someone needs to collate the notes from the discussions at the sprint, summit and online and write it up in XEP syntax. There are still some unsolved questions about the approach (but, from a skim, probably fewer than the document you have submitted).
You have the wrong impression. Certainly I think GC3 is outside of the standards process we have in the XSF, and outside of its venues for discussion, and I think that's a shame.
I think you have the wrong impression. With no standard it's impossible to work within or without the standards process. The XSF standards process literally begins with a document submission, but nobody has written and submitted a suitable document.
I did ask you and Kev, back at the Summit in 2025, to publish a XEP of some form, and I think I asked you to raise it on the mailing list. The XEP I was told couldn't be written because there were too many disagreements about what it would contain. I have a vague recollection that it couldn't be discussed on the list for fear of overwhelming the list? In any case, I took this to mean it was to be done outside of the XSF for the time being.
My question is, if you're so interested in getting something published in this space, why not help with that?
That's allowed, of course. Lots of things happen outside of the XSF. I do wish that some of them (including GC3, but also other things) were done within the XSF, but I lost those arguments years ago.
Again, this "within" vs "without" distinction simply does not exist, it's the same as the "XSF activity" debate.
But it does make it awkward to run things outside the XSF then argue that I shouldn't do something within the XSF as a result. Besides, standards work on XMPP outside of the XSF or IETF feels wrong to me - if it were anyone else, I'd find it outright suspect.
Again, the "outside of the XSF" is just not a thing.
I don't know where GC3 is being discussed (if it still is). There was a chatroom address on your presentation back in the Summit in 2025, but I definitely cannot recall what that was, I don't know where to find it now, and it has never been posted to this mailing list as far as I can find.
There was a MUC, yes, it was a last-minute addition to the slides so that interested people could continue discussion of the topic. I didn't think to post it to the list, because it's not the only place where discussion is permitted (standards talk tends to happen here or in the xsf/jdev MUCs).
Personally, I agree. If I thought for a single moment I could write a successful MUC update/replacement of this magnitude on my own, I'd code first and XEP later. But I don't think I can do this alone, and so I'm drawing on the collective expertise. I already noted I don't think I've even got the requirements right yet.
Where we disagree, I think, is how we get that expertise. I don't think we get it effectively by trying to assemble a team outside of the XSF (or alongside, or however you wish to put it). I think CG3 is, if anything, a demonstration of that not working.
I think this may be the whole basis of the misunderstanding? I don't know what "team" you think was assembled. I don't think I have the capacity to organise such a thing! I think I initially discussed GC3 with Zash and Jonas in the Prosody developer channel, and with Kev around the same time. There was interest, and it organically became one of the main topics of a sprint because I presented the notes and ideas I had been making, and the people present (myself, Conversations and Dino developers, and a few others) had some discussion about it. Then the next round of feedback was at the summit. Maybe, in hindsight, the correct thing to do would have been to actually assemble a team, as a SIG or something. But I know back then it didn't feel like a suitable option - my perspective at the time was that the majority of the community was not really interested in a MUC 2.0, but rather MIX. Now I guess I was wrong, and there is significant broad interest in a MUC 2.0. All this to say, it was just some sharing of ideas and notes between interested parties. It is not, and never has been, some grand organised away-from-the-XSF scheme. Quite the opposite, if anything. Just scraps of notes and ideas, with the goal of maturing into a XEP.
I cannot ignore something I don't know anything about; please stop saying that, I've asked you already.
I'm sorry if you feel you know nothing about it. I presented it at the summit, and you were there, so I guess I made assumptions in this regard.
The trouble with this argument is, in any case, that the very concept of GC3 actually slows things down. Of the four (!) mentions of GC3 on this list, two are discussing other work predicated on GC3. Progress is hindered by the threat of future conflicting work. It's like the dream of the perfect MUC replacement, it becomes the enemy of the good MUC replacement, or something.
I absolutely agree.
Feel free to hijack this thread. I would be delighted to have my ideas shot down by something more sensible.
With today's Prosody security release out of the way, I will make some time tomorrow to gather everything GC3 related into a mailing list post. As I said in my previous email, I don't want to stop anyone from working on a MUC successor that's in the spirit of "fix MUC" rather than "replace MUC with an entirely different system" (i.e. MIX). Your proposal is clearly aligned with that same GC3 approach, which is great - I, and as I gradually discovered, others too, want to see such a thing. But it's frustrating that it wasn't based on any of the work that had been done so far. I accept a large part of the responsibility for this, as based on your email I apparently managed to entirely miscommunicate the whole thing, to the point where you didn't even feel it was worth reaching out before publishing this alternative proposal. Someone once said, many years ago, that they believed most XMPP developers were working on communication protocols because they were actually rather bad at communication themselves. I sadly recognise myself in such a statement. But I try...
I would happily incorporate them into the XEP, rename the thing to GC3, and hand the whole thing over and remove my name. Ideal outcome.
This doesn't sound like an ideal outcome. It seems you are actually interested in this space, and have the time and motivation to work on it. I don't know why you should stop, or remove your name. I don't even care what the document is called.
And if you don't have time, that's absolutely fine too. I have had periods where I do not have time to read the mailing list, and missed people asking me things, and I do dimly recall when my children were young enough to drag me by the arm (and they're still able to distract me with parenting duties even now). This is a volunteer organisation, and must always take second place to actual life. I would caution, though, that everyone else does get to carry on without you.
Even the idea that things couldn't carry on without me would terrify me. It's just painful to watch duplicated efforts, and that's literally the only reason I care. I would have been satisfied if you'd read through the notes and discussions on GC3 and dismissed them all with good reasons. But noted, you didn't, because I evidently didn't do a good enough job in presenting them. I'll try and remedy this part. Regards, Matthew
On Wed, 29 Apr 2026 at 12:39, Marvin W. via Standards <standards@xmpp.org> wrote:
Hi,
On Tue, 2026-04-28 at 18:38 +0100, Dave Cridland wrote:
There's another part, which is limitations of '45, and requirements for New MUC. I think these are probably the most important part - if we can collate and agree those, then we can work to solve them.
That's a good point, so let me go through them:
All my points are excellent. Try not to sound so surprised. ;-)
2. MUC1 occupant addressing is also the nickname - this is bad, because when the nickname changes so does the JID, and it also restricts the form of nicknames in unexpected ways.
"is bad" as I said is not really a good motivation. I agree that if we were to redo MUC from scratch right now, we likely would use the occupant id in the resource, mostly because it feels the right way to do it. Can you outline that "restricts the form of nicknames in unexpected ways"? Is that referring to clients and servers still relying on resourceprep when the RFC is clear that resource is a PRECIS OpaqueString (which has almost no limitations other than forbidding control characters, which seems sensible for nicknames). Can you outline issues that are caused by nickname changes causing JID changes which are fully resolved by not having that? I think those should be in the requirements (e.g. allow MUC participants to block other participants individually), because there might be other, potentially better ways to fix those issues.
I think that combining addressing and visual naming is bad in principle, and I think stable addressing for occupants is in general terms a good thing. But, you're quite right that higher level requirements are probably useful here.
5. Presence-based joining is not (comfortably) compatible with "sparsely online" clients such as mobile; when not online a client is not an occupant - long-term engagement with a chatroom is complicated as a result, so we should fix this.
In my experience, my mobile is actually the least sparsely online client, at least from a MUC perspective. I might be temporarily disconnected due to network unavailable like in tunnels, but that's just for a short time and either TCP is still alive or I can resume the sessions using XEP-0198. But even if those short disconnects would result in being disconnected from the room, I would certainly want to fix this also for when I joined a room ephemerally. In contrast, it's my desktop computer that is typically offline for half of the day, which results in heavy use of MUC-MAM. But at least for me, this seems to be working reasonably well.
That's probably all true, and QUIC is very shiny here too. My experience may well be coloured by clients which are not always-on - that is, clients which are not able to maintain a continuous XMPP connection as we can on Android. But also long-term engagement has a variety of meanings here, and again I should absolutely expand on them. By way of examples, if my server had a constant view of messages, and I were visible as an occupant even when devices were offlne, I could still get push notifications for messages mentioning my name even if not an explicit mention, or I could get pushes for a mere mention of, say, Wimsy. From the other perspective, I can't tell if you dropped offline because you went into a tunnel and lost your session, or whether you dropped offline because you've left the chatroom in disgust at my continually mentioning Wimsy.
9. The same room JID and state should be usable by both MUC1 and MUC2.
Fully agree on state, not so much necessarily on JID. I could perfectly imagine MUC1 and MUC2 to use different JIDs internally, but then discoverability becomes an issue to solve. Given that your current proposal achieves the same room JID by adding restrictions to the users' nicknames, I'm also not sure that this is really necessary. Maybe one might want to rephrase this
I think it's a SHOULD for the jid. I agree that huge chatrooms can't mandate unique nicknames effectively, in which case they can't be exposed on the same jid as MUC1 fully transparently. And maybe that's OK, since huge chatrooms wouldn't work anyway on MUC1. But, for example xsf@muc.xmpp.org probably needs to keep its bare jid address to allow transition sensibly.
So maybe we say that while some MUC2 rooms might not be able to be presented at MUC1, this is often desirable especially during the transition period? 10. MUC1 presence is very noisy; MUC2 should provide a way to reduce or
elide presence entirely.
Fully agree.
Now the remaining points either describe status quo and mention it as explicitly desirable (1, 3, 4, 7) or describe status quo without a clear indication if that's meant to stay this way or changed as part of MUC2 (6, 8).
Do you agree that 1,3,4,7 are actually desirable to maintain?
Right, so you have to have nicknames be unique in a room if you want '45 compatibility. And we absolutely require that, I think, at least in the early phases.
Except if we allow for an additional nickname outside the resource, even for MUC1. I bring this up because if we solve this for MUC1 (e.g. by using something like the XEP-0172 MUC support removed in version 1.1 of that XEP but still used in the wild by some clients, notably Jitsi Meet), that solution almost automatically reduces the importance of the resource in the JID and thus makes a transition to occupant id in resource an easier step.
I'd lean away from introducing (or reintroducing) changes in MUC1 to ease transition, because any client willing to adopt them might as well adopt MUC2.
===
As a less esoteric example, a 'DM' in a MUC from someone who changes their nickname is just annoying to handle cleanly in a client.
That's not the only issue with DM in MUC and we might also want to ask the question (similar to <iq> in MUC) if that's needed or wanted at all, or if rather a protocol to allow an occupant to discover another occupants real bare jid (with their consent) is reasonably suitable for what DM in MUCs could be used.
I think DMs are useful things (even if I generally dislike them and want them turned off). More generally, I think being able to direct traffic to individual occupants is a useful feature beyond just messages. I don't think we want to have to expose real jids to allow this. MUC1 originally had occupant jids be a forwarding device to the real full jid of the occupant. Then we introduced nick sharing as a bit of a hack, and vCard handling and more of a hack still, and then we removed it all for anonymous rooms, and then... Layers upon layers of hackery. I'd like a more well-defined model in MUC2 which would allow for DMs (I think that's the easy case) but also avatars, Jingle, and other things even in anonymous rooms. I do not have a design for this, though - I suspect it'll look like some mixture of proxying and publishing, so for example we might either publish an avatar to "your" occupant, or have the avatar request be proxied back to your own bare jid, or both but you get to pick which. Dave.
For those not paying attention, this was rejected roundly by everyone attending the Council meeting yesterday: https://logs.xmpp.org/council/2026-05-05 The reasons given were: 1) Daniel and Marvin both wanted it split up into small extensions against '45. This is not my preferred approach, but it's a valid enough approach. I think long term we'll run into problems and need a compliance spec to bind the required extensions back into a single spec, or something like that. 2) Stephen said there was no implementation, no plan to implement, and questioned whether it was implementable. Marvin also expressed doubt it could be implemented. I question whether this is a requirement for Experimental, and entirely dispute that the approach cannot be implemented. If the requirement for a ProtoXEP is now that it is a fully polished specification with implementations what on earth is the point in Experimental? We don't even require that for Stable! 3) Marvin also disliked that the XEP described itself as a "discussion point". I actually think this was a misunderstanding of what that term means, but never mind. In order to address these, I have submitted just the addressing/occupancy portion - I believe these two parts are closely interlinked and would be damaged by trying to extract them into two specifications. This should satisfy objection (1). I also knocked out a quick PoC of the server side, which I hope satisfies objection (2), this is in a Draft PR here: https://github.com/igniterealtime/Openfire/pull/3305 - this is done by LLM, from the specification. I really don't like putting this amount of effort (and in this case, cost) into a ProtoXEP submission. This implementation is solely to prove to Stephen and Marvin that it can be implemented, and will not be merged - I fully expect the specification to change as we discuss it. Finally, I stripped the "discussion point" text, to satisfy objection (3). But the XEP remains a discussion point, in as much as people should discuss it (here, ideally), and I'm keen to make changes (including radical ones) that we can build consensus around. One we do have consensus, I'll do a proper implementation with an aim to merging it into Openfire (and Wimsy too). The remaining changes are mostly tidying up, improving references, more examples, etc. Oh, and a way to leave bare jid occupancies, because I forgot that before and it seems important... Dave. On Fri, 24 Apr 2026 at 11:27, Daniel Gultsch <daniel@gultsch.de> wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: New MUC Abstract: This document specifies an enhanced Multi-User Chat protocol that is broadly backwards compatible with that of XEP-0045, but adds a number of key improvements.
URL: https://xmpp.org/extensions/inbox/new-muc.html
The Council will decide in the next two weeks whether to accept this proposal as an official XEP. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi Dave, On Wed, 2026-05-06 at 17:59 +0100, Dave Cridland wrote:
In order to address these, I have submitted just the addressing/occupancy portion - I believe these two parts are closely interlinked and would be damaged by trying to extract them into two specifications. This should satisfy objection (1).
I also knocked out a quick PoC of the server side, which I hope satisfies objection (2), this is in a Draft PR here: https://github.com/igniterealtime/Openfire/pull/3305 - this is done by LLM, from the specification. I really don't like putting this amount of effort (and in this case, cost) into a ProtoXEP submission. This implementation is solely to prove to Stephen and Marvin that it can be implemented, and will not be merged - I fully expect the specification to change as we discuss it.
I'd like to point out that your new ProtoXEP PR is not exactly only the extraction of the previous proposals addressing and occupancy portion, it does include new parts that the previous proposal lacked. Notably it does introduce some new wire protocol parts (specifically the <part/> element). The fact that you created (or had an LLM create) an implementation of what is currently described doesn't really change anything with regards to if it can be implemented, if that implementation is simply useless in practice. As I had also written on GitHub, your new proposal still completely ignores addressing on messages (you know, the thing we primarily use MUCs for), which still has problems unsolved in practice. I don't know Openfire well, but from what I understood, the implementation will simply keep messages for muc2 occupants as is, meaning they still have the nickname in the resource and occupant-id in the message payload. Beside that I disagree that those two things, addressing and occupancy, are closely interlinked. The whole bare jid occupancy session part as described works equally fine with the old addressing scheme. From what I understand, the main thing that's different with the new addressing scheme is where nickname and where occupant id are to be found in the stanzas. Marvin
On Mon, 11 May 2026 at 14:38, Marvin W. via Standards <standards@xmpp.org> wrote:
I'd like to point out that your new ProtoXEP PR is not exactly only the extraction of the previous proposals addressing and occupancy portion, it does include new parts that the previous proposal lacked. Notably it does introduce some new wire protocol parts (specifically the <part/> element). The fact that you created (or had an LLM create) an implementation of what is currently described doesn't really change anything with regards to if it can be implemented, if that implementation is simply useless in practice. As I had also written on GitHub, your new proposal still completely ignores addressing on messages (you know, the thing we primarily use MUCs for), which still has problems unsolved in practice. I don't know Openfire well, but from what I understood, the implementation will simply keep messages for muc2 occupants as is, meaning they still have the nickname in the resource and occupant-id in the message payload.
I think it's fairly obvious that if addressing of occupants changes, then the addressing of messages as well as presence changes. The addressing of iq stanzas will also change. If the implementation is wrong on that front, then the implementation is wrong. Again, implementation isn't required for Experimental (or even Stable!), according to XEP-0001. I have absolutely no doubt that the ProtoXEP is not at the quality gate we'd require for Stable, but I would like to actually bring it into the XSF and work on it with the rest of the participants in this SIG, under the XSF's IPR policy.
Beside that I disagree that those two things, addressing and occupancy, are closely interlinked. The whole bare jid occupancy session part as described works equally fine with the old addressing scheme. From what I understand, the main thing that's different with the new addressing scheme is where nickname and where occupant id are to be found in the stanzas.
I think bare jid occupancy is sufficiently embedded into the concept that it's hard to remove, or at least hard to add in cleanly later. It doesn't work "equally fine" with XEP-0045, which is why there's a bunch of compatibility requirements around that exact case (ones you've commented about on the PR). As MattJ has noted, XEP-0045's increasingly patchwork nature is problematic, and I was hoping not to replicate that. Dave.
On Mon, 11 May 2026 at 15:19, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
I have absolutely no doubt that the ProtoXEP is not at the quality gate we'd require for Stable, but I would like to actually bring it into the XSF and work on it with the rest of the participants in this SIG, under the XSF's IPR policy.
Seems that is already happening here :)
A ProtoXEP Submission is prior to the IPR policy. I've not assigned copyright yet, that happens on Publication. If we were to finalise all XEPs prior to them entering Experimental, then firsty what's the point of Experimental, and secondly they'd all be outside the IPR policy, and a bad actor could then take them away and (for example) charge access. Dave.
secondly they'd all be outside the IPR policy, and a bad actor could then take them away and (for example) charge access.
"a bad actor" as in the author? Could decide to ... not submit? I guess they could, but if the final draft ends up totally different than the initial they could do that anyway if they have some reason to.
On Mon, 11 May 2026 at 15:45, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
secondly they'd all be outside the IPR policy, and a bad actor could then take them away and (for example) charge access.
"a bad actor" as in the author? Could decide to ... not submit? I guess they could, but if the final draft ends up totally different than the initial they could do that anyway if they have some reason to.
Irrespective of the example, you do, surely, accept that work ought to happen within the IPR? Dave.
the IPR policy, and a bad actor could then take them away and (for example) charge access.
"a bad actor" as in the author? Could decide to ... not submit? I guess they could, but if the final draft ends up totally different than the initial they could do that anyway if they have some reason to.
Irrespective of the example, you do, surely, accept that work ought to happen within the IPR?
I agree that finished specs as submitted and accepted by the XSF should be covered by the IPR.
On Mon, 11 May 2026 at 15:54, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
the IPR policy, and a bad actor could then take them away and (for example) charge access.
"a bad actor" as in the author? Could decide to ... not submit? I guess they could, but if the final draft ends up totally different than the initial they could do that anyway if they have some reason to.
Irrespective of the example, you do, surely, accept that work ought to happen within the IPR?
I agree that finished specs as submitted and accepted by the XSF should be covered by the IPR.
OK, so you're not accepting any ProtoXEP unless it is "finished"? As in, what, Stable quality or Final? I'd like to understand what it'll take to get something published. Dave.
I agree that finished specs as submitted and accepted by the XSF should be covered by the IPR.
OK, so you're not accepting any ProtoXEP unless it is "finished"? As in, what, Stable quality or Final?
I'd like to understand what it'll take to get something published.
In general my guiding principle is to avoid things we've seen in the past like MIX, COIN, JinglePub, Inbox, XEP-0284, etc where the spec is published (and in some cases lots of work goes into the spec or multiple other specs end up notionally depending on it) but it never actually goes anywhere. Especially in this case I hope we can agree that a repeat of the MIX process is not likely to get us to a better (for the ecosystem) result. So what does "finished" mean? Does it mean ready for Final? Certainly not. But I'd hope it means that the primary design considerations and latent ambiguities have been squeezed out and that there is some reason to believe that adoption by (some non-trivial part of) the ecosystem is going to happen. I know my opinion is not universally held by coucil, who sometimes says outrageous-to-me things like "numbers are cheap" and so of course I do allow my self to be swayed by the rest and I'm not going to dig in to single-handedly block things everyone else likes, and have voted +0 on several specs I was unsure about in the past based on pressure from others.
On Mon, 11 May 2026 at 16:14, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
I agree that finished specs as submitted and accepted by the XSF should be covered by the IPR.
OK, so you're not accepting any ProtoXEP unless it is "finished"? As in, what, Stable quality or Final?
I'd like to understand what it'll take to get something published.
In general my guiding principle is to avoid things we've seen in the past like MIX, COIN, JinglePub, Inbox, XEP-0284, etc where the spec is published (and in some cases lots of work goes into the spec or multiple other specs end up notionally depending on it) but it never actually goes anywhere. Especially in this case I hope we can agree that a repeat of the MIX process is not likely to get us to a better (for the ecosystem) result.
There is an irony here in that I'm using an Inbox implementation every day... But I accept that Inbox is tricky to do unless you either ignore MUC, or have some kind of bare jid based occupancy. Gosh, if only there were a spec for that, eh? But Inbox works absolutely fine with muclight or muc-sub.
So what does "finished" mean? Does it mean ready for Final? Certainly not. But I'd hope it means that the primary design considerations and latent ambiguities have been squeezed out and that there is some reason to believe that adoption by (some non-trivial part of) the ecosystem is going to happen.
Isn't that Stable? If not, what's the purpose of Experimental? We explicitly ask about implementation intention in the Last Call, for example, and not before. Dave.
Hi, On Mon, 2026-05-11 at 15:17 +0100, Dave Cridland wrote:
I think bare jid occupancy is sufficiently embedded into the concept that it's hard to remove, or at least hard to add in cleanly later. It doesn't work "equally fine" with XEP-0045, which is why there's a bunch of compatibility requirements around that exact case (ones you've commented about on the PR).
Just to confirm, the bare jid occupancy as described right now is: 1. Have the user display as present even when they are not (optionally modify the presence in that case) 2. Send around messages that are to be discarded Those two things don't in any capacity depend on addressing. The first part is explicitly described to work for both MUC1 and MUC2, thus seems to be independent of addressing. The second part is underdefined in the proposal, but likely is meant to send around the messages exactly as they would be if the user joined using the traditional way, just that the bare jid is used in the to attribute instead of the full jid and thus messages get discarded. It would thus work equally well for MUC1 and MUC2 addressing, as the address in the from attribute is ignored and discarded. The only thing you are doing by putting it into this XEP is to make the MUC2 addressing mandatory for those messages. I don't see any need for this. If there is an element that is added as part of a presence-based MUC join to signal MUC2 addressing, the same element could be added to the bare jid occupancy join to signal MUC2 addressing, and when it's missing, old MUC1 addressing could still be used (on those messages that are discarded anyway).
Again, implementation isn't required for Experimental (or even Stable!), according to XEP-0001.
Exactly. Neither do useless/wrong/incomplete implementations provide proof that the XEP is implementable. That was my whole point. I am not asking you to fix the implementation to show me that it's implementable, I want you to fix the specification. The only part of the specification that is sufficiently detailed to be implemented at this stage is the bare jid occupancy: a means to be displayed as online when offline. The addressing part still has too many unknowns to do anything useful with it if implemented. For some of those unknowns there may be reasonable sane things to do (also rewrite addresses in messages), for some it already gets more complicated (MAM responses, because if those are requested before the client joined the room, the server doesn't know if they should reply with MUC1 or MUC2 addresses) and for some there is just no meaningful thing one can do (discover the nickname of a message sent by a user no longer an occupant). Also according to XEP-0001 "implementation of an Experimental protocol is encouraged in order to determine the feasibility of the proposed solution". It even says so twice. If I can determine the feasibility of the proposed solution already without implementing what is written in the XEP, what is the use of encouraging others to implement it? This is what Experimental means to me: "hey people, try implementing this and tell me what you think". And I don't get the vibe that's what you want to tell me. If you want to say "hey people, I'm trying to come up with something, but I don't know how and what exactly, let's work on this document under XSF IPR policy", you don't need to make it Experimental. You can just say this and avoid any doubts on whether your XEP is encouraged for Experimental implementations or not. And if you think we need a venue that is explicitly under XSF IPR policy but not ready for experimental implementations yet, then talk to the board. Marvin PS: IPR policy applies as soon as an extension is submitted for consideration. When is that exactly? Shouldn't it be enough to open a PR against the xeps repo?
On Mon, 11 May 2026 at 16:13, Marvin W. <xmpp@larma.de> wrote:
If you want to say "hey people, I'm trying to come up with something, but I don't know how and what exactly, let's work on this document under XSF IPR policy", you don't need to make it Experimental. You can just say this and avoid any doubts on whether your XEP is encouraged for Experimental implementations or not. And if you think we need a venue that is explicitly under XSF IPR policy but not ready for experimental implementations yet, then talk to the board.
But... that *is* Experimental... Experimental doesn't mandate implementation, it merely encourages it. And you can implement this, not that it's required, and I have, not that I had to. Experimental doesn't even require implementable. The Process we have literally doesn't have a stage before Submission. So you're asking, as a Council member, that I should NOT follow our process as documented in XEP-0001? Dave.
On Mon, 2026-05-11 at 16:36 +0100, Dave Cridland wrote:
On Mon, 11 May 2026 at 16:13, Marvin W. <xmpp@larma.de> wrote:
If you want to say "hey people, I'm trying to come up with something, but I don't know how and what exactly, let's work on this document under XSF IPR policy", you don't need to make it Experimental. You can just say this and avoid any doubts on whether your XEP is encouraged for Experimental implementations or not. And if you think we need a venue that is explicitly under XSF IPR policy but not ready for experimental implementations yet, then talk to the board.
But... that *is* Experimental... Experimental doesn't mandate implementation, it merely encourages it. And you can implement this, not that it's required, and I have, not that I had to. Experimental doesn't even require implementable.
Experimental encourages implementation in experimental branches, which implies implementability and that the XSF as the publishing entity assumes it's worth investing time it to create such implementations.
The Process we have literally doesn't have a stage before Submission. So you're asking, as a Council member, that I should NOT follow our process as documented in XEP-0001?
The process has a phase before submission. It's the research. Part of the research is to determine if "the proposed protocol extension is truly needed in order to fill a gap in existing XMPP technologies and protocols". That gap is neither explained in the document itself nor obvious from reading it. The research may include discussion and those are supposed to happen on exactly this mailing list. Which they are. The only thing we would reach by accepting your latest proposal as a XEP is confusion, because people might assume that they are encouraged to implement this in experimental branches. If you can't wholeheartedly say that people are encouraged to invest their time into creating experimental implementations from your XEP (which I assume because you yourself opted to use an LLM for the implementation rather than investing your time), why do you want to submit it? Marvin
On Tue, 12 May 2026 at 14:03, Marvin W. <xmpp@larma.de> wrote:
On Mon, 2026-05-11 at 16:36 +0100, Dave Cridland wrote:
On Mon, 11 May 2026 at 16:13, Marvin W. <xmpp@larma.de> wrote:
If you want to say "hey people, I'm trying to come up with something, but I don't know how and what exactly, let's work on this document under XSF IPR policy", you don't need to make it Experimental. You can just say this and avoid any doubts on whether your XEP is encouraged for Experimental implementations or not. And if you think we need a venue that is explicitly under XSF IPR policy but not ready for experimental implementations yet, then talk to the board.
But... that *is* Experimental... Experimental doesn't mandate implementation, it merely encourages it. And you can implement this, not that it's required, and I have, not that I had to. Experimental doesn't even require implementable.
Experimental encourages implementation in experimental branches, which implies implementability and that the XSF as the publishing entity assumes it's worth investing time it to create such implementations.
Not really. It never has, historically. Lots of XEPs haven't been implemented, at least in any public form, for ages after becoming Experimental. SASL2, for one. XEP-0198 for another. After a while people sometimes pick them up and try them, in which case they're a success. Both were changed quite extensively in Experimental, because they didn't work, or missed features, or had features that weren't actually useful in the end. Sometimes they're not a success, like MIX (though MIX did indeed get implementations, just not meaningful deployments). The XSF encourages implementation, in XEP-0001, because previously it discouraged it entirely - they were marked purely as discussion items because they'd change in incompatible ways, and implementations didn't interoperate. We fixed that with namespace versioning but XEP-0001 doesn't say either that they have to be implementable, much less that they have to be implemented. Indeed, XEP-0001 might now encourage implementation, but it also caveats that heavily. In other words, I'm very much aware of both what the text says, and also why it says it. The only time the XSF expects actual implementation in the standards process is once the XEP reaches Stable, since that is literally the first time it mentions gaining feedback from implementation and deployment. XEP-0045 and XEP-0060 were both published in entirely different forms to their current state, and were only developed after publication. They were both implemented quite early, but those implementations would have been wildly different. Indeed, they changed after reaching Stable (then Draft) because of feedback from real-world deployments. We're now better at enabling implementation and capturing the feedback during the Experimental phase - and that's good, and was an intentional aim so that Stable (then Draft) would be much more Stable - but that shouldn't mean we shift the entire process left. What you and Stephen are demanding is essentially higher than the Stable quality gate - feature complete and fully implementable, with several plans to implement and at least one implementation - which is not what the process demands at all, and historically does not match. Experimental XEPs are "works in progress", not "finished", as has been demanded. If we apply the quality gate for Stable to Experimental submissions, then honestly I'm unclear what you think Experimental is for. Now, you might want your idea of the process to be the one we all follow, but that's not up to Council, it's up to Board. Previously you've said I should go to Board if I want to follow your mistaken notion of the process; I think I must return the favour, and say that if you want the process to exist as you declare it to be, you need to propose a change to XEP-0001 and have Board approve it. I have somewhat resigned myself to the expectation you'll reject this in any form at this point. Unfortunately, XEP-0001 gives you that right, since it doesn't limit your reasons. However, rejecting it for not being in line with a process that doesn't exist is absolutely and definitively wrong.
The Process we have literally doesn't have a stage before Submission. So you're asking, as a Council member, that I should NOT follow our process as documented in XEP-0001?
The process has a phase before submission. It's the research.
Part of the research is to determine if "the proposed protocol extension is truly needed in order to fill a gap in existing XMPP technologies and protocols". That gap is neither explained in the document itself nor obvious from reading it. The research may include discussion and those are supposed to happen on exactly this mailing list. Which they are.
Again, you seem to be confusing Experimental, Proposed, and Stable. You're quoting the Last Call questionnaire for Stable, there, not actually a documented part of the process rather surprisingly. XEP-0001 has this as the "Proposed" step, section 8 in XEP-0001, as opposed to the "Discussion" phase, which is Section 7, while the XEP is Experimental. We've ended up announcing ProtoXEP submissions as "Proposed XMPP Extension", which might be what's confusing you here. Could you point at XEP-0001 and tell me where in our process we have a research phase before Submission? The word doesn't appear in XEP-0001 at all. You're claiming a process that doesn't exist. And then rejecting a XEP submission based on it, which ironically, under the process which does exist, I have no recourse. This is extremely frustrating.
The only thing we would reach by accepting your latest proposal as a XEP is confusion, because people might assume that they are encouraged to implement this in experimental branches. If you can't wholeheartedly say that people are encouraged to invest their time into creating experimental implementations from your XEP (which I assume because you yourself opted to use an LLM for the implementation rather than investing your time), why do you want to submit it?
Because I want to follow the documented and approved process and get to Section 7. Dave.
participants (6)
-
Daniel Gultsch -
Dave Cridland -
Marvin W. -
Matthew Wild -
Nicolas Cedilnik -
Stephen Paul Weber