- Standards

XEP-0503: Spaces update proposal
by Nicolas Cedilnik 16 Sep '25

16 Sep '25

Hi all, I just submitted a revision to XEP-0503: Spaces. This is something edhelas and I have been working on last week. I intend to implement it in slidge, and he intends to implement UI for it in movim. It is an almost complete rewrite vs the current state, which should not be an issue since it has not been implemented anywhere yet. I tried to incorporate the feedback I got, not only from the mailing but in various MUCs and private conversations I had about the XEP here and there. In short, a space is now just a pubsub node with appropriate configuration and payload, and a space service is a pubsub service with feature requirements. As per the previous revision, the goal of this XEP is to establish a minimal viable protocol for clients and servers to build around the general concept of grouping several entities together. It requires little to no additional support server-side and should work, in a very basic form, with what's already available out there. I believe, that, even in this basic form, it would be nice to have. edhelas and I will also submit soon(ish) another XEP which could be _a_ way of defining how space-wide affiilations/roles/hats could work, by using a "space's main MUC". That would allow for both optimising presence traffic and enforcing consistency between the various rooms of a space. This, of course, would require some additional server and client support, but it looks like we can do something that is relatively usable on any MUC-supporting client. I think it is best to have this in a separate XEP, for future-proofness, since GC3 is just around the corner. ;o) Let me know what you think. -- nicoco

4 9

XMPP Council Agenda 2025-09-16
by Daniel Gultsch 16 Sep '25

16 Sep '25

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, September 16 2025 at 15:30 UTC in xmpp:council@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update • UPDATED: XEP-0503 (Server-side spaces) https://xmpp.org/extensions/xep-0503.html 4) Items for voting a) XEP-0060 / XEP-0248: Improve separation of 'collections' https://github.com/xsf/xeps/pull/1455 b) XEP-0060 & XEP-0248: Default node-type specific configuration https://github.com/xsf/xeps/pull/1460 c) XEP-0070: extend security section https://github.com/xsf/xeps/pull/1453 d) Issue Last Call on 'XEP-0440: SASL Channel-Binding Type Capability' https://xmpp.org/extensions/xep-0440.html 5) Pending votes none See the spreadsheet of doom: https://docs.google.com/spreadsheets/d/1oAHUqBdlkobDcmfQ-YRMfZHGQLMWEdOFuEU… 6) Date of Next 7) AOB 8) Close

1 0

UPDATED: XEP-0503 (Server-side spaces)
by Daniel Gultsch 16 Sep '25

16 Sep '25

Version 0.2.0 of XEP-0503 (Server-side spaces) has been released. Abstract: This document defines an XMPP protocol to cluster several groupchat rooms together. Changelog: Rewrite using pubsub semantics. (nc) URL: https://xmpp.org/extensions/xep-0503.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

Fwd: XEP-0376 (Pubsub Account Management): some feedbacks
by Goffi 13 Sep '25

13 Sep '25

Hello, I'm forwarding this old message, as it has never been answered, and the author (namely Dwd) is more active these days. PAM is very useful in Pubsub toolbox, and I would like to see this specification in a better state :). Thanks! Goffi ---------- Message transmis ---------- Objet : [Standards] XEP-0376 (Pubsub Account Management): some feedbacks Date : vendredi 15 avril 2022, 10:41:49 heure d’été d’Europe centrale De : Goffi <goffi(a)goffi.org> À : standards(a)xmpp.org Hi, I'm currently implementing XEP-0376 both client and service side, and here are my feedbacks. # Form: - a small typo in example 1, it's "xmlns" ("s" is missing) - § 3.3 Unsubscribing: even if it's obvious, an explicit example would be welcome for unsubscribe too - there are a lot of questions on this XEP, I'm not sure if it's the best location for that, IMHO discussing this on standard@ would be more appropriate. - § 5 XMPP Registrar Considerations: even if it made me smile a bit, I don't think that XEP (beside humourous ones) is a location for this kind of jokes. It's not a big deal for experimental XEPs though. # Substance: * § 3.5 auto-subscriptions and § 3.6 Filtering I don't really understand the sentence "this implies that servers would gradually acrue any node type which the user has had a capable client at any time.". Could you formulate it more clearly or at least explain it? Regarding auto-subscription, XEP-0060 is not great itself about it as it's mentioning "root collections" and "subsciption_depth" which are notions of XEP-0248 (and I don't think that there are many complete implementations of it, if any). But that's a topic which should be discussed on a different thread. That put aside, I'm not sure that XEP-0376 should take care at all of auto- subscription regarding that we have already the filtering with +notify. This is done on a per-client basis, and if client wants to get says OMEMO public keys or user mood because it supports those features, I don't see the need to keep track of it at the server level. Sure it's broadcast. To my experience this is not a problem: I use +notify to auto-subscribe when I want update from all users to which I'm presence subscribed, and if I want only events for a specific user/node, I use an explicit subscription (in which case PAM is useful). Thus I would remove entirely § 3.5 and § 3.6, or replace them by a text indicating that PAM service ignores them and they work as usual with XEP-0060/ XEP-0163 auto-subscription and filtering. This would make the whole thing simpler, but please explain me with a clear use-case if I'm missing something. * § 3.7 interaction with MAM I guess events should be archived normally by MAM (at least to be sure that all clients receive them correctly), and I really don't see the need to filter them out (that's only events about explicit (un)subscription to nodes, the traffic should not be high). [this par below is forwarded from a follow-up email] > * § 3.7 interaction with MAM > > I guess events should be archived normally by MAM (at least to be sure that all clients receive them correctly), and I really don't see the need to filter them out (that's only events about explicit (un)subscription to nodes, the traffic should not be high). Second thought: are you talking about the (un)subscribe notification as explained at § 3.2, or XEP-0060 items events? In the later case yes, filtering is probably desirable: if my client doesn't handle blogging, it probably doesn't want all the XEP-0277 items notifications. That's it for now. It's a useful addition to pubsub in XMPP, and I hope to see more implementation in close future. Cheers Goffi

3 2

XSF membership application period Q4 2025
by Alexander Gnauck 08 Sep '25

08 Sep '25

I have setup the XSF membership application Wiki page for the application period Q4-2025 Applications are encouraged from developers and others who are involved in the Jabber/XMPP community. To apply, create a page about yourself on the Wiki here: https://wiki.xmpp.org/web/Membership_Applications_Q4_2025 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

A URI of XEP-0248: PubSub Collection Nodes
by Schimon Jehudah 02 Sep '25

02 Sep '25

Good afternoon. I am interested to know of a valid URI for XEP-0248. Would this be a valid URI? xmpp:comments.hostname?;node=node_collection/node_leaf;item=item_id Kind regards, Schimon

1 0

XLink as a mean to refer to PEP or Pubsub moderator
by Schimon Jehudah 01 Sep '25

01 Sep '25

Good day. Previously, we have discussed about comments node over PEP. https://xmpp.org/extensions/xep-0277.html#comment_add > Note: A comments node SHOULD be located at a generic > publish-subscribe node that is not attached to a user's IM account, > but MAY be located at a personal eventing (PEP) node. While PEP nodes are only accessible to the account owner, it is desired to have people to post items to PEP comments node. I would advise to utilize XLink as a mean of references to moderators and by that, it would be possible to create a uniform comment moderation mechanism for posting comments of Atom Over XMPP (XEP-0277 and XEP-0472). https://www.w3.org/TR/xlink11/ Kind regards, Schimon

1 0

XLink as a mean to relate forwarded messages
by Schimon Jehudah 01 Sep '25

01 Sep '25

Good day. Ladies and Gentlemen. I am exploring the specification XLL (XLink). XLink (XML Linking Language) allows to define links within an XML document; It provides a standard way for specifying relationships between resources, such as documents or elements in those documents; and This can be helpful when working with large and complex data sets, where maintaining connections between different parts becomes crucial. An excerpt from an article of Mr. Hank Simon. > XLink, a language that dramatically extends the capabilities of > linking documents well beyond the abilities of mere HTML internet > pages. > XLink enables bidirectional linking, multiway linking, and > out-of-line linking. Bidirectional linking is simply the idea of > visiting an internet page and returning to the starting point by > clicking on the same link again. Multiway linking is the > implementation of Web rings by using XLink. I was wondering whether XLink could be utilized for forwarded messages and perhaps for other purposes or situations that may require more elaborated solutions such as bidirectional linking. Kind regards, Schimon

1 0

Re: [Board] Board meeting info + voting
by Florian Schmaus 29 Aug '25

29 Aug '25

[CC'ing standards@, as I'd like to engage the community regarding our usage of Github] On 07/08/2025 18.50, E.M. wrote: > Dear all, > > hereby I will post on today's Board Meeting. Ref: https://wiki.xmpp.org/ > web/Board-Meeting-2025 > > We have a two items to vote for, too. Please clearly indicate how (+1, > 0, -1) and on what you are voting (topic). > > Furthermore, we are proposing to have another Board meeting in one week at > Thursday, 14 Aug 2025 > Time: 16:00 UTC / 18:00 CEST > (Can anyone update the calendar if we agree here?) > > Please comment if there are any other topics or input on the items. > > Cheers, > Eddie > _______________________________________________________________________ > > * XEP-0001 and 0143 changes need approval from Board > ** Call to provide you input to the changes and place a comment or review. > Link 1: https://github.com/xsf/xeps/pull/1412 This contains some good changes, like the advise to read, understand, and agree to our IPR. However, I find the the strong emphasis on Github PRs very problematic. Especially the part where we tell people that if they don't have a github account and are not willing to sign up for one, they should find someone who has one. The XSF should not require the usage of a propriety service for contributions. On the other side, I do acknowledge that using a CI-based system for contributions has its advantage. Therefore, a change which mentions that we also accept contributions via Github, outlining the existence of a CI there, would be acceptable to me. But it is my strong believe that we should always accept contributions via mail. Therefore -1, as is. On a side note: We may also want to point out that it is possible to validate changes locally. And we probably should look into codeforge alternatives. But that is outside of the scope of this PR. > Link 2: https://github.com/xsf/xeps/pull/1407 +1, thanks for writing this. > Link 3: ? Do we have this link by now? > * Update on Fiscal Hosting > ** Background: The platform we have been using for fiscal hosting is to > begin moving to a new pricing structure in January, and this affects us. > Details: https://pricing-2026.opencollective.com/ > *** Votes: The XSF Board votes to close the fiscal hosting offering via > Open Collective without replacement and asks the community to suggest > alternatives instead of publishing a survey. +1, as per Matt's analysis, opencollective seems to be to expensive for us. > * Confusion in protocol name (XMTP) > ** Background: See Board mailing list > ** Comment: We don't see that we can do much about it, as XMPP is not a > trademark and they are already aware. I think there is not much we can do after the fact. > * Propose Gonzalo Nemmi (gnemmi) to become member of the XSF CommTeam > ** Background: Gonzalo is publishing and providing great efforts along > the team and work well with the XSF and Community. This deserves > recognition. > ** Votes: The XSF Board votes that if Gonzalo Nemmi (gnemmi) will be > accepted as XSF member, I don't think Board is the right body to approve new members. > that Gonzalo Nemmi (gnemmi) can join the XSF > CommTeam. +1, assuming they fulfill the prerequisites (e.g., being an XSF member). > ** Comment: Jcbrand will be unlisted after not responding but is always > welcome to support and comeback. Thanks for your work JC! - Flow

13 34

PEP - An open and public node
by Schimon Jehudah 29 Aug '25

29 Aug '25

Good day. I realize that PEP is a form of PubSub for accounts. I do want to know whether it is feasible for an account to create a PEP node which other accounts can post items to it. Please advise. Kind regards, Schimon

2 2