XMPP Council - 2026-02-10

It's time, isn't it?

I was gonna say the same 🙂

I was waiting for someone else to say it 🙂

Daniel seems to be missing. I hope that everything is fine. I think we have pending votes on contacts e2ee on the agenda, and probably not much else without editor.

So what do we do? We do the vote without chair? singpolyma are you around?

Sorry I'm here now. Thanks for the ping

oh great

I am here

Sorry I'm very much unprepared.

But yes the e2ee contacts is ending today

And we could start voting on the one singpolyma submitted

Although I didn't send out and agenda so I would all give you three weeks on that one

Have we got space to quickly talk about the maiinging list stuff on Contacts e2ee?

I had one lingering concern that 2 developers couldn't go into 2 rooms and come up with 2 compatible implementations

> Have we got space to quickly talk about the maiinging list stuff on Contacts e2ee? Yes let's do that

Because of the unspecified encryption

Who's votes are we missing by the way?

mine I think

And mine

I guess I said most of the things I wanted to say but (reluctantly) voted +1 anyway

I like the idea generally I'm just a bit concerned... but OTOH I guess we're supposed to say numbers are cheap and the whole xep may be rewritten out from under us after approval anyway, so it barely matters what it says at this poing...

Is there anyone else who wants to say something

dan.caseley (author hat), what do you mean unspecified, it's specified that it's using OX for pubsub, with room for futur algorithm if anything better. Namespace is here to handle the case.

Note that I'm very open to massive change, it's a starting point for me. I'll notably change the group thing to the same thing as roster, following talk on standard@ (just didn't wanted to change while being evaluated by council).

You're right. That is in there. Missed it. I retract my concern 😃

I failed to write this on list I think, but I hinted at this at summit already that I firmly believe one should essentially remove all the "do encryption" from this specification (making it a generic "put your contact list on pubsub" specification) and on top of that create a specification for how to apply encryption to named pubsub nodes in a generic way

is that not basically what the referenced pubsub encruption xep does?

but I agree with larma

larma, I've missed part of the summit, and was not in good state (still recovering actually), so I've probably missed your point at summit.

Ah yes I remember talking about this with you.

I'm just not sure of the point of this if we don't have mandatory e2ee

I general I agree with larma as well. At least as far as better defining pubsub encryption

Not sure if I'll like the specific xep better after that

> I'm just not sure of the point of this if we don't have mandatory e2ee to store extensions for roster somewhere? ↺

larma: I forgot did you vote on this xep yet?

> I'm just not sure of the point of this if we don't have mandatory e2ee I guess that goes back to what I said the other week that we don't have enough pieces of the puzzle yet. I mean surely wrt avatar and vcards and stuff we really need a better pubsub encryption

But if we don't make e2ee mandatory on that, some client will publish in clear, that's a concern IMO. ✏

> is that not basically what the referenced pubsub encruption xep does? the OXPS only describes how to do encryption on a node, it does not describe how to discover the encrypted variant of a named node. So you couldn't use it out of the box to encrypt, say, the bookmarks node, because there is no defined name for the OXPS encrypted bookmarks node ↺

> larma: I forgot did you vote on this xep yet? I'm not sure if I did, but I would still give it a +1. The current specification isn't really tight on using encryption, so removing that would actually be trivial ↺

> But if we don't make e2ee mandatory on that, some client will publish in clear, that's a concern IMO. I believer there is usecases of "contact list" beyond roster and encrypted contact list. For example I could have a shared contact group (which right now is only possible via non-standard shared roster groups in some servers afaik) ↺

For now, the way to know if a node is encrypted, is to get an item and chech the namespace, and you need at least one encrypted item. I guess a note metadata field would be good. I'm not sure if it would be necessary to use dedicated namespaces though (ideally, all non public node should be encrypted).

larma: OK. I'm writing you down as a +1

could we allow multiple items each with different encryption if needed?

for compatibility with apps that support one or the other of the eventual options

singpolyma, seems reasonable, yes.

(actually I don't. I'll try to figure out how everyone voted from history when I'm at a computer in an hour)

+1 from me

ok, I think I'm +1

OK. Thanks.

So it'll get a number but we all expect it to be a lot more work

So to summarize the changes requested, remove the group thing, make e2ee separated (or suggested, with a dedicated node?), allow several contacts per items. that's it?

would be good to have that on standard@

> For now, the way to know if a node is encrypted, is to get an item and chech the namespace, and you need at least one encrypted item. I guess a note metadata field would be good. I'm not sure if it would be necessary to use dedicated namespaces though (ideally, all non public node should be encrypted). That's only possible for clients that do support encryption. Say I wanted to encrypt the XEP-0118 User Tune, if you just put an encrypted item in the regular http://jabber.org/protocol/tune node, it would mean that clients not supporting encryption would get useless notifications and also if you have any other clients that supprot XEP-0118 but not encryption, they might be inclined to overwrite the encrypted "garbage" as it is not XEP-0118 compliant to store encrypted items in that node. ↺

sure, that was expected since I've published. It's a thing which needs a lot of feedback to get right.

Everything else I've got is standards pedantry i think (e.g. make the encryption method a SHOULD) - I can engage in that stuff via DM or on GitHub

larma: yes please post that to standard. I mostly agree with you. But that's probably out of scope for today meeting

> So to summarize the changes requested, remove the group thing, make e2ee separated (or suggested, with a dedicated node?), allow several contacts per items. that's it? several contacts per item seems bad to me... did we not learn this lesson from bookmarks? ↺

yes please on standard so I can check all for the next revision.

Anyway moving on

Sorry for the very unstructured meeting

singpolyma, not all contact, just several. It's to separated number of items from number of contacts, so that can't be guessed (that + the <reserved/> element). ✏

Items for voting A) Link Metadata https://xmpp.org/extensions/inbox/link-metadata.html

+1

singpolyma, not all contact, just several. It's to separate the number of items from number of contacts, so that can't be guessed (that + the <reserved/> element). ✏

+1

(but again I'm giving you 3w so absolutely feel free to be on list or vote next meeting)

If you didn't happen to read it when editor send out the email

haven't read yet, will vote next meeting.

+1

I'm +1 for now but would want to express that I would also like to see this split in two, one that is a generic "Linked Data in XMPP" that describes how to use RDF/XML in XMPP in a more generic sense and one that is "OpenGraph usage in XMPP" that's probably actually just Informative to make sure people are aware that opengraph can be put in there (but doesn't actually describe any standard, because it just builds on top of the linked data)

Date of next

I can't do next week

So I would suggest +2w

+2w wfm

+2w wfm

+2w wfm

+2w wfm

AOB?

Looks like none

Close. Thank you all. Sorry for being late and unprepared

(feel free to ping me earlier next time)

thanks