- Standards

UPDATED: XEP-0353 (Jingle Message Initiation)

by Daniel Gultsch

Version 0.8.0 of XEP-0353 (Jingle Message Initiation) has been released. Abstract: This specification provides a way for the initiator of a Jingle session to propose sending an invitation in an XMPP message stanza, thus taking advantage of message delivery semantics instead of sending IQ stanzas to all of the responder's online resources or choosing a particular online resource. Changelog: Adapt usage of JID types to real-world usage: * Send JMI responses to full JID of initiator instead of bare JID * Send JMI <finish/> element to full JID of both parties (melvo) URL: https://xmpp.org/extensions/xep-0353.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 month

1
0
0 0

Occupant colours

by Dave Cridland

I quite like XEP-0392. I didn't honestly think I would when it first proposed and published, but it's really handy. But, XEP-0392 doesn't - anywhere - specify what the "input" should be. I can see some options: 1) Pick the relevant jid. I'm currently using the bare jid for 1:1 conversations, and the XEP-0045 occupant jid (including nickname) for MUCs. That seems the most obvious, but means nickname changes also change colour. 2) Pick the display name. I could use the name for 1:1 (the one I display, from Roster etc) and the nickname from a MUC. That has the advantage that where those are the same, the colour will be consistent - "Zash" will be coloured the same on all MUCs, for example. 3) Pick the most stable identifier I can. So occupant_id in MUC, though still bare Jid for 1:1. This would mean the bright pink occupant would remain bright pink no matter what nickname change they tried. No escape! Any suggestions? Or doesn't it matter? Dave.

1 month

2
1
0 0

Proposed XMPP Extension: End-to-End Encrypted Contacts Metadata

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: End-to-End Encrypted Contacts Metadata Abstract: This specification describes how to encrypt contacts metadata to minimize server exposure. URL: https://xmpp.org/extensions/inbox/contacts-e2e.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

1 month, 1 week

10
25
0 0

Write-only PubSub node (XEP-0060)

by Schimon Jehudah

Greetings. I am interested to know, whether there is a possibility to create a write-only node. For instance, a node which be written by anyone, and read by selected people, be useful to moderation of contents. Pending urn:xmpp:microblog-await:0 Moderators: read and write Public: write Denied urn:xmpp:microblog-denied:0 Moderators: read and write Public: none Approved urn:xmpp:microblog:0 Moderators: read and write Public: read P.S. The node names are not standard node names. These are node names for the purpose of realization. Kind regards, Schimon

1 month, 1 week

1
0
0 0

Atom Over XMPP and element atom:link

by Schimon Jehudah

Greetings. I would want to discuss of Atom Over XMPP; that is XEP-0277 and XEP-0472, and subsequently XEP-0501; and the implementation thereof by several publishing platforms. Some publishing platforms utilize RFC 4287 in an invalid fashion, and I would want to advise of a better practice. I do not discuss this over the documentation repository, because I do not think that it is necessary, as this is an issue which concerns to RFC 4287 itself The Atom Syndication Format. atom:content ------------ Section 4.1.2 to RFC 4287 titled by The "atom:entry" Element has this statement. > o atom:entry elements MUST NOT contain more than one atom:content > element. However, there are at least two publishing platforms that violate that principle, and provide two elements of "atom:content"; One "atom:content" element of type="xhtml" and an additional one of type="text" which is not really Plain Text as intended by RFC 4287, but is Markdown Text. I suppose that, the purpose of the extra element is to store the source code of the actual content, to facilitate human interaction with these platforms. It is important to not that the valid values of attribute "type" of element "atom:content" are "text, "html", and "xhtml". atom:link --------- Nevertheless, the element "atom:link" offers two relevant attributes to that would fit perfectly. Attribute "href" (location) to specify the URI to the document. That could also be over FTP, Gemini, HTTP, XMPP, over a PubSub URI for public or private access; and it is particularly helpful, to both developers and people, to access or download the source of a document, instead of extracting it from an XML element; Attribute "rel" (relation) which has various of uses over Atom, HTML, and XML, including paging with rel="next" and rel="previous" (RFC 5005), could be utilized to classify the content of the linked document as a source of a post (i.e. rel="source"); and Attribute "type" (MIME-Type) to set the file type of the content (i.e. type="text/markdown"). Attributes "hreflang" and "title", of element "atom:link", might also be useful, yet these two attributes are not crucial to this discussion. Importance ---------- There are three crucial reasons for that advisory. * Compliance with RFC 4287, as intended; * Better classification of data, as proposed; and * Most importantly, to not confuse developers who want to explore publishing over XMPP; for example, developers of publishing platforms such as Bonfire, Pleroma who are meticulous when they implement standards. Of note ------- I was confused, and almost discouraged, when I first attempted to create a publishing platform, because I tested against platforms that utilize more than a single element of "atom:content", and which one was classified as "text" even though it was not plain text. Respectfully, Schimon

1 month, 1 week

2
2
0 0

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 month, 2 weeks

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

1 month, 2 weeks

1
0
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.

1 month, 3 weeks

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.

1 month, 3 weeks

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.

1 month, 3 weeks

1
0
0 0

2026

2025

2024

2023

Standards