- Standards

by Daniel Gultsch

Version 0.3.0 of XEP-0317 (Hats) has been released. Abstract: This specification defines a more extensible model for roles and affiliations in Multi-User Chat rooms. Changelog: Add hat creation and detruction flows; add hue optional parameter; add chatroom presence hats broadcast; complete disco#info; clarify how the service should broadcast updated hats; typos; standardize the form fields; (tj) URL: https://xmpp.org/extensions/xep-0317.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.

6 months

1
0
0 0

UPDATED: XEP-0198 (Stream Management)

by Daniel Gultsch

Version 1.6.3 of XEP-0198 (Stream Management) has been released. Abstract: This specification defines an XMPP protocol extension for active management of an XML stream between two XMPP entities, including features for stanza acknowledgements and stream resumption. Changelog: Remove leftover <optional/> and <required/> children in <sm/> element. (egp) URL: https://xmpp.org/extensions/xep-0198.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.

6 months

1
0
0 0

Re: Receiving a pong signal from an offline JID

by Peter Waher

Hello Schimon (etl al) > I am working on a news service for XMPP, which sends messages according > to status. > > When JID is offline, service should stop. Sounds like you would benefit from using PEP (XEP-0163) which accomplishes this. The publisher publishes a PEP event with its new service namespace, and only online entities with a presence subscription, and a corresponding service-detectable feature requesting PEP events with the corresponding news namespace, will receive the event. In this case, there's no need for the service to manually check subscribers and their current online presence. Best regards, Peter Waher

6 months, 1 week

2
2
0 0

Receiving a pong signal from an offline JID

by Schimon Jehudah

Good day. I am working on a news service for XMPP, which sends messages according to status. When JID is offline, service should stop. Resources --------- As XMPP is presence oriented, it is needed to set extra measures, such as collecting detected resources, in order to be certain that a subject JID is indeed offline. This measure is still tested. Signals ------- I am experimenting with XEP-0199: XMPP Ping as a possible mean to confirm that an account is offline. However, while asking for a pong signal from a full JID (JID with a resource) returns an empty respond, asking for a pong signal appear to always to work when querying a bare JID (JID without a resource). PONG: sch(a)pimux.de/gajim.TN7Y65AS None PONG: sch(a)pimux.de 0.09115195274353027 PONG: sch(a)pimux.de/gajim.TN7Y65AS None PONG: sch(a)pimux.de 0.10207772254943848 My expectation was to have no respond for bare JID, when there is no connected instance to a given JID. Please advise. Kind reagrds, Schimon

6 months, 1 week

2
2
0 0

Reconsider XEP-0146: Remote Controlling Clients

by Schimon Jehudah

Good day. I would want to ask the XSF members to reconsider XEP-0146 for a couple of reasons. * To educate and inform people of Ad-Hoc Commands, a feature which is exclusive to XMPP. * To control other clients when special situationn arises. For several days I have a connected XMPP client instance from my Movim instance which indicates that my JID is available, even though I deem that it should be offline. https://xmpp.org/extensions/xep-0146.xml XEP-0146: Remote Controlling Clients Kind regards, Schimon

6 months, 1 week

1
0
0 0

Client Presence Probes

by Schimon Jehudah

Good day. Question ======== Is it possible for XMPP clients to actively probe for presence? JabberCard ========== I have created JabberCard, an HTML invitation page for XMPP. https://git.xmpp-it.net/sch/JabberCard https://git.0ut0f.space/doesnm/JabberCard JabberCard is based on the module Slixmpp and is an XMPPP client. Idea ==== Months ago, I was advised to add support for status, mood, and activity. I think that it is a good idea. Presence ======== However, it appears that actively probing for presence by XMPPP clients is not specified in the standard. According to the standard, only servers handle that task. 4.3. Presence Probes > Presence probes SHOULD NOT be sent by a client, because in general a > client will not need to send them since the task of gathering > presence from a user's contacts is managed by the user's server. > However, if a user's client generates an outbound presence probe then > the user's server SHOULD route the probe (if the contact is at > another server) or process the probe (if the contact is at the same > server) and MUST NOT use its receipt of the presence probe from a > connected client as the sole cause for returning a stanza or stream > error to the client. https://xmpp.org/rfcs/rfc6121.html#presence-probe Is it possible for XMPP clients to actively probe for presence? Please advise. Kind regards, Schimon

6 months, 1 week

2
2
0 0

Best practice to classify JID type

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

6 months, 2 weeks

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

6 months, 3 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.

6 months, 3 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

6 months, 3 weeks

1
0
0 0

2026

2025

2024

2023

Standards