XMPP Council - 2018-08-01


  1. Dave arranges the chairs

  2. Kev sits at the back.

  3. Zash sits outside

  4. jonasw arranges for buckets of water for everyone to dip their feet in

  5. jonasw

    cold water even

  6. Dave

    1) Roll Call

  7. SamWhited

    here

  8. Dave

    Here, obviously.

  9. Kev mutters from the back

  10. SamWhited

    (by phone, replies may be slow)

  11. Ge0rG o/

  12. Dave

    No Daniel, but I'm assuming he's still on his travels?

  13. Ge0rG

    So Dave arranged the Chair.

  14. Ge0rG

    I think he promised to come back this week?

  15. Dave

    I wasn't sure. I know we were missing multiple last week hence the skip, but I thought Daniel was away longer.

  16. Ge0rG

    pinged daniel in private.

  17. Dave

    Anyway, four of us will do.

  18. Dave

    2) Agenda Bashing

  19. Dave

    Any updates to the Agenda?

  20. Ge0rG

    I liked it, so I propose to change the subject of #2

  21. Dave

    (I'm hoping not, but in case I've missed something...)

  22. Dave

    3) Items for voting:

  23. Dave

    3a) XEP-0050: Remove the status attribute from the request #681 https://github.com/xsf/xeps/pull/681

  24. Dave

    This seems like a pretty straightforward case to me - optional inclusion of an attribute that the receiver is mandated to ignore. So I'm +1.

  25. Kev

    I think this is a typo actually.

  26. SamWhited

    +1, this seems very sensible.

  27. Dave

    What is? The statement being removed?

  28. Kev

    I think it's a typo of 'status' instead of 'action', and the better fix might be to fix the typo.

  29. Kev

    From my reading -50 earlier.

  30. SamWhited

    Why have an optional attribute at all? Feels rather pointless.

  31. Dave

    SamWhited, If it's restating a default, that makes more sense.

  32. Ge0rG

    +1

  33. jonasw

    Kev, that makes sense

  34. SamWhited

    then it should be required still so you can rely on it

  35. SamWhited

    having to check 'is it the default value or does it not exist' is just cumbersome for no reason in my mind

  36. Kev

    SamWhited: Possibly, but that's orthogonal to this patch, I think.

  37. Dave

    SamWhited, If it's not the default value it could be cancelling, though.

  38. jonasw

    I think Kev is right and it was meant to say "action"

  39. Dave

    But in any case, Kev, can you make a comment to that effect and I'll look at it in more detail - could be an example that clarifies too.

  40. SamWhited

    oh yah, I guess so

  41. Dave

    3b) Proposed XMPP Extension: File Sharing Notifications https://xmpp.org/extensions/inbox/fsn.html

  42. Kev

    A comment where? Not on the PR, presumably.

  43. jonasw

    (in reply to the minutes probably)

  44. Ge0rG

    I think Kev is right regarding the typo, but the typo is in the XEP and not in the PR, and the PR is self-consistent.

  45. Ge0rG

    Also the PR removes the typo.

  46. Kev

    I don't like several things about FSN, and think we could almost certainly do it a better way, but I don't see anything preventing Experimental, so +1.

  47. Ge0rG

    I don't like that there is no enumeration of all possible FSN states, and that there is no example of how to stop FSN. But I like the idea, so +1

  48. Dave

    I think a protocol in this space would be useful (even if this changes quite a bit on the way). +1.

  49. Ge0rG

    It might be good to put FSN as a payload into CSN, but I have no strong opinion on that.

  50. SamWhited

    what kev said, except that I'm not sure if I think it should go to experimental or not. on list though.

  51. Dave

    Ge0rG, There was some discussion around that, but I forget what.

  52. Ge0rG

    Dave: it was in the xsf@ MUC

  53. jonasw

    Ge0rG, reasons against doing that: (a) (weak) CSN is final, (b) FSN states should be orthogonal to CSN states (see the business rules)

  54. Dave

    3c) XEP-0065, XEP-0363: Document exposing the service on the user’s domain #682 https://github.com/xsf/xeps/pull/682

  55. Dave

    FWIW, I understand why this is a single PR against multiple XEPs, but I'm not sure it's a good idea. XEP-0001 suggests these two changes should be voted upon distinctly by Council.

  56. Kev

    I think the intention here is right, but I'm afraid I think the way this is formulated is adding confusion rather than resolving it. I think you lead with "Here's how you see a domain has the feature" and then go with "And here's how you check the subdomains if it doesn't>

  57. jonasw

    Dave, council doesn’t need to vote on the second change, because '363 isn’t draft yet

  58. jonasw

    council only needs to vote on the change to '65, and if you reject that one, I guess Link Mauve will split

  59. SamWhited

    oh interesting, I mussed this one. on list, but looking forward to reading it.

  60. Dave

    jonasw, Yes, true, good point.

  61. SamWhited

    missed, even.

  62. Dave

    SamWhited, Mussed you have mist it?

  63. SamWhited

    Ain't phones great?

  64. Ge0rG

    onlist.

  65. Dave

    I think I'll vote on list with this one as well, mostly to take on board Kev's comment and see if I agree.

  66. Dave

    Kev, Is that a -1?

  67. Ge0rG

    I don't understand the PR against 65 as is, will have to research the context first.

  68. Kev

    I feel that -1 sends not quite the right message, because I agree with the change in principle, just not the execution, but yes. I'd at least like to be persuaded I'm wrong before it's merged.

  69. Dave

    Kev, An easy-rectifiable -1, then.

  70. Kev

    Yes.

  71. Dave

    3d) Proposed XMPP Extension: Schrödinger's Chat https://xmpp.org/extensions/inbox/muc-selfping.html

  72. Ge0rG

    +1 obviously. AMA

  73. Dave

    I have comments on this, but nothing that'd prevent it going onto Experimental.

  74. Ge0rG

    This was discussed in October last year already on standards@

  75. jonasw

    .oO(what if another MSN-client changes your nickname while your ping is in-flight and you get an item-not-found or whatever back because your ping target vanished…)

  76. SamWhited

    My only imediate concern is the title. Assuming it's changed to something more discoverable before going to experimental I'm +1

  77. Ge0rG

    jonasw: that's a very interesting one. Do you know of implementations that will change your nickname with MSN?

  78. Ge0rG

    SamWhited: is that a -1?

  79. Kev

    I think I might quibble about the 'sometimes, without warning, intercept, optionally', but otherwise it seems sane enough. +1

  80. SamWhited

    yes, I suppose it's a temporary -1

  81. Kev

    (Other than the name, but I'm not blocking on that even if it pushes the envelope of silliness too far for me)

  82. Ge0rG

    I liked the proposal by Zash, "Schrödinger's chat (Or, how I learned to stop worrying and self-ping in MUCs)"

  83. jonasw

    Ge0rG, same can happen if you’re changing your nickname yourself (although this can probably be solved by deferring the ping for some time after requesting a nick change)

  84. Dave

    Kev, It's far, far too late for you to pretend to be the sensible one.

  85. Ge0rG

    jonasw: I'm sure you won't first change the nick and then send a ping to your old nick

  86. Kev

    I wouldn't dare. I'm suggesting I'm not sensible, and this is too far even for me.

  87. jonasw

    Ge0rG, why not, I have to wait until I get the server ack for my nickchange before I update internal records…

  88. jonasw

    Ge0rG, so which name would you like to have?

  89. Ge0rG

    jonasw: want to document that in the Business Considerations?

  90. jonasw

    "MUC Self-Ping (Schrödinger’s Chat)"?

  91. jonasw

    ah, we have to wait for daniel anyways

  92. Ge0rG

    jonasw: I like the existing name and I'm sad that some Council members consider it silly.

  93. Dave

    4) Outstanding Votes

  94. jonasw

    Ge0rG, for the record, I consider it silly (not in a bad way) and undiscoverable (bad) too

  95. Dave

    Ge0rG, I also consider the name silly. I'm just basically fine with that.

  96. Kev

    I would far prefer jonasw's suggestion.

  97. jonasw

    Dave, you have lost any ground to argue with "Bookmarks 2 (This time it’s serious)"

  98. Ge0rG

    I don't think having "Schrödinger's Chat" in parens will have the desired effect, so my only sane option is "MUC Self-Ping". But I demand a record of the rename in the changelog

  99. Dave

    So, outstanding - I think given the skip, everything has expired.

  100. Kev

    I don't mind silliness, but I think it's obsfucating here, and that's bad.

  101. Dave

    5) Next Meeting

  102. Dave

    Next week, same time, same place?

  103. jonasw

    Dave, you have lost any right to argue since "Bookmarks 2 (This time it’s serious)"

  104. SamWhited

    wfm

  105. Kev

    *obfuscating

  106. Ge0rG

    Unless Sam and Kev would agree on "Schrödinger's Chat (MUC Self-Ping)", which would be my second best choice.

  107. Dave

    Kev, That's a fair point.

  108. Kev

    WFM

  109. jonasw

    Ge0rG, do it yourself then :)

  110. SamWhited

    bookmarks 2 still tells you what it does

  111. Ge0rG

    SamWhited: having numbers in titles is... not optimal.

  112. SamWhited

    please make 'MUC self ping' the first bit.

  113. jonasw hides behind Entity Capabilities 2.0

  114. Ge0rG

    we already have numbered namespaces.

  115. Dave coughs

  116. jonasw

    let’s not open this can of worms

  117. Dave

    Anyone any objections to next week?

  118. jonasw

    Ge0rG, you need to "wfm" next week

  119. Ge0rG

    +1W WFM

  120. Dave

    6) AOB

  121. Dave

    ... Assuming none.

  122. SamWhited

    Nothing here.

  123. Ge0rG

    okay, so I'll go with "MUC Self-Ping (Schrödinger's Chat)" then.

  124. Dave

    7) Ite, Meeting Est.

  125. Dave

    Thanks all.

  126. Ge0rG

    And use Bookmarks 2 as the precedent.

  127. Kev

    WFM

  128. Kev

    Thanks all.

  129. Ge0rG

    Thanks Dave. Thanks Tedd.

  130. SamWhited

    I can live with that.

  131. SamWhited

    thanks everyone