XMPP Council - 2026-04-14

I am still to address Mattj's feedback on XEP-0377. I'm aware of it but struggling to set aside the time to look at it. Partially (which doesn't address all of Matt's comments): Rationale for removing the wording on reusability was attempted to be explained in a mail that I sent earlier: I'd like the XEP to pass as-is, without _additional_ modifications to facilitate reusability explicitly (which could hurt existing implementations). I'm not _against_ it being re-used either.

I'll follow up on the mailing list eventually.

I don't think anything additional was needed for reusability for it to pass? Might just be helpful if the wording was like "as with all XML namespaces, this is a useful reusable element which others XEPs may use. Here we define a first use with blocking command"

iirc a lot of the original feedback was 'please make this more re-usable before having it pass last-call'

It's time

1) roll call

.o/

Howdy!

2) agenda bashing. Editor was a bit lazy so we don't have anything on the agenda today. No pending votes either. I'm just going through it for date of next and for calling for AOB

👋

3) date of next

+1w wfm

+1w wfm

+1w wfm

+1w wfm

4) AOB

Maybe briefly about 377?

> I don't think anything additional was needed for reusability for it to pass? Might just be helpful if the wording was like "as with all XML namespaces, this is a useful reusable element which others XEPs may use. Here we define a first use with blocking command" Personally I generally like that the XEP is now narrower in XEP. I think it's fine that this isn't a huge generic framework that we are never going to finish

+1

Making not that some of the elements can be reused by other XEP won't hurt though?

Basically what singpolyma suggested kinda

Everything that was huge and generic that started in the last ~10 years never crossed the finish line

*narrower in scope

I'm excited about https://github.com/xsf/xeps/pull/1527

I hope this was a joke ;)

I can't wait. There's some good stuff in there.

Other thoughts on 377 so we can give Guus some guidance?

But I'm also expecting some rigorous conversation around it

I am *hoping* for some rigorous conversation around it.

Or should we leave it to the list? (however at this stage in the process council should probably give some direction imho)

Sorry for hijacking. I thought you were done on '377. I don't have anything on that.

OK. I'm taking everyone elses silence as agreeing with my position then...

dwd, dan.caseley: it's like 3 or more things at once that absolutely don't need to. They could all be independent extensions to MUC.

Well, I have no obvious objection, so nothing to say

OK. Any other AOB?

larma, That's absolutely a possibility. Happy to go that route if that's what Council want.

Assuming none

5) close

Thank you all. See you next week

Thanks

dwd: I was planning to submit something myself eventually regarding the IMO most needed aspect of it (the presence flood)

Yes agree no need to add more things to this xep. Xep for doom is bad. Just to say the element can be reused (we already have another xep doing this)

Daniel: thanks

Thanks all

larma, Specifically the flood on join?

dwd: no, also while in the room. It's a major blocker for effectively having rooms with large amounts of users. I remember there was a proposal at summit in the context of spaces, as presence list in multiple rooms in a space is often identical, so it's really mostly duplicated presences. That's the main reason for me to properly spec this as people doing spaces (especially bridging them from discord, where thousands of users in a room is common) seem to believe it's needed. The not receiving presences part is easy (both to specify and implement), but the logical next thing to do would be to allow paginated access to the current presence list, which is a bit more work.

In such big rooms does one have a use for presence or is members probably more the thing? AIUI when a room gets too big on discord it stops showing presence and just uses members

The largest discord server I am in has ~6000 members and even in the room where all of them are a member I can scroll through the user list and see presence for everyone (with pagination on the c2s, although they make it a single scrolled list in the UI)

Interesting you still see green dots etc in 6k room? Maybe it's an option then and not automatic by size. I always thought it was by size

You still need some presence push for that no? At least for whatever part of the list you see at the top

larma, I was thinking the other day of XEP-0237-ish deltas, too.

yes (although most dots are not green of course :D). Might be an option or maybe is different on mobile vs web client (I just checked on web)

yeah, they do push presence updates on the subsection of the list that is displayed (and also when the list changes they add/remove items from the list subsection) ✏

dwd, we do have that for affiliations already, I'm not sure how easy it is for presences really.

Also XEP-0436 for presences apparently

Oh. TIL, etc.

But XEP-0436 probably only reasonably works in very small rooms (if you are temporarily offline in a large group, the changeset is likely to big for the server to allow you to catch up, so you would need to do a full resync)

Yes, but if the server can "trickle" the updates rather than flood before you can even start to see messages, this might be preferable.

> yeah, they do push presence updates on the subsection of the list that is displayed (and also when the list changes they add/remove items from the list subsection) Do we know that, or inferring from the UX? I do agree the UX looks that way, just asking for interest.

Or, indeed, as you say, a "Spaces" MUC might only bother with one set of presence - though that's possible to do client-side in the existing MUC2 sketch.

Also nothing XEP-0436 can provide in its current form (the presence logic is largely the same and if you resync you have to also fetch everything first before being joined)

larma, True.

> Or, indeed, as you say, a "Spaces" MUC might only bother with one set of presence - though that's possible to do client-side in the existing MUC2 sketch. Yes, I would personally be fine with really just a spec as a starting point where you add something to the <x/> that says I don't want presences at all. ↺

It is covered by your MUC2 starting point, but the whole nickname story in it makes it significantly more complicated

larma, Yes, I accept that. Everything could be split up, certainly, though we'd then need a profile XEP to baseline everything again.

Yeah, I'm all in to create a MUC2 eventually (potentially even in a way that isn't build as an extension to MUC1), once we have those things ready. I just want to get thing rolling and I don't see it happen if we aim too big.

larma, That's entirely in line with my goals.

There was the Worcester sprint in 2024 where we discussed a lot about MUC2 and eventually none of this led to anything yet (not blaming anyone), likely because we considered too much and everyone's needs at once.

There is a continual and dangerous risk of becoming MIX2 instead...

Here's the notes from sprint back then in case anyone wants to read: https://pad.nixnet.services/WJm97HA9SJaURGhxNqGOcA?view

>> Or, indeed, as you say, a "Spaces" MUC might only bother with one set of presence - though that's possible to do client-side in the existing MUC2 sketch. > Yes, I would personally be fine with really just a spec as a starting point where you add something to the <x/> that says I don't want presences at all. I guess the reason to this from client instead of as an option on the MUC is because your client knows it implements the needed things to still show members etc without this? ↺

Yes. Having this decided on the MUC (which we already can) isn't super helpful because the MUC admin doesn't really know what the clients will do.

Unless the MUC is too big and just needs to make this call

Sure.

But I personally would already see me doing it for significantly smaller MUCs.

my 1k participants MUC is mostly ok with presence still on. We do have one edge case where it completely kills prosody though haha

There's really no need to always fetch and keep updated the presence list of a room that I'm mostly idling in.

(specifically if our network blips server side or any largish remote server blips on their side the mass of hundreds squared unavailable presences takes down our server)

yes true. I've thought before may even something like CSI where I tell the room "ok I'm looking now send me all the presence" and "I'm not looking don't send presence but keep sending other stuff" or something

Which would be pretty easy if we do this via an additional element in presence because you can just send an updated presence to the room where you change the setting.

(and potentially even indicate idle vs active state in the presence to the room if you want to do that) ✏

Right. That sounds nice