XMPP Council - 2019-07-31

  1. Lance has left

  2. lnj has left

  3. peter has joined

  4. Lance has joined

  5. peter has left

  6. peter has joined

  7. peter has left

  8. Lance has left

  9. Lance has joined

  10. Lance has left

  11. Lance has joined

  12. moparisthebest has left

  13. Lance has left

  14. Lance has joined

  15. Lance has left

  16. Lance has joined

  17. lnj has joined

  18. Lance has left

  19. debacle has joined

  20. Lance has joined

  21. lnj has left

  22. lnj has joined

  23. Lance has left

  24. Lance has joined

  25. ralphm has left

  26. ralphm has joined

  27. ralphm has left

  28. ralphm has joined

  29. Lance has left

  30. Lance has joined

  31. dwd

    Finally getting to Agenda. Sorry for the lateness.

  32. dwd

    Doesn't appear that we have anything new to vote on, though - anyone else know of anything?

  33. ralphm has left

  34. jonas’

    we do

  35. jonas’

    we missed that last week, too

  36. jonas’

    give me a sec

  37. ralphm has joined

  38. jonas’


  39. jonas’

    also this: https://github.com/xsf/xeps/pull/803

  40. Ge0rG

    dwd: I'm not sure how much sense it makes to continue last week's discussion.

  41. Ge0rG

    Regarding message references, that is. I've written a response to the Reactions thread which actually summarizes my opinions on that specific topic

  42. Lance has left

  43. Lance has joined

  44. moparisthebest has joined

  45. moparisthebest has left

  46. moparisthebest has joined

  47. Lance has left

  48. Holger has left

  49. peter has joined

  50. Lance has joined

  51. peter has left

  52. debacle has left

  53. Ge0rG

    just in time for the Council meeting, my power and internet access has been restored.

  54. Kev


  55. Remko has joined

  56. Lance has left

  57. Holger has joined

  58. dwd

    You have the power!

  59. peter has joined

  60. jonas’


  61. Kev

    I'm currently considering blocking Message Reactions.

  62. Kev

    Does that make me a bad person?

  63. jonas’


  64. jonas’

    (I seriously considered blocking, too)

  65. jonas’

    and I may still be swayed

  66. Ge0rG

    Kev: the important question is: does not-blocking it make you a good person?

  67. Zash

    Kev: Depends on the rationale for blocking?

  68. dwd

    It's time!

  69. dwd

    (Well, actually, it's late!)

  70. Kev

    "This is definitely not the Right Way to do this, as we need a general way of referencing a previous message for assorted things, of which reactions are only one, and to use that everywhere, while the reactions syntax is not reusable. This mechanism could be references, or could be attaching, but a reactions-only syntax is definitely unhelpful when we need to be collating all the different types of meta-data responses and exposing them in archives. As-is at the moment, without that half of the puzzle solved (such as the collation stuff from the Summit), reactions are limited. I’m very concerned that not doing it Right at first when it goes Experimental is going to lead to an situation where it gets deployed and is almost impossible to fix the holes later due to inertia-once-implemented. "

  71. dwd

    1) Roll Call

  72. Kev

    I'm here.

  73. Kev

    (Above is the text in my votes email that I've not sent because I can't decide if I'm -0 or -1)

  74. Link Mauve

    I’m here too.

  75. Ge0rG

    I've got the power.

  76. jonas’

    I’m here

  77. jonas’

    can we jump straight into that discussion? because I have some opinion on that

  78. Ge0rG

    yes please.

  79. dwd

    jonas’, Not ideally, no. But AOB certainly.

  80. jonas’

    dwd, this *is* about outstanding votes...

  81. jonas’

    but ok

  82. dwd

    2) Agenda Bashing

  83. Kev

    I'd like to add an item (3) about reactions please.

  84. Link Mauve

    Kev, my rationale for +1ing it was to get that sorted out once we are decided on an attaching mechanism.

  85. Kev


  86. jonas’

    dwd, https://github.com/xsf/xeps/pull/801 https://github.com/xsf/xeps/pull/803

  87. Link Mauve

    Which would change 0308 and some other ones too.

  88. dwd

    I don't mind when we talk abbout reactions, happy to do so in (5) or (7) though.

  89. Link Mauve


  90. dwd

    jonas’, Acks.

  91. dwd

    3) Activity Summary

  92. dwd


  93. dwd

    * New XEP-0420 (Stanza Content Encryption) published. * Last Calls open for XEP-0353 and XEP-0300, both due to close on 13th August.

  94. Ge0rG

    as long as it's not in (6)

  95. Kev

    (Link Mauve: I can see an argument for allowing it through. It's the usual argument that if it's not obviously broken (or duplicating) it should be let through - I subscribe to that argument. Just in this case my suspicion is that we'll see quick adoption of this as-written, and it'll be an interop nightmare later.)

  96. dwd

    So please join in the Last Calls.

  97. Remko has left

  98. dwd

    4) Items for a vote:

  99. jonas’

    I’d like to formally apologize for the delay in publishing those changes (editor hat); my mail client was... messed up to the point that I didn’t get new mail unless I restarted it twice, sacrificed a goat and then pressed F5 right when the last drop of... you know the deal. It should be fixed now and I can continue to work properly.

  100. dwd

    jonas’, Am I write in thinking we have to discuss both of those together?

  101. jonas’

    dwd, no you’re not

  102. dwd

    jonas’, Also, it's an MUA. All MUAs are terrible.

  103. jonas’

    one is about obsoleting the CS '18, one is about a patch for XEP-0368

  104. dwd

    Oh, they weren't the ones I was expecting.

  105. Kev

    Isn't 801 already approved, or did I miss this?

  106. jonas’

    Kev, don’t confuse it with https://github.com/xsf/xeps/pull/796

  107. Kev

    How could I?

  108. dwd

    a) https://github.com/xsf/xeps/pull/801

  109. jonas’

    which was indeed approved, but which I (editor) deferred intentionally so that council gets a chance to discuss 801

  110. Kev

    I find 801 and 796 somewhat contradictory.

  111. jonas’

    (I also asked the author of #796 and they were ok with that)

  112. jonas’

    they are

  113. Link Mauve

    So, according to the thread on XEP-0368 which I re-read just earlier, I’m strongly in favour of 796.

  114. Kev

    (There's also a typo in 801 - s/it's/its/)

  115. jonas’

    Observation: The community seems to have at least three differing opinions on how XEP-0368 should work

  116. dwd

    I'm not sure I understand #801.

  117. Tobias has left

  118. Tobias has joined

  119. jonas’

    dwd, I think #801 is a fallback chain of xmpps-server -> xmpp-server -> A/AAAA, while #796 was (xmpps-server + xmpp-server) -> A/AAAA

  120. dwd

    It seems to imply you'd look up _xmpps and only if that returns a '.' look up _xmpp.

  121. Ge0rG

    796: if there is an SRV record, do not try to connect via A/AAAA 801: if there is an SRV record, *do* try to connect via A/AAAA

  122. jonas’

    yeah, that, right

  123. Link Mauve

    The issue with 801 is that it assumes DNS can’t be trusted, in which case we can plain stop doing XMPP things because SRV and DNS are kind of required for that to work.

  124. Kev

    I don't entirely understand the rationale behind not trusting the DNS results, so using other DNS results in 801.

  125. jonas’

    Kev, exactly

  126. jonas’

    that doesn’t make sense to me either

  127. dwd

    Kev, Only trust the DNS results you like?

  128. jonas’

    I tried to argue that with the author in xsf@, to no avaail

  129. Link Mauve

    Also, defining the port fallback as “yolo” is not a good way to go at it.

  130. Kev

    dwd: It feels rather like principles...

  131. dwd

    There is an argument that one might inject a '.' record to _xmpps-* as a downgrade attack I suppose.

  132. jonas’

    yeah, the unspecified port choice is enough for me to -1 this

  133. Kev

    Yes, but if you control DNS to that extent, can't you do thes ame?

  134. Kev

    Yes, but if you control DNS to that extent, can't you do the same elsewhere?

  135. Kev

    And where has 443 appeared from as a valid fallback port when using A/AAAA?

  136. Zash

    Kev: That might be my fault :(

  137. jonas’

    I am -1 on #801, because: - the port choice is, as Link Mauve put it, "yolo", which isn’t really appropriate - It doesn’t clarify like the title suggests, but instead changes behaviour from the previous business rules - Contradicts how SRV works normally - Isn’t logically coherent (don’t trust DNS, but trust DNS)

  138. Kev

    I don't like 801 at all.

  139. Link Mauve

    Kev, I think the assumption is that you will then poke at random ports on a (cached?) AAAA record, until you get something which looks like a TLS endpoint.

  140. dwd

    Kev, Well, if you control DNS to that extent, #801 is insufficient protection anyway (and arguably makes things worse).

  141. Ge0rG

    I agree with jonas’ here, -1 because of the random ports dropped in.

  142. jonas’

    Kev, Zash was sarcastic in the mail thread and suggested 443 and someone took it seriously.

  143. Kev

    In comparison, 796 seems to be logical to me. Annoying that I'd have to change some of my logic in some places, but sensible.

  144. dwd

    I don't like possibly anything about #801, I think. -1.

  145. Link Mauve

    -1 too, for the same reasons as jonas’.

  146. Kev

    -1 to 801 for the reasons previously stated.

  147. Kev

    And +1 to 796, although my period has expired on it.

  148. dwd

    OK. Moving on.

  149. dwd

    b) https://github.com/xsf/xeps/pull/803

  150. Link Mauve

    I’m +1 on 796 too, if we’re back to it.

  151. dwd

    Obsolete Compliance Suites 2018

  152. Ge0rG

    +1 on 3b

  153. Link Mauve

    +1 too.

  154. jonas’

    +1 on obsoleting '18

  155. Kev

    I am +1 on the implied vote to Deprecated.

  156. Ge0rG

    dwd: you wanted to arrange something re CS2020.

  157. Kev

    I'm +1 on the vote from Deprecated to Obsolete.

  158. dwd

    Kev, Very good.

  159. dwd

    Ge0rG, Yes, you're quite right, I did - mea culpa.

  160. dwd

    I think I'm +1 on this too.

  161. jonas’

    I follow Kev here.

  162. dwd

    jonas’, Well, quite.

  163. dwd

    5) Outstanding Votes

  164. jonas’

    did we just have two votes which were immediately decided?

  165. dwd

    Happy to discuss Reactions here, since it's an outstanding one for Kev?

  166. dwd

    jonas’, Yes. Our dysfunctionality isn't working today.

  167. Link Mauve

    jonas’, indeed!

  168. Ge0rG

    this is outstanding.

  169. Kev

    So, I don't want to be a bastard here and prevent progress.

  170. jonas’

    okay, re Reactions: - I think that References isn’t a good choice for I think it needs to change drastically to be useful, especially for quick aggregation use-cases - Message attaching would work-for-me - I strictly think that we should *not* burden or hurt the original authors of the Reactions ProtoXEP by asking them to wait for/write a XEP for referencing. It’s not their fault we don’t have a coherent way to do that.

  171. Kev

    At the same time, my spidey-sense is telling me this is going to end badly if published.

  172. jonas’

    Kev, regarding that, I am still *very* tempted to -1 it based on the "body fallback" argument.

  173. jonas’

    for similar base reasons as you, actually

  174. Kev

    I would -1 it if it had a body fallback.

  175. Kev

    As that would be obviously broken.

  176. jonas’

    oh dear

  177. jonas’

    I’d like to have a high-bandwidth meeting on that topic

  178. Link Mauve

    Kev, as for your spidey-sense, there are already three implementations in the wild, one of which has been released this week.

  179. Ge0rG

    Kev: it's going to be stalled forever.

  180. Link Mauve

    https://nl.movim.eu/?node/pubsub.movim.eu/Movim/fd1921c6-219f-477b-a4be-ebb25e4cccc5 being the one.

  181. dwd

    FTR, Reactions is https://xmpp.org/extensions/inbox/reactions.html

  182. Kev

    Two main reasons: 1) It'll completely break MAM etc. 2) People tend to use reactions when they don't have enough to say to justify a message, because 500 messages of +1 just distracts from conversation, where [👍500] is fine.

  183. Ge0rG

    I'd suggest we rename XEP-0367 into something more generic, which we can use for all message-relationship causes.

  184. Kev

    Link Mauve: I think that's even more argument not to publish it, then.

  185. Ge0rG

    then we use 0367 for Reactions and everything else.

  186. jonas’

    Kev, how would it break MAM?

  187. Kev

    jonas’: Because you'd end up with e.g. 500 messages in the archive because they've got body content.

  188. jonas’

    regarding (2): still there is communication happening, and non-supporting clients silently not seeing the communication is an extremely bad thing in my opinion.

  189. jonas’

    Kev, reactions need to be in the archive anyways.

  190. jonas’

    note that the XEP specifically puts a <store/> hint in the reactions.

  191. Ge0rG

    Kev: looks like there are two fundamental positions here, which differ on whether reactions are an important part of conversation or not.

  192. Ge0rG

    if reactions are not important, we should -1 the XEP altogether.

  193. Kev

    jonas’: Yes. So you need clients to support it. Just as if you don't support PEP et al you don't get to see user tune, or if you don't support MUC you can't enter MUCs.

  194. Ge0rG

    if reactions are important indeed, we need a legacy fallback body.

  195. dwd

    Ge0rG, Well. Maybe.

  196. jonas’

    Kev, user tune is more passive communication. you know you can’t join MUCs when you can’t join MUCs.

  197. jonas’

    you don’t know you lost messages when your client doesn’t support reactions.

  198. dwd

    I don't think we should have legacy fallback bodies baked into the protocol.

  199. Ge0rG

    Kev: re MAM: reactions are supposed to go into MAM as well, via an explicit hint (which is a rejected XEP itself)

  200. dwd

    I don't see a way to get "there" from that point, and we'll be stuck with legacy forever.

  201. jonas’

    dwd, I think, we should, at least for the Experimental phase

  202. jonas’

    we can easily reevaluate during Experimental

  203. dwd

    jonas’, Nope. We'd never get rid of them.

  204. Kev

    I'm very much -1 on fallback bodies.

  205. jonas’


  206. Ge0rG

    dwd: MUC invitations are a place where we do have legacy bodies, but we did it wrong there.

  207. Ge0rG

    so essentially as a client author, you don't know whether the body provides additional information and you need to somehow make sense of it for the user.

  208. dwd

    OTOH, I'm absolutely fine with legacy fallback bodies being added by servers on the C2S link.

  209. Kev

    I'm not convinced even that is a good idea.

  210. Kev

    (Except for 1:1, where it's fine)

  211. Ge0rG

    dwd: how is that different from the sending client adding them?

  212. jonas’

    dwd, doesn’t work with XEP-0420

  213. Zash

    Would you need to rewrite MAM results on the go then?

  214. Ge0rG

    Zash: depending on the client's disco#info

  215. dwd

    Zash, I'm not suggesting mandating it.

  216. Link Mauve

    I also disagree with fallback bodies being sent, as Ge0rG said reactions are generally not “important”, more like a weak +1 or -1 on random messages, unsupporting clients would render that very annoyingly.

  217. Kev

    But in a MUC sending these things out with bodies is going to be more or less excluding legacy clients from the conversation because of the spam they can't possibly deal with other than by supporting the XEP (in which case ...).

  218. jonas’

    Link Mauve, Ge0rG specifically said they *are* important.

  219. jonas’

    I think we have very different experiences with Reactions

  220. jonas’

    in other chat systems

  221. Ge0rG

    if they are unimportant, they are not adding to the conversation, so let's just skip them altogether.

  222. Kev

    My experience is I'm in a number of chats where the ratio of messages to reactions is almost an order of magnitude.

  223. jonas’

    and based on those different experiences, we have different opinions on the importance of fallback bodies

  224. Ge0rG

    Kev: it will increase pressure on legacy client developers to fix their codebases.

  225. Link Mauve

    Ge0rG, unimportant doesn’t mean unneeded, it just means they generally add little signal to the discussion.

  226. jonas’

    that’s not the case anywhere where I am, but oftentimes reactions are indeed important and used instead of typing a "yes"

  227. Ge0rG

    anyway, I thought this is about Attaching References?

  228. dwd

    Well, MUC and reactions is interesting - if you have a typical MUC setup with a scrollback history of 20 items or so, then reactions will typically blast away the entire scrollback if there's legacy bodies.

  229. jonas’

    dwd, even if there’s not, note that the XEP demands a <store/> hint

  230. dwd

    Unless the MUC is aware of reactions, at least.

  231. Link Mauve

    Ge0rG, pressuring Pidgin to implement something isn’t really going to work.

  232. Kev

    jonas’: Yes, that is a case too. I suggest that in such cases the sensible thing to do is ensure everyone supports reactions.

  233. Ge0rG

    Link Mauve: let natural selection sort _that one_ out.

  234. jonas’

    Kev, well, that’s not how the world works

  235. Link Mauve

    Ge0rG, that one, or us. :p

  236. dwd

    Link Mauve, Designing the network and protocol around the shortcomings of Pidgin isn't really my idea of sensible.

  237. Kev

    jonas’: Within subgroups, it kinda is.

  238. Lance has joined

  239. Ge0rG

    Kev: if everyone supports reactions, you don't have any reason to object to legacy bodies.

  240. jonas’

    Kev, so those subgroups can support Reactions and not be bothered by legacy bodies? perfect. The general public should see any message by default.

  241. Kev

    We can't get the public network as a whole upgraded, but if there are groups where reactions are critical, supporting reactions seems sensible.

  242. dwd

    In 1:1, the client know if the other party supports reactions or not. So we don't need legacy support.

  243. Link Mauve

    dwd, neither is it mine, but it was an extreme example, there are many other only-slightly-maintained clients which won’t get support for it until a long time, if ever.

  244. Ge0rG

    dwd: that's not quite correct.

  245. Link Mauve

    There is no need to harm their users if we can avoid it.

  246. jonas’

    dwd, incorrect

  247. dwd

    In MUC, legacy support would screw up history (and probably archiving), so we don't want it.

  248. Kev

    Indeed, multi-clients breaks everything caps-related.

  249. Ge0rG

    dwd: from the "burn resource locking with fire" thread, there is MAM and Carbons

  250. jonas’

    Link Mauve, exactly, that’s why we need a fallback.

  251. jonas’

    silently omitting communication *is* harming users.

  252. Link Mauve

    jonas’, that’s why we don’t need it. ^^'

  253. Link Mauve

    jonas’, but overwhelming users with very small signal-to-noise is harming them too.

  254. Ge0rG

    So Council is now officially in a Mexican standoff.

  255. Kev

    I feel we've veered wildly off target here, which was me trying to justify vetoing it on the basis of harm to the network once it's ratified and inertia sets in.

  256. jonas’

    Link Mauve, I think that’s easier to sort out by social contract than noticing that communication is happening when there isn’t and *then* sorting *that* out.

  257. Ge0rG

    Link Mauve: less so than dropping messages that contain signal.

  258. Kev

    At least saying "This needs to be a different way" puts a line in the sand so no-one's confused about it.

  259. Ge0rG

    Kev: let's come back to that other controversy, then.

  260. dwd

    But we drop lots of things that contain signal. Message receipts, for example.

  261. Ge0rG

    > I'd suggest we rename XEP-0367 into something more generic, which we can use for all > I'd suggest we rename XEP-0367 into something more generic, which we can use for all message-relationship causes.

  262. jonas’

    dwd, they are (typically) only sent when requested, and then not dropped either?

  263. Kev

    I could be persuaded by adding text to the top explaining how this needs to change and that the authors intend to do so as soon as Other Problem is resolved in the community, I think. Which might be a reasonable compromise?

  264. Ge0rG

    dwd: did you know that there are clients which will send receipt requests into a MUC? And other clients, that will send receipts to those requests, also into the MUC?

  265. Ge0rG

    That being said, there is really no harm done by legacy reaction bodies.

  266. dwd

    Ge0rG, See also typing notifications.

  267. Link Mauve

    jonas’, ask pep. how he felt with reactions and threads in an environment which was enforcing their usage. :p

  268. Link Mauve

    (And his software couldn’t.)

  269. jonas’

    Link Mauve, I know that pep. has strong opinions about things, and they’re often very opposed to mine and we can’t seem to convince each other.

  270. dwd

    ANyway, we're out of time... Maybe argue about this on the list?

  271. Ge0rG

    dwd: that won't work.

  272. jonas’

    the vote expires today

  273. jonas’

    Kev, your vote?

  274. Link Mauve

    Kev, +1 to that.

  275. jonas’

    I don’t believe in XEP authors claiming intention to change anything after acceptance

  276. jonas’

    we had that with OMEMO

  277. Neustradamus has left

  278. Ge0rG

    Kev: what about replacing the reference mechanism in Reactions by 0367, and Council doing its due duty to make 0367 a sensible long-term vehicle?

  279. jonas’

    Ge0rG, I’d be on-board with that one

  280. dwd

    Kev, I'm fine with that. I think I even said I thought it'd radically change, myself.

  281. Kev

    Ge0rG: I don't think it's Council's duty to do anything with 367.

  282. Kev

    But FWIW, despite References, I think 367 could be a reasonable basis for all this stuff.

  283. Ge0rG

    Kev: that's not the right attitude.

  284. dwd

    Kev, Or, BTW, totally fine withouy rejecting it outright until we've disentangled this mess.

  285. dwd

    Kev, Or, BTW, totally fine with you rejecting it outright until we've disentangled this mess.

  286. dwd

    Kev, But asent a vote from you before EOD, it'll go through as-is, so...

  287. Ge0rG

    dwd: this is a bit like prosecuting the XEP author for shortcomings of the ecosystem. I would very much like to NOT pull this card on Experimental

  288. dwd

    Kev, But absent a vote from you before EOD, it'll go through as-is, so...

  289. dwd

    Ge0rG, Personally I agree. But Kev can veto it for having the letter 'e' in it too many times if he chooses.

  290. Kev

    "This is definitely not the Right Way to do this, as we need a general way of referencing a previous message for assorted things, of which reactions are only one, and to use that everywhere, while the reactions syntax is not reusable. This mechanism could be references, or could be attaching, or could be something else, but a reactions-only syntax is definitely unhelpful when we need to be collating all the different types of meta-data responses and exposing them in archives. As-is at the moment, without that half of the puzzle solved (such as the collation stuff from the Summit), reactions are limited. I’m very concerned that not doing it Right at first when it goes Experimental is going to lead to a situation where it gets deployed and is almost impossible to fix the holes later due to inertia-once-implemented. Council had a long and heated discussion about this today, and I think the best thing I can do is -1. My suggested remediation is to a) Get general agreement that either references or attaching can be our Future Mechanism For All The Things (I think we’re pretty much there) b) use Attaching (367) in reactions."

  291. Ge0rG

    Also I remember some people saying that it's much better to have an Experimental XEP than an XML file on some personal server.

  292. dwd

    Ge0rG, I also agree with that.

  293. Kev

    I'm about to send that, unless someone persuades me otherwise.

  294. jonas’

    Kev, go ahead. the change is trivial.

  295. Kev

    Ge0rG: I agree with that in almost all cases. :)

  296. jonas’

    I’ll put my "yes, use XEP-0367 right now" under it

  297. Ge0rG

    jonas’: don't say that lightly. Should the Reaction be a payload of the message or of the <attach-to> element?

  298. dwd

    OK, let's move on.

  299. jonas’

    Ge0rG, message, obviously.

  300. dwd

    Really - we're 5 minutes over already.

  301. Ge0rG

    jonas’: that's not semantically correct

  302. Kev

    I'm done, thank you.

  303. jonas’


  304. dwd

    6) Next Meeting

  305. jonas’

    Ge0rG, on list

  306. dwd

    I am not here next week.

  307. Ge0rG


  308. dwd

    Ge0rG, "phew" to me not being here next week?

  309. Kev

    I am also not here next week. Probably.

  310. jonas’

    +1w wfm

  311. dwd

    Down to three, so let's skip next week unless the remainder want to try?

  312. Ge0rG

    +1w wfm. I might even try to chair it, if there is no agenda.

  313. Link Mauve

    +1W wfm too.

  314. dwd

    OK, next week it is then.

  315. dwd

    7) AOB

  316. Link Mauve

    None from me.

  317. Ge0rG

    A bunch, but we are at -7m time budget already, so nvm.

  318. dwd

    Small note: I've added a new section to the agenda of "Activity Summary" just to note any Last Calls in progress, etc.

  319. peter is aware that he still needs to review and comment on https://github.com/xsf/xeps/pull/793 but $dayjob is very busy right now

  320. dwd

    It feels like these are easy to lose track of otherwise.

  321. dwd

    Comments welcome.

  322. Ge0rG

    dwd: that's great!

  323. dwd

    If there's nothing else?

  324. Link Mauve

    dwd, yup, I noticed that, it’s useful. :)

  325. jonas’

    dwd, I like it

  326. dwd

    8) Ite, Meeting Est.

  327. jonas’

    thanks, dwd

  328. dwd

    Thanks very much all, soryr for the overrun.

  329. pep.

    > Kev> I could be persuaded by adding text to the top explaining how this needs to change and that the authors intend to do so as soon as Other Problem is resolved in the community, I think. Which might be a reasonable compromise? I just read about such promise in 0060 about rsm (replacing max_items) and I laughed, (note that rsm in pubsub is now a thing). I'm really torn on this kind of things. I would pray to the legacy lord everyday for software to magically update (and get rid of Debian, RHEL, etc.) if I knew it worked.

  330. dwd

    I would, BTW, really love to have the concept of a "critical extension" in XMPP.

  331. Zash

    ASN.1 yeeaaaah

  332. jonas’

    I was about to say that ;)

  333. jonas’

    dwd, yes

  334. Kev

    You mean <new-feature><critical/></>, where not being able to process it would be something the client needed to care about.

  335. Kev

    You mean <new-feature><critical/></>, where not being able to process it would be something the client needed to care about?

  336. jonas’

    xmlns:xmpp="urn:xmpp" xmpp:critical="true"

  337. Kev

    (not that format, but that intent)

  338. Zash

    `<{disco#info}feature var="so-shiny" critical="1"/>`

  339. dwd

    Kev, Something like that, yes. That way, a client receiving a reaction would know it was missing something.

  340. dwd

    Kev, I mean, obviously this requires support for critical extensions and so doesn't solve this problem this time. But it might mean that future problems weren't so bad.

  341. jonas’

    I’m all for it

  342. jonas’

    works the other way around, too

  343. dwd

    jonas’, The other way around?

  344. Zash

    A client receiving a stanza and not understanding any of the payloads would be a hint already tho?

  345. jonas’

    dwd, clients to servers

  346. jonas’

    thinking of RSM

  347. Zash

    A 'critical' property seems like a thing that should have been in from the start for it to work

  348. dwd

    Zash, Yes, but that might be fine - in the absence of critical content it can just ignore the stanza entirely.

  349. dwd

    jonas’, Yes, true.

  350. jonas’

    Zash, yeah, but late is better than never, I guess

  351. Zash

    jonas’: "never" is what you get thanks to Pidgin :)

  352. dwd

    Zash, As I said earlier, I really don't want to predicate everything we do on whether Pidgin will work with it.

  353. Kev

    I think we have roughly two choices these days 1) Cater to the lowest possible common denominator, and not accept things that won't work for them 2) Be able to do things that can compete with a new system.

  354. Kev

    It's that simple. If we're not willing to (1), it means we have to start again if we want something better. e.g. Matrix.

  355. Kev

    It's that simple. If we're only willing to (1), it means we have to start again if we want something better. e.g. Matrix.

  356. jonas’

    Kev, I think it’s not that black&white

  357. dwd

    Right, I agree. Obviously in practise we try to provide graceful degradation where there's no harm to the network.

  358. jonas’

    I still don’t think that the legacy body would be harm to the network.

  359. dwd

    jonas’, MUC history?

  360. jonas’

    dwd, <store/> hint?

  361. jonas’

    isn’t that obeyed by MUC history?

  362. Zash

    Is it?

  363. dwd

    jonas’, I don't know, is it?

  364. dwd

    jonas’, It isn't on MUC implementations I've worked on.

  365. jonas’

    dwd, I’d also argue that MUC history is not *that* important anymore nowadays and I can live with breaking it, given MAM.

  366. dwd

    jonas’, So you're OK with breaking legacy clients as long as we don't break legacy clients?

  367. jonas’

    MUC history is a tricky one I admit

  368. jonas’

    but still, at least you can, with a legacy client, see that something was happening (and is happening)

  369. Kev

    Yes. I can see that 200 messages of "I am reacting to this message with a heart. Yes, a heart!" is going to be useful to the legacy client.

  370. flow

    we have MUCs with 200 participants?

  371. Zash

    Can't be worse than message correction

  372. jonas’

    flow, in fact, yes ;)

  373. jonas’

    400 even

  374. jonas’

    oh, not anymore

  375. Zash

    Matrix bridge died?

  376. jonas’

    no, disroot@ lost 200 users

  377. Zash

    I took a peek, everyone was duplicated with [m] suffixes. So, assuming Matrix bridge.

  378. jonas’

    ah, I see

  379. flow

    I feel like the fallback body discussion is a prime example of what could be improved in xmpp land: We do not take the time to get implementation experience and some people appear to really believe that implementations will not put a fallback body, even if it turns out to be beneficial

  380. Link Mauve

    Kev, this critical feature sounds like a broadened version of what I had in mind for XEP-0380.

  381. flow

    "will not put a fallback body in even the XEP requires so" that is

  382. jonas’

    flow, how will you figure out that it’s beneficial when the folks who suffer from it’s absence don’t even notice for quite a while?

  383. Link Mauve

    I approve.

  384. jonas’

    Link Mauve, neat

  385. jonas’

    now we just need to agree on using prefixed attributes for that ;)

  386. jonas’

    because you can stick those literally anywhere

  387. Link Mauve

    Prefixes make everything better!

  388. jonas’ has left

  389. xmpp:jonas’ has left

  390. flow

    jonas’, I haven't even a clear picture how muc-attaching-reactions-mam actually are going play together. It is way to early to tell anythingn

  391. Kev

    I think what we discussed at the Summit would be a good start.

  392. flow

    sometimes it is tremendous helpful to write down a few stanza exchanges to see what it could look like

  393. flow

    then some things get clearer

  394. Ge0rG

    We should run a Matrix bridge on xmpp.org.

  395. Ge0rG

    dwd: just for the protocol: I've sent a 👎 emoji reaction to your last standards@ mail, but it was dropped by everybody because it doesn't contain a legacy body.

  396. Kev

    That's alright, I don't think it had any value :D

  397. Zash

    Sooooo, multipart/alternative

  398. dwd

    I was actually thinking that I spent literally years dealing with MIME Preamble because we were stuck with the legacy - unavoidably in that case.

  399. Ge0rG

    So far, the only non-debunked argument against legacy body is "it will annoy legacy client users", and I think this is an argument pro and not contra legacy body.

  400. Remko has joined

  401. Zash

    "I sent you a reaction but your client doesn't support it. Switch to modern client to get in on that sweet sweet reaction action!"

  402. Kev

    Well, it'll also annoy non-legacy users, because their MUC join context will be destroyed.

  403. Lance has left

  404. Neustradamus has joined

  405. pep.

    And now as a dev I have to implement reactions if I don't want them. Or for the fun of it, the poezio implementation was written as a plugin during the sprint, and it wouldn't make sense with a fallback body anymore :)

  406. pep.

    "So if you don't want reactions, load the plugin to ignore them, otherwise load the plugin to read them"

  407. Zash

    Can you do non-annoying graceful fallback?

  408. Ge0rG

    Kev: what's a MUC join context? Oh, you mean the limited MUC history, that mostly consists of CSNs?

  409. Kev

    Yes, that.

  410. Ge0rG

    I see how legacy reactions will be a game changer there.

  411. Ge0rG

    Zash: feel free to provide one.

  412. Ge0rG

    maybe use threads for that!

  413. Ge0rG

    just put the emoji(s) into a body with the right thread-id

  414. Zash

    ha, threads

  415. Ge0rG

    For the record, yaxim has legacy reactions for a while now, and nobody complained so far. And the Emoji are HUGE!

  416. Ge0rG

    Zash [18:49]: > ha, threads 😬

  417. Ge0rG


  418. pep. runs away from this discussion

  419. Lance has joined

  420. peter has left

  421. moparisthebest

    missed the discussion about https://github.com/xsf/xeps/pull/801 earlier, but I also proposed just not adding text about fallback too (in reply to council minutes), I guess I can put in a PR about that

  422. moparisthebest

    but as to the questions everyone had about "why could A/AAAA be trusted if SRV cannot" it's because there are a few systems that don't support SRV, so you might be getting your SRV from some place that's compromised and your A/AAAA from another that is not

  423. moparisthebest

    Tor is the highest profile one I suppose, but also plenty of broken routers etc

  424. moparisthebest

    I see no harm in falling back, I see harm in MUST NOT fall back, also adding MUST NOT to a draft spec

  425. Zash

    So another "there are broken clients, therefore we must write te

  426. Zash

    So another "there are broken clients, therefore we must write wrong specs" argument?

  427. moparisthebest

    sure, a user sees their XMPP client won't connect, but Whatsapp will, and that means XMPP sucks

  428. moparisthebest

    they don't know or care why

  429. Zash

    I'm not sure this line of reasoning is productive or good for my sanity.

  430. moparisthebest

    Zash, for another example how about a file sharing spec that just assumes everyone has a fully routable ipv6 ?

  431. moparisthebest

    sure, it'd be a simple, great spec

  432. moparisthebest

    just totally unuseable in the real world

  433. Ge0rG

    routable and not firewalled.

  434. moparisthebest

    so there is always an element of this

  435. Ge0rG

    moparisthebest: you are going down a slippery slope, very fast.

  436. Ge0rG

    what if there are xmpp clients not supporting MAM?

  437. Ge0rG

    you can't cover them all.

  438. dwd

    moparisthebest, I'm confused. In the case where no SRV records resolve, we fall back to A/AAAA. In the case where at least one SRV resolves to '.', we do not. What's the problem?

  439. moparisthebest

    dwd, if one SRV resolves to . you can either try to fallback to A/AAAA or give up, I see no harm in trying

  440. dwd

    moparisthebest, What's the point in '.' then?

  441. moparisthebest

    nothing probably, at least not with TLS

  442. Zash

    Isn't the question whether _xmpps IN SRV . means "there's no XMPP here" or "there's no xmpp-over-tls here"

  443. Ge0rG

    Do, or do not. There is no try.

  444. moparisthebest

    when nothing is authenticated I guess it's just as good to trust that vs trying to connect

  445. dwd

    Zash, Nope. That's not the question. The question is "If you get a '/' back from one SRV but nothing from the other, do you use a A/AAAA fallback or not?"

  446. dwd

    Zash, Nope. That's not the question. The question is "If you get a '.' back from one SRV but nothing from the other, do you use a A/AAAA fallback or not?"

  447. Ge0rG

    Can we have a flow chart please?

  448. moparisthebest

    I think with TLS you should always do a fallback, if it succeeds and authenticates, great, if not, oh well, at least you did everything you could

  449. Remko has left

  450. flow

    dwd, why would you fall back in that case without trying to use the one that was not a '."?

  451. flow

    or what does fallback here exactly mean? fallback using implicit TLS? fallback using implicit TLS first and then STARTTLS?

  452. flow

    but I think an answer to Zash's question would be helpful in the discussion, and I think the right answer probably is "there is no XMPP with implict TLS here"

  453. dwd

    flow, You'd do both lookups for SRV, sure. But if you get a dot-response from one and nothing from the other, what then?

  454. Zash

    _xmpps doesn't have any default port defined, so you stop that thread? _xmpp has, so you go for 5222

  455. Zash

    Or if you wanna go and try random IP and port numbers, glhf

  456. Kev

    I can see an argument that it's reasonable to ignore xmpps stuff completely unless it gives you something connectable, and just go 6120 rules, but ... yeah.

  457. Remko has joined

  458. moparisthebest

    yea I think you try 5222, and if that doesn't work

  459. moparisthebest

    maybe implicit on 5223 and/or 443, whatever

  460. moparisthebest

    poke all the ports on the internet until one responds with a proper TLS cert? :D

  461. Zash


  462. Remko has left

  463. moparisthebest

    > ZMap can comprehensively scan for a single TCP port across the entire public IPv4 address space in 4.5 minutes given adequate upstream bandwidth.

  464. moparisthebest

    XEP-0368 implementations MUST use this ZMap to scan all 443s as a fallback

  465. Zash

    > given adequate upstream bandwidth. Can't wait for 5G then

  466. flow

    dwd, ahh "nothing from the other" I ready "not from the other"

  467. flow


  468. flow

    yeah, then I'd probably do a A/AAAA fallback

  469. dwd

    flow, Even though you know the domain supports SRV?

  470. dwd

    I'm actually wondering whether, if you have any _xmpps-* record, including a dot-record, you MUST have a _xmpp-* record, and behaviour is undefined otherwise.

  471. moparisthebest

    *you know something sent you a SRV response, unless we are talking about DNSSEC here

  472. Kev

    I've started leaning towards that.

  473. dwd

    Because I can't image what the administrator intended.

  474. dwd

    moparisthebest, Yes, yes, blah blah.

  475. Kev


  476. flow

    dwd, yes, cause _xmpps → "." should probably mean that there is no XMPP with implicit TLS, not that there is no XMPP at all

  477. Link Mauve has left

  478. Kev

    dwd: You could also argue that xmpps_ . with no xmpp_ is a clear misconfiguration, so trying to fallback in the normal way is the best you can do in the face of a daft admin.

  479. Kev

    But, really, the more I think about this, the more I think it's not daft.

  480. Kev

    6120 defines fallback if you don't have SRV. That means you don't have to do SRV, because you know the clients will just A/AAAA 5222, and if that's the right way to connect, that's fine.

  481. Ge0rG

    But that would only hide the misconfiguration from people's eyes, leading to the creation of something that's as messy as the web.

  482. Kev

    So saying "Yep, do the normal 6120 A/AAAA thing, but I don't support xmpps" starts seeming a lot less daft.

  483. Kev

    I know I've deployed services and not bothered with SRV because it's just not needed when A works.

  484. flow

    I see no requiremnt in RFC 2782 that once you add a SRV RR for one service, you have to add them for all provided services

  485. Ge0rG

    Kev: also the 10% of clients that technically can't resolve SRV

  486. Kev

    Ge0rG: Well, they're not affected by this argument, I think, because they won't see the . on xmpps.

  487. flow

    But even if there where I would write my clients so that they try to discover as many as possible connection mechanisms and use them

  488. flow

    with an extra pranoid setting ignoring SRV "." results if it hasn't been authenticated via DNSSEC probably

  489. Ge0rG

    But the benefit of xmpps is reduced number of RTTs, if you don't count the DNS RTTs

  490. Ge0rG

    Kev: I was just saying that you essentially must provide A/AAAA anyway

  491. Kev

    I think that's only true if you're running a public service with broken clients.

  492. Kev

    I think that's only true if you're running a public service and care about broken clients/networks connecting.

  493. dwd

    flow, I don't *think* a spoofed '.' record is any worse than any other spoofed record.

  494. Kev

    Most services I care about are not public.

  495. Kev

    Or have experience with, I should probably say.

  496. Ge0rG

    Kev: if you don't care about broken client networks, you surely don't need to care about daft admins

  497. Kev

    I'm starting to argue that it's /not/ daft.

  498. Kev

    And "Do normal A stuff for xmpp, and I don't support xmpps" is actually a reasonable thing to say.

  499. flow

    good point

  500. Ge0rG

    Kev: what's wrong with putting the normal A stuff into _xmpp SRV?

  501. Kev

    Why configure more records than you need?

  502. Ge0rG

    Because a client will query them either way

  503. Ge0rG

    Unless you define xmpps=. as "skip _xmpp lookup as well", which I really don't see happening

  504. Kev

    It doesn't really matter as long as clients don't do xmpps fallback, I guess, and that would be horrible anyway.

  505. Kev

    So yes, the right response to 'why configure more records than you need?' is 'yes, why bother with xmpps=.?'.

  506. Ge0rG

    In a sensible world, I'd prefer _xmpps over _xmpp because it'll cut off multiple RTTs

  507. Kev

    Only one, isn't it?

  508. flow

    there are more reasons for implicit TLS

  509. Kev

    > <starttls/> < <proceed/>

  510. Kev

    There's nothing implicit about TLS on an xmpps_ record is there?

  511. flow

    for example it is harder for buggy implementations to leak sensible data in plaintext with implicit TLS compared to STARTTLS

  512. flow

    Kev, depends on your definition on what the implicit part is

  513. flow

    I think I am using the one of RFC 8314 § 3.

  514. jonas’ has left

  515. jonas’ has joined

  516. Ge0rG

    Can't we just agree on "direct TLS"?

  517. flow

    Ge0rG, that is what I've been using before discovering that RFC and its definition

  518. Ge0rG

    flow: an RFC containing an inadequate solution doesn't make it adequate

  519. flow

    what would that inadequate solution be you are talkinga bout?

  520. flow

    the term "Implicit TLS"?

  521. Ge0rG


  522. Ge0rG

    With MTA-STS (which is a horrible abomination of a standard on its own), direct TLS also becomes explicit for email submission

  523. Ge0rG

    If we follow their nomenclature, it's explicit implicit TLS

  524. flow

    well I wasn't happy with "Direct TLS" either, so I decided to use the term that is at least established by an RFC

  525. Ge0rG

    What's wrong with Direct TLS?

  526. flow

    what's direct about it?

  527. Link Mauve has joined

  528. Ge0rG

    You start the connection directly with a TLS handshake

  529. Ge0rG

    I can't imagine a better term.

  530. flow

    hmm, kay, if you look at it from that way

  531. flow

    for me its just that I like well defined (and ideally established) terms

  532. flow

    IIRC I greped the RFCs for "Direct TLS" but could not find any occurance

  533. flow

    but maybe my grep-fu wasn't strong at that day

  534. flow

    so I probably concluded that it isn't a good term, and was pretty happy when I found rfc8314

  535. Ge0rG

    In 8314 the term makes _some_ sense, because there is no explicit signaling for when to use Direct TLS.

  536. Ge0rG

    So it's actually implicit, because you don't know you must use it... 😉

  537. flow

    I always assumed that it is about starting TLS either explicitly via STARTTLS or implictly on the establishment of the underlying transport mechanism (e.g. TCP)

  538. flow

    if you take signaling into consideration, then yes, _xmpps is not implicit

  539. Ge0rG

    Yes, but STARTTLS is always indirect.

  540. flow

    even if quickstart is used?

  541. flow

    and now I go to bed

  542. moparisthebest has left

  543. pep.

    > flow> yes, cause _xmpps → "." should probably mean that there is no XMPP with implicit TLS, not that there is no XMPP at all Then I'd fallback on _xmpp- first, then A/AAAA if this one is not '.' as well

  544. pep.

    > Ge0rG> also the 10% of clients that technically can't resolve SRV Some clients also can't resolve A/AAAA :)

  545. pep.

    As in, directly, without SRV, from what I understand

  546. Ge0rG

    pep.: you mean they are deliberately crippled and violate the rfc?

  547. dwd

    pep., You shouldn't actually be "falling back" to _xmpp-*, you should be doing both lookups in parallel and combining the results, I think.

  548. pep.

    dwd: k

  549. pep.

    Ge0rG: dunno, I think kaidan on android has some issues with that. I couldn't connect on my server

  550. Ge0rG

    pep.: that sounds like a serious bug

  551. pep.

    I'm not the only one to have reported it

  552. Ge0rG

    But then again, it's Kaidan... 🤷‍♂️

  553. Ge0rG

    dwd: happy eyeballs style?

  554. Ge0rG

    dwd: also do A/AAAA in parallel, and recursively follow CNAMEs

  555. pep.

    You'd probably do only.one CNAME query anyway

  556. pep.

    You'd probably do only one CNAME query anyway

  557. Zash

    CNAME processing would be in scope for whatever DNS stuff you have, not the XMPP stuff.

  558. dwd

    Ge0rG, Well, I'm explicitly doing the 2 SRVs in parallel and then ... I can't recall if I do happy eyeballs with the resulting picked A/AAAA, I might do. I look them both up in parallel, don't remember if I try connecting to them all at once.

  559. Zash

    dwd: do you have a thing that does _xmpps-server?

  560. dwd

    Zash, Yes, though not in production right now.

  561. Lance has left

  562. moparisthebest has joined

  563. debacle has joined

  564. peter has joined

  565. peter has left