XMPP Council - 2026-05-12

It's time

1) roll call

👋

here

Howdy!

singpolyma?

2) Agenda bashing

hello!

we don’t have an agenda for today but we do want to go through some pending votes

3) Editors update

none

4) Items for voting

nothing new this week

5) Pending votes

everyone but marvin technically missing on payment required. but that has already been vetod

idk if anyone wants to cast their vote or say something go ahead

Looks like there wasn't enormous change remaining to get Marvin above a -1, so I hope they resubmit

IIRC, it was "don't use XMPP as a payment type registry"?

OK. My. Desktop randomly decided not to send messages?

I can receive them though...

Someone should complain to the developers while I continue from my phone

> IIRC, it was "don't use XMPP as a payment type registry"? Yes

Moving on.

Emoji markup. Dan and goffi are missing votes

+1

Ah good, I missed the payment-required proposal, and my feedback would also have been to use RFC 8905 (which is exactly what larma responded)

emoji markup. dan and goffi are missing

+1 . that's good basis, but I would like to avoid to send all those elements each time we use a custom emoji, we should be able to re-use/cache somehow. Anyway, that's for standard@ I guess

> emoji markup. dan and goffi are missing Great that was dino sending the message after a restart.. M

New muc. singpolyma, dan.caseley and goffi missing (but also already vetod; but if you have opinions on that maybe voice them and/or cast your votes)

I thought I was -1

ok sorry. yes i remember that too but i hadn’t written it down

wrote it down now

I think Dave's already got the first chunk of replacement as a PR. I'm excited to see this keep moving.

TLS channel binding.

+1

i’m still planning to reach out to thilo to see if we can’t submit that to kitten instead

i guess if that is negative or if i don’t get around to it i'll vote +1 next week before the vote expires

I don't know on this one, +0 following comments from last meeting.

PR 1537

dan.caseley, and goffi

That'"s the MUC one?

yes

+1 then

+1

ok. great. that means that the PR and emoji markup pass and will be published by the editor this week

6) Date of Next

+1w wfm

+1w wfm

+1w wfm

i’m unavailable next week actually. we can probably do a +2w or get larma to chair for me?

+1w wfm

Whatever, I'm fine with both options

I'll miss +2w - I'll be poolside :)

ok. i'm not seeing strong opinions; and i'm also not seeing anything super urgent coming up so i'd say we just do +2w

daniel, I can chair if you send the agenda 😉

but +2w also wfm

+2w wfm

Also happy with either/both though

2w it is

7) AOB

yes

3 things actually

1. Practical thing: where there is an open question like here who is AOB, what about using reaction to say "nothing", so we don't wait we now there is nothing?

2. What do we do with SIMS vs stateless file sharing. I know that there a strong opinions on this one, and both are made by councils members, but it would be good to move on

3. What do we do with MIX? Do we let it go ones hoping for finally adoption, or are we full in MUC2/GC3/Whatever backward compatible, and we should try to deprecate MIX then?

I guess emoji markup for now just uses both which pushes out the decision to what ever gets implemented more?

It's not like I'm super happy with that but in a way that's how it always works anyway?

So we count in X months with DOAP, to see who wins? ✏

The author expressed they would like to only use one, but there was no clear opinion which one

I mean emoji markup doesn't really rely on either right? it's just putting a hash

SFS has the pending change needed for emoji markup to not display the image to legacy clients.

(sorry for all the typos in my bullet points above BTW)

goffi, my opinion on (3) is that no action is currently required from Council. There is no replacement (yet), and it has some implementations (though most are incomplete). As mentioned in my GC3 presentation a couple of years ago, it's possible that GC3 could be a step towards MIX, if we still decide we want that. However, personally, I consider that unlikely if GC3/MUC2/whatever fulfils the practical goals.

I have a serious question which is: can we make jingle FT use 0446? has this been pursued in the past? larma implied it was sort of intended

So if a MUC successor gets accepted and widely adopted, then at some point in the future MIX could be officially deprecated if the community wants that, but I think such a discussion is way too premature right now

also we are runnig a bit up to our time limit. i don’t think we will make any sensible decision on MIX in the next 7 minutes

OK, so there is still hope for MIX

and also a bit what MattJ said

> I have a serious question which is: can we make jingle FT use 0446? has this been pursued in the past? larma implied it was sort of intended Definitely something we could do. I can prepare a PR if you want me to. ↺

larma: yeah... I think if that happens it basically just a "namespace version" bump on jingle ft which is annoying and makes me grumpy, but is something we do all the time anyway. after which point if sims "uses the element from jingle" it uses 0446 and then... sfs and sims become identical specs and I guess I stop caring what we use

my only request is that we collapse what ever change we make to jingle ft into one that allows us to finally make it stable

i really don’t want two more namespace bump

i've implement 3 of them already

I think the blockers for Jingle ft right now are that it described features barely implemented

Yes, I don't really see a reason we shouldn't be doing last call on jingle ft except that I guess author never asked for one?

larma, yes. but that might be an argument to remove some

if they haven’t been implemented for 20 years

but they are good ones 😀 I even think there might be implementations out there somewhere

Maybe Jitsi Desktop 😀

Which features are barely implemented?

idk we can also try to implement them in vienna

goffi, mostly the requesting stuff

request files I presume. though I really want that one

ah I do implement it

needed for file sharing actually

ranged transfers?

do too

Ok, perfect then

my sort of goto implementation would be a request+range as a resume of a failed one from the recipients pov

and that would cover both

maybe for vienna. but dunno

if we have enough experience we can also just call it soon

anyway i think we are getting a bit broad topic wise

Then indeed we can last call Jingle FT I think, maybe check with the authors if they can incorporate feedback (unlikely, as they aren't really active anymore) and if not assign a document sheppard for the last call (I can do that)

When is the Vienna thing? I'm not living too far aways actually. ✏

goffi, july 18+19

but first change the metadata element 😅

i thought i had sent something to the list about that

Hum, will probably clash with my holidays.

> but first change the metadata element 😅 It can be feedback that is incorporated with the last call ↺

ok. let's wrap this up. feel free to continue in xsf@

8) Close

Don't need to do two namespace bumps in case there is other feedback during last call

Thank you all. see you in two weeks

Thanks daniel.

Thanks!

Thanks daniel, thanks all

> Don't need to do two namespace bumps in case there is other feedback during last call yes i think we will require one. but i want to avoid two ↺

Would be great to have finally Jingle-FT stable.

This is a minor, but if we make jingle ft use XEP-0446, we also need to stabilize 0446, so the last call should cover both