XSF Discussion - 2021-03-24

  1. Sam

    Is there a reason XEP-0013 isn't yet deprecated? It's not entirely the same thing as MAM, but it doesn't seem worth keeping around

  2. Holger

    Sam: Some clients actually use it to disable offline delivery in favor of MAM.

  3. Sam

    And XEP-0160 for that matter

  4. Holger

    I.e. to avoid some dedup.

  5. MattJ

    Which is a total hack

  6. Ge0rG

    The interop between offline messages and MAM and a seamless transition between MAM and live message delivery is still unsolved.

  7. Sam

    Not deprecating this doesn't help solve it.

  8. Holger

    kk wasn't aware we have proper solutions rather than hacks now 🙂

  9. Ge0rG

    Wait, it's a somewhat deployed solution to one part of the problem space.

  10. Sam

    Especially if clients are using this as a hacky work around, it seems like we should start discourating it

  11. Holger

    In favor of what?

  12. Sam

    In favor of just using MAM and if it doesn't meet your needs you should write a new thing or update MAM instead of relying on hacks.

  13. Zash

    You still get a burst of offline messages then

  14. Sam

    Maybe this should be considered during MAM advancement discussion then. Leaving these out of the discussion doesn't seem great

  15. Sam

    But as always: discouraging people from using old hacks doesn't immediately make all clients remove them entirely.

  16. Holger

    Sam: The use case I mentioned was for MAM clients.

  17. Sam

    It just means we move it to deprecated and recommend that people come up with a new way to do things.

  18. Sam

    Holger: yes, it just seems like a hack we shouldn't encourage

  19. Ge0rG feels inclined to recite old standards@ threads.

  20. Holger

    If we tell client devs not to use 0013 they'll ask what to do instead.

  21. Holger

    Just receive the spam and dedup?

  22. Sam

    Good, that's a good thing for them to be asking and for us to think about

  23. Holger

    Works but doesn't seem less hacky to me. L

  24. MattJ

    Holger, well it's doing that for Prosody servers anyway. right?

  25. Holger

    Works but doesn't seem less hacky to me.

  26. Kev

    (The answer is to not send offline messages when using bind2, IMO)

  27. Holger

    MattJ: Yes. Works but not less hacky.

  28. MattJ

    And I'd like the server to solve this by not sending offline messages to modern clients

  29. MattJ

    Whether that's bind2 or not I don't know, bind2 is perpetually beyond our reach

  30. Kev

    (Or bind3, or whatever we end up using)

  31. Ge0rG

    Kev: bindIM2.0

  32. Zash

    What about messages that end up in the offline store, but not in MAM?

  33. MattJ

    bind2 would be the easiest fix to a whole range of problems

  34. Zash

    (and why‽)

  35. Sam

    Yah, I could see this belonging in MAM or in Bind2

  36. MattJ

    and by bind2 I actually mean "any replacement for the current resource binding step"

  37. Holger

    I know you guys all have nice solutions in your mind. What I don't get is how it helps to deprecate existing solutions *before* we have new ones.

  38. Kev

    Holger: I’m not saying they do.

  39. Sam

    I absolutely think they do. Nobody bothers to make fixes as long as there's some old hacky solution available

  40. Kev

    I’m just saying how I think we should solve the use case.

  41. MattJ

    Holger, XEP-0013 isn't implemented by more than half of deployed servers anyway, and that's unlikely to change. So either it works without XEP-0013 already, or we're no worse off...

  42. Sam

    If we deprecate, it doesn't break any existing thing, it just encourages new solutions to be put forward

  43. Sam

    Also what MattJ said

  44. Holger

    MattJ: Then let's deprecate everything that's not in ejabberd right now as well 🙂

  45. Holger


  46. Sam

    And it makes it less likely that new clients accidentally implement an old thing because MAM has scary red text at the front and this has nice green draft text

  47. Sam

    We can debate where to draw that line (ie. MUC is widely implemented, maybe we can't just get rid of that and say "do MIX"), but this just seems confusing and it's not like a ton of things implement it as Matt pointed out

  48. MattJ

    Holger, that's not what I'm saying, of course. Just that you're positioning XEP-0013 as necessary, when it clearly is not.

  49. MattJ

    Though sign me up for MIX deprecation :D

  50. MattJ


  51. MattJ

    (I think)

  52. Sam

    Anyways, I think this discussion is already helpful and should be part of the council's discussion when the MAM LC is over, that's all I'm saying. Council, please consider that this is related to the MAM LC and might be a thing worth considering :)

  53. Holger

    > Holger, that's not what I'm saying, of course. Just that you're positioning XEP-0013 as necessary, when it clearly is not. It's not necessary, just an optimization. Like e.g. 0198.

  54. Kev

    I don’t think it actually affects MAM advancement.

  55. Holger

    And I think optimizations are legit.

  56. Kev

    (Which doesn’t mean Council can’t think about it, I just don’t think it’s pertinent)

  57. Sam

    As always, I think it's confusing to have two things that both appear to be recommended and have significant overlap in functionality, and therefore it does affect MAM advancement in my mind.

  58. Ge0rG

    Well, it might be an optimization, but using 0013 might also create a hole between MAM sync and live traffic, depending on things the client developer forgot to thoroughly think about

  59. Sam

    Also if parts of this are needed in MAM, we should not advance MAM, so I think it's relevant in that way.

  60. Sam

    (although I tend to agree this makes more sense in bind2)

  61. MattJ

    I agree with Kev that MAM is unaffected

  62. Sam

    Fair, if council doesn't think they're related that's fine. Either way, please consider this a request to discuss deprecating 0013 and 0160

  63. MattJ

    Offline messages are technically not really standardized anywhere (XEP-0160 is the closest, an attempt to document them after the fact)

  64. Sam

    (0160 seems like it's useful, just *very* outdated since it doesn't even mention MAM)

  65. Holger

    > Nobody bothers to make fixes as long as there's some old hacky solution available Like nobody bothers to make fixes rude the old hacky solution is deprecated. Where's that XEP that does stranger blocking now that 0016 is deprecated again?

  66. Holger

    > Nobody bothers to make fixes as long as there's some old hacky solution available Like nobody bothers to make fixes when the old hacky solution is deprecated. Where's that XEP that does stranger blocking now that 0016 is deprecated again?

  67. Zash

    If it works, don't fix it!

  68. Zash

    (they said about the broken mess)

  69. Sam

    That's a perfect example. We have a better solution, it solves the 90% use case, if Process one is still using privacy lists, that's fine but we no longer have a confusing situation.

  70. Holger

    We have the situation that XMPP just doesn't support a use case some are interested in.

  71. Holger

    Because we had to deprecate the existing solution in favor of a non existing one.

  72. Sam

    Who's interested in it? As far as I can tell it's like 2 people and they're both just using the old thing, which is fine.

  73. Holger

    I've been asked more than once how you'd implement that.

  74. Holger


  75. Sam

    So write an XEP for it.

  76. Holger

    We had one.

  77. Sam

    Yes, one that had confusing overlap with another spec and which made it trivial to shoot yourself in the foot and tried to everything under the sun instead of just "block strangers" if that's the functionality from it you need.

  78. Holger

    I've been told we don't need it because someone will write a simpler one. I never said I'll do that.

  79. Sam

    Good, don't, keep using the old thing until someone else writes one then.

  80. Holger

    Now I'm being told the functionality is no longer needed, yay.

  81. Sam

    It's not needed IMO, if it were more people would be interested in writing a replacement.

  82. Holger

    So I'll tell client devs to ignore the depreciation.

  83. Kev

    I think lots of people use the feature, it’s just not standardised any more and is either by server configuration or adhoc command.

  84. Holger

    What's the point of the depreciation then?

  85. Kev

    I might be wrong, but it’s the impression I get.

  86. Sam

    That's fine, if that's what you have to do that's what you have to do. Deprecation doesn't mean you're instantly barred from implementing forever, it means we don't recommend this solution.

  87. Holger

    I'm asking why we stop recommending a solution before coming up with an alternative.

  88. Sam

    Because those two things don't have anything to do with one another, and as long as we're recommending a soultion there will never be an alternative.

  89. Holger

    I don't get that logic at all.

  90. Sam

    I'm not saying an alternative will appear immediately if we stop recommending it. I am saying that there's no chance of getting one if we continue recommending it.

  91. Holger

    If someone thinks a solution is suboptimal he should provide a better alternative. Rather than ditching it and telling others to do that if they needed the functionality.

  92. Kev

    I think that’s been demonstrably untrue through XMPP’s history, FWIW. 191 came about before 16 went away, it just missed a bit (accidentally, I suspect). 313 136, etc. etc.

  93. flow

    What Holger says

  94. Kev

    (My comment refers to never having alternatives while the original is around)

  95. Sam

    Also that (in the case of privacy lists) continuing to recommend them was harmful. They overlapped with blocking command, so we had the situation where some things used one and some used another and the XMPP network wasn't compatible if you switched clients.

  96. Sam

    And also privacy lists would cause you to shoot yourself in the foot, like the cisco phone that when I added it to my account blocked everything that didn't look like a phone number, which IMO shouldn't even be possible in a standardized way.

  97. Sam

    sorry, messages are significantly delayed for me, I'm typing responses then it's taking a minute to send

  98. Sam

    Sure, fair enough, on rare occasions it happens, but I think mostly it's been good when we've deprecated things that are old and broken regardless of whether there's a solution or not.

  99. Sam

    Anyways, unless we have some sort of product manager deciding what features the network must have, I don't see why the XSF has to have a recommendation for every possible feature. If we want people to take XMPP seriously again and stifle the (very valid) Matrix critisism of having too much old cruft and it being impossible to implement XMPP, we should get rid of the old cruft.

  100. Sam

    Sometimes there will be old cruft we really can't get rid of because it's widely used, or is an absolutely necessary feature, etc. but I don't think that's what this is.

  101. Holger

    I think there's significant demand for that feature, but I don't think that matters much. If there's *any* demand for some functionality, having an extension for that makes sense.

  102. Kev

    I think it lives somewhere in the gray area between the two :)

  103. Holger

    Right now it would be used by (and could be recommended to) quite a few users as a simple way to avoid spam, esp. if their contact list basically never changes.

  104. Sam

    We can report spam without also doing lots of other harmful things. And in fact, there is a better more targeted XEP for that.

  105. Sam

    We can have a more targeted XEP for just blocking all users too if that's a feature people want, it just seems like the harm of recommending a giant thing with overlap that breaks across clients just to do that one thing outweighs the benefit of not having a thing in draft that does that one tiny thing you seem to actually want privacy lists for.

  106. Holger

    I'm aware of that XEP, it doesn't do the same thing in a better way.

  107. Holger

    Yes we can have it. We drive have it.

  108. Sam

    The point still stands. An XEP causing actual harm being kept around for one tiny feature seems like a bad tradeoff.

  109. dwd

    I think we need a blockchain.

  110. Zash

    I have a normal chain, is that enough? It holds up a lamp.

  111. Sam

    Maybe privacy lists does meet some threshold for that and this one doesn't, I don't know, we can discuss where to draw that line, but I'd argue that "we have to have all features at all costs" isn't a good place to draw it.

  112. Holger

    This is just about *existing* features. Not all features.

  113. Sam

    Fine, "we have to keep all existing features at all costs" isn't a good place to draw it.

  114. flow

    no, but isntead of assuming that we can create one-size-fits-all kind of xeps, we may have to acknowledge that there could be multiple xeps for the same thing but with a different scope

  115. Sam

    I think that *can* be fine, but it definitely wasn't in this case. When gajim does one thing and conversations does another and it's not compatible so depending on which you log in with people appear blocked or not, that's a problem.

  116. Sam

    Or when a new developer tries to implement an XMPP client and there are two specs that do almost the exact same thing and they have no way to tell which they should implement, or worse, the one that nobody uses that they *definitely* shouldn't implement appears recommended and the other doesn't, that's a problem.

  117. Holger


  118. Sam

    And that's a much bigger problem than deprecating an XEP to provide guidance and not breaking any existing clients or servers.

  119. Holger

    I'm just questioning who to solve such problems.

  120. jonas’

    yeah, it’s a shame that we don’t have documents which give new developers guidance about which XEPs to look at

  121. Sam

    Yes, bringing back the compliance suites was one thing I tried to do to solve those problems, it can't do it on its own though.

  122. Ge0rG

    Just recommend the Compliance Suites ;)

  123. Ge0rG

    Sam: what's missing from compliance suites that you'd like to recommend to new developers?

  124. Sam

    Nothing, and I always do recommend them. But not everyone will find the compliance suties, and the XSF recommending broken products with significant overlap still causes harm.

  125. Sam

    Well, I mean, I dunno if things are missing or not, I just see them as only part of the solution.

  126. Ge0rG

    So the solution to this problem is: make the Compliance Suites more prominent

  127. dwd

    We've discussed putting the current compliance suite prominently on the website, potentially even in a different format so it's nice and simple to read.

  128. Holger

    FWIW I'm all with Sam that overlapping solutions is one of the most severe issues with our specs …

  129. dwd

    XEP-0136 forever?

  130. arc


  131. arc

    Well apparently the meeting isn't happening today either

  132. moparisthebest jots down who to fire at next board election

  133. moparisthebest

    I KID I KID :)

  134. dwd

    I'm here, actually.

  135. Zash

    MattJ, ralphm?

  136. dwd

    Obviously moparisthebest can fire me anyway.

  137. arc

    An email went out to the board list but no action has been taken on it yet

  138. MattJ

    This slot continues to be one of the worst possible in my entire week, my inability to attend should not be a surprise by now :)

  139. MattJ

    I filled out the poll last week, I don't know if everyone has yet

  140. jonas’

    looks like 3 people filled it out so far

  141. MattJ

    arc, looks like you haven't filled out the poll yet?

  142. arc

    I am the easy one 🤣

  143. MattJ

    Sarcasm? :)

  144. ralphm

    Cool, with 4 out of 5 it seems the best availability is on April 1.

  145. ralphm

    Oh, wait, 4 out of 4.

  146. arc

    I'm the easy one because I'm just generally available after 9:00 a.m. Pacific

  147. arc

    And they can be available even earlier than that if that works better for most people

  148. arc

    I'm just not very generally functional before my first tea

  149. ralphm

    So, if we'd retry this tomorrow at 17:00 UTC and then 16:00 UTC after the DST change coming weekend, would that work?

  150. ralphm

    arc: also whooosh

  151. MattJ


  152. arc


  153. ralphm

    Ok, modified the calendar accordingly

  154. moparisthebest

    1. how *should* an XMPP server handle non-XML junk sent from a client after bind 2. how do existing XMPP servers *actually* handle that in the wild?

  155. Zash

    Like, text content between stanzas?

  156. moparisthebest

    for #2 prosody seems to silently ignore it, it'll deliver stanzas sent after said junk just fine

  157. moparisthebest


  158. Zash

    Yeah, goes into the same void as whitespace keepalives.

  159. L29Ah

    any reason for whitespace keepalives, except "my tcp implementation lacks SO_KEEPALIVE"?

  160. flow

    L29Ah, I don't think so

  161. moparisthebest

    many a fun firewall exists that doesn't care about your SO_KEEPALIVE

  162. Kev

    Well, there’s also detecting dead sessions.

  163. flow

    L29Ah, the question is if you don't want to use xmpp ping or SM's <r/> for keepalive

  164. flow

    "if session idle for X minutes, then send xmpp ping to server" is what i usually do

  165. Zash

    Someone should make a diagram of what parts of the stack is appropriate for TCP keepalives, whitespace keepalives, xep-0199, xep-0198 <r/> ...

  166. L29Ah

    moparisthebest: do they just drop empty-data tcp packets for the fun of it?

  167. moparisthebest

    yes, except they sell it as a feature "traffic optimization"

  168. moparisthebest

    they'll also silently drop your TCP connection and not bother sending you a RST on each side, so you both think you are still connected to each other, hence Kev 's "detecting dead sessions"

  169. Zash

    Do TCP stacks even let you send empty packets?

  170. moparisthebest

    well I'm assuming inside TLS here, so it's never empty

  171. flow

    L29Ah, I probably don't have to say that, but please take session idle time into account for keep alive mechanisms, do not simply do periodic sends

  172. Zash

    OH! There's also TLS heartbleed packets :D

  173. flow

    or tcp out of band data

  174. L29Ah

    flow: that SO_KEEPALIVE cares for, but whitespace stuff needs to do it explicitly :/

  175. flow

    L29Ah, right, but it's not rocket science i'd say :)

  176. Zash

    This gets more fun if you have proxies involved.

  177. Zash

    Like, say, all those sslh setups people use to share port 443 with their web server.

  178. Zash

    or websocket proxied trough some reverse proxy

  179. L29Ah

    pontarius-xmpp doesn't care about it yet

  180. moparisthebest

    Neustradamus: https://tools.ietf.org/html/rfc8996 you should get all the servers and clients to implement this, also public servers :)

  181. Neustradamus

    moparisthebest: Nice! Sam will must to know it ah ah

  182. moparisthebest

    they pull no punches language-wise: > TLS 1.0 MUST NOT be used. Negotiation of TLS 1.0 from any version of TLS MUST NOT be permitted. > TLS 1.1 MUST NOT be used. Negotiation of TLS 1.1 from any version of TLS MUST NOT be permitted.

  183. Neustradamus

    MattJ: https://www.ssllabs.com/ssltest/analyze.html?d=jabber.org