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
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.
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
Version 0.2.0 of XEP-0509 (Initial Authentication Pipelining) has been
released.
Abstract:
This specification defines a protocol for discovering if the SASL2
<authenticate> can be pipelined safely along with the stream open, and
if so allows the client to perform this pipelining safely.
Changelog:
Updates based on implementation (dwd)
URL: https://xmpp.org/extensions/xep-0509.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 0.2.1 of XEP-0413 (Order-By) has been released.
Abstract:
This specification allows to change order of items retrieval in a
Pubsub or MAM query
Changelog:
Replace old namespace use in examples. (jp)
URL: https://xmpp.org/extensions/xep-0413.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 0.9.1 of XEP-0384 (OMEMO Encryption) has been released.
Abstract:
This specification defines a protocol for end-to-end encryption in
one-to-one chats, as well as group chats where each participant may
have multiple clients per account.
Changelog:
Fix using id=0 in examples. Spec requires positive numbers. (XEP
Editor: dg)
URL: https://xmpp.org/extensions/xep-0384.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.
