XMPP Council - 2025-10-14

Wow this week has been busy 🙂

Hi

It’s time

1) Roll call

.o/

Howdy! 👋

👋

singpolyma, ping

2) Agenda bashing

Can you add an agenda item for the Council to decide whether to review the draft blog post "Towards Secure and Interoperable Healthcare Chat" and, if so, to provide feedback?

+1

Was gonna suggest the same

lot of items to get through. let's see how we are with time after the existing items

me too :)

but yes

3) Editors update

- UPDATED: XEP-0060 (Publish-Subscribe) - UPDATED: XEP-0248 (PubSub Collection Nodes) - UPDATED: XEP-0070 (Verifying HTTP Requests via XMPP) - UPDATED: XEP-0471 (Calendar Events) - UPDATED: XEP-0472 (Pubsub Social Feed) - UPDATED: XEP-0505 (Data Forms File Input Element) - Proposed XMPP Extension: No-reply JIDs - LAST CALL: XEP-0440 (SASL Channel-Binding Type Capability)

sorry by the way something went wrong with one of the changelogs. i don’t know why that is

a) Issue Last Call on 'XEP-0485: PubSub Server Information' https://xmpp.org/extensions/xep-0485.html

+1

+1

Sorry, I've had not time to check anything unfortunately, I'll vote next week on all items.

larma, ?

+1

b) XEP-0392: Add missing information needed to compute test vectors https://github.com/xsf/xeps/pull/1465

+1

+1

(although the actual technical details are on trust)

Hi

Here

a) +1

+1, also I think meta information on test vectors are not normative and thus that is editorial and probably wouldn't need council

b) +1

Doesn't hurt to ask though ;)

c) XEP-0060: Unmarking 'subscribe' and 'publish' features as mandatory https://github.com/xsf/xeps/pull/1467

+1

on list. (i read it. it's probably fine. but gonna think about it some more)

+1

+1

It's an excellent spot in the inconsistency. Surprised it's survived this long!

d) XEP-0060: Describe the 'http://jabber.org/protocol/pubsub' disco#info feature https://github.com/xsf/xeps/pull/1468

on list

+1

On list

+1

e) Proposed XMPP Extension: No-reply JID https://xmpp.org/extensions/inbox/no-reply-jids.html

+1

+1

the feature is clearly needed. i don’t know if there are more elegant ways to do that... something something identity. but a good starting base for discussion

+1 I was expecting to find server sided rules here too.

I have at least one case where receiving chat messages is a fallback only so this doesn't 100% do my case but it seems a good step

+1

5) Pending votes

Dan on: - XEP-0045: Fix 'roomsecret' field inconsistency (https://github.com/xsf/xeps/pull/1464)

+1

Sorry for lateness

sorry that was actually pending last week already but i forgot to put it on the list

6) Date of next

+1w wfm

+1w wfm

+1w wfm

7) AOB

seems we are good on time

so the blog post

personally i don’t know if council should have or needs to have an opinion on that

Board are also reviewing, I think? Unsure if this needs council.

seems like marketing honestly (not in a bad way)

And more eyes are good

yes board can (and/or should) review that

They asked for out opinion in the comments, not really a vote.

It's because it's in the name of XSF I believe.

It was suggested on the PR that both Board and Council look at it, which is why I've asked about it here. It'd be helpful if Council could at least leave a comment on the PR in response to that request, if only 'we don't think we need to review it' if that's your conclusion.

dwd asked for an explicit review. thats more than a comment

yeah i'm happy to post that we think we don’t need to review that

Maybe we should go the other way, and say that we explicitly have no objections to this?

i mean with my non council hat: I read it. seems fine

As long as there's no technical stuff there you think shouldn't be, that's great.

I've tried to draft the post as _examples_ of a technical implementation, and not so much as a normative reference (which I think is where Council could come in). Nonetheless, I'd appreciate you going over it to spot any absolute errors or omissions - maybe not as a vote-thing, but as general feedabck.

It invites technical collaboration

dan.caseley, i vaguely feel like we shouldn’t rubber stamp things if we don’t have to

The collaboration part may well involve council in the future

> Maybe we should go the other way, and say that we explicitly have no objections to this? 👍 ↺

anything from the other council members?

> dan.caseley, i vaguely feel like we shouldn’t rubber stamp things if we don’t have to OT: Why not? Especially if you are invited to? ↺

I need to read it more carefully, but at quick glance, it seems fine to me. I'll try to read it later today and comment on the PR.

> It invites technical collaboration You can also make any other statement if you want to. ↺

ok read it: tell me next meeting if we should a) say it doesn’t need our review b) we should review it. in case of (b) i'll start a vote?

If that could be done on-list, that'd be nice, as to not prolong things to much.

personally i'm leaning towards (a)... but (b) is also fine

(I don't intend to enforce review by Council, I just would like to understand, because input is of course appreciated)

ok. I'm not hearing a lot from other council members except this one upvote. so any other AOB?

assuming none

8) Close

thank you all. see you next week

Thanks daniel, thanks all.

Thanks! Sorry to keep you busy :)

Reminder that clock's ticking for nominations for the next Council

I'm going to be in a different time zone next week. Someone ping me if I mess this up again and the meeting is about to start

Not that I intent to, obviously

Guus, emus, daniel, I've read https://github.com/xsf/xmpp.org/pull/1576, I agree with the general text, and I don't think that council need to vote on it. Do we need to write something on the PR? Shoudl Daniel do it?

goffi, you don't need to do anything. I just understand it as kind request to take your chance. And that is of course welcome to hear your voice as you may formulate details better and more convincing. So, many thanks!

And you can just comment or PR right away if you have additions

goffi: thanks. To avoid potential conflicting opinions being written down and confusing things, I'd suggest that council speak with one voice if they want to review that text (probably through the Council chair), in a comment on that PR. If you want to provide feedback on the text on a personal level, you could explicitly mention 'council hat off' or something.

yeah it makes sense that Daniel, write the comment, and we apparently all agree .