- Standards

hey

by who knows

hello world

1 year, 1 month

1
0
0 0

An XSLT file is missing over xmpp.org

by Schimon Jehudah

Administrators. Good day. Please copy file https://xmpp.org/extensions/xep.xsl to loccation https://xmpp.org/extensions/inbox/xep.xsl or create a link thereof. This is essential for XEPs that are located under /inbox/ directory. Kind regards, Schimon

1 year, 1 month

1
0
0 0

Proposal to modernize and update the CAPTCHA XEP (XEP-0158)

by techmetx11

XEP-0158 has not been updated (in a major way) since late 2008, and ever since then, all of the challenge types can be easily broken with a neural network or ASICs/FPGAs/GPUs (for Hashcash). This makes out-of-band CAPTCHA sites the only feasible method of fending off bots. But requiring a user to visit a site to send a message or join a MUC doesn't make it as seamless for them, Therefore the XEP should be revamped in a way to still provide a seamless experience while also providing security against modern attackers. These are my suggestions in regards to this: 1) Deprecate OCR and recongition-based challenges and switch to more interactive challenges (such as: pointing to parts of a picture that matches a specified condition) 2) Add more Proof-of-Work algorithms and possibly deprecate Hashcash. There should be a requirement for choosing candidate algorithms, we can use Tor's requirements (from Equi-X's design notes) as an example: 1. The solution proof must be smaller than about 200 bytes. 2. Solution verification must be fast. 3. GPUs and FPGAs should not provide a large advantage for solving the puzzle - https://gitlab.torproject.org/tpo/core/tor/-/blob/main/src/ext/equix/devlog… Unfortunately, the second requirement may disqualify Argon2 from being used, due to its symmetry.

1 year, 1 month

1
0
0 0

NEW: XEP-0505 (Data Forms File Input Element)

by Daniel Gultsch

Version 0.1.0 of XEP-0505 (Data Forms File Input Element) has been released. Abstract: This specification defines an element which can be used with data forms to let users upload one or more files. Changelog: Accepted as Experimental by Concil vote on 2025-07-08 (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0505.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, 1 month

1
0
0 0

NEW: XEP-0504 (Data Policy)

by Daniel Gultsch

Version 0.1.0 of XEP-0504 (Data Policy) has been released. Abstract: This document specifies metadata on how an entity handles its data (encryption, data retention, etc). Changelog: Accepted as Experimental by Concil vote on 2025-06-08 (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0504.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, 1 month

1
0
0 0

UPDATED: XEP-0363 (HTTP File Upload)

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

1
0
0 0

2026

2025

2024

2023

Standards