- Standards

XEP-0277 to include attributes of "atom:feed" element

by Schimon Jehudah

Greetings. XEP-0277 is meant to deliver RFC 4287 (Atom format) over XMPP. However, as with Atom Activity Stream, only elements "atom:entry" are delivered. So, elements "atom:subtitle" and "atom:logo" of element "atom:feed" are neglected. Could we utilize element "pubsub:items" to store that missing data of element "atom:feed"? <items node='urn:xmpp:microblog:0' title='The Journal of Romeo' subtitle='Of the affairs of the Capulet and Montague families.' logo='http://montague.lit/logo.svg'> Regards, Schimon

1 week, 4 days

2
2
0 0

Handling of Extended Key Usage extension in certificates

by Matthew Wild

Hi folks, This is (part of) a discussion I had intended to discuss at the summit, but we already had enough topics to fill the time (!) so I guess it's fine. This change primarily affects server-to-server connections, and therefore server developers. I published a blog post recently which covers some of the background and sparked some discussion: https://blog.prosody.im/2026-letsencrypt-changes/ Basically, OpenSSL (and almost certainly other libraries) validate the Extended Key Usage extension in certificates and, by default, forbid the usage of certificates without the clientAuth purpose from being valid at the client side of a connection. It's important not to be confused by the "client" and "server" terminology here: in a server-to-server connection, the initiating server is a "client" from the perspective of TCP, TLS and the application code. Most CAs have been including the clientAuth purpose in their certificates, however new requirements from Google are insisting that they stop doing this by June 2026. For a long time (at least a decade), Prosody has been overriding OpenSSL's default behaviour and permitting only certificates with the serverAuth purpose to be used for authenticating server-to-server connections, regardless of the direction of the connection. It is our belief that this is the correct way to do things. At least one implementation (ejabberd/fast_tls which also uses OpenSSL) was found so far to depend on the clientAuth purpose being present in certificates used on the "client" side of a server-to-server connection. The fix was released in ejabberd 25.08 last year (there are still many out-of-date servers on the network though). Due to diversity in the CA ecosystem, it's not necessarily safe to use certificates with only the clientAuth purpose to authenticate servers. Unfortunately this is documented nowhere in XMPP currently, which can lead to broken federation at best, and security issues at worst. I've submitted a PR to update XEP-0178, which seemed like the most natural fit for specifying this: https://github.com/xsf/xeps/pull/1501 Regards, Matthew

2 weeks, 2 days

1
0
0 0

Scoping discussion: updating XMPP RFCs / XMPP 2.0

by Guus der Kinderen

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

2 weeks, 3 days

4
3
0 0

Wimsy: Yet another XMPP client

by Dave Cridland

Hi all, Not sure where else to announce this, so here goes... Last Friday, while in the XMPP Summit, I absently started typing in a chat window. I didn't get any chance to do more until the Eurostar back, but I've been occasionally typing in the same chat window now for a week, so I think I have something to share. https://github.com/dwd/Wimsy It's rough, certainly - but it's not bad for something I've barely touched the code of directly, and that I've only spent a week (of spare time) on. Whimsy is now a basic but functional XMPP client, running on: * Linux desktop - I'm using it there a lot. * Web - it's an installable PWA, too, deployed at https://dwd.github.io/Wimsy/ * Android - I have used the build, sometimes, and it does work, though it's probably not yet optimal. * MacOS - Builds in CI? * Windows - I should really try this one too. * iOS - Probably not very useful - no background, and no push - but hey it builds. It's written - apparently - in Flutter/Dart, which is, erm, a language or something. As is traditional in these announcements, I should note that Wimsy is just a hobby, and won't be big or professional like those other clients. Somewhat more seriously, the roughest parts of the UX are in the onboarding - like telling you to pick a PIN without any explanation of what that's for (encrypted local cache), or the *very* confusing checkbox for direct TLS (really only applies if you specify a host manually). I'll fix these up in time, as well as working toward a full compliance suite level. It's MIT-licensed, though includes a radically changed xmpp_stone library, and the upstream of that (copied in) is under Apache 2. People willing to test it and provide feedback would be enormously welcome, particularly on platforms I've not got to yet. "Bugs" - any suggestions for improvements really - are welcome as PRs putting a markdown file describing the improvement (in detail!) into ./bugs/new/ Less formalized suggestions are also welcome. Aside from the "Dave, why did you vibe-code an XMPP client in a week you mad idiot?" type. Because I'm not really in a position to review the code changes, I'd rather not accept direct patches. Seems odd, I know. Have fun, play nicely, Dave.

2 weeks, 6 days

1
0
0 0

Proposal: Add <no-notify/> hint to XEP-0334 (Message Processing Hints)

by Laura G.

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.

2 weeks, 6 days

5
6
1 0

UPDATED: XEP-0143 (Guidelines for Authors of XMPP Extension Protocols)

by Daniel Gultsch

Version 1.1.3 of XEP-0143 (Guidelines for Authors of XMPP Extension Protocols) has been released. Abstract: This document provides information intended to assist authors of XMPP Extension Protocols. Changelog: Reflect preference for GitHub pull requests for initial submission, PRs to contain only one changed XEP. (dwd) URL: https://xmpp.org/extensions/xep-0143.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.

2 weeks, 6 days

1
0
0 0

UPDATED: XEP-0001 (XMPP Extension Protocols)

by Daniel Gultsch

Version 1.26.0 of XEP-0001 (XMPP Extension Protocols) has been released. Abstract: This document defines the standards process followed by the XMPP Standards Foundation. Changelog: * Surface (and correct) the source control information. * Surface the publication URL (although I assume anyone reading this has figured that one out by now). * Surface the contributor side of things. * Add bit about XEP authors making PRs if they don't exist - this is "new" rather than documenting existing practice. * Add bit about PRs getting XEP author approval (existing practice hithertofore undocumented). * Add bit about Council (etc) adding authors if they drop off (existing practice hithertofore undocumented). * Add note to clarify that Retraction doesn't mean Deletion (existing practice, documented, but has been misunderstood before). (dwd) URL: https://xmpp.org/extensions/xep-0001.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.

2 weeks, 6 days

1
0
0 0

Presence problem in large MUC rooms.

by Goffi

Hi, Following what I've said yesterday at the summit, I would like to explain more my idea, and get your feedback. So basically the problem with presence in large MUC is that we get 2 things: - initial presence when we join the room - all the presence update when people join and leave, which is quite often with people on mobiles. So my point was that we are seeing MUC by the way it's used today. But we don't have to. We don't have to be actively in the room. What we want when we are in a large room, is to be able to check it when we want, and be notified when we are mentioned. For smaller rooms, we may want to be notified on each new message. The way I see it, we could have 2 ways to join a MUC: active and passive. The active join would be what we do today, we get all the presence, and updates, it's really bandwidth intensive. The passive join, on the other hand, would only say "we are in the room". The MUC service would then notify the client only in case of mention (or for any message in case of "subscribed" room). Benefit: - we don't have presence spam anymore, the client does an active join only when the user want to actually be in the room. So it's only one room at the time. - client doesn't have to actively parse message to look for mention, on mobile it will get a push notification and wake up only when necessary - It should be easy to implement on top on existing MUC implementation - It's backward compatible: non-compatible client will just to "active" join all the time, and get all the presence spam. Probably we can also optimize the initial presence in case of active join, but that's another topic. I think that solves the presence issue. Let me know what you think about it. Best, Goffi

2 weeks, 6 days

6
12
0 0

Agenda for XSF Board Meeting on 5 February 2026

by Guus der Kinderen

Dear Board members, This email announces the agenda for our next Board meeting, scheduled for Thursday, 5 February 2026, from 17:00 to 17:30 UTC. The meeting will take place in the XSF chatroom at xmpp:xsf@muc.xmpp.org?join. Brief context is included for each agenda item to support preparation. *1. Welcome*Opening of the meeting. *2. Formalize Agenda*Confirm and approve the agenda for this meeting. *3. Review and vote on proposed changes to XEP-0001 and XEP-0143*The Board will review and vote on proposed changes to XEP-0001, which require Board approval. The Council has already approved the proposed changes to XEP-0143. This item is included to ensure process clarity and to determine whether the Board wishes to formally note or endorse those changes as well. *4. Summit and FOSDEM report and follow ups*A brief review of the recent Summit and our presence at FOSDEM. The purpose is to identify any concrete outcomes, learnings, or potential follow-up topics that may require future Board or membership attention. No decisions are expected under this item. *5. Increase Board meeting frequency*Discussion of a proposal to increase the frequency of Board meetings, with the aim of improving engagement, continuity, and overall productivity. *6. Any Other Business*Items not listed above that require brief attention. *7. Date of Next Meeting*Agreement on the date of the next Board meeting. *8. Close*Closing of the meeting. Please review the relevant materials ahead of the meeting so that we can use our time efficiently. Kind regards, Guus

3 weeks, 1 day

1
0
0 0

QUIC(ker)

by Dave Cridland

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.

3 weeks, 6 days

5
4
0 0

2026

2025

2024

2023

Standards