XMPP Council - 2018-11-14


  1. jonas’

    Ge0rG, do you still agree with MattJ’s assessment after the recent update?

  2. Ge0rG

    jonas’: from a skim of the XEP, it looks like it's still relying on MUC message semantics

  3. jonas’

    huh, ok

  4. Ge0rG

    jonas’: unless there was another update since yesterday

  5. jonas’

    not that I knew

  6. Ge0rG

    So I'm torn between documenting a hack that works, more or less, and got implemented because somebody wanted pictures on a MUC, and doing it right.

  7. Ge0rG

    AFAIR, all avatar XEPs have drawbacks, and there's no really good specification.

  8. jonas’

    yes

  9. jonas’

    the PEP-based avatars for users seem to work rather okay, except that they don’t allow for multiple different MIME types in pubsub.

  10. Zash

    Let's allow that then?

  11. Ge0rG

    Let's have multiple nodes, each with multiple items!

  12. Zash

    Or multiple items in both nodes with whatever

  13. Ge0rG

    I'm on mobile today, so semi present. Can't chair, but will try to swipe fast enough

  14. Kev

    'tis time, 'tis time.

  15. Kev

    Daniel's the only one who can't today, I think, from the last minutes.

  16. SamWhited

    o/

  17. Kev

    Do we have a Dave?

  18. Ge0rG

    Kev: you are chairing?

  19. Kev

    I can if Dave's not here.

  20. Ge0rG

    My train is delayed, and I'm in it

  21. Kev

    1) Roll cal

  22. Kev

    1) Roll call

  23. Ge0rG

  24. Kev

    I'm here, Sam, Ge0rG. Daniel apologies, I think Dave's missing.

  25. Kev

    Sorry, I was desperately trying to close off my last meeting.

  26. Kev

    Fully here now.

  27. Kev

    2) Agenda

  28. Kev

    Ted sent out a bunch of suggestions around LC items.

  29. Kev

    Tedd sent out a bunch of suggestions around LC items.

  30. Kev

    Rather than going through them now, I think it'd be more effective if we agreed to give feedback to each on-list in the relevant threads.

  31. Kev

    What do people feel about that?

  32. Kev

    And to then have a concrete vote on each last week, with a 1-week timeout instead of the normal 2-week.

  33. Kev

    And to then have a concrete vote on each next week, with a 1-week timeout instead of the normal 2-week.

  34. jonas’

    next week is too late.

  35. Kev

    (On the basis that last week is our last chance this term)

  36. jonas’

    (for a vote with 1w timeout?)

  37. SamWhited

    That seems reasonable to me; as long as we don't let them roll over to the next term which always means they're forgotten about.

  38. Ge0rG

    Isn't that our last week with a 1 week timeout?

  39. Kev

    Ah, is my timing a week out?

  40. jonas’

    the 22nd is next week, thursday

  41. Kev

    Yes, I think you're right.

  42. Kev

    Ok, in that case I suggest exactly the same plan but s/1w/1d/

  43. Ge0rG

    What about voting today with 1w instead mm

  44. Ge0rG

    What about voting today with 1w instead?

  45. Ge0rG

    We still end up with 1 week for on-list

  46. Kev

    Ge0rG: My preference is always having a live discussion here to kick things off, but am not opposed if that's what people want.

  47. Ge0rG

    We had two weeks for a list discussion

  48. SamWhited

    We can always have a live discussion, but we might as well get the voting started so that we're not pushed for time

  49. Kev

    Yeah, but we sucked.

  50. Ge0rG

    Kev: do you think another week is going to change that?

  51. Kev

    Ok, that's 2:1 in favour of starting now with 1w expiry, so I'm ok with that. Can we make that 1w+1d?

  52. Kev

    So the voting period ends with the end of term.

  53. SamWhited

    Sounds good to me

  54. Ge0rG

    8d is okay

  55. Kev

    Cool.

  56. Kev

    3) https://xmpp.org/extensions/xep-0357.html Advance to Draft?

  57. Kev

    I'm on-list or next meeting.

  58. SamWhited

    I'm on-list. Re-reading this one I just don't think I have the necessary background knowledge to really have a good opinion.

  59. Ge0rG

    -1 because the high priority topic hasn't been addressed. I liked the stripped stanza proposal very much.

  60. Kev

    I'm very much in favour of allowing pushing the real data through, BTW.

  61. Ge0rG

    The current XEP is much better than half a year ago, but the feedback from the list last August wasn't addressed

  62. Kev

    Privacy is needed to be supported, but it's also useful to allow users/deployments to make the tradeoff of utility vs. privacy.

  63. Ge0rG

    Kev: a tri-state of none / stripped / full will make that possible

  64. Kev

    Yes.

  65. Ge0rG

    Was suggested some months ago

  66. Kev

    I'm aware I'm the caretaker of 357, so I probably need to put the time in here.

  67. Kev

    Goodness knows what time, but I shall try.

  68. SamWhited

    That seems overly complicated to me, but I am for allowing data

  69. Kev

    4) https://xmpp.org/extensions/xep-0359.html Advance to Draft?

  70. Ge0rG

    The current status quo of hard coding "you have a new message" into the server module config is... non-ideal

  71. Ge0rG

    I've submitted some feedback to 0359 yesterday, and would like to see it addressed, but won't block it on that matter. +0 without a change or +1 if it's properly addressed

  72. Kev

    I'm list/next meeting on this as well.

  73. SamWhited

    I'm on-list for this one as well

  74. Kev

    5) https://github.com/xsf/xeps/pull/692

  75. Kev

    I am, again, onlist/next meeting.

  76. SamWhited

    +0

  77. Ge0rG

    on-list

  78. Kev

    6) https://github.com/xsf/xeps/pull/693

  79. Kev

    OL/NM

  80. Ge0rG

    on-list

  81. Ge0rG

    This is so productive MC

  82. SamWhited

    +0; pub-sub is something that I just don't feel confident enough with to review it no matter how many times I re-read it.

  83. Ge0rG

    This is so productive!

  84. Kev

    7) https://github.com/xsf/xeps/pull/715

  85. Kev

    OL/NM

  86. Ge0rG

    on-list

  87. SamWhited

    +1

  88. Kev

    8) https://github.com/xsf/xeps/pull/716 https://mail.jabber.org/pipermail/standards/2018-November/035434.html

  89. Kev

    OL/NM

  90. Ge0rG

    It's asking for discussing, right?

  91. jonas’

    discussion didn’t happen

  92. jonas’

    council needs to make a decision

  93. Ge0rG

    Currently, the examples in the XEP are missing the feature, right?

  94. jonas’

    are you talking about #715 or #716?

  95. SamWhited

    -1; I agree that it's weird to always include it even though it's obvious that it's supported, but I don't see the need to modify a final XEP and add optional behavior. My recommendation to implementations is to just follow the standard as its written, weird quirk and all, and if you need to check disco support make this assumption yourself.

  96. jonas’

    that’s the most sensible word I heard about that so far, SamWhited :-)

  97. SamWhited

    I apologize for not replying to the list about this; I meant to do so earlier.

  98. Ge0rG

    Will accepting 715 make the examples consistent with the standard and include the feature everywhere?

  99. jonas’

    Ge0rG, the former, yes. the latter, haven’t checked.

  100. Ge0rG

    ...and increase the number of examples where it's included?

  101. jonas’

    yes.

  102. jonas’

    if it is councils wish that the feature shall be in every disco#info/disco#items example in that XEP, I can do that upon merge.

  103. jonas’

    s/do/ensure/

  104. Kev

    I need to catch up, but I'm not keen on making any non-vital changes to 30.

  105. Kev

    Or any substantial non-vital changes.

  106. SamWhited

    Indeed; even in the state we're in today where everything ignores this, it's probably not going to break anything as is.

  107. Ge0rG

    I'm not sure we need to have it in all examples of all XEPs, I'd rather add a note to 0030 that the feature might not be present in *examples* but needs to be implemented

  108. SamWhited

    A little non-normative note seems reasonable.

  109. Ge0rG

    Yes, and it wouldn't change the normative text.

  110. SamWhited

    Although I don't think it's necessary either, but that would probably be for the next council to decide.

  111. Ge0rG

    So it's an editorial change.

  112. Ge0rG

    I don't see the need to hunt all XEPs for compliance

  113. SamWhited

    That's true, I'd be happy for the editors to just make that change

  114. Kev

    Sounds like time to move along, to me?

  115. SamWhited

    *nods*

  116. Kev

    9) Date of next

  117. Kev

    SBTSBC?

  118. SamWhited

    WFM

  119. jonas’

    Ge0rG, SamWhited, please propose wording.

  120. Ge0rG

    jonas’: can you remind me tomorrow around noon?

  121. jonas’

    Ge0rG, not really

  122. Ge0rG

    +1W WFM

  123. pep.

    /send_delayed "tomorrow around noon" poke Ge0rG

  124. Kev

    10) Yay, double-figures. AOB?

  125. SamWhited

    "Note that this may be omitted in examples in the XEP series"

  126. SamWhited

    s/may/is sometimes/

  127. Ge0rG

    Kev: did we have any expired votes to recast?

  128. Ge0rG

    Open votes from last week?

  129. Kev

    https://github.com/xsf/xeps/issues/717 Is the only open one from last week, I think.

  130. Ge0rG

    SamWhited: s/this/the disco#info feature /

  131. jonas’

    I think the expired stuff was already covered

  132. Kev

    (And which I need to deal with)

  133. Kev

    The expired stuff is what Tedd put on the agenda, I believe. I've not checked the SoD to verify.

  134. Ge0rG

    I have started working on the Moved XEP but it turned out to be a huge mess, implementation wise.

  135. Ge0rG

    There's a rendered version of a preliminary proposal on my private server, but nothing official yet. Will submit it to the next council

  136. Kev

    Thanks.

  137. Ge0rG

    The only reasonable way I see is to use messages instead of presence, but I'm not clear yet whether we need messages from the old account or from both

  138. Kev

    Moved is a bit of a nightmare if you want to do anything automatically because you need your server to also do things automatically (like link MAM archives) and all sorts of horrors follow from entities causing your archive to be rewritten.

  139. Kev

    AOAOB?

  140. SamWhited

    none here

  141. Kev

    I'm hearing a silence of 'no'.

  142. jonas’

    -

  143. Kev

    So, thanks all.

  144. Kev

    <<EOF

  145. SamWhited

    Thanks

  146. Ge0rG

    Kev: we can solve Moved with a permanent roster annotation

  147. Ge0rG

    Is there precedent for roster annotations?

  148. Kev

    Ge0rG: I find your ideas intruiging and I wish to subscribe to your newsletter.

  149. Kev

    Ge0rG: I find your ideas intriguing and I wish to subscribe to your newsletter.

  150. jonas’

    Ge0rG, MIX.

  151. jonas’

    and it’s a horrible precendent, IMO.

  152. Ge0rG

    Kev: you can rent my services at only 180€/hr... 😢

  153. Ge0rG

    Yes, MIX is a mess.

  154. Ge0rG

    But a Moved message will only be retained for so long, if at all.

  155. jonas’

    (I’m not saying the concept of roster annotations is a horrible precedent, but that particular implementation is)

  156. Ge0rG

    If you have MAM=contacts, and the old JID is removed, will your server purge the Moved message?

  157. jonas’

    probably not

  158. jonas’

    would be terrible if it did

  159. jonas’

    both for how MAM works, and for users

  160. Ge0rG

    Did I mention that implementing Moved on top of real life XMPP is a mess mm

  161. Ge0rG

    Did I mention that implementing Moved on top of real life XMPP is a mess?

  162. Kev

    FWIW, roster annotations have been a thing we've been discussing for well over a decade.

  163. Kev

    MIX is just the first time we had a concrete use for them.

  164. Ge0rG

    Kev: but it never happened?

  165. Ge0rG

    Moved would be a concrete use case.

  166. jonas’

    IMO, the easierst for both clients and servers would be a namespaced element within the roster <item/>

  167. Ge0rG

    A PEP tombstone would be another possibility, but less flexible

  168. jonas’

    (regarding the general concept of roster annotation?)

  169. Ge0rG

    jonas’: that would be a roster annotation, right?

  170. jonas’

    (regarding the general concept of roster annotations)

  171. jonas’

    Ge0rG, yes, that’s my point (just clarifying; I understand you’re probably behind latency)

  172. Ge0rG

    jonas’: and I'm approaching the next coverage hole. Also typing on a touch screen

  173. jonas’

    good luck

  174. Ge0rG

    Thanks. Looks like I survived the meeting well enough at least

  175. jonas’

    also, xsf@ maybe.

  176. Ge0rG

    If implementing roster annotations takes as long as persistent PEP, I'm out.

  177. jonas’

    shouldn’t be as hard

  178. Ge0rG

    Not sure it's about being hard.

  179. Ge0rG

    https://xmpp.org/extensions/xep-0145.html