- Standards

by Daniel Gultsch

Version 1.2.0 of XEP-0363 (HTTP File Upload) has been released. Abstract: This specification defines a protocol to request permissions from another entity to upload a file to a specific path on an HTTP server and at the same time receive a URL from which that file can later be downloaded again. Changelog: * Add optional upload purpose when requesting slots (dg) URL: https://xmpp.org/extensions/xep-0363.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 year, 2 months

1
0
0 0

UPDATED: XEP-0080 (User Location)

by Daniel Gultsch

Version 1.10.0 of XEP-0080 (User Location) has been released. Abstract: This specification defines an XMPP protocol extension for communicating information about the current geographical or physical location of an entity. Changelog: Added <regioncode/> element. (jp) URL: https://xmpp.org/extensions/xep-0080.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 year, 2 months

1
0
0 0

XEP XML documents to be structured as Atom Syndication Format

by Schimon Jehudah

Good day. I was wondering of formatting the XML documents for XEPs to Atom Syndication Format. This would allow people to subscribe to selected XEPs and to receive automatic updates. The XHTML pages would remain the same, as they are today, once the XSLT stylesheet be adapted to the new Atom format. This is a recent realization which I have had, during drafting a new publishing system in which each page, be made of Atom Syndication Format, including fixed pages such as "about", "contact", and "help", with an exception for an OPML page. gemini://woodpeckersnest.space/~schapps/journal/2025-07-03-rivista-to-be-atom-based-publishing-system.gmi https://portal.mozz.us/gemini/woodpeckersnest.space/~schapps/journal/2025-0… Please advise. Kind regards, Schimon

1 year, 2 months

1
0
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.

1 year, 2 months

4
11
0 0

XEP-0388 user-agent notes

by Dave Cridland

Hi all, I'm currently implementing SASL2 (et al) into Openfire, which is amusing since I had the first implementation there years ago. In doing so, I've a few comments, most of which are directed at past-me of course. Past-me is an idiot, and I have ample evidence of this. 1) One of the changes from the original SASL profile is that there's no need for (and mention of) the "equals hack" to indicate no data. Should this be explicitly called out? 2) The user-agent - this is a SHOULD (well, RECOMMENDED, which means the same thing). The consequences of not including it are that other specifications might rely on it - the same as the id, which is also SHOULD. I dislike the amount of SHOULD here, it feels like the "outer" SHOULD is sufficient, and a user-agent with no id attribute is a bit useless. 3) The id string given MUST be a UUIDv4. What should the server do if it receives a non-UUID, or a UUID of a different type to v4? A purist might reject it, but this seems wrong - what guidance can we put here? If we accept any old string, and it's not a UUIDv4, what happens? 4) Second para of Initiation talks about an authorization string, but there's no such string defined. Was this intended to mean the requested authorization identity in the SASL mechanism? That's an interesting challenge, especially from just the initial-response which might not be present. I think I follow the intent here, but the detail seems off. Dave.

1 year, 2 months

1
0
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.

1 year, 2 months

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

1 year, 2 months

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.

1 year, 2 months

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

1 year, 2 months

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

1 year, 2 months

1
0
0 0

2026

2025

2024

2023

Standards