XMPP Council - 2026-06-09

There are no new agenda items but we will have a meeting today and go through pending votes and AOB

Apologies for late notice, but a kid thing has happened, and I need to go do uncle things. I'll miss the meeting. Will be On List and get my votes sorted before next week.

no worries. I think this is going to be a short meeting anyway

👋

It’s time

1) roll call

i've already seen larma

.o/

is singpolyma around too?

i guess not. moving on

2-4) no agenda bashing. no editors updates. no new items for voting

5) pending votes.

a lot. everyone on the two jingle ones. everyone but goffi on xid

i'm +1 on xid.

+1 on https://xmpp.org/extensions/inbox/jingle-rtt-sync.html

there has been feedback. which i hople will be addressed. but there is enough there to start the work

+1 on https://xmpp.org/extensions/inbox/jingle-geoloc.html but I think that PEP is sufficient here. However it's good enough for experimental IMO.

> there has been feedback. which i hople will be addressed. but there is enough there to start the work Will be addressed, definitely, lot of valuable feedbacks. ↺

i think both jingle XEPs have some questions to anwser wrt to the use case. i mean on one hand i kinda see how one runs into that problem. but i’m also wondering if there isn’t a more elegant way to do this

for example but not necassirily with xml streams over jingle

but i still think there is value in getting this under xsf control and colab on that

+1 on both

larma, any votes? otherwise on list or next meeting is fine

I see some risks with xid due to breaking backwards compatibility by assigning a new meaning to jids. But maybe it's something to see if it causes issues in practice, so let's +1 for now

jingle-rtt-sync has some aspects that make sense to specify, so let's +1 for now and sort out the how later.

jingle-geoloc I will vote 0. The specification as is is entirely incompatible with the Jingle framework and it's unclear to me what the goal is (sending geoloc via jingle or sending geoloc in-band) ✏

i get the premise wrt stop sharing when the calls ends and stuff. doing that with access control on PEP is non trivial or risky

but yes i wonder if that could be a more straight forward to 0080 instead of binding that to jingle

moving on

Also Pubsub e2ee is barely implemented (I think that Libervia is the only implementation), Jingle is e2ee

not as far as this spec is concerned...

I need to check, but it's not a matter of having the transport encrypted?

it's session-infos; not jingle xml streams over the transports for example

(which would be e2ee)

Oh, OK.

and i guess my proposal for that problem

That's a problem then.

6) Date of next

+1w wfm

+1w wfm

+1w likely won't work for me

ok. let’s keep it on the calander and see who will make it

7) AOB

It would be to have your feedback on standard@ about the URI proposal by edhelas.

Re geoloc: we can also specify sharing geoloc in messages (optionally encrypted via SCE), which solves access control easily (just stop sending) and is effectively what is currently described just without the need of doing anything with jingle.

Notably I don't think that removing `node` is a good idea, but the pubsub type is definitely good to have.

> It would be to have your feedback on standard@ about the URI proposal by edhelas. +good ↺

(*sigh* "last" message correction)

larma, yes. and/or which can also be shared via jingle xml streams if for some reasons you really want to move that over jingle

goffi, i'm not sure i’m following

is this an AOB or can this just be an email on the list

It's just a nudge on his email, if you haven't noticed. As it's a proposal to modify XMPP scheme (add a a new key which, but most problematic, remove the "node" for a pubsub node which is not a great idea IMO).

But yes is should be on the list, not here.

ok.

assuming no other AOB?

8) Close

thank you all. see you next week

Thanks

Sorry I got called away right at meeting time

Geoloc especially I'm very dubious about