Hi folks,
As promised in another thread, I'm posting a round-up of "GC3"
resources. But first, I'll summarize what this is about for people who
missed the summits/sprints where it was discussed.
The idea grew, from discussions with a few people, that it would be
good to level up group chats in XMPP, without breaking significantly
with the extremely entrenched MUC protocol.
In fact, we have already extended MUC (XEP-0045) in various ways, both
by updating XEP-0045 itself and through various add-on XEPs in recent
years, some with relatively rapid adoption (XEP-0421), and others not
so rapid (yet?).
There has been vague occasional talk of "MUC 2" for a very long time
(since before MIX), mostly various isolated ideas for improvements. I
wanted to try and finally glue some of these ideas together, without
necessarily "stealing" the title as an official MUC successor, so
"GC3" became a working title.
Shortly after I'd started gathering this together, we held a sprint in
the UK. A lot of that sprint ended up being reviewing the GC3
wishlist, priorities, eliminating some bad ideas, and clarifying some
possible approaches.
The slides of the GC3 presentation I gave at Summit 27, a few months
later, are here:
https://matthewwild.co.uk/uploads/xmpp-gc3-jan-2025.pdf
The main GC3 notes, including feedback from the sprint and summit, are
available here: https://pad.nixnet.services/s/7xKNOKxxE
In addition to the notes, there have been a couple of partial attempts
at turning it into something more like a specification.
This one by Jonas: https://pad.nixnet.services/s/yu7drWpml
This one by Kev: https://github.com/swift/protoxeps/blob/master/gc3.md
Both these are missing some things, they probably overlap in some
areas and conflict in others. But definitely together they form the
basis of anything that would become a GC3 XEP.
Apart from this, Kev also produced some additional related documents:
- https://github.com/swift/protoxeps/blob/master/acl.md
- https://github.com/swift/protoxeps/blob/master/related-entities.md
These were spawned from GC3 discussions, but could certainly stand as
XEPs in their own right. I don't want to speak for Kev, but I assume
if there is sufficient interest then he would be willing to work
further on these and get them submitted, or have someone else help to
do so.
Okay, that's the status of documentation.
Partly because of the numerous ideas floating around, I also wanted to
work on at least a rough prototype implementation of at least some
core parts of the code. Just to try out the approach and prove it can
work.
I know that implementation isn't required by the XSF in order to have
an experimental XEP. However, faced with the decision between spending
time on writing a GC3 XEP, and figuring out if it can even be
implemented, I personally chose to prioritize the latter. This isn't
any kind of statement about whether or not there should be a GC3 XEP
submitted at this stage, I *personally* just don't want to spend time
writing such a broad XEP for a protocol that may need drastic changes
as soon as anyone tries to implement it. I won't (and, anyway, can't)
stop someone else with time and motivation from doing what they want
(implementation or specification) with any of the "GC3" notes we've
gathered. I presented them at the summit precisely with the hopes that
everyone interested in the topic may do exactly that, so we can move
the thing forward.
After the summit presentation, I started making some necessary changes
to the Prosody MUC code to allow us to accommodate some of the
discussed GC3 features. Mainly internal refactoring of some APIs and
data structures to make it more extensible and support chats where we
have mixed MUC and GC3 clients.
The only externally visible change in Prosody so far, is that I began
implementing a participant list fetch protocol (behind an experimental
feature flag). Ironically, it's one of the parts of the protocol we
deemed during the sprint as high priority and yet we don't actually
have a protocol for this written anywhere in the several "GC3"-related
documents, yet.
One of the features of such a protocol would be paging, e.g. using
RSM. Prosody's implementation doesn't currently support this. I
immediately ran into the problem that to support paging, the
participant list needs to be ordered and stable. Currently Prosody
stores affiliations and participants in unordered hash tables. Another
thing that needs refactoring.
Okay, that's the implementation update from me.
Now, the status and future of GC3...
It appears from discussions that multiple people have come to view me
as having some kind of "ownership" over GC3. This was entirely
unintended and very unfortunate. It's true (I think?!) that I picked
the name, and I wrote the first draft of notes. However I think by now
that between various discussions online and offline across and venues
(regrettably not this list?), my personal contributions to the whole
thing are quite outnumbered by others.
Obviously if nobody else beat me to it, at some point writing a GC3
XEP was inevitably on my todo list. So I accept that I'm somehow the
"default" person in a way - going to push this forward, eventually, if
nobody else can/will. But it seems somehow this appeared as some kind
of exclusivity, and this was likely due to poor communication on my
part.
In that regard, I am glad that Dave ignored this and broke the ice
with the MUC2 proposal regardless, surfacing this whole issue.
I like collaborating with smart folk, it's why I am here and why I do
open-source. But I (and I'm not alone) have far more ideas, wishes and
responsibilities than I have time to work on all at once. Sometimes
this also means I get rather behind on emails, or that I might miss
MUC discussions.
If anyone else feels that I am somehow blocking them from doing what
they want - I'm always willing to talk it over. And if that fails,
please, just go ahead and do it.
Now, finally, GC3 future...
Realistically, I'm unlikely to change trajectory. I have a long list
of stuff to do, and honestly, GC3 is outranked by various other
priorities for the coming month or two at least.
This means, I see the following possible outcomes:
- MUC2 halts and nothing further happens until I finally get around to
a GC3 XEP (nobody wants this)
- MUC2 continues as a from-scratch parallel effort (not ideal in my
opinion, but I can't and won't block such an effort, especially not if
others think it's a good path)
- MUC2 is at least informed and improved by the prior work on GC3,
adopting as much or as little as deemed appropriate. Even if it
ultimately adopts none of it, I think this would be a win.
What I care about is that we arrive at a good MUC successor XEP with a
good path to adoption. I will say it again just to be clear here: I
don't care what it's called, or whose name(s) are on the document.
Regards,
Matthew
Hey all,
Some of you have heard me talk about this at the Summit, but I'd like to
revisit/reexamine our QUIC binding to improve performance of XMPP on low
bandwidth. I'm not sure we'll get to this at the Summit, and there's not
many who want to talk about it so I wondered if this summit topic could
have been an email. (Except then we discussed it anyway)
The primary concerns on low bandwidth - beyond sending fewer bytes on the
wire - are round-trips and head-of-line blocking.
I think XMPP has a good story on round-trips; we're down to very few during
authentication and connection setup, and during normal messaging operation
we don't worry about latency at all.
Head-of-Line blocking, or HoL Blocking, is when - in our case - packet loss
causes the stream to stall until the packet is retransmitted, which is at
least a round-trip away - and can be more due to bandwidth-delay product.
At the same time, we cannot eliminate this entirely (by, say, sending
stanzas over UDP directly) because if we do that we lose the ordering. Out
of order messages can be confusing, and lead to bad misunderstandings.
The rules on this are in RFC 6120, and are rather more complicated than we
normally worry about - normally, we just process everything on a strea, in
order, and this does satisfy the rules. But the rules allow us to process
stanzas in any order we like, as long as
So, what I'm thinking is a way to use the additional channels in QUIC such
that we open multiple channels on both C2S and S2S sessions, which would
form part of the same virtual stream, and we can distribute messages such
that we maintain ordering within messages where we need to, but allows us
to out-of-order (and avoid HOL Blocking) messages sent between unrelated
jids.
This differs to the existing XEP, where each channel maps to a single XML
Stream and XMPP session.
Notes from the Summit:
WEBTRANS would also be of interest, but "raw" QUIC has some advantages as
well, so we probably want both with a uniform approach.
So, my plan is to get an implementation together and a XEP.
Anyone else interested?
Dave.
Hi all,
I've submitted a PR against XEP-0467 for QUIC multi-stream support. The PR
points to a PoC implementation for C2S on both client and server - I should
note these both currently only work on Linux.
They do run, though, and I'm using them as my "daily driver". You should
definitely not do this, the code is demonstrably unsafe (due to
implementation, not the spec).
This will all need substantial tweaking before it's really where I'd like
it, but the key features are that one conversation need not HoL block
another. This builds on QUIC's migration etc.
The downside of this approach is that it utterly kills XEP-0198. XEP-0198
is predicated on stream state being able to be captured in just two
integers and an opaque id. QUIC essentially handles the resumption case,
but QUIC connection state is much more complex than two integers, and we
lose the common usage of XEP-0198 <r/> - <a/> to drive "single-tick" state.
We'll need something new to replace it.
If you are familiar with QUIC then you are likely much more familiar with
QUIC than I am; please please do review and discuss!
Thanks,
Dave.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Emoji Markup
Abstract:
This specification leverages and (or ) to send custom emojis
URL: https://xmpp.org/extensions/inbox/emoji-markup.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Payment Required
Abstract:
This specification defines an XMPP protocol extension that enables
services to require payment before granting access to a resource. It
provides a payment-system neutral invoice format supporting multiple
concurrent payment options, including bank transfers (SEPA, IBAN, UPI)
and instant-settlement networks (Lightning Network), and integrates
with the existing CAPTCHA challenge mechanism defined in XEP-0158.
URL: https://xmpp.org/extensions/inbox/payment-required.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
Version 1.1.0 of XEP-0345 (Form of Membership Applications) has been
released.
Abstract:
This specification outlines the form and mandatory content of
membership applications.
Changelog:
Apply policy changes after Board vote on 2026-04-16
Allow Legal Name to be provided privately to the Secretary instead of
published.
Add support for alternative public identifiers.
Clarify handling of private information and alignment with XSF
disclosure policy. (gdk)
URL: https://xmpp.org/extensions/xep-0345.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
Version 1.35.4 of XEP-0045 (Multi-User Chat) has been released.
Abstract:
This specification defines an XMPP protocol extension for multi-user
text chat, whereby multiple XMPP users can exchange messages in the
context of a room or channel, similar to Internet Relay Chat (IRC). In
addition to standard chatroom features such as room topics and
invitations, the protocol defines a strong room control model,
including the ability to kick and ban users, to name room moderators
and administrators, to require membership or passwords in order to
join the room, etc.
Changelog:
* Add clarification how to unset a reserved nickname when modifying
the member list.
* Split passage which defines how to modify the member list into
multiple sentences to improve readability. (ph)
URL: https://xmpp.org/extensions/xep-0045.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
It seems to me that XEP-0077 is not RFC compliant in section 3.3
specifically it says:
> In order to require additional information before changing the password,
> the server or service SHOULD return a Data Form in the error stanza:
However https://datatracker.ietf.org/doc/html/rfc6120#section-8.2.3 says:
> An IQ stanza of type "error" MAY include the child element
> contained in the associated "get" or "set" and MUST include an
> <error/> child
That is to say, it may not contain any child other than an <error/> child
and possibly an echo of the request.
Now, one could imagine a syntax for embedding a data form in an <error/> but
this is not what XEP-0077 describes.
Has anyone implemented this part of XEP-0077 in practise? If I return the
error with this form will anyone respect it? Do we need to care that this is
not RFC compliant or can we squint and say that it's a sort-of echo of the
request but with more fields to fill out...
Hi folks,
I'm curious if anyone has thoughts on being able to undo a XEP-0425
moderation action.
The use cases I have in mind are:
- admin accidentally moderated the wrong message
- one admin moderates a message, but after consideration/discussion
with other admins, it is decided it shouldn't have been moderated
- reverting automated moderation after human review
This last point is the one that sparked this email, however I have
experienced the other cases as well over the past couple of years.
For the automated case, all I necessarily want is for clients to hide
(by default) messages in a group chat which are likely to be spam, for
example if some trusted but non-admin users have reported it. When an
admin does respond, they could then moderate the message fully, or
unhide it (if the report was incorrect, e.g. malicious).
This hiding/unhiding could be a new XEP, or we could solve
"unmoderation", which solves the other use cases and probably makes
the most sense.
Thoughts?
Regards,
Matthew
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Occupant Mute Synchronization
Abstract:
Allows synchronizing a list of muted group chat participants between
multiple clients.
URL: https://xmpp.org/extensions/inbox/xep-occupant-mute-sync.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
