This message constitutes notice of a Last Call for comments on
XEP-0424.
Title: Message Retraction
Abstract:
This specification defines a method for indicating that a message
should be retracted.
URL: https://xmpp.org/extensions/xep-0424.html
This Last Call begins today and shall end at the close of business on
2025-01-06.
Please consider the following questions during this Last Call and send
your feedback to the standards(a)xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction
and requirements?
3. Do you plan to implement this specification in your code? If not,
why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated!
Hi all,
At the recent Summit, we had a long and nuanced discussion about the state
of the XMPP RFCs and whether there is value in updating parts of them,
potentially through the IETF, to better reflect how XMPP is actually
implemented and used today.
To be clear upfront: This is not a proposal to start an IETF working group,
nor a commitment to produce new RFCs. The discussion at the Summit surfaced
enough open questions that it seems worthwhile to first have a focused
scoping and feasibility discussion.
Some of the motivations that were raised:
- The current RFCs do not describe a baseline that results in
interoperable modern implementations
- Discoverability for new implementers is difficult (knowing which XEPs
are "essential")
- The IM landscape has changed significantly since the original RFCs
- External review and feedback could be valuable
- There may be marketing and positioning benefits, but these are
secondary
At the same time, many concerns were raised:
- The sheer amount of work required, and whether we realistically have
the manpower
- Risk of scope creep (e.g., baking too much into RFCs)
- Loss of flexibility compared to the XEP process
- Fear of starting something we cannot finish
- Unclear interaction with compliance suites and the "living standard"
nature of XMPP
- Potential pushback or distraction from other IETF efforts (e.g., MIMI)
Questions that seem worth discussing at this stage:
- Is it useful to think about updating some RFCs (e.g., core, IM), while
leaving the rest to XEPs?
- What would be clearly in-scope vs out-of-scope?
- Is there enough interest and capacity to justify exploring this
further?
- What would be a sensible first step that does not overcommit us?
If you were at the Summit and felt strongly one way or the other, it would
be great to hear your perspective here. If you weren't, fresh viewpoints
are equally welcome.
The goal of this thread is simply to assess whether this topic is worth
pursuing further, and if so, in what very limited and realistic form.
Kind regards,
Guus
I'd like to propose adding a new processing hint to XEP-0334 to support silent/whisper messages - messages that are delivered normally but don't trigger notifications on the recipient's device.
Use Case:
My mother and I communicate via XMPP throughout the day. She frequently participates in screen recordings and video calls (about 1 hour daily) where notification sounds and popups would be disruptive. However, she doesn't want to use DND mode because she needs to remain reachable for genuine emergencies.
The solution we need: the ability to send non-urgent messages silently so she can read them when she next checks her client, without interrupting her work.
User Demand:
This feature is heavily requested across messaging platforms. A quick search shows thousands of users asking "how to send silent messages" or "send without notification" for Facebook Messenger, WhatsApp, Telegram, and other platforms. Telegram already implements this as "send without sound." The demand is clear and widespread.
Proposed Addition to XEP-0334:
A <no-notify/> processing hint with the following semantics:
<message to='recipient(a)example.com' type='chat'>
<body>Please look at the following when you have time: ...</body>
<no-notify xmlns='urn:xmpp:hints'/>
</message>
Behavior:
- The receiving client SHOULD NOT trigger audio/visual notifications
- The message SHOULD still be delivered and stored normally
- The message SHOULD appear in the chat history
- The message MAY still update unread counts (implementation-dependent)
- Clients MAY provide UI indication that a message was sent silently
Benefits:
- Allows nuanced communication without forcing binary DND states
- Respects recipient's focus/workflow while maintaining async communication
- Reduces notification fatigue
- Provides sender control over message urgency
- Simple to implement - clients already have notification suppression logic
Backwards Compatibility:
Clients that don't recognize <no-notify/> will simply deliver the message normally, which is acceptable fallback behavior.
This would be a natural extension to the existing hint types in XEP-0334 (no-store, no-copy, store, no-permanent-store) and addresses a genuine gap in XMPP's messaging capabilities.
Thoughts? Is this something the community would support adding to XEP-0334, or would it be better suited as a separate XEP?
Best regards,
L.G.
I'm using an email mask just because I don't want recruiters to get a view of my personal life, please consider the proposal objectively.
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.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: New MUC
Abstract:
This document specifies an enhanced Multi-User Chat protocol that is
broadly backwards compatible with that of XEP-0045, but adds a number
of key improvements.
URL: https://xmpp.org/extensions/inbox/new-muc.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
Hi all,
Some of the work I'm dealing with has the requirement that clients
belonging to their organisation shouldn't access arbitrary HTTP endpoints
outside their administrative boundary. I think this is a reasonable
requirement.
As an example, if A(a)a.example wants to send a file to B(a)b.example, A
uploads to their own server, which:
* Might (or might not) perform virus scanning, and
* Might (or might not) log IP addresses and other activity, and
* Might (or might not) expire the file sooner than B's organisation's
retention policy.
Some of these "might (or might not)" cases are probably specific to
enterprise cases, but others are more general and apply to consumer/private
messaging too.
What I'd like to explore therefore is whether we could have B's server pull
a copy of the file for B to access, processing and retaining it as B's
organisation requires.
But, and here lies my problem, I have literally no idea how to go about
this without disruption to the generally working case of HTTP upload.
Anyone got any ideas?
Dave.
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.
