- Standards

XEP-xxxx: Pubsub Node Bookmark
by Timothée Jaussoin 02 Oct '26

02 Oct '26

Hello :) A year ago my XEP-xxxx: Pubsub Node Bookmark was merged in Inbox. This XEP define a simple element that points to a Pubsub Node and that can be embeded in a Bookmarks list, it was designed to be close to the XEP-0402: PEP Native Bookmarks <conference/> element. You can see a live version there https://movim.eu/xeps/pubsub-node-bookmark.html . I just submited a tiny PR to fix the examples there https://github.com/xsf/xeps/pull/1565 I'd like to have feedback on it and if possible publish it as we would like to use it extensively in the Spaces and in Movim to replace the historical https://xmpp.org/extensions/xep-0330.html in the upcoming weeks. Regards, edhelas

1 0

UPDATED: XEP-0491 (WebXDC)
by Daniel Gultsch 02 Oct '26

02 Oct '26

Version 0.1.4 of XEP-0491 (WebXDC) has been released. Abstract: This document defines an XMPP protocol extension to communicate WebXDC widgets and their state updates. Changelog: * Support realtime channels (spw) URL: https://xmpp.org/extensions/xep-0491.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.

1 0

New protoxep: MUC is ready
by Nicolas Cedilnik 29 Sep '26

29 Sep '26

Hi all, I submitted a protoXEP today <https://github.com/xsf/xeps/pull/1563>. A rendered version is at <https://nicoco.fr/muc-ready.html> It is a proposition for a mechanism to avoid the following situation: 1. a MUC services shuts down and kicks clients out; 2. clients don't re-join the MUC automatically. This is generally not an issue for local users, since MUC services and XMPP server implementations are tightly coupled in practice and can work around the situation by supporting restarting the MUC service "silently". Also, when the whole XMPP server is restarted, clients re-login and re-join all MUCs after that, so the issue does not arise. It is however a problem for non-local users. Clients have adopted different strategies for this situation. For instance, Conversations does not attempt to re-join automatically, and gajim retries periodically. I propose that MUC services can emit MUC invitations on startup to signal that a room is ready to be re-joined. The invite stanza has a dedicated |<ready />| element, which lets clients treat these invites differently than others, eg, by avoiding to display it to the user or triggering re-join as they see fit. Slidge already has this "invite users on startup" behaviour and I developed a small prosody module <https://modules.prosody.im/mod_muc_invite_affiliated.html> <https://modules.prosody.im/mod_muc_invite_affiliated.html> with a similar behaviour. If this proposition is accepted, I will add the dedicated element in the invites of both this prosody module and slidge. Maybe this should be a new section in /XEP-0249: Direct MUC Invitations/ instead? What does the community think? Is it a terrible idea or does it fill a gap that is missing? -- Nicolas

1 0

Proposed XMPP Extension: Multistream XMPP
by Daniel Gultsch 29 Sep '26

29 Sep '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Multistream XMPP Abstract: Multistream protocols such as QUIC and WebTransport offer significant performance improvements to XMPP, particularly over constrained or degraded networks. This specification defines a binding for the XMLStream onto multistream transports, including both QUIC and WebTransport. URL: https://xmpp.org/extensions/inbox/xmpp-quic-redux.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

3 2

Proposed XMPP Extension: SASL2 Terms of Service Acceptance Task
by Daniel Gultsch 29 Sep '26

29 Sep '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: SASL2 Terms of Service Acceptance Task Abstract: This specification defines a SASL2 task, per the extensibility mechanism of XEP-0388, that lets a server require a user to accept the current terms of service before authentication completes. URL: https://xmpp.org/extensions/inbox/sasl2-tos.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

4 3

Sparse Mesh Federation Topologies
by Dave Cridland 25 Sep '26

25 Sep '26

Hi all, I appreciate that the subject line is a bit, well, pretentious. Sorry. In a meeting the other day, a requirement popped up to avoid the existing full-mesh routing in XMPP. I didn't comment, or explore it. Existing cases (Openfire's "trunking", Metre, Isode M-Link Edge/Gateway) have done this by explicit configuration, some gnarly DNS spoofing, and odd-ball TLS overrides. I'm wondering if it's worth exploring a standards-based solution here, where we'd have something like a routing protocol (like a BGPish or OSPFish thing for XMPP)? This would mean that when a.example talks to b.example, it might be told that b.example can forward traffic to c.example (and possibly how), and a.example could decide by some metrics, configuration, and trust that it would then send traffic to c.example via b.example. Or, not. I imagine the security implications will require quite a bit of thought, to say the least... Is there any interest in discussing this further? Dave.

2 2

XSF membership application period Q4 2026
by Alexander Gnauck 24 Sep '26

24 Sep '26

I have setup the XSF membership application Wiki page for the application period Q4-2026. Applications are encouraged from developers and others who are actively involved in the Jabber/XMPP community. To apply, create a page about yourself on the Wiki: https://wiki.xmpp.org/web/Membership_Applications_Q4_2026 If you don't have a wiki account, send your full name, preferred nickname and email address to me or one of the other Sysops: https://wiki.xmpp.org/web/Sysops When you need help with your application then don't hesitate to contact me directly Apply now!!! Thanks, Alex

1 0

XEP-0332 implementation experience and an offer to work on a revision
by Özcan Oğuz 24 Sep '26

24 Sep '26

Hello everyone, I have been implementing XEP-0332 in xmpp-httpx, a TypeScript library for Node.js and browsers, and would like to share implementation experience and offer to help co-author a revision. The library implements paths for all seven body mechanisms, with documented interpretations and deviations. It has been exercised over Prosody 13 and used by several browser integrations and an HTTP-origin gateway. These are implementation and integration results, not independent XEP-0332 interoperability tests. I also created a WebExtension and Dillo extension for httpx. Code: https://github.com/ooguz/xmpp-httpx Protocol notes: https://github.com/ooguz/xmpp-httpx/blob/main/docs/protocol-notes.md Test coverage and interoperability matrix: https://github.com/ooguz/xmpp-httpx/blob/main/docs/interop.md There are two related areas I would like to discuss and clarify: 1. Clarifying and updating the existing protocol The request/response model has been useful in practice. Several details nevertheless need clarification or an explicit design decision: Chunked transfer completion and failure: empty transfers, missing or conflicting chunks, bounded buffering, and the processing rules for the existing close element. Zero-based numbering is already specified. The unit of maxChunkSize and guidance for accounting for Base64 expansion and the complete stanza envelope. The relationship between an embedded Jingle offer and ordinary Jingle session initiation, acknowledgement, acceptance, and rejection. The allowed request-body mechanisms and their discovery. In particular, our use of IBB for request bodies goes beyond the current response-only restriction. A consistent distinction between malformed HTTPX requests, unsupported transport mechanisms, HTTP errors, and failures after the response IQ has already been sent. Gateway header and body handling, including the existing description of preserving HTTP chunk framing. A migration policy for SIPUB’s deprecated dependencies. I would separate corrections to examples from behavioral changes, and document our implementation choices as such rather than assume that they should become the specification. 1. An optional CONNECT extension A second application suite, n146 (the reason why I started development in the first place) uses the same library as a web-over-XMPP proxy. It is not yet publicc ready and is not an independent protocol implementation. For that application, we implemented an experimental CONNECT mapping: A req with method='CONNECT' identifies a host and port using authority-form. A successful resp identifies an IBB session. The proxy opens that session, which carries tunnel bytes in both directions. This reuses IBB’s explicitly defined bidirectional operation. It extends XEP-0332, which currently excludes CONNECT. In our tests, the mapping supports HTTPS access through HTTP CONNECT and SOCKS5 frontends, including concurrent browser traffic in Chromium and Firefox. These are application-level results; I would not present them as proof that the tunnel semantics are complete. Before proposing normative text, I think we need agreement on connection establishment, graceful shutdown versus abort, pending-data handling, timeouts, peer/session binding, and failures between the successful response and IBB establishment. The current implementation’s shutdown choices need further review. Discovery also needs to identify the precise supported wire format. I would not reuse one feature identifier for both the existing experimental req form and a future standalone connect element without defining how peers distinguish them. For an initial profile, IQ-carried IBB seems a useful baseline. Windowing, bounded buffering, and scheduling across concurrent streams could be documented as implementation guidance, with reproducible benchmarks rather than general performance guarantees. CONNECT and absolute-form forwarding would also require explicit destination authorization, network access restrictions, resource limits, and security/privacy guidance distinguishing XMPP transport encryption from TLS carried inside a tunnel. I would be happy to work with the author and interested implementers on: A focused patch addressing existing ambiguities and example errors. A separately reviewable CONNECT and request-target proposal, either within XEP-0332 or as a companion extension. Shared wire fixtures and interoperability tests against an independent implementation. I can contribute XML patches, examples backed by test fixtures, and the public implementation as an interoperability target. I would welcome feedback on the scope before combining these changes into a revision. Would updating XEP-0332 be the preferred direction, and should CONNECT be considered within that work or separately? Pointers to other implementations, or to earlier discussion of its exclusion, would also be very useful. Sincerely, Özcan Oğuz

3 2

Re: New QUIC binding
by Dave Cridland 22 Sep '26

22 Sep '26

On Tue, 22 Sept 2026 at 14:14, Florian Schmaus <fschmaus(a)gmail.com> wrote: > > Hi Dave, > > Is there a brief summary about what xep467 and yours do differently? > And, of the same interest, which things you do in a similar way (if any). > XEP-0467 maps a TCP-like XMLStream onto a single bidirectional QUIC stream. Multiple XMLStreams can be carried in a single QUIC connection as multiple QUIC streams. This preserves nearly all the properties of TCP, for good or bad. The good is that XEP-0198 maps across cleanly, the bad is that Head-of-Line blocking affects the entire XMLStream as a whole, just like in TCP. You do, though, get the advantages of QUIC connection migration between, say, 5G and WiFi. It's a good first step, but it's also a dead end because we can't take advantage of other QUIC capabilities. My approach is to have a single XMLStream map to multiple bidirectional QUIC streams. The specification (but not what I implemented) allows for multiple XMLStreams within a single QUIC connection. This avoids HoL blocking between conversations, reducing the effects of poor networks on the XMLStream as a whole, and meant I needed a different approach for "the ticks" - or at least the first one - since XEP-0198 doesn't work. As such, it uses QUIC itself to provide much of what XEP-0198 does, including the first tick. It also allows us to pipe calls, file transfers, and other non-XMLStream data alongside the XMLStream(s) using other QUIC streams and datagrams, in the future. Or possibly even sending XML elements over datagrams, if we're feeling a bit wild. The similarities are really that both approaches use QUIC, and so we get connection migration, round-trip reductions for connect, and so on. You can (in theory, see other note) connect, negotiate TLS, and do SASL authentication in a single round-trip. > > > https://github.com/xsf/xeps/pull/1561 > > Is there a rendered version somewhere? > No, sadly. Dave.

1 0

ProtoXEP: SASL2 Terms of Service Acceptance Task
by Guus der Kinderen 21 Sep '26

21 Sep '26

Hi all, (due to the XSF's mail server's issues of last week, I've sent this email a couple of times. I expect the earlier mails to never be delivered, but in case of a flood of the same message: my apologies). I'd like to submit a proposal for consideration as a XEP. The PR linked below is a draft SASL2 task, built on the extensibility mechanism of XEP-0388, that lets a server require a user to accept the current terms of service before authentication completes. It defines a single task on top of the generic <continue/> flow. Briefly, the task lets the server present the current terms and version and the client accept them within the SASL2 negotiation, and treats acceptance as a per-account record the server should persist, with a non-fatal fallback (re-ask next time) for anonymous authentication or a transient storage failure. I'm bringing this at an early stage deliberately: I'd like the list to shape a rough idea through discussion rather than just rubber-stamp a finished one. The alternative to bringing this in rough is having the real discussion happen somewhere else entirely, before it ever reaches this list - I prefer to have that discussion within the XSF ecosystem, because the XSF should be the place where knowledgeable people organize around doing this work, not somewhere they only show up once it's done. Given the recent AI-disclosure thread: this was produced through an extended back-and-forth with Claude, including a full review of the Openfire reference implementation it's based on. The prose is machine-drafted; I made the substantive calls and take responsibility for the result. PR: https://github.com/xsf/xeps/pull/1562 Happy to rework, narrow, or withdraw this based on feedback. Kind regards, Guus

1 0