XSF Discussion - 2017-12-14

  1. moparisthebest

    can, or should I say do, any XEPs define new stanzas ?

  2. SamWhited

    moparisthebest: no, and no. You can define payloads to be transmitted in existing stanzas or new unroutable top level elements, but not new routable stanzas with their own delivery semantics.

  3. moparisthebest

    that makes sense but I wasn't absolutely positive

  4. moparisthebest

    thanks SamWhited

  5. Ge0rG

    moparisthebest: if you define a new routable stanza type, you'll have to change all existing clients and servers

  6. jonasw

    daniel, please re-send the council minutes to standards@

  7. Guus

    Fellow board members: I've mentioned this in mail last week, but didn't get any ack, so just in case it was missed: I won't be able to make todays meeting.

  8. Flow

    dwd: "I deliberately use a fixed resource string here because it makes debugging much easier.", so what do you think about bind 2.0 not allowing for that?

  9. dwd

    Flow, Pretty sure you know the answer to that. :-)

  10. Zash

    Prosody doesn't initiate piggybacking, everything is weird

  11. Flow

    dwd: I can only guess. I still hope we could give clients the ability to provide a resource prefix when using bind 2.0

  12. jonasw

    I don’t see a use in a prefix. It can’t be used for addressing, which would be my main use-case for stable resources.

  13. Kev

    Flow / dwd: Except that the split resource thing actually means that in this case it's just as easy.

  14. Kev

    jonasw: Debugging is easier if you have friendly parts to the resource, at least.

  15. Flow

    jonasw, it's not about stable resources, but as debugging aid

  16. Flow

    Kev, didn't get that, sorry. It's just as easy was *what*?

  17. Kev

    It wasn't important.

  18. Flow

    Kev, It still would be nice to understand what you meant

  19. Kev

    I think that a resource of kev@isode/client1/{random} is as easy to debug as kev@isode/client1 in terms of grepping and following logs. While kev@isode/{random} does definitely make it difficult.

  20. Kev

    Or more difficult, anyway.

  21. Kev

    My bind2 plan is still the split-resource thing we discussed at the summit, to allow for this.

  22. Ge0rG

    But what was discussed at the summit is `kev@isode/{random}/{morerandom}`, which is just crazy.

  23. Guus

    I think what was discussed was `kev@isode/{freeform-butpredictable}/{random}

  24. Ge0rG

    I'm pretty sure the consensus was kev@isode/{client-generated-uuid}/{server-generated-uuid} with a strong implication of those horrible 128-bit-hex-blobs

  25. dwd

    I have to admit I'm worried that all jids will now begin "kev@isode".

  26. dwd


  27. Ge0rG

    dwd: the double-UUID namespace would allow for a conflict-less mapping of all XMPP users onto kev@isode, at least.

  28. Guus

    you can't have enough Kevs.

  29. jonasw

    Guus, the proper way to add me to Summit is to simply edit the wiki page?

  30. dwd

    But anyway. I understand that there is benefit in some implementations to enforce a server-written portion of the resource. I don't think this benefit is applicable to all implementations.

  31. Guus

    Ge0rG: I was under the impression that we discussed a combination of a human-recognizable identifier (for easy debugging/grepping), and a random part (to prevent predictable full jids). But then again, I'm enjoying the sight of a new castle every 7 seconds or so.

  32. jonasw

    (Guus: this is the wiki page I’m talking about: https://wiki.xmpp.org/web/Summit_22 )

  33. Guus

    jonasw: and show up in Brussels. :)

  34. jonasw

    well, yes

  35. dwd

    And right now, I'm more concerned about fragile clients and misbehaving servers when trying to join chatrooms.

  36. Ge0rG

    Guus: I'm solving that for many years now by using `"yaxim.%08x" % uint.random()`

  37. Guus

    jonasw: there's a MUC and a mailinglist you might want to subscribe to.

  38. Ge0rG

    dwd: welcome to MUC hell.

  39. jonasw

    Guus, URIs?

  40. jonasw

    (ugh, yet-another-MUC, I’m running out of tabs!)

  41. Guus


  42. Guus


  43. Guus

    summit@xmpp.org for the mailing list.

  44. jonasw


  45. dwd

    Ge0rG, Well, the actual bug here is in S2S routing, not in MUC per se.

  46. jonasw

    Guus, is there a recommended check-in/check-out date if one wants to participate in the Summit?

  47. jonasw

    like, "latest recommended check-in, earliest possible check-out to get all of summit"

  48. jonasw

    e.g. would it be sufficient to arrive on the 1st, or is that too close?

  49. jonasw

    same for checkout

  50. Ge0rG

    dwd: I'm sure that the problem is triggered by s2s issues, but it's still a shortcoming of the MUC protocol

  51. Guus

    jonasw: having attended only once, I'm not much of an expert, but last year, the summit was two full days. From the Netherlands, I arrived in the morning, and was able to attend the entire day, then spent four days to also be able to visit FOSDEM. I think I travelled back on Monday, to catch all of FOSDEM.

  52. jonasw

    I see

  53. Guus

    jonasw: maybe take further questions to summit@ ? :)

  54. jonasw

    soooo maaaany muuucs :)

  55. jonasw

    but sure

  56. dwd

    Ge0rG, What's the shortcoming? If traffic is dropped due to a bug, and a client relies on perfect network conditions, then I think blaming the protocol is a little excessive.

  57. dwd

    Ge0rG, Not saying I think MUC is perfect, but I don't think it's the MUC protocol at fault in this instance.

  58. Ge0rG

    dwd: the MUC protocol lacks provisions to test whether the client is still connected and to restore connectivity. The existing workarounds are very complicated and unreliable

  59. dwd

    Ge0rG, Sure. But the sequence I showed occured on initial client connect. The client *knows* that it's disconnected from the chatroom (the MUC might not, but we have a simple atomic solution there).

  60. Ge0rG

    dwd: in that case I'm going to read your mail now

  61. ralphm set the topic to

    XSF Board Meeting | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

  62. ralphm bangs gavel

  63. ralphm

    0. Welcome + Agenda

  64. nyco


  65. ralphm

    Hi! Who do we have?

  66. nyco


  67. ralphm

    MattJ, Guus, Martin?

  68. Guus

    ralphm: in absent as announced

  69. nyco

    Guus said he can't be there

  70. MattJ


  71. ralphm

    I missed that

  72. ralphm

    So we are lacking two. I am a bit worried about appointing a Chair for this Board's term. Since we haven't been complete since the start of the term, we haven't been able to do this, and we have to figure out how to resolve this. I don't think hoping we are complete a next meeting is a good strategy. Ideas welcome

  73. Kev

    Ask for volunteers on-list. Vote at the next meeting. Anyone missing has 7 days to vote.

  74. Kev

    Ideally in the new year, in case people are going to be absent due to the holidays.

  75. Kev

    But something like this :)

  76. MattJ

    Yeah, I'd be fine with that

  77. ralphm

    Ok, I'll draft an e-mail about this

  78. nyco

    let's schedule a dedicated meeting, specifically for this, at an agreed time & date

  79. ralphm

    nyco: we do. It is called a board meeting

  80. nyco

    I mean at a different time

  81. nyco

    one that is specific, short, dedicated, efficient

  82. ralphm

    come on, we tried to agree upon a date for the last few meetings and didn't get everyone to respond (in time)

  83. ralphm

    These meetings were short (30min) and efficient.

  84. MattJ

    Yeah, this is the time and day that everyone agreed on

  85. ralphm

    Ok. Given the rest of the agenda and the lack of 2 people, I suggest we adjourn.

  86. ralphm

    I'll send that e-mail and we meet in +1

  87. ralphm


  88. MattJ


  89. MattJ

    Thanks ralphm

  90. ralphm bangs gavel

  91. ralphm set the topic to

    XSF Discussion | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

  92. dwd

    Martin's ill. Or as he put it this morning, developing a closer relationship with the toilet. Sorry, should have passed that on.

  93. Zash

    Question: Why does the new board and council go "live" right after elections?

  94. Guus

    Zash: the bylaws state that an elected official holds office until a successor has been appointed (paraphrased).

  95. Guus

    I don't know why that was put in.

  96. Guus

    Having more procedure would add complexity. If there's benefit to it, I'd be open to changes.

  97. Guus

    why are you asking?

  98. Zash

    Wondering about having a transition period to ease handoff.

  99. Guus

    I'm not sure if it'd meaningfully ease things. The added complexity might outweigh it.

  100. Zash

    But suddenly I'm unsure if any of the orgs I've been involved had that or not.

  101. Guus

    (also, the current board differs with just one person from last years board - not sure if there is the need for much transitioning)

  102. jonasw

    dwd, ugh, I hope Martin gets well soon!

  103. Kev

    I don't think you need concurrent or delayed responsibilities to do handover.

  104. Kev

    It's not like a job where you leave the building.

  105. dwd

    Kev, I have pondered, in the past, suggesting that we stagger elections though, to try and maintain some sort of continuity. But not enough to actually propose anything concrete.

  106. Zash

    Like, elect half the board at a time?

  107. Ge0rG

    We have that process with the XSF Membership.

  108. Tobias

    we do indeed

  109. moparisthebest

    it wouldn't be bad to kind of interleave them with member votes, that would actually bring number of votes per year down

  110. moparisthebest

    like we vote for members 4 times a year, we could vote for council/board 2 of those times also

  111. Ge0rG

    but then we only vote for half the board.

  112. Ge0rG

    the process will be... challenging

  113. moparisthebest


  114. nyco

    2.5 humans?

  115. moparisthebest

    I think we could divide it sanely :P

  116. Guus

    I'm not opposed to any of this, but I'm not seeing real benefit either.

  117. nyco

    well, refreshing half the team mid-term is a good practice, generally given we are short on resource and engagement, that would generate onboarding overhead