- Standards

Spec proposal: bookmarks hierarchy
by Nicolas Cedilnik 18 Oct '26

18 Oct '26

Hello all, Edhelas and I submitted a PR on github for a spec proposal: <https://github.com/xsf/xeps/pull/1574> A rendered version is at <https://nicoco.fr/bookmarks-hierarchy.htm>. The idea is to have an additional item in pubsub/pep nodes containing bookmark items, defining bookmarks directories. The bookmark items themselves have a dedicated extension referring to these directories, with a "weight" used to sort them within the categories. Our obvious use case is organising rooms in a XEP-0503 space, but it could possibly be used for organising PEP bookmarks too. Feedback welcome and appreciated! Have a nice sunday, -- nicoco

1 0

Re: XEP-0353 language clarification
by onf 15 Oct '26

15 Oct '26

On Thu Oct 15, 2026 at 8:35 PM CEST, Thilo Molitor wrote: > The privacy aspects are discussed here: https://xmpp.org/extensions/xep-0353.html#security > > Because exchanging messages with other entities is effectively a presence > > leak, an XMPP client that implements the receiving side of this specification > > MUST disable sending of accept messages by default and MUST enable the feature > > only as a result of explicit user confirmation. Such confirmation can be > > provided per request, by automatically allowing requests received from Jingle > > initiators in the responder's contact list, or through some other suitable > > means as long as sending accept messages does not occur by default. > > But granted this is not ideal for several reasons: 1. the <accept/> element > was a :1 namespace one, but we rolled that back to the :0 namespace where the > same functionality is called <proceed/>. Also <ringing/> should be added in > that section of the XEP as well. Indeed, I read that section as being about <proceed/> -- indicating that a device is ringing can hardly be called "sending [an] accept message". > Regarding Dino never sending <ringing/>: older versions of that XEP didn't > include a ringing indication, maybe Dino simply implements an earlier version > of XEP-0353? Yes, I already said that in the thread you quote: > > On 10/14/26 6:59 AM, onf wrote: > > > I just checked and version 0.3.1 of the XEP that Dino claims to > > > implement doesn't seem to contain any description of <ringing/>, which > > > explains it. Its messages related to this XEP likewise don't include > > > <store/> hints because that's not specified in that version either. ~ onf

1 0

Proposed XMPP Extension: MUC is ready
by Daniel Gultsch 15 Oct '26

15 Oct '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: MUC is ready Abstract: This specification provides a way for MUC components to inform clients that a room is ready to be re-joined. URL: https://xmpp.org/extensions/inbox/muc-ready.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

6 8

We should require AI disclosure
by Goffi 09 Oct '26

09 Oct '26

Hello everybody, I would like to bring a discussion on AI policy. We can't really ignore anymore that modern models have become very capable, and I suspect that they are used for spec authoring. This raises, I believe, copyright issues: if someone use AI to redact a whole section of a spec, how can we be sure that it's not an existing specs for some other place, possibly under copyright, that is copied or paraphrased? How can an author guarantee that it's original work (hint: they can't)? I think that there are 3 distinct uses: 1. As a light formatting/checking help, for instance to generate a table from a human written section, to correct the formulation of a sentence, or to draft an example. This is notably useful for non native English speakers. 2. As a help to search existing state of art on some feature, or any kind of data, without writing anything in a protoXEP. 3. As a way to generate whole sections. Instinctively, and If we put aside ethical and ecological concerns about LLMs, I think that 1. and 2. are OK, and 3. should be forbidden. And in all cases, it should be disclosed. I would like your feedback on this matter, in particular people with legal knowledge. I would like to avoid a flamewar, I know that this topic is sensitive and there opinions are highly divided, please express your opinion calmly. The fact is, we can't ignore this anymore. Should this be discussed with board or council? Thanks. Best, Goffi

14 43

hi
by wanrup07＠gmail.com 07 Oct '26

07 Oct '26

hi

1 0

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