- Standards

XSF membership application period Q2 2025
by Alexander Gnauck 12 Mar '25

12 Mar '25

I have setup the membership application Wiki page for the application period Q2 2025 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_Q2_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 Apply now!!! Thanks, Alex

1 0

NEW: XEP-0503 (Server-side spaces)
by Daniel Gultsch 11 Mar '25

11 Mar '25

Version 0.1.0 of XEP-0503 (Server-side spaces) has been released. Abstract: This document defines an XMPP protocol to cluster several groupchat rooms together. Changelog: Promoted to Experimental (XEP Editor: dg) 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

Proposed XMPP Extension: Server-side spaces
by Daniel Gultsch 05 Mar '25

05 Mar '25

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Server-side spaces Abstract: This document defines an XMPP protocol to cluster several groupchat rooms together. URL: https://xmpp.org/extensions/inbox/spaces.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

3 3

XMPP Council Agenda 2025-02-25
by Daniel Gultsch 25 Feb '25

25 Feb '25

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, February 25 2025 at 16:30 UTC in xmpp:council@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update * Proposed XMPP Extension: Server-side spaces https://xmpp.org/extensions/inbox/spaces.html 4) Items for voting a) Proposed XMPP Extension: Server-side spaces https://xmpp.org/extensions/inbox/spaces.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

Splitting XEP-0455 (Service Outage Status)
by Mathieu Pasquet 06 Feb '25

06 Feb '25

Hi everyone, I have been thinking lately about updating XEP-0455 (and getting around to implementing it), and I find the initial semantics that I came up with a bit murky. My plan now is to remove the in-band events and outage planning entirely, to only keep the signaling part (using 0128) and the json format to describe an ongoing outage. I would also update the wording to say that a client should fetch the external address only if it does not manage to connect to the server. This way, the XEP will do one thing and do it quite efficiently, and the in-band events and planning can go into another XEP without being constrained by the requirements for (complete and ongoing) outages from 0455. Writing this to the list to collect some thoughts on the matter, or if anyone would be more interested in implementing this reduced version. Cheers, mathieui

1 0

XEP-0377: New option for Spam Reporting
by Guus der Kinderen 05 Feb '25

05 Feb '25

Hello, XEP-0377 describes a mechanism to report spam or abusive content to the local domain. While implementing the server-sided part of this, I was trying to think of useful processes that could follow a report. Some of those actions could include sharing the report with third parties, such as the origin server of the spam, or a centralized spam-related collection service (like xmppbl). There is a privacy aspect to this. An end-user that flags a particular message or entity might not realize or even appreciate that their report is being forwarded to others than the local domain. I suggest having an additional field added to the data structure that is already defined in the XEP. This field is used by the reporter to signal if they agree to share the report with third parties. Clients could present this option as a checkbox that reads something like "Allow this report to be shared with relevant third parties" (or better words). Kind regards, Guus

1 1

XEP-0484: Fast Authentication Streamlining Tokens and TLS Early Data example
by Michael Uvarov 04 Feb '25

04 Feb '25

Hi, I cannot figure out how to use early data in XEP-0484. Main question, which part does go into the early data? <authenticate/> stanza? And how does it combine with XML stream start? How does the server should reply and when? It would be nice to have the complete example for successful auth, including indication of what goes into early data and what does not. Maybe people who already implemented early data in XEP-0484 could comment. https://xmpp.org/extensions/xep-0484.html

2 2

UPDATED: XEP-0474 (SASL SCRAM Downgrade Protection)
by Daniel Gultsch 25 Jan '25

25 Jan '25

Version 0.4.0 of XEP-0474 (SASL SCRAM Downgrade Protection) has been released. Abstract: This specification provides a way to secure the SASL and SASL2 handshakes against method and channel-binding downgrades. Changelog: * Use better value delimiter (tm) URL: https://xmpp.org/extensions/xep-0474.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

UPDATED: XEP-0424 (Message Retraction)
by Daniel Gultsch 25 Jan '25

25 Jan '25

Version 0.4.2 of XEP-0424 (Message Retraction) has been released. Abstract: This specification defines a method for indicating that a message should be retracted. Changelog: * Use a XEP-0425 /me command in the fallback body * State that a tombstone's <retracted/> element's 'id' attribute should match the retraction message's 'id'. * Specify XEP-0359 as a dependency and require that the stanza 'id' be used instead of the origin-id. * Update the "Security Considerations" to mention the risk of non- unique message IDs. (jcb) URL: https://xmpp.org/extensions/xep-0424.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

Proposed XMPP Extension: Gateway Relayed Encryption
by Daniel Gultsch 20 Jan '25

20 Jan '25

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Gateway Relayed Encryption Abstract: This specification describes a mechanism for end-to-end encryption with gateways that is compatible with third-party networks. URL: https://xmpp.org/extensions/inbox/gateway-relayed-encryption.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

5 10