XMPP Council - 2022-10-19

daniel: can we add https://github.com/xsf/xeps/pull/1188 to the Agenda?

ok

Now that's a list to vote on!

o/

/o\

👋️

o/

moooommmm the ecosystem is moving again!!!

don't moxie me!

Either my Dino or my notebook has connection issues

Give me one second

perhaps both!

It's time

1) roll call

is jonas’ around?

aehm

wonder if they are fixed now...

well that message came through but that's all I can be confident about

two generals?

yes plus a few delayed ones

ok. I think we are good now

2) Agenda bashing

larma wanted to add https://github.com/xsf/xeps/pull/1188 - I suggest we just do that as an aob

3) Editors update

- Proposed XMPP Extension: PubSub Social Feed (https://xmpp.org/extensions/inbox/pubsub-social-feed.html) - Proposed XMPP Extension: OpenPGP for XMPP Pubsub (https://xmpp.org/extensions/inbox/pubsub-encryption.html) - Proposed XMPP Extension: SASL SCRAM Downgrade Protection (https://xmpp.org/extensions/inbox/xep-downgrade-prevention.html)

4) Items for voting

we have a long list today

a) Proposed XMPP Extension: PubSub Social Feed (https://xmpp.org/extensions/inbox/pubsub-social-feed.html)

lgtm on first glance but want to take a closer look. on list

I'm +1 here I don't even have nits

I note it references (and uses) XEP-0071 (XHTML-IM) ✏

on-list

which I'm not opposed to, nowadays I believe the deprecation of XHTML-IM was a mistake

I'm +1

this seems like a reasonable embedding of Atom

can we de-deprecate it?

Ge0rG, we can do everything, if need be, if we can get Board on board

the only thing I'm missing is words on how this relates to ActivityPub

but that's no blocker

sorry, I wasn't being very serious.

I'm on-list

just my 2 cents: I thnik deprecating it for pure IM cases was a good thing, but for other things like social feeds, it should still be possible to use it...

b) Proposed XMPP Extension: OpenPGP for XMPP Pubsub (https://xmpp.org/extensions/inbox/pubsub-encryption.html)

on list

let's not go into that rabbithole :)

on-list

on-list ✏

I have some comments like it should probably specify at least some PGP algorithms that should *not* be supported, but so should OX, generally lgtm though, I'll bring it up on-list

is this a +1?

on-list :) sorry

ok :-)

the signature thing has been raised on-list already, and there's something in the making for that IIRC

+1, although I'd love if it was mentioned in title/abstract that this only supports encrypted content (it can't be signed only). Also I started to dislike OX in general (from original being a fan) but that's another story 😉 ✏

c) Proposed XMPP Extension: SASL SCRAM Downgrade Protection (https://xmpp.org/extensions/inbox/xep-downgrade-prevention.html)

on-list

I have mixed feelings about that. I'm not really sure it fills a gap in the xmpp protocol

yuck, another "try to protect password from MITM'd TLS" set of hoops, which I'm opposed to on principle, though the spec itself looks fine :/

the use case or the scenarios where this provides additional security is super niche

(filling a gap is only a requirement for moving on to Stable :))

no, it does not try to protect passwords, but to detect such MITMs and it tries to protect the list of channel-bindings as well

mitm detection is not necessarily about protecting the password; but about protecting against mitm

right that's fair

which i generally think is a good thing. not sure this one is the correct approach though

I think the main usecase is to protect the channel-binding list

on-list

on-list too

I have words on list I think

same, on-list

tmolitor, maybe then don't put requirements in if they are not really requirements 😉

larma: they are requirements, but both requirements are not equally important

d) Should this go into XEP-0198? XEP-0198: Add section defining SASL2 and BIND2 interaction https://github.com/xsf/xeps/pull/1215 this one is not about merging the PR; because this depends on other things; but getting an idea if council would like this in 0198 or in a new xep

if you have proper channel-binding in place, you won't need to protect the SASL mechanism list...but if you don't have channel-binding, protecting the SASL mechanism list is of value

to me the change is backward compatible enough that the discoverability of putting it into 198 is worth it

I agree putting it into 198 is best

tmolitor wants to see the world burn and writes verbatim `/>` in XML cdata :D

I think we first should talk about the updates to xep-0386/xep-0388 before considering this PR

good :)

yeah, integrating this in '198 works for me ✏

larma: I agree with that, both are Deferred, and adding them into 0198 as-is seems counterintuitive

please see what daniel wrote.

(and I, in the xeps issue tracker)

> […] but getting an idea if council would like this in 0198 or in a new xep

this is not about merging, just figuring out if I need to tell tmolitor to put it in a new XEP, so that they can go ahead and do that

I think it's likely that some updates to bind2 and sasl2 will pass (soon-ish) to un-defer them and to actually allow for what this PR is doing

(instead of blocking on dwd to accept the changes to bind2 and sasl2, and then blocking again on rewriting the update to '198 as protoxep)

without consequences to the questions if we want something like this in 198

For discoverability, it would suffice to have a short list with the XEP titles.

is #1215 adding new content that's not found in 0386/0388?

both bind 2 and sasl2 are extensible. the question is should 198 say "i'm a bind 2 extension" or should there be a new xep that says hey you can use 198 as a bind 2 extension

I think it would be fine to put this into 0198 IIF it's reasonable to assume that 0386/0388 are moving to stable soonish.

larma: +1 to that

I was just trying to understand if it's adding new protocol or just new examples of documented protocol

Well #1215 does not add new content strictly speaking, one could infer the details of '198 and '388 interaction themselves, but #1215 makes these things more discoverable and concentrated to one point

conceptually speaking, I think making 0198 say "I'm a bind2 extension" is more logical than making bind2 say "this is the 0198 bind2 extension btw"

i don’t think bind2 would say that. if anything there would be a third xep - I think

it tries to explain some uncertainties one may have when implementing '0198 for SASL2 and BIND2

but I think we have enough of an answer here

Even if 0386/0388 changes are merged, it is not a given that they are going to stable soonish and I wouldn't like to see a stable xep pointing to experimental/deferred xeps and thereby confusing implementors of 0198

larma, what if a note is added which explains the why?

larma: I think the §9 intro is clear enough to not confuse readers

I think it would be fine to just not have it in 0198 while 0386/0388 are experimental. Because IMO it's fine if the experiments are partially underspecified (that's how things typically have been in experimental in the past anyway)

but yeah, having a note in §9 saying that you only need to implement the respective subsections when you implement xep-0386/xep-0388 would probably be good

I can add such a note, if that's what council wants

a note like this certainly won’t hurt

larma, would that be sufficient so that it's ok to include to '198?

mind that we cannot fully control *when* things go to stable, so it must also be ok if that won't happen immediately

I think it would be premature to add it now, but I'm not sure what amount of activity around 0386/0388 would warrant the merge

I think this belongs in 0198 and if it makes things much easier to everyone we can add it "early", but I'd rather see to have at least some delay between merging 0386/0388 and adding this when it's not strictly required to get the experiments roling

perhaps a good % of clients and servers implementing an update to them and a ton of traffic on the mailing list ?

Logically I think bind2 provides a mechanism, and then other xeps can say that they use that mechanism, so saying in 198 how 198 interacts with bind2 makes sense to me. Similarly anything else that may fit into the bind2 exchange.

For a future XEP that does something during bind it makes much more sense for the future XEP to say "And this is what happens during bind" than BIND2 mention every possible XEP that could be used with it.

ok we are running up on a time limit. I don’t think we are going to fully answer the question today and it all depends on bind 2 and sasl 2 changes to be merged anyway

(though it seems there are no strong arguments against having this as a '198 update *eventually*)

moparisthebest, ton of traffic on mailing list IMO rather indicates that there are likely going to be changes which is rather an indication to not touch 198 yet

(bind2 will be merged, presumably, as it's Experimental and the Author is happy with it. SASL2 may be another matter)

I'm taking away that 198 is the right place. it's only a matter of figuring out the correct time

daniel, +1 🙂

larma, right just that it's indicitive of the "amount of activity", and +1 on what daniel just said

I've just added a note: https://dyn.eightysoft.de/xeps/xep-0198.html#inline

are people ok with extending the meeting by 10mins?

yep!

I am

(I would like to start voting on the other two items today)

sure

quorum, let's go

e) XEP-0045: Remove more of GC1 (https://github.com/xsf/xeps/pull/1213)

+1

+1

+1

+1

+1

We're sure this doesn't open the door to people not including the payload?

passed. thank you

f) XEP-0167: Release version 1.2.2 (https://github.com/xsf/xeps/pull/1212)

+1

Kev, > In order to inform occupants of room roles and affiliations, and to make it easier for clients to track the current state of all users in the room, MUC service implementations MUST provide role and affiliation data (and, if allowed by the room configuration, full JID) in all presence stanzas, including presence stanzas of type "unavailable" sent when a user exits the room for any reason.

that requires the <x/> element, IIRC

(ok)

+1 on f)

+1 on f)

+1

I don't think f) needs council (schema is non-normative IIRC), but +1 anyway

5) Pending votes: none

6) Date of next

+1w wfm

+1w wfm

+1w wfm

+1w probably wfm

(RIPE GM is in parallel, but past experience says I can attend the council meeting nontheless)

+1w wfm ✏

7) AOB larma said something about https://github.com/xsf/xeps/pull/1188 - can you repharse this is an action council should consider taking?

I suppose making dwd react

what jonas’ said 🙂

or decide without him

(and or making larma co-author officially)

but given that dwd is reactive elsewhere, we should try poking him first

though that is strictly the editor's job

so I'll shoot him a mail now

ok. thank you jonas’

any other aob?

not from me

none here

(and thanks jonas’ )

(mail sent)

and no AOB here

ok. assuming none then

8) Close

thanks daniel, thanks all

thank you all

thanks!

thanks all

thanks

Oh look, reactions! https://logs.xmpp.org/council/2022-10-19?p=h#2022-10-19-8d7503edf14921df

whaaat

Now the only thing we need is stickers!

Hey, get off my lawn

(seriously though, neat :))

No, now it's inline custom emojis apparently

custom reactions

:yes-indeed-mountain-man-nodding:

<reaction>lol</reaction>