XMPP Council - 2026-07-07

Today's meeting will be quick. We have pending votes for payment required from goffi and Marvin. Feel free to bring up 66 as an AOB goffi

We very rarely move xeps from stable to final. I would like to embed that into a larger discussion on if we should

That one specially feels a bit random and the current usage seems a bit unclean...

Idk other candidates would probably be HTTP upload. And I'm sure there are more

But that's just my personal opinion and an explanation on why I didn't just add a vote to the agenda

66 is so simple and already being partially superceded in the experimental sphere so I think final is rather appropriate there really

I mean on one hand yes. And I think I'd be inclined to vote yes on that. However voting it to final two weeks before it's gets deprecated seems random

If we see it in a context of advancing more than this particular XEP I think I'd be more fine with it

I doubt we'll be formally deprecating it for a very long time. Or ever really it's a very useful xep in many contexts

I've just happened work with this one this week, and the "draft" state caught my eyes.

On another topic, are we accepting AI generated protoXEP? The discussion wasn't leading to clear consensus on standard@, and https://xmpp.org/extensions/inbox/payment-required.html has been clearly written with AI.

I mean my words may be misleading: I'm not saying it's fully AI generated, I don't think it is, but AI has been used for sure.

I don't think there's been any decision against it. So long as it meets quality bar, I've no objections. We can change course later if we become overwhelmed.

It's more verbose than it should be, that's painful to review.

> On another topic, are we accepting AI generated protoXEP? The discussion wasn't leading to clear consensus on standard@, and https://xmpp.org/extensions/inbox/payment-required.html has been clearly written with AI. I don't find anything "clearly" about this ↺

Also there are potential legal implications.

I don't think we can worry about every hypothetical legal implications. And anyway a legal question is up to board not us ✏

I think we have either reached the point or will eventually reach the point where 'AI generated' isn't clear cut

Indeed

> I don't find anything "clearly" about this singpolyma, All sections are filled, which basically never happens on first submission (notably for XML Schema), there is a high use of em dashes which is typical from AI, and not from humans, it's very verbose, and the genaral feeling of the style make it very AI-like to me. I have little doubt on that. ✏ ↺

I don't think it's easy or even possible for an organization like the XSF to have a position on that. What I have said in the past though is that I won't be available to do this job (editor + council chair) if we get to too many slop XEPs per week

All sections filled... So the complaint is someone actually followed the rules for once?

Just get an AI to do my job I guess 🤷‍♂️

Right now we aren't though right? Still averaging less than one xep of any kind for week?

I don't say that it's bad or good, and I don't think it's slop, there have been obviously work on this specification, but the question of AI must on the table at some point, and XSF should decide if it must be disclosed or not.

i don't really see why. But it's a question for board and not for us

> All sections filled... So the complaint is someone actually followed the rules for once? It's not a complaint, it's a question about our position. And all sections filled is just on of the clues I've mentioned. ↺

Well for one, we can't be sure that AI is not repeating verbatim some parts of closed specification from its training data.

IP law like all laws are just tools of oppression anyway. The people in power never adhere to their own laws anyway. I'm just worried about workload

(not important) I found the recent PRs where the responses to comments were clearly coming from an LLM frustrating, and I was glad Daniel was dealing with them instead of me :)

You're absolutely right! :)

>> I don't find anything "clearly" about this > singpolyma, All sections are filled, which basically never happens on first submission (notably for XML Schema), there is a high use of em dashes which is typical from AI, and not from humans, it's very verbose, and the genaral feeling of the style make it very AI-like to me. I have little doubt on that. Also the git commit messages are also overly verbose, which is weird because of how unnecessary it is (considering nobody reads them) ↺

As a reviewer, I would appreciate at least a disclaimer on AI usage. As a XSF member, I would like the board to take position on that.

Personally I feel rather strongly that declaration of AI use is a minimum sensible step with practically few downsides, regardless of any other policies

Reviewing LLM output is, in my experience, more effort than reviewing content written by experienced humans

The kinds of mistakes they make are different

Yes and the cost of submitting something is completely unproportional to the work it takes to review. That's why I said I'm not available to do it

Anyway it's time

1) roll call

👋

.o/

dan.caseley, singpolyma: you around?

Hi!

2) agenda bashing. I didn't sent one out. We have one request for discussion (final 66) which I would like us to discuss in the AOB section

3) items for voting None

4) pending votes

As stated earlier goffi and larma on payment

Here

I'm not super confortable with this protoXEP, and I sincertly hope I won't start to see payment request to add somebody to my roster. Anyway I won't block, I'm +0

I think if you do, you can find another XMPP service to use :)

It's the server of the contact, not mine!

Then they don't deserve your friendship if they want you to pay for it ;)

We are currently 3 times +1 and one +0, right?

Yes

yes

As someone who sells things over xmpp I'm more amenable to the concept I suppose 🙂

I'm in favour of having an error for this. The payment-required condition used to be in the RFCs, and it was removed. I think it should have remained. Services will charge for things for various reasons, and it's better to have a standard in-band way of doing that.

But this XEP does a bit more than just reinstate the old error condition, I haven't fully reviewed it

I'm not against selling things over XMPP, but using it as antispam pose many problems IMO. Anway, that more for standard@ discussion I guess.

larma: do you want to vote on this now?

OK, so it's fine if I also +0. I have my fair share of concerns with this specification, but I also don't want to block it

OK. That means it passes. Moving on

5) date of next

+1w wfm

+1w wfm

I'd like to eradicate every mention of lightning from the specification, but I guess the author is primarily interested in exactly that and not so much the RFC standard or SEPA payments...

+1w wfm

+1w wfm

+1w wfm .. 95% confidence

6) AOB

> I'd like to eradicate every mention of lightning from the specification, but I guess the author is primarily interested in exactly that and not so much the RFC standard or SEPA payments... yeah, I'm not super happy with it either. And Btw, SEPA is 20s with instant payment which is free nowadays. ↺

Passes the mic to goffi

yes well not much to add that I think we should put XEP-0066 (and probably other old and widely used specs) to last call for final.

I guess I should contact the author for that (it's PSA I believe), right?

Or guess as my open question to the room. Should we generally try to advance a bunch of stable xeps

Specs which are untouched for 15+ years and widely used should be Final IMO

I agree

I looked it up it's under council control to vote on that. Technically there is no list or author feedback loop required

the purpose of the process is to get XEPs from experimental to final. And I see no obstacle for this xep

>> I'd like to eradicate every mention of lightning from the specification, but I guess the author is primarily interested in exactly that and not so much the RFC standard or SEPA payments... > yeah, I'm not super happy with it either. And Btw, SEPA is 20s with instant payment which is free nowadays. the majority of humans don't live in EU though ↺

Daniel, even if not mandatory, I think that it's normal to ask author first

> the majority of humans don't live in EU though SEPA was mentioned, I replied to that. I'm aware it's not worldwide. ↺

So we can just fiat declare it final? ✏

I'm not convinced there is a 'normal' for a process we haven't done in a long while

Does anyone remember the last time we did this? I don't

By "normal", I mean polite. I would like to be contacted if I were the author. ✏

But if you want to start a discussion on the list and/or ask the author please go ahead

> I'd like to eradicate every mention of lightning from the specification, but I guess the author is primarily interested in exactly that and not so much the RFC standard or SEPA payments... I'd like for the XEP to have cryptocurrency integration, but seeing Lightning getting mentioned a lot in it makes me feel like the author is way more interested in specifically that than any other cases ✏ ↺

I don't think a discussion on just would be unreasonable

I guess a thread on the list that also explicitly asks PSA for comment / approval?

Maybe we can gather XEP to advance first? PSA is probably the author of most of them anyway

Is that you volunteering?

I mean that was basically my initial question, right. If we just do this one or if we want to make that a general thing we try to do

I guess I'm fine with trial running that on 66

To get back into the flow and create a procedure again

OK, I can write a message on that and mention PSA

*if* we involve list and author we can only run so many in parallel anyway

fwiw XMPP and lightning are both open and permissionless (networks and code) and work worldwide, seems like a perfect match

> OK, I can write a message on that and mention PSA Sounds good to me

The rest of council is fairly silent. Any other comments on that or should we move on?

OK I guess that concludes this AOB. Any other AOB?

Momentum on stuff that isn't the flavour of the week feels like A Good Thing.

I guess that means no other AOB

There has to be a CfE before moving to final anyway, doesn’t there, so list will end up involved?

Which means

7) close

Thank you all. See you next week

Thanks Daniel, thanks all.

> fwiw XMPP and lightning are both open and permissionless (networks and code) and work worldwide, seems like a perfect match That applies to most cryptocurrencies (not ERC-20 tokens), so I don't get why Lightning is more important in the XEP than any other cryptocurrency ✏ ↺

It's not that I don't want any crypto in Payment Required, it's just that it should be less biased towards one currency ✏

Cynthia: you can do cryptocurrency with that XEP, even all lightning is just examples and non-normative, so other cryptocurrency stuff could work similarly. Also a note for the author jcbrand: the use and references to lightning URI schema and URIs built from it should probably be removed eventually, because those are not IANA registered. Use bitcoincash instead (Stupid joke, sorry, but at least they in the register) or have someone actually register it with IANA. ✏

I wonder how many cryptocurrency developers are interested in registering their URI schema with the IANA

Probably we only need the payto URIs for example

and anyone can use others of course

Cynthia: it doesn't need to be the cryptocurrency developer registering it.

singpolyma: that would of course be my favorite as well.

GNU Taler also has their taler: URI scheme registered. ✏

> Cynthia: it doesn't need to be the cryptocurrency developer registering it. Oh, interesting ↺

singpolyma: just spotted your name in the GANA payto target type registry ^^

So GANA maintains the registry for payto?

I thought it was the RFC lol

An RFC cannot maintain a registry

similar to a xep