- Standards

XEP-0001 Changes to reflect current practice wrt XEP Authors

by Dave Cridland

Hey hey, Boring incoming: https://github.com/xsf/xeps/pull/1407 This is draft to avoid the XSF Board accidentally approving it before the community has had a chance to discuss. The main change is the paragraph added in Section 6 (Discussion Process), covering changes to the XEP during Experimental: The XEP author incorporates the feedback by creating source control patches > (such as Pull Requests), in line with the preferred method in &xep0143;. > Direct changes to an Experimental XEP, such as a contributor providing a > patch (or Pull Request on GitHub), are still the responsibility of the XEP > author, and are only applied if the XEP author agrees. If a XEP has > multiple authors, while agreement is sought from all authors, only those > opinions from responsive authors are considered. If the Approving Body > feels that the XEP author is not responsive, another author may be added > unilaterally by the Approving Body. This is trying to do two things: 1) Document the existing practice that the XMPP Council has followed, whereby changes to Experimental XEPs need "agreement" (PR approval, or similar) from the XEP Author. 2) Document the existing practice that the XMPP Council has followed. whereby if a XEP Author isn't responsive (ie, doesn't respond to emails, etc) the XMPP Council can add a new XEP Author. 3) Document the *new practice* that if a contribution isn't a PR, it's the XEP Author who is responsible to turn it into one. The rest of the changes surface and restate existing process/policy/URLs and aren't that interesting (well, even less interesting). There is one additional possible process deviation we should document (or call the Process Police out, or something). Submission of a XEP, as per XEP-0143, occurs via email tot he Editor. Is this really still the case? Or are these now by PR? That'll need changing in XEP-0143, which I'm happy to do if that's the case. It'd be nice to have a non-PR variant of the process (post here?) Dave.

7 months, 1 week

6
16
0 0

NEW: XEP-0502 (MUC Activity Indicator)

by Daniel Gultsch

Version 0.1.0 of XEP-0502 (MUC Activity Indicator) has been released. Abstract: This specification provides querying entities an approximate indication of the level of activity in a given XEP-0045 Multi-User Chat room. Changelog: Promoted to Experimental (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0502.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.

7 months, 1 week

1
0
0 0

UPDATED: XEP-0501 (Pubsub Stories)

by Daniel Gultsch

Version 0.2.0 of XEP-0501 (Pubsub Stories) has been released. Abstract: This specification defines a way of publishing Stories over XMPP. Changelog: Add pubsub#item_expire in the node configuration (tj) URL: https://xmpp.org/extensions/xep-0501.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.

7 months, 1 week

1
0
0 0

XSF membership application period Q1 2025

by Alexander Gnauck

I have setup the membership application Wiki page for the application period Q1 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_Q1_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

7 months, 1 week

1
0
0 0

NEW: XEP-0501 (Pubsub Stories)

by Daniel Gultsch

Version 0.1.0 of XEP-0501 (Pubsub Stories) has been released. Abstract: This specification defines a way of publishing Stories over XMPP. Changelog: Promoted to Experimental (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0501.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.

7 months, 1 week

1
0
0 0

Proposed XMPP Extension: Pubsub Stories

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Pubsub Stories Abstract: This specification defines a way of publishing Stories over XMPP. URL: https://xmpp.org/extensions/inbox/stories.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

7 months, 1 week

4
6
0 0

XMPP Council Agenda 2024-12-17

by Daniel Gultsch

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, December 17 2024 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: Pubsub Stories * UPDATED: XEP-0500 (MUC Slow Mode) * LAST CALL: XEP-0421 (Anonymous unique occupant identifiers for MUCs) 4) Items for voting a) Proposed XMPP Extension: Pubsub Stories https://xmpp.org/extensions/inbox/stories.html b) Issue Last Call on 'XEP-0424: Message Retraction' https://xmpp.org/extensions/xep-0424.html c) Issue Last Call on 'XEP-0425: Moderated Message Retraction' https://xmpp.org/extensions/xep-0425.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

7 months, 2 weeks

1
0
0 0

UPDATED: XEP-0500 (MUC Slow Mode)

by Daniel Gultsch

Version 0.1.1 of XEP-0500 (MUC Slow Mode) has been released. Abstract: This specification describes a way to rate limit messages a single user can send to a MUC room. It includes room configuration option, and how servers and clients can handle such a feature. Changelog: Include first feedbacks (jl) URL: https://xmpp.org/extensions/xep-0500.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.

7 months, 2 weeks

1
0
0 0

Proposed XMPP Extension: MUC Slow Mode

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: MUC Slow Mode Abstract: This specification describes a way to rate limit messages a single user can send to a MUC room. It includes room configuration option, and how servers and clients can handle such a feature. URL: https://xmpp.org/extensions/inbox/xep-slow-mode.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

7 months, 2 weeks

6
12
0 0

XEP-0163 (Personal Eventing Protocol) Allow multiple publishers; XEP-0045 (Multi-User Chat) Allow PEP

by Schimon Jehudah

Good day! I am the developer of Slixfeed news bot, which is a syndication feed reader (Atom/RDF/RSS). This matter is also related to Morbot. See https://codeberg.org/TheCoffeMaker/Morbot/issues/13 Concern ------- I have to attempted experiment with PEP nodes, and my attempt has failed due to: XEP-0045 service-unavailable The feature requested is not supported by the conference XEP-0163 forbidden You're not allowed to create nodes Proposal -------- I suggest to enable PEP nodes for MUC JIDs too. I suggest to change the approach "One publisher per node.". See https://xmpp.org/extensions/xep-0163.html#approach-publisher > There is no need for multiple publishers to a PEP service, since by > definition the service generates information associated with only one > entity. The owner-publisher for every node is the bare JID of the > account owner. In order to allow a secondary "channel" interface for people and group chats, and also for other reasons (see further), it would be useful to: 1) Allow multiple publishers. 2) Allow PEP for MUC JIDs. By a "channel" interface, I mean, that should a news bot be included for a group chat, the updates would be sent to a PEP node of the group chat JID instead to the chat itself, which would keep the chat view cleaner. Example use cases: Number #3 represents the use of Morbot and Slixfeed, and is useful for forwarding of news journals. 1) Use : Inbox Affiliation : Publish-Only Publishers : JIDs which Presence is shared with or in Roster 2) Use : Collaboration (e.g. Pad, Whiteboard etc.) Affiliation : Publisher Publishers : Determined manually 3) Use : Updates Affiliation : Publish-Only Publishers : Determined manually Note ---- Slixfeed can use its own PEP nodes named after its subscribers respectively, albeit that would be more demanding on the server of which Slixfeed is operated on, than publishing to PEP nodes of other JIDs, and yet it would not be practical for group chat JIDs, which the bot also supports. Please advise. Kind regards, Schimon

7 months, 3 weeks

4
13
0 0

2025

2024

2023

Standards ----- 2025 ----- July 2025 June 2025 May 2025 April 2025 March 2025 February 2025 January 2025 ----- 2024 ----- December 2024 November 2024 October 2024 September 2024 August 2024 July 2024 June 2024 May 2024 April 2024 March 2024 February 2024 January 2024 ----- 2023 ----- December 2023

Standards