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
Not an XSF thing, but there's a Standards programme going on at Soverign
Tech that can fund open source maintainers to get to IETF (and other)
meetings. It's aimed at those who cannot otherwise go, to bring new voices
in.
I've not been to an IETF week in a while, but they're truly fascinating,
and I'd highly recommend it. If you're maintaining open source software and
want to go, but can't afford to, then you've a few days left to sign up.
This really is a great opportunity!
---------- Forwarded message ---------
From: Ted Hardie <ted.ietf(a)gmail.com>
Date: Thu, 14 May 2026 at 09:05
Subject: Re: Pilot project for standards participation
To: IETF <ietf(a)ietf.org>
I wanted to bump this both because the deadline is coming soon: 19 May
2026 at 11:59 PM and because there were a number of questions about whether
folks could apply if they would be invoicing via an institution*. *There's
an updated FAQ on that: https://www.sovereign.tech/programs/standards/faq.
The key text is:
"Generally, it is our strong preference to work directly with open source
maintainers through this program, either as a freelance agreement or as a
contract with a sole proprietor.
We do recognize that open source maintainers operate in a variety of
organizational settings. If you meet the requirements of the program
<https://www.sovereign.tech/programs/standards#requirements> but can only
invoice us through a legal entity that employs others, you are welcome to
apply. Please bear in mind the following:
- We may exclude applications for any reason at our sole discretion. As
per our goal to bring missing and underrepresented voices into standards
organizations, applications from organizations which do not require public
support for this work are likely to be excluded.
- The program is centered around building a relationship with individual
maintainers. If an organization's relationship with the individual ends or
changes in a manner impacting the work, Sovereign Tech Agency's
relationship with the organization will also come to an end.
- We will not be able to accommodate significant changes to our standard
legal agreements, which we will ask strong applicants to review ahead of
time."
So if that was holding anyone back from applying, please consider whether
the update changes your ability to take advantage of the opportunity.
regards,
Ted Hardie
On Thu, May 7, 2026 at 1:49 PM Ted Hardie <ted.ietf(a)gmail.com> wrote:
> I sent this information to the hackathon and open-source lists, but it was
> suggested I share a bit more widely.
>
> Some time ago, the Sovereign Tech Agency run a survey on the ability of
> open source maintainers to participate in standards work. Based on that
> data, they have now developed a pilot project for supporting open source
> maintainers that want to get involved with standards. That pilot has
> launched, with the IETF as one of the targets (along with the W3C and
> ISO). Background information is here:
>
> https://www.sovereign.tech/news/join-sovereign-tech-standards-network
>
> along with the application details:
>
> https://www.sovereign.tech/programs/standards
>
> Here's a direct link to the application as well:
>
> https://ats.talentadore.com/apply/sovereign-tech-standards/mXw0q0
>
> If you know of open source folks who might be interested in this kind of
> support, please share it with them.
>
> thanks,
>
> Ted Hardie
>
>
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: New MUC
Abstract:
This document specifies an enhanced Multi-User Chat protocol that is
broadly backwards compatible with that of XEP-0045, but adds a number
of key improvements.
URL: https://xmpp.org/extensions/inbox/new-muc.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
[cc to standards(a)xmpp.org since it is of interest to the xmpp ecosystem]
I've uploaded draft-ietf-kitten-sasl-ht-01. The major changes since the
adoption by the Kitten WG are
- the introduction of a response status byte to indicate success or
failure responses
- the capability to transmit authenticated key/value pairs in the
exchanged messages (e.g., for XEP-0474 [1])
SASL-HT is already deployed using an older and incompatible version of
the I-D in some parts of the XMPP ecosystem. Therefore, we probably need
to adjust the SASL Mechanism Name to avoid interoperability issues. For
example, from
HT-SHA-512-ENDP
to
HT2-SHA-512-ENDP
Please forgive my lack of creativity regarding the new name. Suggestions
on a more creative naming schema that is in-line with the constraints of
SASL Mechanism names are appreciated.
And, of course, feedback in general is welcomed.
- Florian
1: https://xmpp.org/extensions/xep-0474.html
Hi all,
I'm trying to summarise a discussion in the council@ chatroom, and - like
an LLM - I am not perfect so may misrepresent or misunderstand some views.
Errors, therefore, I shall claim as my own; views however are not.
First, some history.
In the early days of XEP-0045, each occupant corresponded to precisely one
full jid (ie, a client session). All stanzas sent to the occupant jid were,
therefore, forwarded through directly to that full jid. This general model
of "pure forwarding" has been maintained throughout XEP-0045's history, but
it has been modified heavily.
Quite early on - Kev thought 2001, MattJ thought 2003 - the need to have
vCards in particular be different started changing rules, and when Prosody
started doing MUC (and also M-Link) they started intercepting vCard to the
MUC occupant jid and forwarding that to the user's bare jid. Prosody now
does this with PEP as well.
In addition, "nick sharing" - allowing multiple full jids of the same user
behind a single occupant jid - makes forwarding most IQ stanzas complicated.
All this causes existing problems with preserving privacy in semi-anonymous
rooms.
What we do in the future (under MUC2/GC3/IRC4 whatever) broadly falls into
3 options that were discussed.
Option 1: The occupant jid forwards nothing, but has a way of requesting a
contact jid.
Option 2: The occupant jid forwards everything to the user's bare jid, and
their server "deals" with it.
Option 3: The occupant jid responds itself, without forwarding, and data
(vCards, PEP, etc) need to be uploaded by the user and stored by the MUC.
Option 4: The occupant jid has rules set by the user, which cause it to
either forward or reject particular traffic. I imagine some of these rules
will cause PEP subscriptions and event forwarding/fanout, potentially.
There were proponents of each of these approaches (and some proponents of
multiple).
There's a further discussion in xsf@ that I've not yet properly read.
My opinions follow:
Of these options, I think I'd like Option 4, but will settle for Option 2.
Option 2 feels like the natural fallback for Option 4 anyway.
One outcome is that in Future-MUC, there's an implication that Private
Messages, PEP, and vCard will go to the *bare* Jid, and that unless we do
something "clever", so will Jingle calls to Occupants. We would then
control these with existing (or new) access control on our own server, or
Option 4's new rules, or some combination of both.
I appreciate the simplicity of Option 1, but I think it's too simple - even
for Private Messages I'd need to reveal my identity. If I'm in a sensitive
room (say a healthcare related one) I might really want (or need) PMs but
not be willing to reveal my identity.
Option 3 seems very heavyweight and expensive to maintain and manage. I
don't particularly want to upload an avatar (and more) to each MUC room,
and nor do I see how those will work with (for example) Jingle.
As noted, I may have misconstrued the options presented!
Dave.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: TLS Channel-Binding Downgrade Protection
Abstract:
This specification provides a way to secure the SASL and SASL2 SCRAM
handshakes against channel-binding downgrades through TLS version
downgrades.
URL: https://xmpp.org/extensions/inbox/tdp.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
Version 0.3.0 of XEP-0503 (Server-side spaces) has been released.
Abstract:
This document defines an XMPP protocol to cluster several groupchat
rooms together.
Changelog:
* Fix pubsub node field name in room disco info.
* Specify how to attach images (avatar and banner) to a space. (nc)
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.
Version 0.2.0 of XEP-0463 (MUC Affiliations Versioning) has been
released.
Abstract:
This specification provides a way to reduce the amount of queries
necessary to stay up-to-date with affiliations in a MUC room.
Changelog:
Use a dedicated child element of <x/> rather than namespaced
attributes. (lmw)
URL: https://xmpp.org/extensions/xep-0463.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.
Version 0.2.0 of XEP-0449 (Stickers) has been released.
Abstract:
This specification provides a protocol to send stickers and to create
and share sticker packs.
Changelog:
Make pack attribute explicitly a MAY. Add more details about
sending/receiving stickers without a sticker pack. (lmw)
URL: https://xmpp.org/extensions/xep-0449.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.
