XMPP Council - 2019-06-05

I'm in meetings that won't end, don't know if I'll be around for Council. Although I don't think we have Agendums anyway.

I've had two AOB-style points where I'd like to hear The Voices Of The Elders

but those can be fitted into the mail-to-standards@ format as well

Same situation as last week in respect of nothing I can find for the agenda, BTW, but I'd like to hold the meeting anyway for form's sake.

And because I wanted to know why we've had nothing at all for two weeks.

summer?

Possibly.

I'd also like to have a Meeting today, even if only to officially announce that I'm absent for the next two Wednesdays

'tis time

dwd, Ge0rG, Kev?

Kinda.

Hi.

I’d like to mention that I have a hard deadline on 15:30Z

Ooops. Distracted, sorry.,

1) Roll Call.

Yes.

Everyone here, by the looks of things, assuming Ge0rG is still about.

2) Agenda Bashing.

I saw nothing for the agenda, but I note that Georg wanted to say some things in AOB.

I got nothing

As do I.

3) No Items For A Vote.

4) Outstanding Votes

Link Mauve is outstanding

I think Link Mauve has one last chance for his which expires today?

Link Mauve, Could you look into that please.

Yes.

5) Next Meeting

+1w wfm

Next week - Ge0rG is going to be absent, any other apologies?

probably +3W for me, but I somehow managed to sneak in the last two times where I was Officially Absent

Ge0rG, will you be able to vote on list?

Err, the only pending vote I have is on a PR of mine, for which I’m obviously +1.

jonas’: most probably yes

Link Mauve, you wouldn’t be the first (not even in this period I thik) to veto your own PR.

Cool.

Indeed. ^^'

6) AOB

Ge0rG, You first.

Thank you very much, dwd

6a) Handling of ephemeral messages for offline users

oh dear

that sounds like yet another can of worms :)

The latest and greatest ejabberd will only accept messages to offline users if those messages will be stored in offline storage / MAM, and will reject otherwise

this leads to massive spam of errors when you send CSNs to an offline contact

I think that behaviour is sane

Holger said that this is strict following of the RFC and of https://xmpp.org/extensions/xep-0160.html

I think that it's not very helpful to bounce ephemeral messages, and even less helpful for the sending entity

Ge0rG, I'd really appreciate that being raised in the Inbox thread I started.

I think the sending entity needs to deal with errors to ephemeral messages sensibly

Ge0rG, Since I think it relates.

because now every one of your clients needs to track all in-flight messages

dwd: I'm curious as to what link you see

does it?

hm, that’s one of those cases where including the original payload would be very valuable

jonas’: ephemeral messages will maybe get carbon-copied. errors... maybe but less probably so.

as it saves tracking

jonas’: ejabberd does so

Well, I see the general problem of dealing with clients coming on and off-line being connected.

I'd rather change 0160 to allow silent dropping of ephemeral messages

What does a server do if it doesn't bounce them? Drop, or store-and-forward?

because there is no benefit in those errors

didn’t we agree that OTR was ephemeral?

dwd, not necessarily, these may also be interested in ephemeral messages.

silently dropping OTR or equivalent would be not-so-great

Link Mauve, Yes indeed.

dwd: I'd say drop

Ge0rG, So for some messages - like CSN - I'd agree. For others, like receipts...

jonas’: worse than delivering OTR messages to another client?

Receipts aren't ephemeral.

dwd: what Kev said

Ah, indeed.

Ge0rG, under IM-NG, they would not be re-routed ✏

I'd even argue that message errors shouldn't be ephemeral, if they are a bounce of a non-ephemeral message

jonas’, Under IM 2.0, we have exactly-once delivery even during network outage, though.

Ge0rG, that would require to include the original payload in the error

jonas’: they wouldn't be stored offline either, then

dwd: do we?

I keep coming back to an idea I hate about this.

Ge0rG, Probably. We have evertything else.

which would also help with bouncing ephemeral messages because clients could recognize the errors to belong to an ephemeral message

Which is that we need another stanza, or another message type :p

dwd: I'm not sure we have per-client offline stores

jonas’: that's a good point

Ge0rG, re OTR: that’s the point -- they should be reject-ed instead of dropped or rerouted ✏

jonas’: but I don't think any of the OTR plugins will make effective use of those bounces

so maybe we should amend '160 to require the bouncer to include the orignial payload completely

Ge0rG, Do you have enough from The Voices to start a reasoned thread on standards@?

that would give clients the ability to treat bounces of ephemeral messages as such, without having to track them

Kev: that's something we could achieve in IM 2.0, right?

dwd: I think so, but I lack the time to actually write all that down

Ge0rG: It's not inconceivable, but it's more radical than I hope to need.

I’m happy to repeat my own arguments on-list

is anybody happy to repeat my arguments on-list? :D

I don’t think another message type is a solution to anything, since it’ll have to interact e.g. with MUC and MUC-PMs properly.

OK - who wants to start this thread on standards@? I don't think it's going to get decided in Council without a lot of over-run.

And I think Ge0rG had another item?

are there any other AOBs? I didn't write down that item and I'm now pondering what it was again.

I don’t want to put words in Ge0rGs mouth, I’d prefer if Ge0rG did it himself.

Ge0rG, Yeah, I have two small ones.

jonas’: I'm perfectly fine with you putting words in my mouth

Ge0rG, I’m not ;)

or maybe just quoting from today's backlog? ;)

Small One The First: Given the quiet period, is it worth us looking for any XEPs worth advancing? Perhaps an Experimental.

dwd: feel free to go on then.

dwd, sounds like a good plan

I propose XEP-0280!

Could I ask each of us to find a XEP to advance? Doesn't matter if we pick the same one, but it might be nice to advance some stuff.

dwd, sounds like a plan again

Thanks.

Yup, agreed!

I think just taking the opportunity to have a few lighter weeks makes sense, personally, but I'm flat out, so ...

Small One The Second: I note that MLS has reached a stable point in its development.

I don't think there's anything we need to do at this stage, though I might look at an MLS/XMPP XEP if I can find the time.

Worth noting, though, since it looks very promising indeed.

(MLS = Message Layer Encryption, basically an IETF spec for E2EE).

What's the 30 second summary of the properties?

OMEMO

Oh, as bad as that?

MLS might become very interesting in the context of the Germans demanding messenger interop

(I don’t actually know, but it has PFS again)

Kev, It's a ratchet-based solution built around groups, not 1:1.

Good start.

Kev, Post-Compromise, rather than PFS, since it ratchets on demand and on group membership changes, not on every message.

That sounds like a sensible approach

Kev, Standardized encrypted form syntax and concepts.

Kev, Downside is that it blocks server-side archiving as usual, but I had a design that'd work for earlier versions.

I've really lost my trust into IETF doing security when they published MTA-STS.

So, that's me - Ge0rG, can you recall your second item?

MLS wouldn't be adopted by german govt unless it had mandatory backdoors anyway right?

moparisthebest: different parts of the govt

dwd: I think I can

moparisthebest, You can have them if you want, just insert a new member mandatorily on the server. Impossible to do without someone noticing, though, which is a good thing.

Ge0rG, Go for it.

6d) weird interations of 0198 and 0357

*interactions, obviously.

When a session gets hibernated, and there are unacked stanzas in it, should there be a push notification?

Yes, I don't know what the specs say here. But to my mind, a "Maybe Live" 198 disconnected session won't get pushes until some timeout occurs.

sounds like a good thing to me, but I’m not a mobile person

This comes from a corner case where yax.im was causing significant battery churn on Monal/iOS, as follows:

(I have to leave in 3min)

(but I’m not a mobile person either, so you might as well continue without me)

1. server sends a stanza 2. Monal sends CSI inactive 3. Monal gets background-killed 4. prosody notices the dead socket 5. prosody sends push, wakes up Monal 6. monal connects, sends CSI inactive,

Given the time, this sounds absolutely reaosnable. I'm interested in this, but shall we continue for those interested afterward (and maybe in xsf@?)

there is no requirement to require an <a> after each stanza, so I'm not doing that on my instance

So there is also 0352 being involved?

maybe clients should send a pro-active <a/> when entering CSI-inactive?

especially mobile

to avoid issues with unacked stanzas when they get background-killed

jonas’: yes, that's the workaround, but it's racy

is it?

jonas’: because they can't send an <a> when they are killed

ETIMEDOUT - I'm going to end this meeting, but feel free to stay if you're interested.

if you don’t want to be woken up for a stana, send <a/>

7) Ite, Meeting Est.

Thanks all.

if you can’t send <a/>, you need to be woken up

even only for the server to be able to release the stanza memory

gotta run now :)

So +3W for the next meeting?

Link Mauve: +1W without Ge0rG I think

Ge0rG, I think we may need to revisit advice on when to send an <r/> - we want to send one any time you want to start a timer, loosely.

dwd: that's an interesting PoV, yeah

And anytime you get a push notification, or get a traditional offline message (or fish them from MAM), you might get duplicates. It's just going to happen sometimes.

<=1 or >=1, after all.

this is a solvable problem

it's not pretty, but it's straight-forward