- Standards

XEP-0045 combining valid and invalid ban list modification in one request

by Guus der Kinderen

Hello! XEP-0045 Section 9.1 defines that: - a user cannot be banned by an admin with a lower affiliation. - if an admin or owner attempts to ban himself, the service MUST deny the request. Section 9.2, that deals with modifying the ban list of a room (potentially applying changes that affect more than one participant) does not mention these cases. It stands to reason that similar definitions must apply. To me, this raises the question of dealing with ban list modification requests that contain both 'valid' as well as 'invalid' modifications. I do not believe that the XEP clearly specifies how to deal with these. I would think that the entire request is to be rejected (as opposed to only the 'valid' modifications' be applied). Can we add this explicitly in the XEP? Kind regards, Guus

8 months, 4 weeks

2
2
0 0

XMPP Council Agenda 2024-07-09

by Daniel Gultsch

Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, July 9 2024 at 16:00 UTC in xmpp:council@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update - UPDATED: XEP-0440 (SASL Channel-Binding Type Capability) https://xmpp.org/extensions/xep-0440.html - UPDATED: XEP-0491 (WebXDC) https://xmpp.org/extensions/xep-0491.html 4) Items for voting a) XEP-0386: Add an XML Schema https://github.com/xsf/xeps/pull/1356 5) Pending votes Travis and Daniel are pending on - XEP-0054: Updated error cases to be compatible with RFC 6121 See the spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa… 6) Date of Next 7) AOB 8) Close

8 months, 4 weeks

1
0
0 0

UPDATED: XEP-0491 (WebXDC)

by Daniel Gultsch

Version 0.1.2 of XEP-0491 (WebXDC) has been released. Abstract: This document defines an XMPP protocol extension to communicate WebXDC widgets and their state updates. Changelog: * Suggest what to use for selfAddr * Add acknowledgements (spw) 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.

9 months

1
0
0 0

UPDATED: XEP-0440 (SASL Channel-Binding Type Capability)

by Daniel Gultsch

Version 0.4.2 of XEP-0440 (SASL Channel-Binding Type Capability) has been released. Abstract: This specification allows servers to annouce their supported SASL channel-binding types to clients. Changelog: * Add an XML schema. * Mention that this specification does add a new namespace that should go to the registrar. * Fix indentation, typos, misuse of '' vs. </> for elements, etc. (egp) URL: https://xmpp.org/extensions/xep-0440.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.

9 months

1
0
0 0

XMPP Council Agenda 2024-07-02

by Daniel Gultsch

Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, July 2 2024 at 16:00 UTC in xmpp:council@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update - NEW: XEP-0492 (Chat notification settings) https://xmpp.org/extensions/xep-0492.html - UPDATED: XEP-0484 (Fast Authentication Streamlining Tokens) https://xmpp.org/extensions/xep-0484.html 4) Items for voting a) XEP-0054: Updated error cases to be compatible with RFC 6121 https://github.com/xsf/xeps/pull/1351 5) Pending votes none See the spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa… 6) Date of Next 7) AOB 8) Close

9 months

1
0
0 0

UPDATED: XEP-0484 (Fast Authentication Streamlining Tokens)

by Daniel Gultsch

Version 0.2.0 of XEP-0484 (Fast Authentication Streamlining Tokens) has been released. Abstract: This specification defines a token-based method to streamline authentication in XMPP, allowing fully authenticated stream establishment within a single round-trip. Changelog: * Added an XML Schema. * Fixed text where 'count' was assumed to be an element, not an attribute. * Fixed indentation in a few examples. (egp) URL: https://xmpp.org/extensions/xep-0484.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.

9 months

1
0
0 0

NEW: XEP-0492 (Chat notification settings)

by Daniel Gultsch

Version 0.1.0 of XEP-0492 (Chat notification settings) has been released. Abstract: This document defines an XMPP protocol extension to synchronise per- chat notification settings across different clients. Changelog: * Promoted to Experimental (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0492.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.

9 months

1
0
0 0

UPDATED: XEP-0484 (Fast Authentication Streamlining Tokens)

by Daniel Gultsch

Version 0.1.1 of XEP-0484 (Fast Authentication Streamlining Tokens) has been released. Abstract: This specification defines a token-based method to streamline authentication in XMPP, allowing fully authenticated stream establishment within a single round-trip. Changelog: * Link to latest draft version (09) of the HT SASL mechanism. (lnj) URL: https://xmpp.org/extensions/xep-0484.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.

9 months

1
0
0 0

Extended contacts

by avidseeker7＠protonmail.com

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.

9 months, 1 week

3
2
0 0

Subscription and invites policy

by avidseeker7＠protonmail.com

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.

9 months, 2 weeks

1
0
0 0

2025

2024

2023

Standards

2025

2024

2023

Standards ----- 2025 ----- April 2025 March 2025 February 2025 January 2025 ----- 2024 ----- December 2024 November 2024 October 2024 September 2024 August 2024 July 2024 June 2024 May 2024 April 2024 March 2024 February 2024 January 2024 ----- 2023 ----- December 2023

Standards