Re: Proposed XMPP Extension: New MUC

Matthew Wild <[email protected]> Wed, 29 Apr 2026 15:20:10 +0100
Newsgroups gmane.network.jabber.standards-jig
Message-ID <CAJt9-x65WtEJTuuA6OJPxCpehmAWevMDLc5+603_fyWDyeb=vw@mail.gmail.com>
On Wed, 29 Apr 2026 at 14:31, Dave Cridland <[email protected]> wrote:
> On Wed, 29 Apr 2026 at 13:04, Nicolas Cedilnik <[email protected]> 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
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]