XMPP Council - 2026-05-05

Hey I've got a car accident. Nobody is injured fortunately, but my car is destroyed, and I'll have to go to police. You can image that I can't attend the meeting today in those conditions.

sorry to hear that, hope it works out :(

Auch. Good luck.

Thanks. We'll the most important is that nobody is injured. But sure it's a rough day

so much agenda today

Hi

It’s time

1) Roll call

👋

hello

is dan.caseley here as well?

2) Agenda bashing

nothing to bash I assume?

3) Editors update

* Proposed XMPP Extension: Payment Required (https://xmpp.org/extensions/inbox/payment-required.html) * Proposed XMPP Extension: Emoji Markup (https://xmpp.org/extensions/inbox/emoji-markup.html) * Proposed XMPP Extension: New MUC (https://xmpp.org/extensions/inbox/new-muc.html) * UPDATED: XEP-0449 (Stickers) * UPDATED: XEP-0463 (MUC Affiliations Versioning) * UPDATED: XEP-0503 (Server-side spaces) * Proposed XMPP Extension: TLS Channel-Binding Downgrade Protection (https://xmpp.org/extensions/inbox/tdp.html)

4) Items for voting

a) Proposed XMPP Extension: Payment Required https://xmpp.org/extensions/inbox/payment-required.html

on list

this one I like, but it creates a new payment type registry which seems highly unneeded since the referenced RFC already has a registry

the amount/display-amount thing also seems like a security issue

(show user one amount, they actually pay another when they click)

both seem like valid criticism

do you want to reject based on that?

I guess so. I don't want to take it without those things being addresses at least

-1 we shouldn't do our own registry. I advise the author to have that specified elsewhere and then just have a XEP that instructs how to use that

yeah, payto uri rfc already has a registry, seems the obvious place

b) Proposed XMPP Extension: Emoji Markup https://xmpp.org/extensions/inbox/emoji-markup.html

i think there was already some feedback on list. but an acceptable starting base

+1

+1

What Daniel said ;)

this one is basically just part of XEP-0394 but specified outside in order to make it optional I guess? +1

c) Proposed XMPP Extension: New MUC https://xmpp.org/extensions/inbox/new-muc.html

-1

i think i'm leaning toward -1 because we want to spec those features seperately?

I'm -1 here. I think the scope of the XEP is to unclear to even start one. It can't really be implemented either.

i mean as other people have pointed out there are valid use cases for those things

no implementation, no obvious plan to implement, not currently specified enough to be able to implement

but if council’s job is to provide guidance our guidance is to do seperate xeps for each feature

I also have my issue with the author clearly stating it's meant to be a starting point for a discussion. XEPs are not discussion venues, we have our lists, channels and summits for that. ✏

d) Proposed XMPP Extension: TLS Channel-Binding Downgrade Protection https://xmpp.org/extensions/inbox/tdp.html

+0 I'm not sure I see why but also seems fine

(from the floor, will on-list) https://xmpp.org/extensions/inbox/tdp.html seems to try to allow "safely" downgrading to a known-broken-for-a-decade+ and replaced 8+ years ago TLS version instead of just... refusing to use it? wild

yes I’m not sure about that one. i mean the spec is fine I guess. probably belongs into kitten not here. but we have other xeps that have the same problem

i mostly share moparisthebest concerns

I see the same that moparisthebest said, but also I believe this belongs to the IETF (along with 474)

name a maintained server that supports channel binding and not tls 1.3, it's a solution looking for a problem

i mean just do tls 1.3 and be done?

As an excuse, even with clients forcing 1.3, servers are still somewhat likelt to allow 1.2 for backwards compatibility ✏

name a maintained TLS library without 9999 known and published vulns that doesn't support TLS 1.3... if such a client exists it certainly won't implement this xep without adding support for 1.3?

yeah idk. we can accept it and let people play with it?

I'm somewhat hesitant to accept a XEP that I believe shouldn't go to stable (but rather IETF), other than that I agree with daniel

ask the author nicely if he wants to submit it to kitten instead?

i would love to see more activity in kitten anyway

i mean it's not like copy pasting that into an id draft rfc is a lot of work

this requires changing code, if projects change code in 2026 they support 1.3 for free and can simply enforce that instead...

e) XEP-0045: Fix examples for messages from the room itself https://github.com/xsf/xeps/pull/1537

+1

+1

I'm generally +1, but I would like to point out that these roominfo/roomconfig things are confusing as hell and we should try to clean them up somehow

My favorite solution would be to migrate to having the roomconfig form as an additional form in disco info, not to randomly add the roomconfig fields into roominfo without putting that in the registry (which is the status quo) ✏

But that discussion is mostly adjacent to the change (which just fixes one occasion of roominfo/roomconfig confusion)

feel free to start a thread on the list I guess. this would certainly break some code in my client

and/or I would for the next decade look them up in both data forms ✏

Yes, I'm well aware that migration would be hard/impossible

This message has been retracted by the sender.

ok. moving on

But then currently clients already have to lookup multiple things (servers can put roominfo_subjectmod or roomconfig_changesubject in the info)

Am I still able to comment on my XEP? Or any XEPs?

Sorry for network issues

5) Pending votes

none

6) Date of next

+1w wfm

+1w wfm

+1w wfm

Cynthia, usually not during the meeting. but it seems to be on a good path anyway? maybe continue your discussion in the xsf channel or on the list (that gives a wider audience access to it)

7) AOB

assuming none

8) Close

thank you all. see you next week

singpolyma, Does this mean you'll reject all XEPs that don't have an implementation?

I lean that way but I'm no so strict for example if everyone else disagrees with me or if the author is obviously about to implement it or is working closely with someone who is, etc

singpolyma, I mean, I've said I can implement it easily enough. What parts did you think were underspecified?

for example "If a MUC1 client is joining, this will be as normal. For MUC2 clients, this will also include an additional element giving the MAM summary of the room." what does this element look like? what is a MAM summary of the room?

"Not bouncing groupchat messages." I honestly don't know what this line under muc pam is meant to convey. nor in general what is a pam, etc

A MAM Summary is explicitly defined in XEP-0313, so that's a shame. "Not bouncing groupchat messages" - means what it says. The RFCs require servers to bounce (ie, return an error stanza for) groupchat messages sent to the bare jid.

PAM has ended up a term of art, you'll find it mentioned in MIX, and MattJ's GC3 notes.

Anyway, I'll split this into XEPs, and apparently have to implement it before you'll accept it, unlike any other XEP, so...

I have very good experience with a MUC replacement in a single XEP that had to be split up into multiple XEPs and then everyone would be happy, so this is bound to go well.

Absolutely, it's a winning strategy.

larma, "Discussion point" != "discussion venue", by the way.

dwd: sure, but if you want to work out the requirements for MUC2, that's a discussion and that needs to be happening on a discussion venue, a list of potential requirement discussion topics is not what standards track XEPs are about. The only thing I could potentially see is an informational requirements XEP for MUC2, so we all talk about the same issues to be resolved, but that's not what you proposed.

And when it is about collecting issues with MUC that should be solved in MUC2, that sounds more like a wiki page than a XEP.

I'm not sure I agree with splitting it but I guess it depends on the goals. Whether the goal is to have a "muc2" or to have se extensions to muc

To me, it makes sense to have a new protocol baseline for the new protocol. Possibly an additional XEP to describe interop with MUC, if it doesn’t fall out trivially in the wash. But I think splitting it out so it’s all just MUC extensions that tie us to XEP-0045 forever would be a poor choice.

> To me, it makes sense to have a new protocol baseline for the new protocol. Possibly an additional XEP to describe interop with MUC, if it doesn’t fall out trivially in the wash. But I think splitting it out so it’s all just MUC extensions that tie us to XEP-0045 forever would be a poor choice. looks like you are asking for MIX2 lol ↺

I think it makes sense to have a MUC2 that is largely equivalent to MUC1 + extensions and changes are largely syntax, not semantics, which means that it is reasonably easy to maintain interop between MUC1 and MUC2, both on servers (meaning to create a server that allows MUC1 and MUC2 clients to join the same room) and clients (meaning that it's easy to create an abstraction layer on clients which make MUC1 and MUC2 behave the same). The difference between MUC2 and MUC1+extensions IMO should be limited to the smallest amount necessary

if there's any learnings from MIX it's that protocol with no implementation and no backwards interop is utterly doomed from the start, so yea, clearly both should be required to advance the next

I agree, though I'm not in the multi-XEP camp. To me, we already *have* XEP-0045 + a bunch of extensions, and that's part of the problem.

I would like to see a XEP that doesn't depend on implementers reading XEP-0045 and understanding all its quirks (unless they are implementing the XEP-0045 protocol for interop purposes)

how is this "bunch of extensions" a problem? I mean I understand it temporarily makes our "documentation" on the standard less accessible (because people have to know they should implement those extensions), but I'm not sure how that would be better compared to having multiple competing standards (with some incomplete and barely implemented) ✏

Pretty much that, plus it's not really possible (in a way that provides a good experience for the reader) to subtract stuff from XEP-0045

Which would be competing?

Well, if we do a MUC2, even if servers can be created that are compatible with both, what do you tell people to implement for new implementors? The one that means they will not be able to talk to some existing servers and client (that don't support MUC2 yet) or the other that is implemented everywhere? ✏

We do have the sad story in our community of a client that developed all the new things people told them will be adopted soon, and they invested years into creating software that is today incompatible with everything else, requiring them to eventually start implementing the old stuff nonetheless.

That's a fair point

In my mind we already have MUC1 + extensions, and people can (and are) implementing that

and it's good that we're evolving stuff, but it's still rather messy

I am not aware of a lot of clients that implemement only MUC1 + extensions, they usually can somewhat handle living without those extensions

the decision to drop support for servers/clients without that extension would eventually follow once it's widely implemented.

Well, we're already in the situation where clients that don't implement some stuff will have a hard time, but yeah

But this approach also makes it hard to make some more significant changes (such as the addressing)

You can call that "an extension" if you want to, but to me it's a second protocol

and that's really what this is about, to me. Yes, we're making a second protocol, but it's close enough to the first protocol that it shouldn't be hard to implement alongside the first one (especially the first one + extensions)

At least, that's the theory

In truth, as mentioned in my mailing list post, I already encountered multiple hurdles with updating Prosody's implementation

So I don't know, I don't want to speak for other implementations

It's certainly not the same level of difficulty as the couple of attempts I made at fitting MIX on top of MUC, but it's still some work (and more than I expected, but I think I was overly optimistic to begin with)

muc can almost be implemented by a client over c2s, maybe fully unlocking that for muc2 gets us impls much faster? don't need to wait for server or OS updates

that's 1 client/bot per muc room fwiw