XMPP Council - 2026-06-16

This is why I suggested that Council can/should ignore ProtoXEP submissions that "the community" has no interest in. Honestly I don't care whether a XEP took five minutes with an AI, what I care about is whether a significant amount of people want to work on it.

It isn't solving any problem, but it is essentially distributing the workload of deciding if a ProtoXEP is slop or not.

That sounds awfully like Council start getting to decide which problems they’ll allow people to solve with XMPP (standards), which doesn’t sound desirable. I think the quality bar is a better bet than how well represented particular industries/interests are within the XSF/Council.

I hadn't seen that dwd suggested that. But I was thinking if we should replace the proto->experimental process with something that resembles working group adoption

Where we ask our community if they are willing to work on / provide feedback on the xep

Maybe. It would change the dynamic significantly, though, for niche interests. Possibly not so much for the normal Internet chat use cases, but there’ve certainly been a number of cases where the overlap between the XSF participants and the people the spec is serving is small, but the size of community served by having it as a standard is significant.

I do accept that if Council/Editor are overwhelmed by worthless submissions that is a problem that needs addressing somehow, and there might not be an ideal solution.

Maybe something to discuss during the next summit

I mean 'working group adoption' is just a vibe check. Not a vote. So if you respond to a working group adoption call with 'we are an established xmpp service provider and we are going to put three full time employees on the matter' that can probably fulfill the loosely defined working group adoption requirements

Right, I'd hope that Council understand that for some niche cases, it's going to be fulfilled by just two people, and for others it'll need substantially more. If someone produced a ... I dunno, let's say yet another message markup, I'd expect the bar to be pretty high. If someone wanted to do ultra-low bandwidth, it'd just need two orgs. One org putting lots of people on wouldn't satisfy me, to be honest.

Not talking for the editor as he's doing a lot of work that I'm not, but with council hat, I feel the submission rate very reasonable so far. Thing is we have weeks with nothing to vote one, an suddently 3, 4, 5 big things at the same time. We'll see how it will evolve, but so far I don't have the feeling that we are overwhelmed with AI slops.

If Daniel, feels that he has too much work, maybe we can find ways to have more people on it. Does the editor has to be a single person? Could we have some collaborative workflow for that? We could also to things like Council agenda on a pad or something like that. ✏

The Editor is a team, it’s just that we’ve basically never had more than one person willing to do the work at once.

If Daniel, feels that he has too much work, maybe we can find ways to have more people on it. Does the editor has to be a single person? Could we have some collaborative workflow for that? We could also do things like Council agenda on a pad or something like that. ✏

Generally speaking there is a certain amount of efficiency in having council chair and editor be the same person

And the tooling does mean that Editor is less onerous than it used to be. But still definitely not nothing, and worth not burning yet another Editor out.

Is there a "playbook" for new editors to understand what needs to be done, how to run the tooling etc?

I wrote one a while back, I assume it’s still around somewhere, although whether Daniel does smarter things than me, who knows.

it’s time

1) roll call

.o/

👋

singpolyma, dan.caseley are you around?

here

no agenda today. just here for calling on some pending votes and set a date for the next meeting

2) no editors update

3) no items for voting

4) Pending votes

according to my spreadsheet singpolyma and dan.caseley on all xeps from two weeks ago. namely Jingle sync. Xmpp decentralized ids, jingle user location

in addition to that goffi on jingle location

I didn't vote on it already?

(if i missed any votes pleas give a a reminder)

I think that I was +1

yes found it in the history. thank you

Sorry

+1 on all three.

goffi, recorded. dan.caseley recorded

technically the votes expire in this meeting. if singpolyma doesn’t vote the will all pass (since they have at least +3)

I'm very uncomfortable with the location one

fwiw i was going to draft an email that you can more or less just use xep80

xep80 defines the geoloc element and suggest pubsub only as a possible transport

decentralized IDs I see the future of but as written also seems rather prone to issues (it suggests putting these in eg from= on normal xmpp? or at least seems to. which would break all kinds of stuff I imagine)

it is full withhin the xep (though we can add words) to stick that in a message

or in a jingle xml streams if you want

the jingle RTT is the other one? I don't love having a second RTT protocol just for gateways but maybe it's fine. I don't feel as strongly there

i wouldn’t blame you for rejecting jingle location. or i go 0 and you go 0 and then it fails :-)

Did you see the bit from the author in the real time text on the use case? That made me think that location has similar constraints.

i think what i outlined above wrt xep80 is a perfectly acceptable solution to the problem stated in the the intro

well even with the "gateways already speaks this" in RTT case... can't gateway translate? but I'm not as certain

Ok I'm gonna -1 jingle location

+0 RTT

any vote on xid?

(i recorded the other 2)

I sort of feel like a xep that actually uses XID would make what XID is for and how it should be written more clear

but in the spirit of "no one cares about experimental" maybe I should just assume such will exist eventually

actually uses DID you mean?

is there a xid?

Whatever the protoxep is called now. I thought it was xid. anyway, yeah, the fact that it seems partly/fully overlapped with DID too also gives me pause

I've answered to that on standard@, beyond the complexity of DID, DID could anyway be used with a different prefix byte. Current version us algo already implemented for OMEMO in most clients.

Oh right. I forgot it's a roll-your-own-crypto tied to AESGCM besides also my other concerns

I don't like how many of goffi's xeps I've been responsible to -1 for 😛 I do like you goffi and I appreciate your work

I think I'll +0

is this tied to a grant, goffi?

> I don't like how many of goffi's xeps I've been responsible to -1 for 😛 I do like you goffi and I appreciate your work ah ah, no bad feeling don't worry 😉 ↺

> is this tied to a grant, goffi? this part of serverless grant indeed: https://nlnet.nl/project/ServerlessXMPP/ ↺

ok, then nevermind. +1. go get your grant money

I don't think that a rejection would block the money anyway

I'm sure it won't actually

singpolyma: OK thanks

Moving on

5) date of next

+1w wfm

Fwiw a +0 would have made it pass too. But that's alright

+1w wfm

+1w wfm

6) AOB

edhelas has made a PR to change XMPP Pubsub URI, should the council vote on it or is it just an editor thing?

I'm very in favor of it BTW, it's about adding `pubsub#type`

The PR: https://github.com/xsf/registrar/pull/52

You could discover that but I guess it's nice to have a hint in the URI maybe

You need an extra request on the server, for one it's not a big deal, but it's nicer not to have too.

Anyway it's already 18:00, so I guess we'll see how this PR evolves.

OK.

7) close

Thanks!

Thank you all. See you next week