March 2025 - Standards

Which one to use: `authorization-identity` or `authorization-identifier`

by Andrzej Telezynski

Hello, I am confused about those two elements: `authorization-identity` and `authorization-identifier`. Are they equivalent? They seem to be used in the same context. Grepping the XEPS repo shows both are used: $ grep -rl authorization-identity ./xep-0484.xml ./inbox/xep-fast.xml ./inbox/sasl2.xml ./xep-0386.xml $ grep -rl authorization-identifier ./xep-0480.xml ./inbox/xep-downgrade-prevention.xml ./inbox/xep-scram-upgrade.xml ./inbox/sasl2.xml ./xep-0198.xml ./xep-0388.xml ./xep-0474.xml What confuses me is that they both are used in the same context, f. ex.: "XEP-0386: Bind 2" has `authorization-identity` in successful Bind response: https://xmpp.org/extensions/xep-0386.html#example-4 <success xmlns='urn:xmpp:sasl:2'> <authorization-identity>user(a)example.com/AwesomeXMPP.4232f4d4 </authorization-identity> <bound xmlns='urn:xmpp:bind:0'> <metadata xmlns='urn:xmpp:mam:2'> <start id='YWxwaGEg' timestamp='2008-08-22T21:09:04Z' /> <end id='b21lZ2Eg' timestamp='2020-04-20T14:34:21Z' /> </metadata> </bound> </success> But "XEP-0388: Extensible SASL Profile" uses `authorization-identifier` https://xmpp.org/extensions/xep-0388.html#example-7 <success xmlns='urn:xmpp:sasl:2'>  <additional-data> dj1tc1ZIcy9CeklPSERxWGVWSDdFbW1EdTlpZDg9 </additional-data> <authorization-identifier>user(a)example.org</authorization-identifier> </success> Is it valid to use `authorization-identifier` in all those cases? What about other XEPS that use `authorization-identity` f. ex. "XEP-0484: Fast Authentication Streamlining Tokens" ? https://xmpp.org/extensions/xep-0484.html#example-3 It seems that clients need to expect both variants anyway. I am hoping for some advice or clarification, maybe I have missed something. Thanks, Andrzej -- *Come see us at: *Alchemy Conf 2-3 Apr | ElixirConf EU 15-16 May | Code BEAM Lite Stockholm 2 Jun | Lambda Days 12-13 Jun | *Learn more >> <https://www.erlang-solutions.com/events/>* Erlang Solutions cares about your data and privacy; please find all details about the basis for communicating with you and the way we process your data in our Privacy Policy. <https://www.erlang-solutions.com/privacy-policy.html> You can update your email preferences or unsubscribe from all lists here. <https://forms.erlangsolutions.com/email-preference?epc_hash=pZxDpeyjOBLTF6P…>

2 days, 1 hour

3
3
0 0

[XEP-0433] (Extended Channel Search): Search Form Fields

by Goffi

Hi, I'm currently implementing XEP-0433 (Extended Channel Search), nice work thanks. I have a couple of feedback: 1. I see in example 3 (https://xmpp.org/extensions/xep-0433.xml#example-3) a `min_users` field which is not described in https://xmpp.org/extensions/ xep-0433.xml#table-1, would it be possible to add it? 2. I think that it would be nice to specify recommended default values in the table. 3. The "sort" field is redundant and less powerful than XEP-0413 (Order-By), is there any reason to not use the later? 4. I feel that it would be useful to indicate somewhere the minimum of characters expected in a search query, so client doesn't send useless requests. Maybe via disco? Thanks! Goffi

5 days, 4 hours

1
0
0 0

New XEP proposal: Spaces

by Nicolas Cedilnik

Hello everyone, I just submitted https://github.com/xsf/xeps/pull/1426 with a rendered version at https://nicoco.fr/inbox/spaces.html This is an attempt at a minimal "spaces XEP". I remember reading a document a long time ago which looked impressively complete but did not turn into a XEP proposal. I suspect this is because the document attempted to cover everything, and there are very different use-cases for spaces, with different permissions models, ranging from fully public to completely private through "some rooms are public but some require being part of a subteam" etc. I tried a different approach here, attempting to lay the foundation of what is the minimum to cluster several groupchats without relying on a dedicated MUC service just for that. The slidge-based gateways for discord, mattermost and matrix already implement listing the "servers", "teams" and "spaces" of these networks via adhoc commands. I would very much like to make this a bit more generic (and standardised!) in slidge "core", the gateway library (and also expose in the disco#info of each room which "space" it is a child of). About the name, I called it "server-side spaces" because I think what Gajim already does with its workspaces is great and should be standardized at some point too, that would be another XEP, maybe "client(or user)-side spaces", later. I already gathered a little feedback from the xsf@ room, and incorporated it in the present submission. Looking forward to reading your feedback. -- nicoco

1 week, 6 days

5
10
0 0

Commenting system based on XMPP

by Schimon Jehudah

Greeetings, ladies and gentlemen! First of all, I would want to congratulate Mr. Nicolas Cedilnik (nicoco) for creating a plugin to the publishing system Pelican. Reference: https://codeberg.org/nicoco/pelican-pubsub Second, I would want to create an HTML based commenting system service, and I would be glad to receive your consultancy on how to design it. By that, I mean, to which PubSub nodes should comments be published to. And then I will create a system based upon FastAPI and Slixmpp. P.S. Currently, there are three or four brands that provide commenting systems in a centralized fashion. Kind regards, Schimon

2 weeks, 3 days

2
1
0 0

Transmit of contact photo per Jabber ID

by Schimon Jehudah

Good day! I want to create a weather bot which is not a component. However, I would not be able to make a dynamic use of contact photo, as I would with a component. Because, it is not possible to selectively transmit contact photo. I think, that this would have useful uses to different use-cases, so it would be good to create an XEP to it. Please advise, Schimon

2 weeks, 3 days

1
0
0 0

XSF membership application period Q2 2025

by Alexander Gnauck

I have setup the membership application Wiki page for the application period Q2 2025 Applications are encouraged from developers and others who are actively involved in the Jabber/XMPP community. To apply, create a page about yourself on the Wiki: https://wiki.xmpp.org/web/Membership_Applications_Q2_2025 If you don't have a wiki account, send your full name, preferred nickname and email address to me or one of the other Sysops: https://wiki.xmpp.org/web/Sysops Apply now!!! Thanks, Alex

3 weeks

1
0
0 0

NEW: XEP-0503 (Server-side spaces)

by Daniel Gultsch

Version 0.1.0 of XEP-0503 (Server-side spaces) has been released. Abstract: This document defines an XMPP protocol to cluster several groupchat rooms together. Changelog: Promoted to Experimental (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0503.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.

3 weeks, 1 day

1
0
0 0

Proposed XMPP Extension: Server-side spaces

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Server-side spaces Abstract: This document defines an XMPP protocol to cluster several groupchat rooms together. URL: https://xmpp.org/extensions/inbox/spaces.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

4 weeks

3
3
0 0

2025

2024

2023

Standards March 2025

2025

2024

2023

Standards March 2025 ----- 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 March 2025