XMPP Council - 2018-03-06

  1. Ge0rG

    Dave: https://github.com/xsf/xeps/pull/600

  2. Ge0rG

    Dave: https://github.com/xsf/xeps/pull/600 - "XEP-0045: Implement stable IDs on Reflection"

  3. jonasw puts an hooray emoji both for 600th PR and for the thing itself

  4. Zash

    xep-0600 already?? :)

  5. Ge0rG

    I think somebody volunteered to write XEP-0404

  6. jonasw

    I also think s o

  7. jonasw

    kev maybe

  8. Ge0rG

    I think so too

  9. Ge0rG

    People joining with /phone and /tablet JIDs. Somebody really needs to fix their implementation :>

  10. pep.

    You mean fix Conversations?

  11. Zash

    https://hg.prosody.im/prosody-modules/file/6f34e51a23f0/mod_compact_resource/mod_compact_resource.lua An `if event.resource == "phone" then event.resource = ...` in there?

  12. daniel

    Ge0rG: join where?

  13. Zash


  14. Zash notices https://github.com/siacs/Conversations/commit/63cd8e598177b6b5757ab8518a48a44928dbe387

  15. pep.

    Why not just let the server do it itself? ^

  16. pep.

    As account.getResource() doesn't seem to be used if set

  17. Ge0rG

    random on every bind is similarly broken.

  18. Ge0rG

    MattJ: you wanted to make public your horrible hack of per-client offline history

  19. MattJ

    I did

  20. Ge0rG

    Really, if we have that, we can get rid of MAM.

  21. MattJ


  22. Zash

    Ge0rG: Worksforme, and I dislike fixed resources like 'phone' enough to just randomize it always

  23. Zash

    I only know Swift doing what I think is right

  24. Ge0rG

    Zash: I know some clients doing what I think is right.

  25. Ge0rG

    And despite my opinion being clearly superior, most developers seem to ignore it and insist on dumb client and server behavior.

  26. Dave

    FWIW, I explicitly try to make clients use fixed identifiable resources because it helps my debugging.

  27. Ge0rG

    Dave: could you please highlight the parts of your message that contain sarcasm?

  28. Dave

    None, in this instance.

  29. Ge0rG

    Dave: thanks very much. I kind of expected that to be a sarcastic response to my megalomania, especially beacuse I was asking to have human-readable resources for debugging purposes all along.

  30. Ge0rG

    I'm still convinced that `/phone.########` with a random postfix created by the client on account setup is the most sane middleground.

  31. SamWhited

    If you're using it for debugging can't the server do that? Use that library that gives you four random words and then tack on some proper randomness. Why does the client need to be involved?

  32. Ge0rG

    SamWhited: because the server doesn't know if you are connecting with the same client or with a different one

  33. Ge0rG

    SamWhited: things like push and per-device-offline-history and even parallel session management make more sense if the server can distinguish your client instances

  34. SamWhited

    *nods* I see. I generally think we should discourage anything that requires individual clients to be known (eg. per-device-offline-history seems like the wrong way to go about doing history), but I suspect I'll never convince anyone else of that.

  35. Ge0rG

    SamWhited: I think that server-side tracking of individual clients makes much sense and can aid in synchronizing stuff faster.

  36. jonasw

    not to mention killing off other streams when reconnecting without SM

  37. Ge0rG

    SamWhited: the more the server knows about a client, the dumber we can make the client

  38. SamWhited

    I have a vague feeling (not a strong one yet) that it just leads to a more complicated protocol and hurts us, but I don't have any good reasoning for that. I don't think not having it would make any of the clients any less dumb.

  39. SamWhited

    It just means we have to design specs assuming that all clients get the same data and view of the world, which seems like a reasonable simplification to make.

  40. Ge0rG

    SamWhited: yes. But we are not designing a new protocol from scratch, instead we are adding layers of cruft on a 1996 unreliable message dispatching system.

  41. Ge0rG

    And with the combo of 0198, 0280, 0313 life is a huge mess for client developers.

  42. Ge0rG

    also offline messages.

  43. Zash

    1996? ITYM 1998

  44. SamWhited

    I don't disagree with any of that, but I also don't think that means we have to keep designing things that way and can move towards simplifying the protocol.

  45. Ge0rG

    SamWhited: I'm open to suggestions

  46. Kev

    I think offline messages quietly die.

  47. Kev

    With 'xmpp 2'.

  48. Ge0rG

    I think that per-client offline messages would silently fix UX for legacy client users

  49. Kev

    I think 198 is a different layer, and not really a big deal for clients (at least for acks. I'm still not entirely sold on resume).

  50. SamWhited

    Kev already said what I was about to say :)

  51. Kev

    Ge0rG: Only if you assume a small disconnect. Once you get into hundreds of messages, it doesn't.

  52. Ge0rG

    Kev: with hundreds of messages, MAM with RSM provides a better progress display

  53. SamWhited

    Although, the other thing I've already said: in my mind it's simpler if the client knows nothing about the resourcepart except that it was assigned one by the server. If the server doesn't necessarily know the difference between clients I think it simplifies what we'll do with the protocol.

  54. jonasw

    only if you get <count/> :-)

  55. Ge0rG

    SamWhited: again, only if we start from scratch

  56. SamWhited

    No, we could do that today

  57. Ge0rG

    SamWhited: resource binding already has implications based on client identity.

  58. Kev

    Ge0rG: I don't think so. A server can assign resourceparts to everything already, and some do.

  59. SamWhited

    Well sure, I'm not suggesting every server change overnight

  60. Kev

    Or I've not understood.

  61. SamWhited

    But as Kev just said, it's perfectly backwards compatible to move towards a world where servers always assign a resourcepart.

  62. SamWhited

    Some of them already do it.

  63. jonasw

    that’s not a good idea with SM-less clients though?

  64. jonasw

    unless you take the resource proposed by the client as a hint on which connection to kill.

  65. Ge0rG

    jonasw: with Carbons that doesn't matter™

  66. jonasw

    Ge0rG, it does

  67. Ge0rG

    Because you can just keep two dozens of zombie resources for your client, no problem.

  68. jonasw

    Ge0rG, but the client would lose messages

  69. Ge0rG

    The other person will not receive error bounces for messages that went into them.

  70. Ge0rG

    Zombies are great.

  71. jonasw

    sarcasm-detector fails

  72. Ge0rG

    Let's grow them.

  73. jonasw


  74. jonasw

    sounds like a good idea

  75. SamWhited

    If they're a legacy client without carbons or SM they can already lose messages, so it seems like we can ignore that. If we really can't ignore that, then the server can still see what resource part the legacy client is detecting, use that internally for tracking, and then assign it a random one.

  76. Ge0rG

    jonasw: no, zombies

  77. Dave

    SamWhited, I don't think you can make things *worse*.

  78. Ge0rG

    I'm sure we can make things worse.

  79. Dave

    Ge0rG, Well, yes. s/can/should/

  80. jonasw

    especially, I realize that the losing messages is independent of killing the old connection

  81. jonasw

    I was confused, sorry

  82. SamWhited

    Dave: I didn't follow that; what makes things worse?

  83. Ge0rG

    And I think that making random resources enforced by the server _will_ make things worse.

  84. Ge0rG

    XMPP message delivery is already very fragile, and even with most modern clients you have issues of not receiving 0184 messages.

  85. Dave

    BTW, I've updated the Spreadsheet Of Doom™ with tomorrows items for a vote. There's a lot. https://docs.google.com/spreadsheets/d/1AZ-Sna6OiRG--b-mJMKv3XXfrn3Nehm0kAtlyJvImL0

  86. jonasw

    holy smokes

  87. jonasw

    what’s a CFE?

  88. jonasw

    Call For Experience for moving to final?

  89. jonasw

    so this is essentially a Final vs. Deprecate vote?

  90. Ge0rG

    jonasw: right

  91. jonasw


  92. Zash

    > Ett webbläsarfel har uppstått. Thanks supporting Firefox

  93. jonasw

    who’s going to do all the editorwork :-P

  94. Dave

    jonasw, Exactly. But we vote to CFE, and if that succeeds, I'll drop the other one.

  95. Dave

    jonasw, Oh, I had a thought about that - would github issues be OK for tracking editor tasks?

  96. jonasw

    Dave, I’d *love* that

  97. Ge0rG

    So I grepped for 0020 usage today, and found only 0066 and 0155 that are not deferred

  98. jonasw

    a bulk issue is fine with me

  99. Dave

    jonasw, OK, I'll *try* to do that.

  100. jonasw

    especially if you use the '* [ ] foo' syntax

  101. Ge0rG

    And 0020 is on the agenda as well

  102. Ge0rG

    Eh, 0066

  103. Dave

    jonasw, Hmmm. I can try that, or just individual issues.

  104. jonasw

    Dave, individual issues would work too, but that might in fact be more overhead because more pageloads for me.

  105. Dave


  106. jonasw

    I prefer: bluk issue with '* [ ] list' > bulk issue in whatever format > Spreadsheet of Doom ~ one issue per task

  107. jonasw

    I’m not sure on the ordering of the last two

  108. Dave

    Yeah, the SoD is useful for tracking voting (at least for me).

  109. Dave

    But not so much for tracking editor actions.

  110. jonasw

    if I had +w I could tick off editor actions tehre too. but what I need most is something which gets me an email in my inbox when something is to b e done

  111. Zash

    Issue tracker!

  112. SamWhited

    If the editors want to move to GitHub issues (and someone is willing to create the issues), let's close the Trello board to avoid confusion.

  113. jonasw

    I’d be in favour of that

  114. jonasw

    I never was able to use the trello thing productively. the email notifications are pretty useless to me

  115. daniel

    Zash: I'm missing so much context. That commit you linked is just a debug option for Guus to debug open fire. It deliberately not kicks you old resource

  116. daniel

    And I'm not getting the joined with a resource phone thing either. Like instead of a proper username or what?

  117. daniel

    That really shouldn't happen

  118. Zash

    daniel: It looked relevant to the topic at the time

  119. Dave

    SamWhited, It might be useful for people to note non-GH-ish things for the agenda.

  120. jonasw

    Dave, for the editor agenda?

  121. Dave

    jonasw, Council.

  122. jonasw

    I think sam was referring to the editor trello, but I might be wrong.

  123. SamWhited

    Dave: yah, I just meant the editor one. Let's not make editors use two tools.

  124. SamWhited

    Dave: Also, a request: can there be a tab on that spreadsheet that mirrors the main one but only gives you a view of the last two weeks?

  125. SamWhited

    (do spreadsheets have a name for that? Like a materialized view in a proper database?)

  126. Dave

    SamWhited, I have literally no idea. But you're looking for the pink ones.

  127. Dave

    29) Close

  128. Dave


  129. SamWhited

    The pink ones are all in the future which I assume means I have no outstanding stuff? I am happy to make a new tab with just the view I care about if you give me access.

  130. Dave

    SamWhited, Well, yes, the pink ones aren't until tomorrow (I do the spreadsheet first, then the agenda from that).

  131. Dave

    SamWhited, But also, anything red in your column (except again I've updated that prior to the meeting - which I normally don't do).

  132. SamWhited

    But my column is in the middle, so I have to find it which makes me sad

  133. SamWhited

    Or rather, the current date it in the middle, so I have to scroll down and figure out which was the last meeting.

  134. Ge0rG

    Dave: while we are here. I wanted to address the insufficient uniqueness of IDs in RFC 6120, but I have no idea what we can do about it, process-wise

  135. Ge0rG

    Can't we align the member names to the spreadsheet column letters, so Kev would be in K, Sam would be in S and Daniel and Dave would be in D? :D

  136. Dave

    I'm mildly concerned by the idea of provably unique stanza identifiers. But saying they ought to be globally unique seems fair.

  137. Kev

    Is a 29 item 30minute agenda sensible, or would we be better off chunking this a little bit?

  138. Dave

    Ge0rG, If I knew how to make the spreadsheet keep Row 1 from scrolling I'd be happy.

  139. Zash

    is OUGHT in that rfc2119 follow-up?

  140. SamWhited

    Dave: there is a little dark bar under row 1, drag it down below row 1 and that becomes the title.

  141. SamWhited

    But I said column, I meant rows. It's the rows I'm trying to get to quicker.

  142. SamWhited

    *above row 1

  143. jonasw

    Dave, suggestion: given that that’s going to be a long agenda, could council discuss the PRs (where people put work into getting things proposed) first?

  144. Ge0rG

    jonasw: 👍

  145. Dave

    jonasw, That's the cherry on top of the agenda, though.

  146. Dave

    jonasw, It's the reward for getting through the other bits.

  147. Dave

    Kev, FWIW, this is really a 15 item agenda, with some items potentially having two votes. I think we'll overrun, but not badly.

  148. Kev

    I've not looked at it properly, I'm barely functioning today after a headache yesterday, but I saw it was long and got worried.

  149. jonasw

    Dave, how about I ping you on github when marking an issue Needs Council?

  150. jonasw

    does that anything good or do you get the mails anyways

  151. Dave

    Kev, Most votes are paired CFE/Deprecate, where we don't do the second if we've done the first.

  152. Dave

    jonasw, I do the agenda by looking at all the open pulls, actually, so while I do get the mails I don't use them for that.

  153. jonasw

    Dave, okay, whatever works for you :)

  154. jonasw

    reminds me, gotta send emails

  155. Dave

    SamWhited, Made it not-pink unless the items are between 0 and 14 days in the past.

  156. SamWhited

    I still have to scroll down and find it and I am lazy; can I please just get a second tab that I can make a view that only shows the last two weeks that are not in the future?

  157. SamWhited

    Or can we clear out the old stuff?

  158. jonasw

    I think I still have to execute two ediotr actions from last meeting, maybe put those into something else first.

  159. Ge0rG

    > Or can we clear out the old stuff? I'd like to keep history, even if only in a separate tab. It helps when looking for discussion agendas (our council agenda logs are inherently unsearchable by XEP #)

  160. SamWhited

    This would work:

  161. SamWhited

    =filter(Sheet1!A$2:A, Sheet1!$A$2:$A<TODAY(), Sheet1!$A$2:$A>(MAX(filter(Sheet1!$A$2:$A, Sheet1!$A$2:$A<TODAY()))-14))

  162. SamWhited

    There may be a simpler way of course

  163. Dave

    SamWhited, OK, you now have both a "Current" tab and a "Sam" tab. "Current" lists current votes, and "Sam" only lists current votes for which you haven't voted.

  164. Dave

    Of course, none of these list anything right now because there are no current votes.

  165. SamWhited

    oh individualized tabs; fancy! Thanks

  166. Ge0rG

    "You need to be logged in as samwhited@gmail.com to view this tab." Bummer.

  167. SamWhited

    I don't know who samwhited@gmail.com is, but it's not me

  168. SamWhited

    I appear to be able to see all the tabs, but they all show up with no data in them

  169. Dave

    SamWhited, Right. Because there are no current votes.

  170. Dave

    SamWhited, I changed some of the dates to check it worked. :-)