KevI'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.
Ge0rGI've had two AOB-style points where I'd like to hear The Voices Of The Elders
Ge0rGbut those can be fitted into the mail-to-standards@ format as well
dwdSame 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.
dwdAnd because I wanted to know why we've had nothing at all for two weeks.
jonas’summer?
dwdPossibly.
Ge0rGI'd also like to have a Meeting today, even if only to officially announce that I'm absent for the next two Wednesdays
jonas’'tis time
jonas’dwd, Ge0rG, Kev?
KevKinda.
Link MauveHi.
jonas’I’d like to mention that I have a hard deadline on 15:30Z
dwdOoops. Distracted, sorry.,
dwd1) Roll Call.
jonas’
Ge0rGYes.
dwdEveryone here, by the looks of things, assuming Ge0rG is still about.
dwd2) Agenda Bashing.
Ge0rGgot two AOBs
dwdI saw nothing for the agenda, but I note that Georg wanted to say some things in AOB.
jonas’I got nothing
dwdAs do I.
dwd3) No Items For A Vote.
dwd4) Outstanding Votes
Ge0rGLink Mauve is outstanding
dwdI think Link Mauve has one last chance for his which expires today?
dwdLink Mauve, Could you look into that please.
Link MauveYes.
dwd5) Next Meeting
jonas’+1w wfm
dwdNext week - Ge0rG is going to be absent, any other apologies?
Ge0rGprobably +3W for me, but I somehow managed to sneak in the last two times where I was Officially Absent
jonas’Ge0rG, will you be able to vote on list?
Link MauveErr, the only pending vote I have is on a PR of mine, for which I’m obviously +1.
Ge0rGjonas’: most probably yes
jonas’Link Mauve, you wouldn’t be the first (not even in this period I thik) to veto your own PR.
dwdCool.
Link MauveIndeed. ^^'
dwd6) AOB
dwdGe0rG, You first.
Ge0rGThank you very much, dwd
Ge0rG6a) Handling of ephemeral messages for offline users
jonas’oh dear
jonas’that sounds like yet another can of worms :)
Ge0rGThe 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
Ge0rGthis leads to massive spam of errors when you send CSNs to an offline contact
jonas’I think that behaviour is sane
Ge0rGHolger said that this is strict following of the RFC and of https://xmpp.org/extensions/xep-0160.html
Ge0rGI think that it's not very helpful to bounce ephemeral messages, and even less helpful for the sending entity
dwdGe0rG, I'd really appreciate that being raised in the Inbox thread I started.
jonas’I think the sending entity needs to deal with errors to ephemeral messages sensibly
dwdGe0rG, Since I think it relates.
Ge0rGbecause now every one of your clients needs to track all in-flight messages
Ge0rGdwd: I'm curious as to what link you see
jonas’does it?
jonas’hm, that’s one of those cases where including the original payload would be very valuable
Ge0rGjonas’: ephemeral messages will maybe get carbon-copied. errors... maybe but less probably so.
jonas’as it saves tracking
Ge0rGjonas’: ejabberd does so
dwdWell, I see the general problem of dealing with clients coming on and off-line being connected.
Ge0rGI'd rather change 0160 to allow silent dropping of ephemeral messages
dwdWhat does a server do if it doesn't bounce them? Drop, or store-and-forward?
Ge0rGbecause there is no benefit in those errors
jonas’didn’t we agree that OTR was ephemeral?
Link Mauvedwd, not necessarily, these may also be interested in ephemeral messages.
jonas’silently dropping OTR or equivalent would be not-so-great
dwdLink Mauve, Yes indeed.
Ge0rGdwd: I'd say drop
dwdGe0rG, So for some messages - like CSN - I'd agree. For others, like receipts...
Ge0rGjonas’: worse than delivering OTR messages to another client?
KevReceipts aren't ephemeral.
Ge0rGdwd: what Kev said
jonas’Ge0rG, under IM 2.0, they would not be re-routed
dwdAh, indeed.
jonas’Ge0rG, under IM-NG, they would not be re-routed
Ge0rGI'd even argue that message errors shouldn't be ephemeral, if they are a bounce of a non-ephemeral message
dwdjonas’, Under IM 2.0, we have exactly-once delivery even during network outage, though.
jonas’Ge0rG, that would require to include the original payload in the error
Ge0rGjonas’: they wouldn't be stored offline either, then
Ge0rGdwd: do we?
KevI keep coming back to an idea I hate about this.
dwdGe0rG, Probably. We have evertything else.
jonas’which would also help with bouncing ephemeral messages because clients could recognize the errors to belong to an ephemeral message
KevWhich is that we need another stanza, or another message type :p
Ge0rGdwd: I'm not sure we have per-client offline stores
jonas’Ge0rG, re OTR: that’s the point -- they should be reject-ed instead of dropped
Ge0rGjonas’: that's a good point
jonas’Ge0rG, re OTR: that’s the point -- they should be reject-ed instead of dropped or rerouted
Ge0rGjonas’: but I don't think any of the OTR plugins will make effective use of those bounces
jonas’so maybe we should amend '160 to require the bouncer to include the orignial payload completely
dwdGe0rG, Do you have enough from The Voices to start a reasoned thread on standards@?
jonas’that would give clients the ability to treat bounces of ephemeral messages as such, without having to track them
Ge0rGKev: that's something we could achieve in IM 2.0, right?
Ge0rGdwd: I think so, but I lack the time to actually write all that down
KevGe0rG: It's not inconceivable, but it's more radical than I hope to need.
jonas’I’m happy to repeat my own arguments on-list
Ge0rGis anybody happy to repeat my arguments on-list? :D
jonas’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.
dwdOK - 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.
dwdAnd I think Ge0rG had another item?
Ge0rGare there any other AOBs? I didn't write down that item and I'm now pondering what it was again.
jonas’I don’t want to put words in Ge0rGs mouth, I’d prefer if Ge0rG did it himself.
dwdGe0rG, Yeah, I have two small ones.
Ge0rGjonas’: I'm perfectly fine with you putting words in my mouth
jonas’Ge0rG, I’m not ;)
Ge0rGor maybe just quoting from today's backlog? ;)
dwdSmall One The First: Given the quiet period, is it worth us looking for any XEPs worth advancing? Perhaps an Experimental.
Ge0rGdwd: feel free to go on then.
jonas’dwd, sounds like a good plan
Ge0rGI propose XEP-0280!
dwdCould 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.
jonas’dwd, sounds like a plan again
dwdThanks.
Link MauveYup, agreed!
KevI think just taking the opportunity to have a few lighter weeks makes sense, personally, but I'm flat out, so ...
dwdSmall One The Second: I note that MLS has reached a stable point in its development.
dwdI 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.
dwdWorth noting, though, since it looks very promising indeed.
dwd(MLS = Message Layer Encryption, basically an IETF spec for E2EE).
KevWhat's the 30 second summary of the properties?
jonas’OMEMO
KevOh, as bad as that?
Ge0rGMLS might become very interesting in the context of the Germans demanding messenger interop
jonas’(I don’t actually know, but it has PFS again)
dwdKev, It's a ratchet-based solution built around groups, not 1:1.
KevGood start.
dwdKev, Post-Compromise, rather than PFS, since it ratchets on demand and on group membership changes, not on every message.
Ge0rGThat sounds like a sensible approach
dwdKev, Standardized encrypted form syntax and concepts.
dwdKev, Downside is that it blocks server-side archiving as usual, but I had a design that'd work for earlier versions.
Ge0rGI've really lost my trust into IETF doing security when they published MTA-STS.
dwdSo, that's me - Ge0rG, can you recall your second item?
moparisthebestMLS wouldn't be adopted by german govt unless it had mandatory backdoors anyway right?
Ge0rGmoparisthebest: different parts of the govt
Ge0rGdwd: I think I can
dwdmoparisthebest, 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.
dwdGe0rG, Go for it.
Ge0rG6d) weird interations of 0198 and 0357
dwdedits "interactions".
Ge0rG*interactions, obviously.
Ge0rGWhen a session gets hibernated, and there are unacked stanzas in it, should there be a push notification?
dwdYes, 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.
jonas’sounds like a good thing to me, but I’m not a mobile person
Ge0rGThis comes from a corner case where yax.im was causing significant battery churn on Monal/iOS, as follows:
jonas’(I have to leave in 3min)
jonas’(but I’m not a mobile person either, so you might as well continue without me)
Ge0rG1. 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,
dwdGiven the time, this sounds absolutely reaosnable. I'm interested in this, but shall we continue for those interested afterward (and maybe in xsf@?)
Ge0rGthere is no requirement to require an <a> after each stanza, so I'm not doing that on my instance
Link MauveSo there is also 0352 being involved?
jonas’maybe clients should send a pro-active <a/> when entering CSI-inactive?
jonas’especially mobile
jonas’to avoid issues with unacked stanzas when they get background-killed
Ge0rGjonas’: yes, that's the workaround, but it's racy
jonas’is it?
Ge0rGjonas’: because they can't send an <a> when they are killed
dwdETIMEDOUT - I'm going to end this meeting, but feel free to stay if you're interested.
jonas’if you don’t want to be woken up for a stana, send <a/>
dwd7) Ite, Meeting Est.
dwdThanks all.
jonas’if you can’t send <a/>, you need to be woken up
jonas’even only for the server to be able to release the stanza memory
jonas’gotta run now :)
Link MauveSo +3W for the next meeting?
Ge0rGLink Mauve: +1W without Ge0rG I think
dwdGe0rG, 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.
Ge0rGdwd: that's an interesting PoV, yeah
dwdAnd 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.