XMPP Council - 2022-01-05

'tis time, isn't it?

Hello everyone. It is time

Happy new year, Council!

1) Roll coll

👋️

Happy new year!

do we have a moparisthebest?

i guess not. anyway let's move on

2> Agenda bashing

there are some additional changes to the agenda

the editor has published a few new proposals after i sent out the agenda yesterday

I'm not sure we need to start voting on those right away

nobody has had time to read them anyway and at least one is spinning off into an interesting discussion on-list already

(a discussion the outcome of which will decide +1/-1 for me)

i think we can start the voting. i don’t expect people to vote now though

Yay for more discussion

3) Editors update.

see above

4) Items for voting

Move XEP-0424 (Message Retraction) to stable

I think the points raised on list are sufficient for me to go -1: Depends on a bunch of experimental XEPs the future of which is unclear.

yes i agree with jonas’

and this seems to summarize the list discussion as well

-1, I think we need to sort out the message referencing mechanism first

same here (also applies to 425)

0425 got even more gotchas

I'm -1 here as well

Also I dislike the amount of boilerplate in both

larma, just to confirm that's a -1 for 424?

daniel, yes

Ok. Thank you everyone

Move XEP-0425: Message Moderation to stable

-1

-1

also -1, same reasoning

also -1

alright. thank you

Ok. As I said earlier i'm now gonna start votes on the 4 proposed xeps.

personally i'm ready to vote but feel free to say 'on list'

and/or vote next meeting

Proposed XMPP Extension: Compatibility Fallbacks (https://xmpp.org/extensions/inbox/compatibility-fallback.html)

on-list

+1

+1

(well, I submitted it, so would be weird to be against)

good enough to play with. +1

though I note it misses a Requirements section

Proposed XMPP Extension: Call Invites https://xmpp.org/extensions/inbox/call-invites.html

+1

+1

looks sensible +1

FYI, this will become useful with https://github.com/xsf/xeps/pull/1139/files

though one thing which would be useful for readability in that XEP is wording on where to send <left/> to

on-list

jonas’, can you mention that on list, so I have a record and don't forget it?

will do

thx

Proposed XMPP Extension: Message Replies (https://xmpp.org/extensions/inbox/replies.html)

+1

+1

on-list

is this the 3rd or 4th xep dealing with replies? :-)

hopefully it's the first to stick

jonas’, ?

I was thinking

so

I'm not sure we should accept this without a Design Considerations section detailing why the other mechanisms are not workable

we already have <thread/>, References and Fastening, at the very least.

so to me this smells like duplication, about the only hard reason to reject a protoxep. ✏

am I misguided here?

None of the ones you mention specifically go for replies

well <thread/> kind of does

jonas’, sounds sensible

Yeah, we could resurrect threads indeed. ✏

wouldn’t neceassarily have been a reason for me to reject but i get where you are coming from

jonas’, thread allows multiple messages in a thread, business rules in that protoxep specifically says "Answers MUST NOT be be assumed to relate to any other messages than the referenced one."

larma, some rationale in the document would be appreciated before acceptance I think.

I surely can write it down

to me it's not immediately obvious why <thread/> doesn't work here, since a reply could always fork off a fresh thread kind of

only if the initial message already had a thread id

it requires the og message to have a thread-id

ohh

meh

luckily, replies doesn't depend on the original to have an origin-id

i find the thread example not very fitting personally but i do see overlap with references and fastening

Overlap in a sense of "points to a previous message in chat"

overlap as in the authors intented this to be used for this

i think

oh, message attaching would be another one with overlap

so we're at five specs (if we count <thread/>) doing very similar things

I don't agree they are "very similar", but I see what you mean. We probably need a section in the protoxep to tell them all apart

ok, I'm -0 on this, but this document desperately needs a Design Considerations section to explain why the other four standards are not an option to achieve the goal

ok. thank you

Proposed XMPP Extension: PubSub Namespaces - https://xmpp.org/extensions/inbox/pubsub-ns.html

-1, until there's a good explanation for why pubsub#type isn't an option.

i don’t know enough about pubsub to make a good call on that

on-list

+/- 0

FYI, https://github.com/xsf/xeps/pull/986 has the explanation

should go into the document :)

do you want to cast a vote larma?

or else I would like to move on

on-list for now

looking at the time

5) Pending votes

Everyone but Jonas pending on XEP-0060: Release version 1.23.0 (https://github.com/xsf/xeps/pull/1126)

-1 from me

should go into 0004

and we should ask editor to cherry pick the editorial / non controversial bits from that PR

out of curiousity (I don't have any horses in that race), how would a '4 integration look like? sounds tricky to me, considering that '4 is Final.

-1 from me as well, although I'm not sure if 0004 is the right place either, but the proposal definitely shouldn't go as is

-1 with the PR as-is, maybe a better non-normative wording can be proposed if we fail to update 0004

jonas’, i think there has been some discussion on how that can still be done in 0004 in a compat way. but i also think a new xep (that modifies 0004) can be done

right

Wow, we managed to run over time

yes. but we are mostly done I think

6) Date of Next

+1w wfm

+1w wfm

+1w

+1W

7) AOB either we don’t have any or I need to ask people if they are ok with extending the meeting by 10mins

any aob?

none

no

none

ok. awesome. thank you everyone

8) close

thanks daniel

Thanks daniel!

Thanks 🙂

BTW, as References Guy, I don't think References is a reason to block Replies, but agree that some explanation in Replies would be worthwhile.

We need a Venn diagram!

(I do think references would work fine for the use case, but references being stuck (currently?) on URIs makes it a bit unfortunate.)

I think the whole space would greatly benefit from someone with time and understanding trying to map out how all the things work together (and that's the kind of leadership Council's good for), and I think that having a bunch of different ways to reference stanzas is undesirable, but ... yeah.

Isn't that what Summits were good for, before 2020?

searching the wiki for references yields https://wiki.xmpp.org/web/Georg%27s_Talk_on_Message_routing among other things.

Summits used to be good for sorting out the high level view, and moderately ok for motivating people to write things, yes. There is a bit of an issue with XEPs written in a hurry to support stuff that was happening/just happened at Summits and then wither on the vine (e.g. References).

I could try to allocate a few hours to write down the principal means we have to reference messages with their pros/cons and to collect an overview of which XEP does what. That's the sort of thing I like delving in, after all. Would wiki format be appropriate, or should I make it another "what's wrong in ..." presentation?