June 2025 - 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.

1 month, 1 week

6
17
0 0

Situation of DOAP

by Schimon Jehudah

Good evening. I am working on a Python script which generates an Atom Syndication Format XML feed from XMPP DOAP files. I will further add to it an XSLT stylesheet to transform it to XHTML. I have attached that script, for those who are inqusitive about it. Problems -------- However, I did notice, that some DOAP files are not updated, and some are missing information. Proposal -------- I would suggest to add attributes for types of links (i.e. Gemini, HTTP, PubSub, etc.), because in near future, resources such as homepage, bug-database, developer-forum, developer-support, etc. will be hosted on PubSub services over XMPP, instead of HTTP. Question -------- Is there an automated DOAP generator software or service? Conclusion ---------- If there is no automated service yet, then I would create an XHTML software with forms that would do so. Afterwards, I would also create an XMPP service with Data Forms for that purpose. Please advise. Kindly, Schimon

1 month, 2 weeks

1
1
0 0

Proposed XMPP Extension: Data Policy

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Data Policy Abstract: This document specifies metadata on how an entity handles its data (encryption, data retention, etc). URL: https://xmpp.org/extensions/inbox/data_policy.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

2 months, 1 week

4
11
0 0

Proposed XMPP Extension: Data Forms File Input Element

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Data Forms File Input Element Abstract: This specification defines an element which can be used with data forms to let users upload one or more files. URL: https://xmpp.org/extensions/inbox/data-form-file-element.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

2 months, 1 week

3
2
0 0

XEP-0317: Hats, Update and complete the protocol

by Timothée Jaussoin

A few weeks ago I made an important pull request to complete, fix and update the XEP-0317: Hats. https://github.com/xsf/xeps/pull/1437 This PR included the following changes: * Specify a urn:xmpp:hats:commands:dcreate command to add a hat to the available list * Specify a urn:xmpp:hats:commands:ddestroy command to destroy a hat from the list * Clarify how the service should broadcast the hat changes when it is edited, assigned, removed or destroyed * Specify a way for an entity to get the complete list of hats using a hash in disco#info * Add a hue optional parameter allowing entities to assign a color to the hat that can be displayed properly in any conditions on the client (as explained in XEP-0392: Consistent Color Generation) * Standardize all the form fields using XEP-0068 * Fix some typos I tried to reach the authors without success so I'm trying again using the mailing list. I'd really like to move it forward then we can start implementing them in our clients and servers. Regards, edhelas

2 months, 1 week

3
4
0 0

XEP-0461 feedback: multi-message replies

by Greatsword

I've seen some IM platforms (namely Revolt and Guilded) have the ability to let the user reference multiple messages in a single reply, which might be a useful feature. I think with the XEP as it currently is, it could be fairly simple to add support for this feature. I think an addition like this would be good. """ Section 3.2 - Multi-Message Replies A user may want to reply to multiple messages with a single message. This can be done by including many reply elements. Ordering is important, so the reply element MUST include an "arrangement" attribute that counts up from 0, with 0 being displayed at the top in the client UI. EXAMPLE 5. Yuri replies to both Max's and Anna's messages in a MUC. ``` <message to='knightsguild(a)muc.example.org' from='knightsguild(a)muc.example.org/anna' id='groupchat-id1' type='groupchat'> <stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id1' /> <body>A fort will keep us safe!</body> </message> <message to='knightsguild(a)muc.example.org' from='knightsguild(a)muc.example.org/max' id='groupchat-id2' type='groupchat'> <stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id2' /> <body>Adoring blue flags for style!</body> </message> <message to='knightsguild(a)muc.example.org' from='knightsguild(a)muc.example.org/yuri' id='groupchat-id3' type='groupchat'> <stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id3' /> <body>Excellent ideas! Let's get right to it!</body> <reply to='knightsguild(a)muc.example.org/anna' id='groupchat-id1' arrangement='0' xmlns='urn:xmpp:reply:0' /><reply to='knightsguild(a)muc.example.org/max' id='groupchat-id2' arrangement='1' xmlns='urn:xmpp:reply:0' /> </message> ``` A fallback for this would work in the same way as the previous section, the main difference is that the fallback would include all referenced messages. """ I think it also might be worth considering having some kind of limiter in how many messages can be referenced by one reply - perhaps MUCs that advertise support for replies could indicate in a data form how many references may be one message, and if clients don't self-enforce this, then the MUC could throw a policy violation error and drop the message.

2 months, 1 week

4
8
0 0

Enhancing privacy for BoB messages (XEP-0231)

by Schimon Jehudah

Good day. I would want to discuss the possibility and best practice of creating server-side modules that would copy BoB data (XEP-0231: Bits of Binary) to own server in order to avoid exposure of IP address of the receiver. Kind regards, Schimon

2 months, 2 weeks

6
11
0 0

XMPP Council Agenda 2025-06-24

by Daniel Gultsch

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, June 24 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-0284 (Shared XML Editing) https://xmpp.org/extensions/xep-0284.html 4) Items for voting a) XEP-0363: specify purpose/buckets when requesting slots https://github.com/xsf/xeps/pull/1445 5) Pending votes - Dan on everything from last week - Daniel on 'Proposed XMPP Extension: Data Forms File Input Element' - Goffi, technically on 'XEP-0388: Fix failure example sequence' but has been vetoed already in favor of "Should Daniel just fix the schema" See the spreadsheet of doom: https://docs.google.com/spreadsheets/d/1oAHUqBdlkobDcmfQ-YRMfZHGQLMWEdOFuEU… 6) Date of Next 7) AOB 8) Close

2 months, 2 weeks

1
0
0 0

UPDATED: XEP-0284 (Shared XML Editing)

by Daniel Gultsch

Version 0.1.4 of XEP-0284 (Shared XML Editing) has been released. Abstract: This specification defines a protocol that enables two or more endpoints to collaboratively edit an XML object. The protocol is intended for use mainly over the Extensible Messaging and Presence Protocol (XMPP), either by existing instant messaging clients or by specialized editing clients. However, the protocol could also be used over a direct TCP connection rather than over XMPP. Changelog: * Fix the registrar section. * Format the glossary better. * Add missing <state/> wrappers in examples. * Write an XML Schema. (egp) URL: https://xmpp.org/extensions/xep-0284.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.

2 months, 2 weeks

1
0
0 0

Selective advertizing of activity and mood (XEP-0107 and XEP-0108)

by Schimon Jehudah

Greetings. Preface ------- I would want to advise to extend XEP-0107 (User Mood) and XEP-0108 (User Activity), so that it would be possible to selectively advertize of activities and moods. This is beneficial for both humans and machines. Because the examples for humans may be vague, I will write an obvious case for machines. Service ------- KaikOut is a moderation service (i.e. "bot", so called) for group chats. As with traffic signs, and unlike status messages, activity and mood are fixated, even though both have an option for custom text, and because of it, they can be used as constant and accurate indicators for activity and state of machines. That is, activities and moods can be used as signs, and also to signal of events. See further examples. Additionally, status messages, activities and moods serve different purposes, which is another reason to have an option of selective advertizing for activity and mood. Example ------- This is a realization of using activities and moods in a selective fashion over different group chats simultaneously. Ideas with XEP-0107: User Mood ------------------------------ amorous: When KaikOut writes good scores. annoyed: When KaikOut writes bad scores. ashamed: When KaikOut demotes a moderator. calm or bored: When group activity is under a certain level. happy or relaxed: When moderation activity is under a certain level. restless: When moderation activity is above a certain level. cautious or serious: Routine mood. remorseful or frustrated or sleepy: When KaikOut is disabled. proud: When KaikOut bans or kicks an occupant. ashamed or shocked: When a group chat owner pormotes a moderator which was demoted by KaikOut. surprised: When KaikOut is demoted. thankful: When KaikOut is set to be a moderator. Ideas with XEP-0108: User Activity ---------------------------------- working: When KaikOut writes scores. sleeping: When KaikOut is inactive. Reference: https://git.xmpp-it.net/sch/KaikOut/issues/36 Kind regards, Schimon

2 months, 3 weeks

2
2
0 0

2025

2024

2023

Standards June 2025