XMPP Council - 2026-01-20

It's time

1) roll call

Hi!

.o/

Marvin is still on vacation (not pinging him) but do we have singpolyma?

2) agenda bashing I didn't send one out but I would like to start voting on encrypted roster

3) editors update

I merged a few PRs that cleaned up some bugs in the xeps and added entities for authors and stuff. I consider all of them editorial

But I don't know let me know if you spot anything unusual as a result of that

Roger

4) items for voting

A) Proposed XMPP Extension: End-to-End Encrypted Contacts Metadata https://xmpp.org/extensions/inbox/contacts-e2e.html

+1 mostly due to my general policy on if there is enough text to implement it it can get a number. But note my several objections on the list

Daniel, have you seen my last message about allowing several <contact/> per pubsub item. Would it be an acceptable middle-ground for you?

I'm starting to think this might not belong into pubsub at all...

+1 (I'm the author). But if there is another solution for it, I'm open to evaluate. I would try to avoid 2 XEPs if we can reach consensus, but OK to accept another one if it's the best way to find a good solution, as I've said on standard@

I'll be honest, I've only caught up and read it in the last hour.

Clearly, there are practical implications on list already.

I'd like to see some typographical improvements that I'll share on the list.

dan.caseley: we have two weeks to vote so no worries if you want to take your time

My biggest concern is around the design being for a "serverless configuration" that isn't specified - not tying a contact to a JID gives me concerns that this might not be possible to implement right now. What am I missing? (tell me to go to list with this too if you want to keep this moving faster)

Yes I haven't even responded to the no jids thing. I mean serverless messaging fine. But if we want to address it as an entity on XMPP it needs some sort of jid, no?

I think “This is more complicated than it needs to be because of an unmet requirement” is a reason for things to have been rejected or delayed in the past, perhaps seeing the non-roster case specced would help? (from the peanut gallery)

If a serverless system doesn't fit into jids we better fix that somehow

The issue with JID (in its current use) is that it's tied to domain, and that what I want to avoid. But it's still possible to use a JID in <identity> element, just not mandatory. But I guess discussing this on-list would be better, more eyes.

Will do!

The other things, is what if the contact move from a server to another?

The only way to match is then some kind of cryptographic fingerprint, right? We need that to identify the contact. ✏

I guess those are all valid questions and I'm not deep enough into those things to have an answer. But it feels weird to fix that only for encrypted rosters?

Seems like we want something that works for both old and new rosters

(I guess old and new is a very misleading terminology. But you know what I mean)

Indeed, users migrating between servers is a problem that could be tackled. It's not something I'm aware of being tackled in XEPs elsewhere. I guess the roster is the first place you _could_ fix it, from the POV of a human contact moving between N JIDs, and how you associate those.

To me RFC roster will only be used for presence subscription and maybe blocking users, and it's tied to the server anyway. The e2ee version will be used for every other metadata.

> I guess those are all valid questions and I'm not deep enough into those things to have an answer. But it feels weird to fix that only for encrypted rosters? roster is first step. ↺

Another solution is to abuse JID, as I've said on standard@. But we can't match regular JID and fingerprint at the same time then.

I mean we (or I) don't know what serverless messaging looks like exactly. So we can't provide input for that

I mean maybe we do serverless messaging and move and stuff first so we know the requirements for encrypted roster

Seeing how close we are from summit, I think we should discuss that there, if enough people are interested.

I'm fine by putting this protoXEP on hold for a moment.

Anyway I think as chair I should say that we should move on. It's better to have those more detailed discussions on the list

Or at summit

indeed

So we have a record of them and other non council members can participate

5) pending votes

None

6) date of next

+1w wfm

+1w wfm

+1w wfm

7) AOB

nothing on my side.

Nope!

8) close.

Thanks!

Thank you all. See you next week

yep, at the meeting then IRL.

FWIW, from a server with roster groups point of view, I wouldn’t want to replace the current roster’s use of names, and from both server and client’s point of view I wouldn’t like to split the roster information between the roster and a pubsub node, and from a server and client’s point of view I wouldn’t like to lose the roster properties like roster versioning etc. Not that this is a reason to not publish the XEP, but I don’t think this is some panacea roster metadata replacement.

Kev: the fact that this isn't for everyone btw makes me less worried about the size constraints that were brought up on the list

Because some people don’t want it, it’s ok for some people not to be able to have it?

> Anyway I think as chair I should say that we should move on. It's better to have those more detailed discussions on the list does that mean we're not voting now or we still want the vote open? ↺

I don't think there is panacea solution anyway, we have to maintain backward compatibility. However, i think that this is a feature we need if we want to reduce metadata (I often see people criticising XMPP for this). In many use cases, this is not necessary though (e.g. I don't thing e2ee encrypted contact is necessary for most team work use cases).

singpolyma: I meant move on with the meeting

The voting is open for the next two weeks

this seems like basically bookmarks2 but for non-mucs since some have decided bookmarks2 is only for mucs? I think there is a lot of overlap with discussions around how to handle extended metadata for contacts generally

ok, cool

singpolyma, I would very much be interested by your input on this. May you write it down on standard@ so we can discuss this with the whole community there?

yes for sure, I will go read the thread now