- Standards

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

Exoskeleton Market Analysis: Emerging Growth Drivers, Strategic Trends & Key Segments Forecast to 2035
by km3065158＠gmail.com 07 Oct '26

07 Oct '26

The Global Exoskeleton Market Report is a comprehensive report on the Exoskeleton market, offering key insights on business strategies, current trends, and presenting qualitative and quantitative analysis of the Exoskeleton market. This report offers in-depth research insights on key and significant aspects of the Exoskeleton market, providing an in-depth analysis of key drivers, restraints, restraints, growth prospects, threats, and risks. The report also includes an in-depth analysis of the competitive landscape and regional scope of the Exoskeleton market. The global Exoskeleton market report employs an extremely extensive and perceptive process that analyzes statistical data relating to services and products offered in the market. The research study is a pivotal document in understanding the needs and wants of the clients. The report is comprised of significant data about the leading companies and their marketing strategies. The Exoskeleton industry is witnessing an expansion and change of dynamics owing to the entry of several new players. The study outlines the rapidly evolving and growing market segments along with valuable insights into each element of the industry. The industry has witnessed the entry of several new players, and the report aims to deliver insightful information about their transition and growth in the market. Mergers, acquisitions, partnerships, agreements, product launches, and joint ventures are all outlined in the report. Key Companies Profiled in the Report are Alpha Chemika Bionic Yantra CYBERDYNE Ekso Bionics ExoAtlet Fourier Intelligence Gloreha Guangzhou Yikang Medical Equipment Hexar Humancare Hocoma MediTouch Milebot Robotics Global Exoskeleton Market by Body Part Covered (Upper Body, Lower Body and Full Body), Mode of Operation (Powered, Passive and Hybrid), Form of Exoskeleton (Rigid and Soft), Mobility (Fixed / Supported and Mobile), End Users (Patients, Healthcare Providers, Industry Workers, Military Personnel and Others). The research report offers a comprehensive regional analysis of the market with regards to production and consumption patterns, import/export, market size and share in terms of volume and value, supply and demand dynamics, and presence of prominent players in each market. Regional Analysis Covers: North America (U.S., Canada) Europe (U.K., Italy, Germany, France, Rest of EU) Asia Pacific (India, Japan, China, South Korea, Australia, Rest of APAC) Rest of the World (Australia, New Zealand and Other Countries) To know more about the report, visit @ https://www.rootsanalysis.com/reports/exoskeleton-market.html Furthermore, the report provides analytical data in an organized format segmented into charts, tables, graphs, figures, and diagrams. This enables readers to understand the market scenario in an easy and beneficial manner. Moreover, the report aims to impart a prospective outlook and draw an informative conclusion to assist the reader in making lucrative business decisions. The report, in conclusion, provides a detailed analysis of the segments expected to dominate the market, the regional bifurcation, the estimated market size and share, and comprehensive SWOT analysis and Porter’s Five Forces Analysis. Thank you for reading our report. For further queries, please connect with us, and our team will provide you the report best suited to your requirements.

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

UPDATED: XEP-0491 (WebXDC)
by Daniel Gultsch 02 Oct '26

02 Oct '26

Version 0.1.4 of XEP-0491 (WebXDC) has been released. Abstract: This document defines an XMPP protocol extension to communicate WebXDC widgets and their state updates. Changelog: * Support realtime channels (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.

1 0

New protoxep: MUC is ready
by Nicolas Cedilnik 29 Sep '26

29 Sep '26

Hi all, I submitted a protoXEP today <https://github.com/xsf/xeps/pull/1563>. A rendered version is at <https://nicoco.fr/muc-ready.html> It is a proposition for a mechanism to avoid the following situation: 1. a MUC services shuts down and kicks clients out; 2. clients don't re-join the MUC automatically. This is generally not an issue for local users, since MUC services and XMPP server implementations are tightly coupled in practice and can work around the situation by supporting restarting the MUC service "silently". Also, when the whole XMPP server is restarted, clients re-login and re-join all MUCs after that, so the issue does not arise. It is however a problem for non-local users. Clients have adopted different strategies for this situation. For instance, Conversations does not attempt to re-join automatically, and gajim retries periodically. I propose that MUC services can emit MUC invitations on startup to signal that a room is ready to be re-joined. The invite stanza has a dedicated |<ready />| element, which lets clients treat these invites differently than others, eg, by avoiding to display it to the user or triggering re-join as they see fit. Slidge already has this "invite users on startup" behaviour and I developed a small prosody module <https://modules.prosody.im/mod_muc_invite_affiliated.html> <https://modules.prosody.im/mod_muc_invite_affiliated.html> with a similar behaviour. If this proposition is accepted, I will add the dedicated element in the invites of both this prosody module and slidge. Maybe this should be a new section in /XEP-0249: Direct MUC Invitations/ instead? What does the community think? Is it a terrible idea or does it fill a gap that is missing? -- Nicolas

1 0