XMPP Council - 2024-06-18

if it's unique to the user, if a user has multiple clients, both clients should use the same string, otherwise they will look like different users, no?

Only the user's only client uses this string. You never generate an id for anyone but yourself

Oh I see what you're saying. Hmm

Maybe you're right. I wonder that they haven't thought of this for the main spec but I guess it's because they only have one implementor on their protocol. Ok, I will think more about this and probably add a line to spec this. Thanks for your patience in explaining

I guess they just put the users email address. I actually think they once had that in the spec to put the email address there (which is why it's called selfAddr)

yes, it used to say to put the email address, and then when I came in they changed it to what it says now, but I think they also were considering to do some kind of per-widget id for anonimity (though this seems not needed since the widgets can only communicate with other people who already know your id anyway...)

Not in a muc?

moparisthebest: in a muc the others still know your in-muc id

anyway I've talked to them about it and despite the wording they are indeed still just using email address. I'll add a section about this

Ah yes, different jid though

It's time

1) roll call

👋

hello!

👋️

1) Roll call

It’s time

Hi

singpolyma, larma?

disregard the two roll calls. my dino got disconnected and resend those after a restart

2) Agenda bashing

any changes to the agenda?

I assume not

3) Editors update

* Proposed XMPP Extension: Chat notification settings (https://xmpp.org/extensions/inbox/notification-filter.html) note that this has already been updated to 0.0.2 after list feedback * Proposed XMPP Extension: WebXDC (https://xmpp.org/extensions/inbox/webxdc.html)

4) Items for voting

a) Proposed XMPP Extension: Chat notification settings (https://xmpp.org/extensions/inbox/notification-filter.html)

+1

+1

+1

Concerns me a bit the MUST NOT seems likely to be deleted by existing things that don't yet implement this... But +1

b) Proposed XMPP Extension: WebXDC (https://xmpp.org/extensions/inbox/webxdc.html)

+1

There's definitely missing stuff too. I don't know how a client or server could complete a full implementation from this XEP, but it's certainly interesting enough to proceed.

moparisthebest, it's in the extensions block and extensions should be kept, no?

+1

+1 though I'd like security considerations to link specific things, ideally maintained on webxdc, but otherwise we can enumerate them, the awful 9999 webrtc hack comes to mind

For notify settings, I wonder if in the end we might want to have an iptables-like rule system, because now it's unclear to me how different rule elements and advanced elements interact, and what happens if they're conflicting

> moparisthebest, it's in the extensions block and extensions should be kept, no? I guess... The "such as extensions" is pretty vague :/ ↺

dan.caseley, do you want to cast your vote now? or are you on list?

hi

+1 I don't like WebXDC as a concept. Something icky in the 'executable through chat'. But I don't think my taste is a reasonable objection :)

I'm a bit concerned that https://xmpp.org/extensions/inbox/notification-filter.html has no implementation attempts yet and contains things which don't directly apply to obvious cases (such as 1:1) chats

yeah i don’t like it either. but better to have it standardized for clients that do want to use it

c) XEP-0045: Add punctuation to improve readability (https://github.com/xsf/xeps/pull/1344)

Yeah, security considerations of webxdc spec definitely needs some updating before it can move forward, but good enough for now

i think this is editorial but I wanted to run this by you anyway

+1

WebXDC: +1 from me obviously :)

The no implementations I'm not a fan of either but not blockable for me

+1 for Guus' weeks of hard labour

0045 punctuation: +1

+1 on c)

+1 on c)

d) XEP-0153: Add missing EMAIL/USERID element in example (https://github.com/xsf/xeps/pull/1348)

on list

d) +1

+1

Hmm yea on-list, wonder what implementations do...

It's an example in 153, not in 54, FWIW.

The examples in 54 are correct, AFAICS.

d) +1

what Kev said 🙂

So it's 153 giving an example of 54 protocol and getting it wrong. This feels safe to me :)

yes I’m +1 too. used the last 3 minutes to verify that :-)

5) Pending votes

none

6) Date of Next

+1w wfm

+1w wfm

+1w wfm

I'll trust you all I'm +1 on d) then too :)

+1w wfm

7) AOB

None here

None

8) Close

Thank you all. See you next week

Thanks daniel and all!

Thanks all 👋