June 2024 - Standards

LAST CALL: XEP-0440 (SASL Channel-Binding Type Capability)
by Daniel Gultsch 24 Oct '25

24 Oct '25

This message constitutes notice of a Last Call for comments on XEP-0440. Title: SASL Channel-Binding Type Capability Abstract: This specification allows servers to annouce their supported SASL channel-binding types to clients. URL: https://xmpp.org/extensions/xep-0440.html This Last Call begins today and shall end at the close of business on 2024-05-20. Please consider the following questions during this Last Call and send your feedback to the standards(a)xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!

9 30

Proposed XMPP Extension: PubSub Server Information
by kevin.smith＠isode.com 08 Jun '25

08 Jun '25

The XMPP Extensions Editor has received a proposal for a new XEP. Title: PubSub Server Information Abstract: This document defines a data format whereby basic information of an XMPP domain can be expressed and exposed over pub-sub. URL: https://xmpp.org/extensions/inbox/pubsub-server-info.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

3 3

Bibliography and PubSub
by Schimon Jehudah 27 Aug '24

27 Aug '24

Greetings XSF! Thanks to Mr. Timothée Jaussoin (alias "edhelas") who is responsible for "XEP-0472: Pubsub Social Feed" I am interested and investigate about developing and utilizing XMPP PubSub. I am working on a couple of XMPP chat bots to which I will integrate support for PubSub. * Slixfeed (integrated) Slixfeed is a news bot of which PubSub support is almost done. It will use of affiliation='publisher' as defined in XEP-0060 to post news items to PubSub nodes https://git.xmpp-it.net/sch/Slixfeed * BukuBot (not yet integrated) BukuBot is a new chat bot which I contemplate on adding PubSub support in order to make link directories sharable, yet I do not think it would be wise to utilize node `urn:xmpp:links:0` for this purpose. Because of this, I would like to discuss of a new XEP which probably would be similar to XEP-0277 and XEP-0472, yet it would be specifically aimed at bibliography management. Such XEP would be utilized to share Book and Scholar citations, URLs (Gemini, Gopher, HTTP, XMPP), and other type of references over XMPP PubSub. I would be thankful for you to help and share your thoughts on this matter. Kind regards, Schimon

3 12

XEP-0439: Quick Responses - Feedback
by Philipp Hörist 18 Jul '24

18 Jul '24

Hi, I looked through the XEP and i find a few things not great. Im not getting the difference between <response> and <action>. And the XEP makes no attempt to describe it. A question that i answer with "Yes" or "No" should be a response, but a Question that i answer with "Merge" is an action? Seems completely random. The XEP mentions no use case that can only be done with <response>, i see no reason at all as a client developer to implement this. Now for <actions>, the id attribute is under specified, it seems essential to the whole thing working at all. Should this be a globally unique ID? Or at least unique per remote JID? In my opinion <action> should have another id attribute (of course differently named) referencing the message it belongs to. We have this pattern with message errors, iq responses, reactions, message replies, moderation, etc., we should not break this pattern here for no gain, just because its theoretically possible to still match this if the id is globally unique. I think this is a really nice idea and feature, but it should fit in with current XEP patterns, and better describe what <response> even should accomplish. Is the original Author still around? I also looking forward to other peoples opinions.

4 9

Extended contacts
by avidseeker7＠protonmail.com 26 Jun '24

26 Jun '24

The current contact implementation is lacking, which causes having lots of fragmentation and duplicates in contacts. Here are some scenarios: * XEP proposal1: meta contacts. A single person John Doe has multiple accounts doe1(a)ex1.com, doe2(a)ex2.com, doe3(a)ex3.com ... It would make more sense to have an "extended contact" or a "meta contact" that combines all of these addresses. * XEP proposal2: once meta contact is implemented, it would be desirable to have a field for a personal note. For example, this is available in Slack and Discord. In 2020 there was an XMPP sprint for "studying Discord and bringing its interesting features" (https://wiki.xmpp.org/web/Sprints/2020_November_Online) and I think this is an interesting and useful feature. * XEP proposal3: better contact integration. The contacts data on XMPP apps of Android is very isolated from the rest of apps. All other messaging apps interact well with the device contacts and phone numbers, except for XMPP because it doesn't use phone numbers as identifiers. But once we have XEP proposal2 and we can add personal notes, we can also add a field for phone numbers for contacts that would make it more interoperable with device contacts that are identified with phone numbers. For these 3 proposals, I was moving point by point to explain the motive behind the next proposal which actually combines all of the three previous points. * XEP proposal4: vCard compatible contacts. The vCard standards solves all three points since it 1) accepts multiple phone numbers and emails, 2) Include note, birthday, company and other miscellaneous fields, and 3) are supported natively by phone contacts. As of vCard v4, it has XML property which "is used if the vCard was encoded in XML (xCard standard) and the XML document contained elements which are not part of the xCard standard." * XEP proposal5: once vCard standard is supported, it would be easy to have XMPP as a WebDav server. Android app like Conversation have access to all contact information and can easily sync contact information with phone contacts. * XEP proposal6: It remains to clarify how XMPP clients deal with contacts that have no XMPP handle. Signal chose the position of not showing them in app at all. WhatApp prepares an SMS to invite them. This might be left to the client, but as a Slidge gateway user, it would be convenient to check phone numbers as a username handle for the current server. E.g: if a phone number is +18884440000, client would check the main gateway servers setup by users +18884440000(a)example.org, +18884440000(a)whatsapp.example.org, and +18884440000(a)telegram.example.org. If non of these exist, then the client can proceed with inviting them to XMPP.. As for the security, a simple disclaimer like: "XMPP found these gateway users but couldn't verify their ownership" should suffice. * XEP proposal7: contact-related features might need revision like XEP-0140 (contact groups), as this is implemented in vCard too.

3 2

Subscription and invites policy
by avidseeker7＠protonmail.com 20 Jun '24

20 Jun '24

When using gateways that create many users (e.g: https://slidge.im) XMPP clients are spammed with subscription and invitation requests. It would be useful for users to set a policy that rejects any incoming request and only manually approve subscriptions and invitations.

1 0

Bookmarks groups
by avidseeker7＠protonmail.com 20 Jun '24

20 Jun '24

XEP-0402 only describes bookmarks as a single category, but it is useful to have different categories within bookmarks. This is similar to Telegram's "Folders" features where one can organize different chats within specific areas of life: e.g: 1. Work 2. Friends 3. Family 4. and so on...

1 1

UPDATED: XEP-0107 (User Mood)
by Daniel Gultsch 20 Jun '24

20 Jun '24

Version 1.2.2 of XEP-0107 (User Mood) has been released. Abstract: This specification defines a payload format for communicating information about user moods, such as whether a person is currently happy, sad, angry, or annoyed. The payload format is typically transported using the personal eventing protocol, a profile of XMPP publish-subscribe specified in XEP-0163. Changelog: Fixed typo (XEP Editor (dg)) URL: https://xmpp.org/extensions/xep-0107.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 0

NEW: XEP-0491 (WebXDC)
by Daniel Gultsch 20 Jun '24

20 Jun '24

Version 0.1.0 of XEP-0491 (WebXDC) has been released. Abstract: This document defines an XMPP protocol extension to communicate WebXDC widgets and their state updates. Changelog: * Promoted to Experimental (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0491.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 0

UPDATED: XEP-0153 (vCard-Based Avatars)
by Daniel Gultsch 20 Jun '24

20 Jun '24

Version 1.1.1 of XEP-0153 (vCard-Based Avatars) has been released. Abstract: This document provides historical documentation of a vCard-based protocol for exchanging user avatars. Changelog: XEP-0054 says “Email addresses MUST be contained in a <USERID> element”. (egp) URL: https://xmpp.org/extensions/xep-0153.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 0