XSF logo 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’ https://github.com/xsf/xeps/pull/801
  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 Congratulations.
  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’ why?
  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 Ack.
  90. dwd jonas’, Acks.
  91. dwd 3) Activity Summary
  92. dwd Noting:
  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’ why?
  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’ thanks
  304. dwd 6) Next Meeting
  305. jonas’ Ge0rG, on list
  306. dwd I am not here next week.
  307. Ge0rG phew.
  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.
  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 https://upload.yax.im/upload/fCLNTXQr0YhbBor3/Screenshot_20190731-185205_yaxim.jpg
  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 ALL THE PORTS
  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 *read
  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 Idd.
  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 Yes
  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