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
2026-07-20.
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!
Hey all,
I would have liked, at this point, to write a nice note about how I've
got Early Data working. But I've got several problems with this, both
practical and standards related. This email concentrates on the
standards side.
The goal with this would be that on QUIC, we can connect, establish
TLS, perform authentication, binding, stream state configuration, and
eventually other things all within the first round-trip. This would
result in connections (or at least reconnections - some data needs
caching) to occur fast even on quite slow networks.
0RTT "Early Data" is replayable, so an attacker can extract it from
the QUIC connection (or TLS handshake on TCP) and re-send it. This can
be defeated by counters (as FAST defines in XEP-0484) or by ensuring
that the request is idempotent and carries no side-effects (as HTTP
recommends).
The counter works by defeating the replayability; HTTP's approach
means that the replayability no longer matters.
The problem with the counter approach we've taken to date is that this
immediately onflicts with cases where we do want to replay it for
legitimate reasons, such as Happy Eyeballs and similar approaches to
"racing" multiple connection attempts. On poor networks, a first
connection attempt might succeed, but the response is lost, causing
counters to be updated and subsequent attempts to be rejected.
The only alternative I can see is to defer any side effects until the
handshake completes, noting that this does include resource binding -
in particular resource conflict resolution, which often has quite
large side effects for the losing session. I think this seems vaguely
possible, but I worry I have forgotten other side effects.
The other potential problem is that the early data is sent, and
processed, before most channel binding types are available, in
particular the TLS Exporter type. I suspect - and if you know, please
chip in - that this is OK, in as much as if the handshake completes
with the session ticket and PSK then the original channel binding from
the first connection still holds, in effect, as proof that the
endpoints remain unchanged. But I would really like to know for sure.
Finally, I note that because we're reliant on handling the early data
before a client can receive the features, then either the client
should "just know" the available mechanisms for early data
authentication, or else it will need to be told in a previous session.
And IAP (XEP-0509) needs to work, so the actual features/config inputs
used to calculate that need to remain unchanged.
Anyway, would appreciate any notes/ideas others have on this area!
Dave.
Hey all,
I'm coming to the end of three weeks of testing XMPP/QUIC over
"constrained" networks. The networks here aren't actually particularly
bad; but the guest WiFi is horrendous, and I've tested some fairly
odd-ball things like running XMPP/QUIC over public 4G data at 5,000ft
above one of the great lakes, and an alarming number of people testing
this (including the nice people with the network degradation hardware)
so I've got a new ProtoXEP. This is a new QUIC binding, with
WebTransport support, and is entirely and totally incompatible with
the existing Experimental XEP-0467. Obviously Travis paved the way
here, and I'm late to the party!
https://github.com/xsf/xeps/pull/1561
The first thing I'd like to make clear is that I don't think what I've
done is "final" in any sense, but it is a practical starting point for
useful discussion. I'm 100% open to changes, and fully expect some in
the coming weeks.
The second thing is that what I've written is not what I have
implemented and tested - it's what I suspect I should really have
implemented, in hindsight. I didn't think about the stream headers,
for example, which allow multiple stream types, or the refinements
about ordering rules I've documented here - I just did bare streams
and bare jid pair ordering. It works well, but can be improved.
As such, I'd like to propose that - as an experiment in ways of
working - Council does not vote on this yet, and we should instead
discuss as a community and figure out ourselves when it's ready to put
before Council (assuming it ever is).
But... The basics of this specification (modulo stream headers) are in
Wimsy and my "dwd-deploy" branch of Openfire, and have been heavily
tested under a range of network conditions. The basics seem to work
well, and effectively cope with some awful traffic conditions. I've
been working on this for about 6 months, and for most of that time any
messages you've seen from me have gone over QUIC for the C2S leg.
Dave.
Hi all,
the 29th XMPP Summit is coming up in a little over 24 hours. Friday
and Saturday from 13:00-16:00 UTC.
This is our first online summit and is hosted on a Big Blue Button
server provided to us by the FSFE.
https://conf.fsfe.org/b/mkw-hvi-ujx-kb7
This is your last chance to propose some topics on our wiki.
https://wiki.xmpp.org/web/Conferences/Summit_29#Proposed_Topics
We will be voting on the 4 topics that we are going to be discussing
very early in our Friday time slot. So be on time and do get familiar
with the topics beforehand.
On time means 20 minutes early! The room will be open and we will be
having some nice hallway discussions.
cheers
Daniel
