Hi, On Tue, 2026-04-28 at 18:38 +0100, Dave Cridland wrote: That's a good point, so let me go through them: "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. 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. 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 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).  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. === 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

On Wed, 29 Apr 2026 at 13:04, Nicolas Cedilnik &lt;nicoco(a)nicoco.fr&gt; wrote: It'll certainly be doing resourceprep. What sort of control characters? 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 15:20, Matthew Wild &lt;mwild1(a)gmail.com&gt; wrote: 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? 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 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. Please do take the time to explain why, and why your approach is better. Dave.

On Wed, 29 Apr 2026 at 18:28, Matthew Wild &lt;mwild1(a)gmail.com&gt; wrote: 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. 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). I'll assume this is just a joke. Unless I've missed my reapplication window somehow. 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. 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. 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 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. 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 12:39, Marvin W. via Standards &lt;standards(a)xmpp.org&gt; wrote: All my points are excellent. Try not to sound so surprised. ;-) 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. 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. 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(a)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 Do you agree that 1,3,4,7 are actually desirable to maintain? 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. 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.

Hi Dave, On Wed, 2026-05-06 at 17:59 +0100, Dave Cridland 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. 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

Seems that is already happening here :)

"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.

I agree that finished specs as submitted and accepted by the XSF should be covered by the IPR.

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.

Hi, On Mon, 2026-05-11 at 15:17 +0100, Dave Cridland wrote: 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). 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, 2026-05-11 at 16:36 +0100, Dave Cridland wrote: 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 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