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.
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.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Group Chat Reporting
Abstract:
This specification describes how a client can report abuse and spam in
a MUC or other group chat context.
URL: https://xmpp.org/extensions/inbox/xep-gc-reporting.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
Good Morning Council Members,
the next XMPP Council Meeting will take place on, Tuesday, April 7
2026 at 15:30 UTC in xmpp:council@muc.xmpp.org?join
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors update
* Proposed XMPP Extension: Message Archive Management: Trim Command
* Proposed XMPP Extension: Group Chat Reporting
* Proposed XMPP Extension: Occupant Mute Synchronization
* UPDATED: XEP-0384 (OMEMO Encryption)
* UPDATED: XEP-0413 (Order-By)
* UPDATED: XEP-0509 (Initial Authentication Pipelining)
4) Items for voting
a) Proposed XMPP Extension: Message Archive Management: Trim Command
https://xmpp.org/extensions/inbox/xep-mam-trimming.html
b) Proposed XMPP Extension: Group Chat Reporting
https://xmpp.org/extensions/inbox/xep-gc-reporting.html
c) Proposed XMPP Extension: Occupant Mute Synchronization
https://xmpp.org/extensions/inbox/xep-occupant-mute-sync.html
5) Pending votes
Daniel on XEP-0045: Add clarification regarding unsetting reserved nicknames
See the spreadsheet of doom:
https://docs.google.com/spreadsheets/d/14gy_nhuTnqlktakJfLZ2Mc-jblSaG0na0Kh…
6) Date of Next
7) AOB
8) Close
