- Standards

by Schimon Jehudah

Good day. I have a question concerning to preferable practice in JID recognition. Preface ------- I am working on an XMPP service (i.e. "bot") for both private and group chat. I utilize Slixmpp for that task. Slixmpp ------- Slixmpp has a "reply" function which automatically classifies the task, due to information which is attached to IQ Stanza. Concern ------- However, when the service actively sends schedule messages, it needs to classify the given JID to which it sends a message. Database -------- I have recently decided to classify subscribers of the service inside a database, which also has fields of Private, MIX, and MUC. Disco ----- I was wondering whether should query JID addresses using "disco" (i.e. XEP-0030: Service Discovery), or should I utilize the database? Utilizing "disco" is prone to errors (e.g. when server blocks another server - displaying "recepient-unavailable" - yet contacts can still communicate). Conclusion ---------- Please advise. Kind regards, Schimon

4 months, 1 week

2
2
0 0

A minimal XMPP server

by Schimon Jehudah

Greetings. Because there are lightweight implementations of IRC servers, there are various of video games that utilize IRC as a mean to converse. I do think, that a basic, and modular, XMPP server would be an interesting choice to various of video games, from action games to simulators, including FreeSO. This, of course, would expand the user-base of XMPP, and would allow to anyone to participate in discussions with people who are playing a game, without the need to have that game installed. A father plays a video game with his sons at his house, then he goes with his daughter to a piano lesson; the father can still communicate with his kids, whereas the kids would be able to continue to communicate directly via the video game while playing it. What do you think? Kind regards, Schimon

4 months, 2 weeks

1
0
0 0

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.

4 months, 2 weeks

6
17
0 0

XMPP Council Agenda 2025-08-05

by Daniel Gultsch

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, August 5 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 none 4) Items for voting a) XEP-0198: Remove leftover optional and required children in sm element https://github.com/xsf/xeps/pull/1447 b) XEP-0167: Make ssrc attribute unsignedInt instead of generic string https://github.com/xsf/xeps/pull/1446 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

4 months, 2 weeks

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

4 months, 4 weeks

1
1
0 0

hey

by who knows

hello world

5 months, 1 week

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

5 months, 1 week

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.

5 months, 1 week

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.

5 months, 2 weeks

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.

5 months, 2 weeks

1
0
0 0

2025

2024

2023

Standards