XMPP Council - 2018-06-06

  1. Dave

    Afternoon all.

  2. Kev


  3. daniel


  4. jonasw


  5. Dave

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

  6. Dave

    Do we have Ge0rG and SamWhited ?

  7. SamWhited

    oops, yup, sorry

  8. jonasw

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

  9. Dave

    OK, we'll hope Ge0rG joins us later.

  10. Dave

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

  11. jonasw


  12. jonasw

    I like his minutes :)

  13. Dave

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

  14. Dave

    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

  15. Dave

    Anyone any opinions on this one?

  16. daniel

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

  17. SamWhited

    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.

  18. SamWhited

    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)

  19. daniel

    note it's not exactly standarizing just 'informational'

  20. jonasw

    isn’t zip encryption horribly broken?

  21. SamWhited

    It might be

  22. Dave

    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.

  23. Kev

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

  24. Kev

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

  25. Dave

    Kev, You have a view on this?

  26. Dave

    Oh. Lag.

  27. SamWhited

    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.

  28. Kev

    But I wouldn't even be fond of historical.

  29. Kev

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

  30. Dave

    Ah, that was weird.

  31. Dave

    OK. Votes, then?

  32. SamWhited


  33. Kev


  34. Dave

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

  35. Dave

    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

  36. Dave

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

  37. Dave

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

  38. Kev

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

  39. daniel

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

  40. Dave

    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.

  41. Kev

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

  42. SamWhited

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

  43. Kev

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

  44. Dave

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

  45. daniel

    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

  46. Kev

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

  47. Kev

    Lua is pegging the CPU.

  48. Dave

    Right - votes, anyone?

  49. daniel

    that's how i usually implement it

  50. daniel

    and not everyone running xmpp is in an open enviroment

  51. Dave

    daniel, Well, that's certainly true.

  52. SamWhited


  53. Kev


  54. Dave

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

  55. daniel

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

  56. daniel


  57. Kev

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

  58. Kev

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

  59. Dave

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

  60. daniel

    but offer still stands if people find it useful

  61. daniel

    on list

  62. daniel

    ok never mind. +1

  63. daniel

    and meh lag

  64. Kev

    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.

  65. Dave

    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.

  66. Kev

    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.

  67. Kev

    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".

  68. Dave

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

  69. SamWhited

    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.

  70. Kev

    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.

  71. Dave

    OK - votes?

  72. Ge0rG

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

  73. Kev

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

  74. SamWhited

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

  75. daniel

    Ge0rG, pizza or the police?

  76. Dave

    OK (And welcome Ge0rG).

  77. Dave

    daniel, Could be both.

  78. Ge0rG

    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

  79. Dave

    5) Outstanding Votes

  80. jonasw

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

  81. Dave

    Ge0rG, Thanks.

  82. Dave

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

  83. Ge0rG

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

  84. Dave

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

  85. Dave

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

  86. Dave

    Anyone got AOB?

  87. Kev

    Not here.

  88. daniel


  89. SamWhited


  90. Ge0rG

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

  91. Dave

    7) Next Meeting

  92. Dave

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

  93. Kev

    Sounds likely.

  94. Ge0rG

    I know I can't do next week.

  95. SamWhited


  96. daniel

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

  97. Dave

    Ge0rG, Noted.

  98. Dave

    8) Ite, Meeting Est.

  99. Dave

    Thanks all.

  100. Kev

    Thanks all.

  101. Dave goes to update the spreadsheet.

  102. jonasw

    Dave: thanks 😺

  103. Dave

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

  104. jonasw

    good thanks