- Standards

Comments on ProtoXEP: Jingle Audio/Video Conferences
by Dave Cridland 20 Oct '26

20 Oct '26

Hi Jérôme, standardizers, I saw that Jérôme had resubmitted av_conferences, and since this is an area of interest of mine, and one I sadly lack the detailed understanding to drive, I reviewed it with some interest. Firstly, this is, in my view, a major step forward and I would welcome it being published as a XEP. This is despite my suspicion that it will need more work. The main areas are around signalling for some of the cases that are hinted at. For example, bounded/demand forwarding, resolution selection, and so on. The biggest structural change - I think - is that the spec assumes that participants would get one or more SSRCs bound to them, and I suspect the "right" way to achieve a good result in the client is to bind SSRCs to UX elements; so a SSRC maps to "The 4th most recent speaker", or "This pinned particiant", for example - and the Focus then instructs the SFU to map an inbound stream to that SSRC accordingly. That implies that <origin/>, which maps to the <content-add/> set in Jingle, would need to be replaced with something that's part of the <description-info/> instead. Obviously this is all with the caveat that I have no idea what I'm talking about, really... But, I would really love to see interoperable multiparty calls in XMPP. Dave.

2 1

Spec proposal: bookmark last known name
by Nicolas Cedilnik 18 Oct '26

18 Oct '26

Hey everybody (bis), I submitted a(nother) proxoXEP today: <https://github.com/xsf/xeps/pull/1575>. A rendered version is at <https://nicoco.fr/bookmark-last-known-name.html>. The idea is for clients (or, wait for it: gateways) to set a bookmark extension "last-known-name" for MUCs in the PEP bookmarks. This last known name can then be used in the "start chat"-like dialog of clients for them to display a human-readable for the "chat" without (or before/while) querying its disco#info. Of course, this spec only makes sense if client developers think it does fill a gap. As a user, I know that there is a gap, because it happened a few times to me that I wanted to join a room from my new client, and couldn't figure out which bookmark item it was because it had never been joined before from this client (and the JID localpart was gibberish). Maybe it makes more sense to expect clients to disco#query all bookmark items instead. Side-note: maybe we should have some sort of registrar for standardized bookmark extensions, instead of having them all as separate XEPs? Maybe not. Community, what do you think? -- nicoco

1 0

Spec proposal: bookmarks hierarchy
by Nicolas Cedilnik 18 Oct '26

18 Oct '26

Hello all, Edhelas and I submitted a PR on github for a spec proposal: <https://github.com/xsf/xeps/pull/1574> A rendered version is at <https://nicoco.fr/bookmarks-hierarchy.htm>. The idea is to have an additional item in pubsub/pep nodes containing bookmark items, defining bookmarks directories. The bookmark items themselves have a dedicated extension referring to these directories, with a "weight" used to sort them within the categories. Our obvious use case is organising rooms in a XEP-0503 space, but it could possibly be used for organising PEP bookmarks too. Feedback welcome and appreciated! Have a nice sunday, -- nicoco

1 0

Re: XEP-0353 language clarification
by onf 15 Oct '26

15 Oct '26

On Thu Oct 15, 2026 at 8:35 PM CEST, Thilo Molitor wrote: > The privacy aspects are discussed here: https://xmpp.org/extensions/xep-0353.html#security > > Because exchanging messages with other entities is effectively a presence > > leak, an XMPP client that implements the receiving side of this specification > > MUST disable sending of accept messages by default and MUST enable the feature > > only as a result of explicit user confirmation. Such confirmation can be > > provided per request, by automatically allowing requests received from Jingle > > initiators in the responder's contact list, or through some other suitable > > means as long as sending accept messages does not occur by default. > > But granted this is not ideal for several reasons: 1. the <accept/> element > was a :1 namespace one, but we rolled that back to the :0 namespace where the > same functionality is called <proceed/>. Also <ringing/> should be added in > that section of the XEP as well. Indeed, I read that section as being about <proceed/> -- indicating that a device is ringing can hardly be called "sending [an] accept message". > Regarding Dino never sending <ringing/>: older versions of that XEP didn't > include a ringing indication, maybe Dino simply implements an earlier version > of XEP-0353? Yes, I already said that in the thread you quote: > > On 10/14/26 6:59 AM, onf wrote: > > > I just checked and version 0.3.1 of the XEP that Dino claims to > > > implement doesn't seem to contain any description of <ringing/>, which > > > explains it. Its messages related to this XEP likewise don't include > > > <store/> hints because that's not specified in that version either. ~ onf

1 0

Proposed XMPP Extension: MUC is ready
by Daniel Gultsch 15 Oct '26

15 Oct '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: MUC is ready Abstract: This specification provides a way for MUC components to inform clients that a room is ready to be re-joined. URL: https://xmpp.org/extensions/inbox/muc-ready.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

6 8

Aluminum Cable Market Enables Power Transmission
by wanrup07＠gmail.com 15 Oct '26

15 Oct '26

The transmission and distribution of electrical power across residential, commercial, and industrial applications depends on aluminum cables that provide reliable conductivity while offering advantages in weight and cost compared to copper alternatives. According to Market Research Future, the Aluminum Cable Market was estimated at USD 120.55 billion in 2024 and is projected to grow from USD 125.2 billion in 2025 to USD 182.85 billion by 2035, exhibiting a compound annual growth rate of 3.86% during the forecast period. Report Key Statistics Market Research Future's comprehensive analysis reveals that North America is the largest market for aluminum cables, with a valuation of USD 10.5 billion in 2023 expected to grow to USD 15.0 billion by 2032. Europe follows with a valuation of USD 12.0 billion in 2023, potentially escalating to USD 17.0 billion. The Asia-Pacific region dominates with a valuation of USD 14.0 billion in 2023, projected to reach USD 20.0 billion. The Power Transmission segment continues to dominate, while the Telecommunication segment is witnessing rapid growth. AAC enjoys the largest market share, while ACSR is the fastest-growing. Industry Trends: Sustainability and Renewable Energy The most significant trend in the aluminum cable market is the focus on sustainability. Aluminum cables are gaining traction due to their recyclability and lower environmental impact compared to traditional copper alternatives. Growth in renewable energy is driving demand. As solar and wind energy projects proliferate, the need for reliable and efficient cabling solutions is becoming more pronounced. Technological advancements are improving performance. Manufacturers are developing cables with enhanced performance characteristics. Challenges: Competition and Raw Materials Competition from copper cables affects market share in some applications. Raw material cost volatility affects prices. Technical requirements continue to evolve. Future Outlook: Smart Grid and Electric Vehicles The future of the aluminum cable market lies in expansion into renewable energy sector with specialized aluminum cables. Development of lightweight aluminum cables for automotive applications will drive demand. Implementation of smart grid technologies utilizing aluminum cabling solutions will enable new capabilities. Expert Discussion: Regional Market Dynamics Insights published by Market Research Future indicate significant regional variation in aluminum cable demand. North America's leadership reflects extensive infrastructure development, with key players including Southwire Company, General Cable, and AFL. Europe's market is driven by industrial applications, with key players including Nexans and Kabelwerk Eupen AG. Asia-Pacific is the fastest-growing market, with key players including LS Cable & System and Sumitomo Electric Industries. Conclusion The Aluminum Cable Market is positioned for sustained growth as electrification accelerates and infrastructure modernizes. While challenges related to competition, raw materials, and technical requirements persist, ongoing innovation ensures that cables will continue to improve. The evolution toward smart grid and electric vehicles will define the competitive landscape through 2035. Read More: https://www.marketresearchfuture.com/reports/aluminum-cable-market-33651

10 16

We should require AI disclosure
by Goffi 09 Oct '26

09 Oct '26

Hello everybody, I would like to bring a discussion on AI policy. We can't really ignore anymore that modern models have become very capable, and I suspect that they are used for spec authoring. This raises, I believe, copyright issues: if someone use AI to redact a whole section of a spec, how can we be sure that it's not an existing specs for some other place, possibly under copyright, that is copied or paraphrased? How can an author guarantee that it's original work (hint: they can't)? I think that there are 3 distinct uses: 1. As a light formatting/checking help, for instance to generate a table from a human written section, to correct the formulation of a sentence, or to draft an example. This is notably useful for non native English speakers. 2. As a help to search existing state of art on some feature, or any kind of data, without writing anything in a protoXEP. 3. As a way to generate whole sections. Instinctively, and If we put aside ethical and ecological concerns about LLMs, I think that 1. and 2. are OK, and 3. should be forbidden. And in all cases, it should be disclosed. I would like your feedback on this matter, in particular people with legal knowledge. I would like to avoid a flamewar, I know that this topic is sensitive and there opinions are highly divided, please express your opinion calmly. The fact is, we can't ignore this anymore. Should this be discussed with board or council? Thanks. Best, Goffi

14 43

hi
by wanrup07＠gmail.com 07 Oct '26

07 Oct '26

hi

1 0

Re: LAST CALL: XEP-0424 (Message Retraction)
by violet＠nullhost.de 05 Oct '26

05 Oct '26

Hello! Apologies in advance; I've just subscribed to the mailing list (so I can't reply to the thread), and I'm also a pretty new XMPP developer (I've definitely missed the Last Call). > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? Yes! > 2. Does the specification solve the problem stated in the introduction > and requirements? Mostly. I have a specific concern for retraction in 1:1 chats, where retractions target the @id. RFC 6120 states the @id can be unqiue to the stream, or across all streams (aka "global"), where this is up to the sender. For an XEP that uses @id to refer to *any* previously sent message, even requiring supporters to use a global @id is not enough, as the RFC also makes no mention of what happens to the @id outside of that stream (only that entities use it to know some response was a direct result of a stanza they sent within that stream). Because of this, it seems to me that an entirely valid client implementation is to count up from 0 for each stanza sent in that stream (maybe due to lightweight requirements where there is no CSPRNG?), and their server can route that stanza along with an entirely different @id, as long as it remembers the link between that @id and the one the client used for when a response is sent back to that client. (I would also like to submit that, while such an implementation would be expensive, and I cannot prove that implementations like this currently exist, we should still take them into account as they are fully compliant, and not doing so is how we make specifications that can be unreliable.) Requiring entities to also not modify the @id when sending into different streams would have considerations for entities that don't support the specification (thus the @id can be different for others). And if supporting entities don't modify an @id from an unsupporting entity, that could also possibly break stream-uniqueness guarantees. I am sure there are many similar issues. An XEP which successfully uses @id in 1:1 is LMC, as it is explicitly limited to the last message. Thus, if there are multiple messages from that entity with that @id, the message to be corrected is the most recent one from them at that time, with that @id. If we want to target *any* previous message, this cannot be done. > 3. Do you plan to implement this specification in your code? If not, > why not? As it is currently written, no. I believe 0359's <origin-id/> would be one possible solution for the above, as that element (and even the name of 0359) seems to have been written specifically for this problem. Looking at the commit history for 0424, this used to be the case until ~2 years ago! I would love to hear why it stopped being used. > 4. Do you have any security concerns related to this specification? Maybe not necessarily security-related, but it seems entirely possible to write fully-compliant implementations which can break in 1:1 chats, due to the instability of @ids. > 5. Is the specification accurate and clearly written? I have two nitpicks with its wording: > Supporting clients MUST set a unique 'id' on the <message> element in > outgoing stanzas (as per Unique and Stable Stanza IDs (XEP-0359) [9]), > [...] "unique" here could be interpreted, using the RFC, as unique to one stream or across all streams. Additionally, 0359 makes zero mentions of requiring supporters to handle @ids any differently (it only introduces <stanza-id/> and <origin-id/>), while this passage states it does. This could cause problems where entities may check for 0359 support, and then incorrectly assume a behavior entirely unspecified by 0359. This mistake is actually made later in 0424: > Clients that don't support Unique and Stable Stanza IDs (XEP-0359) [9] > (and therefore don't support Message Retraction (XEP-0424) [14]), > are not guaranteed to have a unique 'id' attribute on their <message> > elements. > [...] > To mitigate this, clients can do a Service Discovery (XEP-0030) [1] request > to check if the other client supports XEP-0359, and if not, [...] I am sure this XEP will eventually see a lot of adoption in the future (and it definitely serves a very important purpose in my eyes), but as it currently stands for 1:1, I see some edge cases that I would prefer not to have to debug, whenever they become an issue. Thank you all for your efforts to maintain the XMPP ecosystem. — Violet

1 0

XEP-xxxx: Pubsub Node Bookmark
by Timothée Jaussoin 02 Oct '26

02 Oct '26

Hello :) A year ago my XEP-xxxx: Pubsub Node Bookmark was merged in Inbox. This XEP define a simple element that points to a Pubsub Node and that can be embeded in a Bookmarks list, it was designed to be close to the XEP-0402: PEP Native Bookmarks <conference/> element. You can see a live version there https://movim.eu/xeps/pubsub-node-bookmark.html . I just submited a tiny PR to fix the examples there https://github.com/xsf/xeps/pull/1565 I'd like to have feedback on it and if possible publish it as we would like to use it extensively in the Spaces and in Movim to replace the historical https://xmpp.org/extensions/xep-0330.html in the upcoming weeks. Regards, edhelas

1 0