On Wed, 29 Apr 2026 at 14:31, Dave Cridland <dave(a)cridland.net> wrote:
On Wed, 29 Apr 2026 at 13:04, Nicolas Cedilnik
<nicoco(a)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