XMPP Council - 2018-06-06

Afternoon all.

Here.

hi

.

1) Roll Call [https://en.wikipedia.org/wiki/Roll_Call_(Hank_Mobley_album)]

Do we have Ge0rG and SamWhited ?

oops, yup, sorry

(last messgae I have from georg is around :59, so I guess he’ll be right back)

OK, we'll hope Ge0rG joins us later.

2) Isn't it nice that Tedd Sterr does the minutes?

yes.

I like his minutes :)

It *is*, but he is starting to complain about this section.

3) Proposed XMPP Extension: OMEMO Media sharing Title: OMEMO Media sharing Abstract: An informal way of sharing media files despite limitations in the OMEMO encryption URL: https://xmpp.org/extensions/inbox/omemo-media-sharing.html

Anyone any opinions on this one?

+1. but i know it might be controversial so no hard feelings if other people are -1 on that :-)

I don't love the way Conversations shares encrypted files, but I'm not against standardizing it either. I wonder if it wouldn't make more sense to send the files in an encrypted ZIP archive or something though.

That way they can still be opened even if your client doesn't support them, and ZIP is well standardized (or some similar format if there are others that are widely supported)

note it's not exactly standarizing just 'informational'

isn’t zip encryption horribly broken?

It might be

That's good. So I'm concerned with inventing a new URI scheme, and also including a thumbnail in the same field. I get that this is Informational, but that usually describe "Best Practices", and this doesn't strike me as one.

I think making this Informational seems wrong (less wrong than standards-track, but still).

I could see the argument for historical (in its more recent meaning, rather than the formal one).

Kev, You have a view on this?

Oh. Lag.

ZIP specifically supports an AES mechanism that's apparently not broken (according to one random site on the internet), but really that was just an example because I knew Windows could open it. There may be some other standard format that's better.

But I wouldn't even be fond of historical.

Sorry, I think muc.xmpp.org just froze for a few minutes.

Ah, that was weird.

OK. Votes, then?

+0

-1

I'm -1 - I think if we had this now we'd be trying to deprecate it.

4) Proposed XMPP Extension: Ephemeral Messages Title: Ephemeral Messages Abstract: This specification defines a protocol to send ephemeral messages over XMPP and synchronize timer value setting across devices. URL: https://xmpp.org/extensions/inbox/ephemeral-messages.html

Let it flow, let it flow! Oh, let those stanzas flow...

Ah, better. It seems frozen again, hence the song...

I'm not entirely sure I even understand this one.

as someone who has implement burner messages a couple of times I don’t think this is how it should be done at all

I understand it (well, mostly), but I don't see how one can do ephemeral messages in an open environment with any kind of reliability.

I think the argument on-list was that it was advisory.

Yah this didn't seem great to me. Sounds like we're all more or less in agreement here.

And you can do advisory ephemeral messages in an open environment.

Well, yes. But I have no idea how you communicate the advisory nature to your user.

but for something that is 'advisory' there is way too much weird stuff going on in the xep. if you want to achieve the advisory effect just add a <please-burn-after seconds="5"/> to the message and be done with it

Or deal with the UX of your messages all vanishing at different times from your local archive.

Lua is pegging the CPU.

Right - votes, anyone?

that's how i usually implement it

and not everyone running xmpp is in an open enviroment

daniel, Well, that's certainly true.

-1

-1

But yeah, NTP-over-XMPP is enough for me to -1 this one.

i offered a while ago to write down what i usually use but nobody really wanted me to

-1

I don't think this *is* NTP over XMPP.

It's trying to synchronise agreement on the age of messages before they expire, I *think*.

4a) XEP-0045: Add a feature for the voice request flow #653 https://github.com/xsf/xeps/pull/653

but offer still stands if people find it useful

on list

ok never mind. +1

and meh lag

daniel: I'm almost inclined, although I have no interest in it myself at the moment, to say it'd be worthwhile to head off other people doing it in stranger ways.

So this wasn't on the agenda (sorry!), but I figured I'd raise it and if people want to vote on list I'll totally understand.

I think the PR should really mention that although it's normatively should now, it wasn't in the past - but equally that voice requests are so rarely (if ever) implemented that we're probably not going to see much fallout from adding as-is.

That said, it probably is not hard to just add "this feature advertisement wasn't present in earlier versions of the specification, so servers might implement voice requests and not advertise it".

+1 on this PR. Looks straightforward, though if the caveat Kev mentions were added I'd be even happier.

I don't love adding more things for a feature that is rarely used and slowly growing 0045 even more, but I'm not sure that I'd block either.

I'm also not sure what it achieves, other than being certain that a voice request is supported - as you have no way of knowing that it's not supported.

OK - votes?

I'm very sorry, I just had somebody at the door

So I'm +0 on this. I don't see how it's actually helping anything, but won't block it.

I'm on list I suppose. I keep going back and forth between "it doesn't matter" and "we need to stop adding cruft"

Ge0rG, pizza or the police?

OK (And welcome Ge0rG).

daniel, Could be both.

OMEMO Media sharing --> on-list Ephemeral Messages --> I've had a look at it and I don't like it, but I have no constructive ideas how to make ephemeral messages work better. on-list 4a #653 --> +1

5) Outstanding Votes

SamWhited: I don't see how a feature var is cruft, tbh. Without it, the existing feature spec is pretty useless.

Ge0rG, Thanks.

So I haven't updated the Spreadsheet of Doom, which I'll do after this, so I don't actually know what's outstanding.

I've heard that I missed a vote on IM-NG and nobody noticed.

But if you know you're outstanding, please... instand? ... yourself.

6) AOB [https://en.wikipedia.org/wiki/Abom_language]

Anyone got AOB?

Not here.

nope

nope

I think that AOB is not aob, but if we insist on it, we should backronym to tlh.

7) Next Meeting

I think that'd be 2018-06-13 at 1500Z?

Sounds likely.

I know I can't do next week.

WFM

> I think that'd be 2018-06-13 at 1500Z? 👍

Ge0rG, Noted.

8) Ite, Meeting Est.

Thanks all.

Thanks all.

Dave: thanks 😺

jonasw, No oustanding action I can see for the Editor, but the spreadsheet is updated.

good thanks