XSF Discussion - 2021-04-14

  1. adiaholic has left
  2. eevvoor has left
  3. adiaholic has joined
  4. derwin has left
  5. derwin has joined
  6. adiaholic has left
  7. lorddavidiii has joined
  8. alexbay218 has joined
  9. paul has left
  10. Aleksej has left
  11. debacle has left
  12. mukt2 has left
  13. chronosx88 has left
  14. lskdjf has left
  15. chronosx88 has joined
  16. Vaulor has left
  17. adiaholic has joined
  18. arc has left
  19. arc has joined
  20. adiaholic has left
  21. mukt2 has joined
  22. sebastian has left
  23. sebastian has joined
  24. arc has left
  25. arc has joined
  26. neshtaxmpp has left
  27. Vaulor has joined
  28. neshtaxmpp has joined
  29. stp has left
  30. adiaholic has joined
  31. Calvin has left
  32. mukt2 has left
  33. millesimus has left
  34. arc has left
  35. arc has joined
  36. arc has left
  37. arc has joined
  38. arc has left
  39. arc has joined
  40. arc has left
  41. arc has joined
  42. arc has left
  43. arc has joined
  44. millesimus has joined
  45. alameyo has left
  46. mukt2 has joined
  47. adiaholic has left
  48. adiaholic has joined
  49. Seve has joined
  50. alacer has left
  51. Syndace has left
  52. Syndace has joined
  53. govanify has left
  54. govanify has joined
  55. lorddavidiii has left
  56. lorddavidiii has joined
  57. arc has left
  58. floretta has left
  59. stp has joined
  60. floretta has joined
  61. govanify has left
  62. govanify has joined
  63. alacer has joined
  64. stp has left
  65. chronosx88 has left
  66. chronosx88 has joined
  67. eric has left
  68. eric has joined
  69. mukt2 has left
  70. dos1 has left
  71. rdelaage has left
  72. superkuh has left
  73. antoine has left
  74. moparisthebest has left
  75. moparisthebest has joined
  76. moparisthebest has left
  77. moparisthebest has joined
  78. adiaholic has left
  79. adiaholic has joined
  80. mukt2 has joined
  81. adiaholic has left
  82. moparisthebest has left
  83. Yagiza has joined
  84. moparisthebest has joined
  85. adiaholic has joined
  86. moparisthebest has left
  87. adiaholic has left
  88. adiaholic has joined
  89. moparisthebest has joined
  90. moparisthebest has left
  91. moparisthebest has joined
  92. sebastian has left
  93. Neustradamus has joined
  94. moparisthebest has left
  95. Vaulor has left
  96. chronosx88 has left
  97. chronosx88 has joined
  98. moparisthebest has joined
  99. moparisthebest has left
  100. moparisthebest has joined
  101. Neustradamus has left
  102. Neustradamus has joined
  103. Seve has left
  104. moparisthebest has left
  105. menel has joined
  106. moparisthebest has joined
  107. sebastian has joined
  108. adiaholic has left
  109. adiaholic has joined
  110. moparisthebest has left
  111. moparisthebest has joined
  112. moparisthebest has left
  113. moparisthebest has joined
  114. adiaholic has left
  115. adiaholic has joined
  116. Syndace has left
  117. Syndace has joined
  118. jjrh has left
  119. jjrh has joined
  120. adiaholic has left
  121. andy has joined
  122. mukt2 has left
  123. sebastian has left
  124. adiaholic has joined
  125. sebastian has joined
  126. APach has left
  127. APach has joined
  128. adiaholic has left
  129. adiaholic has joined
  130. adiaholic has left
  131. paul has joined
  132. adiaholic has joined
  133. karoshi has joined
  134. Tobias has joined
  135. mukt2 has joined
  136. steffen has joined
  137. emus has joined
  138. moparisthebest has left
  139. moparisthebest has joined
  140. moparisthebest has left
  141. adiaholic has left
  142. adiaholic has joined
  143. moparisthebest has joined
  144. moparisthebest has left
  145. moparisthebest has joined
  146. moparisthebest has left
  147. moparisthebest has joined
  148. moparisthebest has left
  149. adiaholic has left
  150. moparisthebest has joined
  151. moparisthebest has left
  152. moparisthebest has joined
  153. moparisthebest has left
  154. adiaholic has joined
  155. moparisthebest has joined
  156. moparisthebest has left
  157. moparisthebest has joined
  158. adiaholic has left
  159. adiaholic has joined
  160. chronosx88 has left
  161. chronosx88 has joined
  162. mukt2 has left
  163. Andrzej has joined
  164. mukt2 has joined
  165. wurstsalat has left
  166. mathijs has left
  167. mathijs has joined
  168. Andrzej has left
  169. sebastian has left
  170. menel has left
  171. croax has joined
  172. Guus has joined
  173. raghavgururajan has left
  174. raghavgururajan has joined
  175. ti_gj06 has joined
  176. sebastian has joined
  177. wladmis has left
  178. wladmis has joined
  179. Syndace has left
  180. Syndace has joined
  181. mukt2 has left
  182. moparisthebest when confronted with a too-big stanza as a server, what would the implications be if the server just silently dropped the stanza and carried on instead of terminating the stream with an error ?
  183. moparisthebest maybe this answer is different for s2s vs c2s
  184. jonas’ moparisthebest, if it can do that, it should instead bounce the stanza properly
  185. jonas’ then there are no (new) implications, beyond what you already get when servers make decisions about which stanzas to deliver
  186. moparisthebest what if it can drop it, but can't parse it
  187. jonas’ unlikely, I think
  188. jonas’ to bounce a stanza, you only need the startElement SAX event
  189. jonas’ (or equivalent)
  190. jonas’ I think you already need that + endElement + magic to determine the stanza boundaries anyway
  191. BASSGOD has left
  192. mukt2 has joined
  193. jonas’ I guess dropping would be similar to s2s-closing (without stream management), so there’s not much of a difference there, except that deliverability of other stanzas will be improved (as they don’t get lost in s2s TCP buffers when the stream is killed)
  194. Andrzej has joined
  195. moparisthebest I'm determining stanza boundaries by counting tags and don't have an XML parser
  196. jonas’ how are you counting tags?
  197. jonas’ (to count tags, you already need something like an XML parser ;))
  198. Guus has left
  199. jonas’ enough of an XML parser to add only a shim layer to extract the attributes out of the tags anyway
  200. jonas’ enough of an XML parser to add only a shim layer to extract the attributes out of the attributes needed for bouncing anyway
  201. moparisthebest roughly, incrementing on < and decrementing on /> or </ so a stanza boundary is when the counter hits 0
  202. jonas’ <![CDATA[ < ]]>?
  203. moparisthebest hopefully no one sends that :D seems to have worked so far
  204. jonas’ it is valid though
  205. jonas’ and: what stops you from catching the slice from the first < to the first > and parsing that as attributes? you can drop all namespace-related stuff as that’s not needed on stanzas anyway, just plain key/value
  206. moparisthebest hrm maybe, so you think that'd be valid? sending an error response on too-big-stanzas and just skipping them otherwise? but not terminating the stream?
  207. jonas’ yes
  208. jonas’ <policy-violation/> would be an appropriate stanza error I think
  209. jonas’ or maybe <resource-constraint/>
  210. yushyin has left
  211. marek has left
  212. BASSGOD has joined
  213. jonas’ https://tools.ietf.org/html/rfc6120#section-
  214. jonas’ look at that, policy-violation has stanza size limit as an example
  215. jonas’ oh, that’s the stream error, sorry
  216. yushyin has joined
  217. moparisthebest antranigv in this MUC has an avatar that makes a stanza bigger than 262,144 bytes for instance
  218. jonas’ but I think the stanza error is as valid
  219. jonas’ and bouncing individual stanzas with whatever errors you feel like is the right of a server; clients need to cope with that
  220. marek has joined
  221. jonas’ dropping on the other hand is tricky because it may be seen as violation of the "MUST reply to IQ requests" clause of RFC 6120
  222. flow > moparisthebest> antranigv in this MUC has an avatar that makes a stanza bigger than 262,144 bytes for instance One of the reasons that make me believe that servers should be very conservative about the sizes of stanzas they accept. Someting in the range of 10 KiB to 64 KiB seems appropriate
  223. flow I also think that with larger stanza sizes you get easily into scheduling issues, as in, a single stanza can dominate the link while it is transferred
  224. flow This is turn means, that you should probably bounce to big stanzas at the first hop, and close the stream on all following hops as soon as the limit is reached
  225. flow This is turn means, that you should probably bounce too big stanzas at the first hop, and close the stream on all following hops as soon as the limit is reached
  226. jonas’ good point about hogging the link
  227. flow Unfortunately, I believe that the major parts of the ecosystem would break if we do that
  228. flow But I really hope that we get the ecosystem towards a reasonable sized stanza limit in the future
  229. flow Of course, this requires, things like RSM on disco#(info|item) responses
  230. flow Of course, this requires things like RSM on disco#(info|item) responses
  231. jonas’ servers already do that :(
  232. dwd I wonder if MAM-like responses on disco might make more sense. Or additional sense.
  233. jonas’ ;)
  234. millesimus has left
  235. flow Furthermore, if we talk about techniques that split large content into multiple stanzas, then we have to be aware that it's not easy for the generating entity to assess the resulting stanza size
  236. jonas’ just found this https://github.com/horazont/muchopper/commit/7affc581a8539eebc190371d95539bed1fb8bd7c#diff-6d5dca6e6e9b9db00d48d0bb6b748f7302f6b941e4bcee48427a54ff74122c46R48
  237. jonas’ just found this https://github.com/horazont/muchopper/commit/7affc581a8539eebc190371d95539bed1fb8bd7c#diff-6d5dca6e6e9b9db00d48d0bb6b748f7302f6b941e4bcee48427a54ff74122c46R53-R59
  238. flow But probably a pramgatic approach like, "aim for 10KiB stanzas, but limit at 32KiB" is good enough here
  239. flow jonas’, is https://github.com/horazont/muchopper/commit/7affc581a8539eebc190371d95539bed1fb8bd7c#diff-6d5dca6e6e9b9db00d48d0bb6b748f7302f6b941e4bcee48427a54ff74122c46R53 fixed today?
  240. jonas’ I did not check again since that commit
  241. millesimus has joined
  242. moparisthebest it's ok I'm 99% sure I found an ejabberd bug while looking at this too, are `<features xmlns="http://etherx.jabber.org/streams"><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls></features>` and `<stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls></stream:features>` the same or not?
  243. mukt2 has left
  244. moparisthebest prosody, dino, gajim, and conversations are ok with either, ejabberd requires the second
  245. jonas’ they are the same in XML 1.0 with Namespaces
  246. jonas’ but yeah, ejabberd is picky
  247. moparisthebest odd failure mode too, it just hangs for 90 seconds and then sends `<stream:error><connection-timeout xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>Idle connection</text></stream:error>` and hangs up
  248. jonas’ yep, probably the parser doesn’t read it as belonging to the stream namespace and then drops it
  249. jonas’ moparisthebest, but note the interop note in https://tools.ietf.org/html/rfc6120#section-4.8.5
  250. alexbay218 has left
  251. jonas’ > Implementations are advised that using a prefix other than 'stream' for the stream namespace might result in interoperability problems.
  252. moparisthebest ah, nice
  253. flow moparisthebest, sounds like you have a new(?) project, what is it? :)
  254. Aleksej has joined
  255. floretta has left
  256. moparisthebest flow, reverse proxy https://github.com/moparisthebest/xmpp-proxy still super early, just started dogfooding it on my server recently :)
  257. BASSGOD has left
  258. mathijs has left
  259. mathijs has joined
  260. adiaholic has left
  261. mukt2 has joined
  262. adiaholic has joined
  263. menel has joined
  264. BASSGOD has joined
  265. adiaholic has left
  266. peetah has left
  267. peetah has joined
  268. adiaholic has joined
  269. Seve has joined
  270. Vaulor has joined
  271. flow moparisthebest, so you are competing with dwd now? :)
  272. dwd Competition always welcome.
  273. dwd Especially as I've not had any time for Metre recently.
  274. jonas’ I think metre doesn’t do c2s, does it?
  275. dwd It does not, no.
  276. dwd Going to go out on a limb and suggest that xmpp-proxy doesn't do S2S, it's just a connection proxy, too.
  277. eevvoor has joined
  278. moparisthebest https://github.com/surevine/Metre ? quite a bit different I guess
  279. mukt2 has left
  280. debacle has joined
  281. moparisthebest xmpp-proxy does c2s and s2s, and multiplexes both along with starttls + direct tls all on the same port(s), but also limits stanza sizes
  282. dwd But inbound only if I follow this right?
  283. moparisthebest correct, inbound only, and provides TLS
  284. dwd And that StanzaFilter looks scary. :-)
  285. Kev How does it cope with presenting the client cert to the server?
  286. Andrzej has left
  287. Kev Or is there a ‘I have verified trust, just do external’ flag being passed to the server-proper somehow?
  288. Andrzej has joined
  289. dwd Kev, Yeah, doesn't seem to be any support for that.
  290. Kev Probably more applicable to C2S where client certs are uncommon than to S2S then, I guess?
  291. moparisthebest no support for client cert auth, server just trusts connections from it is encrypted implicitly (also for the PROXY header)
  292. Kev Although I guess it probably gets in the way of -PLUS too?
  293. dwd It'd break channel bindings, yes. Also I think the start-tls handling makes me cry.
  294. papatutuwawa has joined
  295. moparisthebest yes I agree the StanzaFilter is scary haha
  296. moparisthebest these are all correct reactions I think
  297. Kev I keep getting tempted to write one of these for M-Link, but I keep deciding it needs to be more than a naive proxy because of the interactions between TLS and auth.
  298. Kev (Also because I’d like to use it as a mechanism for seamless upgrades).
  299. moparisthebest (personal opinion for my use-cases only incoming) interactions between TLS and auth are dead, let them lie
  300. dwd Funnily enough, I thought about adapting the Metre code into an Openfire C2S connection manager.
  301. dwd moparisthebest, I think that's not true given channel bindings especially.
  302. moparisthebest do they work with TLS 1.3 yet ?
  303. Kev moparisthebest: You might not like channel binding, but surely you’re not opposed to S2S strong auth?
  304. dwd moparisthebest, Thanks to Sam, yes.
  305. moparisthebest will they work with QUIC
  306. dwd moparisthebest, Your xmpp-proxy doesn't work with QUIC, so somewhat irrelevant, but I think they should given they're simply based on an exported key.
  307. menel has left
  308. superkuh has joined
  309. antoine has joined
  310. dos1 has joined
  311. mukt2 has joined
  312. rdelaage has joined
  313. moparisthebest unfortunately if the web doesn't use them, we can't rely on them being supported anywhere
  314. dwd moparisthebest, Except key exports *are* used and seem well supported, so Sam's approach seems much more likely to be generally available.
  315. floretta has joined
  316. moparisthebest and QUIC is the future so I wouldn't call it irrelevant, still a hair early though, we'll see
  317. dwd moparisthebest, Sure. I expect we'll have XMPP over QUIC at some point. But I don't think key exporting is affected by QUIC versus TLS/TCP, so everything should "just work".
  318. dwd moparisthebest, Obviously there's very much a place for xmpp-proxy as a bridge to uplift existing servers and services with QUIC etc support though.
  319. millesimus has left
  320. millesimus has joined
  321. jonas’ moparisthebest, so that effectively forces use of dialback? or what?
  322. dwd moparisthebest, I think your StanzaFilter works for idiomatic XMPP XML, but I'm not entirely sure it'll work correctly in some edge cases. I suspect if I'm sufficiently abusive I can at least sneak a closing stream tag past it.
  323. jonas’ I’ll just say CDATA
  324. dwd jonas’, Oh, yeah, good point, that too.
  325. Andrzej has left
  326. moparisthebest also '< stream:stream' and a few other things, probably ok, it accomplishes it's goal
  327. Andrzej has joined
  328. dwd moparisthebest, And '<str:stream', and all sorts. Likely it'll work in all non-abusive cases. But yeah, I can get it to terminate the session without the XMPP server thinking its over, and I can get the XMPP server to close it without xmpp-proxy to work. And any server advertising -PLUS basically won't allow auth. Hopefully. But as I say, it'll mostly work and it's a useful tool for a number of cases.
  329. wurstsalat has joined
  330. Kev dwd: The server needs to know there’s a TLS terminator in the way anyway, so presumably should not present any auth mechs that don’t proxy in any case.
  331. moparisthebest yep I agree, it was written in a bit of a hurry for one specific use-case which it accomplishes, I'll elaborate more later, and in the meanwhile think about if it can support CDATA sanely without bringing in an XML parser :/
  332. emus has left
  333. Kev I would be inclined to bring in an XML parser, personally.
  334. alameyo has joined
  335. Kev Well, let me rephrase that.
  336. Kev If I wanted this to be generally useful, I would bring in an XML parser.
  337. dwd Kev, Oh, I think it *is* generally useful, but possibly limited to testing out deployment strategies you'd then incorporate into server mainline code.
  338. Kev If it just needs to meet a use case and it meets it, *shrug*.
  339. moparisthebest I only hesitate because historically XML parsers have been known to have worse bugs than "closes connection wrongly sometimes"
  340. Kev That is not unfair.
  341. emus has joined
  342. dwd moparisthebest, This is true, but I can smell the faint odour of a DoS attack there somewhere.
  343. bean has joined
  344. moparisthebest I think yes, but only in terms of killing s2s connections ?
  345. Kev Killing S2S is probably less bad than *not* killing S2S
  346. Kev (I have no idea if such an issue can present)
  347. adiaholic has left
  348. adiaholic has joined
  349. lskdjf has joined
  350. LNJ has joined
  351. mukt2 has left
  352. adiaholic has left
  353. Syndace has left
  354. Syndace has joined
  355. adiaholic has joined
  356. flow moparisthebest, jxmpp has a XmlSplitter, which probably does something similar to yours. It doess not contain a full blown XML parser, but is a little bit more robust as yoursI think
  357. mukt2 has joined
  358. flow I guess what I am trying to say is, that there exists probably a middle ground between having a full blown XML parser and too trivial parsing for things like that
  359. menel has joined
  360. moparisthebest flow, thanks, I'll have a look https://github.com/igniterealtime/jxmpp/blob/master/jxmpp-core/src/main/java/org/jxmpp/xml/splitter/XmlSplitter.java
  361. paul has left
  362. paul has joined
  363. BASSGOD has left
  364. BASSGOD has joined
  365. pasdesushi has joined
  366. govanify has left
  367. govanify has joined
  368. pasdesushi has left
  369. ralphm has joined
  370. mathieui So… it has come to my attention that profanity is essentially using 140-chars ids for every stanza
  371. mathieui was there any rationale for not limiting the length of the id attributes? we do cap the size of JID, afair
  372. flow mathieui, sadly the length restriction of JID parts is the
  373. flow exeception, not the rule
  374. flow we do not limit pubsub IDs either
  375. BASSGOD has left
  376. BASSGOD has joined
  377. mathieui indeed :/
  378. mathieui but as far as I understand it, the only properties we want for identifiers is "we can fit something non-guessabled and non-bruteforceable in it, and all the better if we can write some arbitrary data for testing"
  379. mathieui but going over 30 or 50 characters seems overkill in every case
  380. menel has left
  381. jonas’ https://modules.prosody.im/mod_client_proxy.html would like to have a word with you ;)
  382. derwin has left
  383. flow mathieui, yes, I think you are mixing two aspects here: the missing length restriction for many ID things in XMPP *and* the question what a sufficiently long ID is
  384. Aleksej has left
  385. flow that said, 140 chars is way to long
  386. mathieui flow: true, but one could influence the other
  387. flow not really
  388. flow just because a random ID can be shorter, there may be very well use cases for long IDs which carry some semantics
  389. flow arguably, this may not be likely for stanza IDs, but very true for e.g. pubsub IDs
  390. flow and I am not sure if it isn't true in some case for stanza IDs
  391. flow in any way, we should point the profanity guys to https://www.grc.com/haystack.htm
  392. mdosch has left
  393. mdosch has joined
  394. millesimus has left
  395. floretta has left
  396. Andrzej has left
  397. mukt2 has left
  398. hamish has left
  399. Steve Kille has left
  400. dwd Every now and then, I wonder about translation to a UUID in all cases. Mostly for the database efficiency.
  401. edhelas dwd +1
  402. Steve Kille has joined
  403. mukt2 has joined
  404. Zash 36 octets for 122(?) bits of entropy feels inefficient, plus they don't help with sort order
  405. millesimus has joined
  406. dwd Yes, you need both a sequential id and a uuid in the database. But cheap to lookup a 128 bit number in an index.
  407. larma Also UUIDs can be compressed on wire if octet optimization is what you aim for
  408. hamish has joined
  409. jonas’ something about https://github.com/ulid/spec
  410. dwd I mean, if we wer etalking XMPP 2.0, I'd be saying stanza ids are alwasys UUIDv4 and any duplications detected cause immediate session termination.
  411. Kev Of course, even a 128bit integer in string form is less than 140 characters :D
  412. adiaholic has left
  413. Zash Profanity with their signed IDs?
  414. mathieui the worst part of the profanity thing is that the id is a base64 of some form of humongous uuid in string form
  415. mathieui so it’s like thrice the size for no entropy gain
  416. Zash Uuid + hmac(key, uuid) IIRC
  417. mathieui but why
  418. dwd So you can detect forged responses and bounces, I imagine.
  419. Ge0rG Except nobody does it.
  420. Ge0rG I've looked into that source code before. But then I erased my memories with alcohol.
  421. adiaholic has joined
  422. dwd But it seems to me that the most interesting attacks based around forging responses would be based around witnessing an existing outbound and just copying the ID, which isn't affected by whether or not the id is signed.
  423. Ge0rG Yeah.
  424. Ge0rG IIRC I did a benchmark of "who does the longest message IDs" on my server, and #1 was bifrost, which stuck whole XMPP messages into the ID, for reasons nobody can anticipate, and #2 was profanity
  425. mukt2 has left
  426. menel has joined
  427. floretta has joined
  428. jonas’ what
  429. goffi has joined
  430. edhelas time to to XMPP stanza over XMPP messages ids
  431. edhelas *do
  432. stp has joined
  433. dwd Years ago, a security audit on some stuff I did decided the id space was a side-channel attack. (As were arbitrary XML attributes etc).
  434. dwd I mean, it's fair enough, but in cases where that matters you need a protocol break anyway.
  435. adiaholic has left
  436. Wojtek has joined
  437. mukt2 has joined
  438. adiaholic has joined
  439. pasdesushi has joined
  440. pasdesushi has left
  441. pasdesushi has joined
  442. adiaholic has left
  443. pasdesushi has left
  444. adiaholic has joined
  445. Zash has left
  446. Zash has joined
  447. Zash has left
  448. Zash has joined
  449. pasdesushi has joined
  450. pasdesushi has left
  451. mukt2 has left
  452. govanify has left
  453. adiaholic has left
  454. govanify has joined
  455. mukt2 has joined
  456. adiaholic has joined
  457. pasdesushi has joined
  458. adiaholic has left
  459. pasdesushi has left
  460. pasdesushi has joined
  461. pasdesushi has left
  462. pasdesushi has joined
  463. adiaholic has joined
  464. strypey has joined
  465. strypey has left
  466. menel has left
  467. pasdesushi has left
  468. menel has joined
  469. adiaholic has left
  470. adiaholic has joined
  471. papatutuwawa has left
  472. adiaholic has left
  473. pasdesushi has joined
  474. adiaholic has joined
  475. pasdesushi has left
  476. pasdesushi has joined
  477. pasdesushi has left
  478. pasdesushi has joined
  479. pasdesushi has left
  480. pasdesushi has joined
  481. pasdesushi has left
  482. pasdesushi has joined
  483. adiaholic has left
  484. mukt2 has left
  485. pasdesushi has left
  486. floretta has left
  487. adiaholic has joined
  488. adiaholic has left
  489. chronosx88 has left
  490. chronosx88 has joined
  491. mukt2 has joined
  492. eric has left
  493. eric has joined
  494. floretta has joined
  495. pasdesushi has joined
  496. mukt2 has left
  497. mukt2 has joined
  498. pasdesushi has left
  499. jubalh has joined
  500. mdosch https://github.com/profanity-im/profanity/issues/1520
  501. mdosch > Our brilliant plan to make Profanity famous among the XMPP community was a huge success. > Profanity became a constant hit for discussions in the community. Everybody was and is talking about its huge IDs. > Now that we have achieved making people aware of Profanitys existence it's time to make them love Profanity. > So let's have shorter IDs.
  502. Zash "If you want an answer on the Internet, post the wrong answer first."
  503. pasdesushi has joined
  504. edhelas the community manager of Profanity Inc. is a genius
  505. edhelas i propose that the XSF hire him
  506. Andrzej has joined
  507. floretta has left
  508. DebXWoody #1520 \o/ We will be seen by movim :-)
  509. adiaholic has joined
  510. Andrzej has left
  511. Andrzej has joined
  512. mukt2 has left
  513. pasdesushi has left
  514. Andrzej has left
  515. Andrzej has joined
  516. ti_gj06 has left
  517. Kev Certainly the best issue I’ve read today.
  518. derwin has joined
  519. ti_gj06 has joined
  520. lovetox has left
  521. Andrzej has left
  522. pasdesushi has joined
  523. ti_gj06 has left
  524. floretta has joined
  525. ti_gj06 has joined
  526. lovetox has joined
  527. deuill has left
  528. pasdesushi has left
  529. deuill has joined
  530. deuill Another one for XMPP2
  531. mukt2 has joined
  532. pasdesushi has joined
  533. pasdesushi has left
  534. Andrzej has joined
  535. alameyo has left
  536. adiaholic has left
  537. adiaholic has joined
  538. alameyo has joined
  539. mukt2 has left
  540. mukt2 has joined
  541. adiaholic has left
  542. alameyo has left
  543. Andrzej has left
  544. mukt2 has left
  545. adiaholic has joined
  546. millesimus has left
  547. mukt2 has joined
  548. Andrzej has joined
  549. steffen has left
  550. jubalh Hi guys
  551. Zash 👋️
  552. jubalh Profanity actually used UUIDs before. We later added an identifier (instance id + barejid) and hashed that together with an uuid and take a base64 from it. The reason for this was that we didn't have any database and we used this to filter messages in MUCs.
  553. Ge0rG that sounds like insanity
  554. jubalh And yeah I just used a UUID instead of a shorter value to hash together because I was lazy and the XEP didn't forbid it :)
  555. Zash The XEP‽
  556. jubalh I mean no rfc or XEP said anything (to my knowledge) about the length of an ID
  557. Andrzej has left
  558. Zash Maybe every RFC and XEP should have the text "Use your common sense." somewhere.
  559. mathieui jubalh, I am curious though, apart from the hack with the hmac, what is the base64 for?
  560. Ge0rG mathieui: because base-16 is not sufficiently inefficient
  561. Ge0rG so it needs to be wrapped
  562. jubalh Zash: it was not about common sense. It was about having few time and solving an issue quickly ;)
  563. jubalh mathieui: I don't remember right now. Maybe it had to do with using barejid or something and the allowed values? Not sure anymore.
  564. jubalh I'll read the code in the next days and change that. We also have a DB now so we could actually check in there if we send the message ourselves.
  565. jubalh And the part about making Profanity famous is half-true too :) Because I knew (and more people brought it to my attention) pretty long value and devs will notice ;)
  566. Ge0rG I noticed.
  567. jubalh Hahaha
  568. Ge0rG Other people noticed too.
  569. jubalh I love you too Ge0rG :)
  570. mathieui Ge0rG, you did not complain hard enough!
  571. Ge0rG I even spent ~half an hour trying to understand what devil has ridden you for doing it this way
  572. moparisthebest > Zash: it was not about common sense. It was about having few time and solving an issue quickly ;) amen brother
  573. Ge0rG mathieui: I did, but probably in the wrong place
  574. mathieui But having the messages not display in movim because the DB field for the ID is too short was certainly more fun
  575. Zash Don't trust remote IDs?
  576. jubalh Isn't having a limit length for IDs in the DB even more wrong? :) There is no max length defined AFAIK
  577. moparisthebest a way to send messages that only display in certain clients you say mathieui ? nice attack
  578. mathieui jubalh, edhelas trusted "common sense", and having an index on a TEXT column is meh
  579. Ge0rG also relevant here: https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html#:~:text=The%20index%20key%20prefix%20length,REDUNDANT%20or%20COMPACT%20row%20format.
  580. jubalh i never trust common sense. I have seen all kinds of IDs so our DB doesnt limit it for example. There are some clients that start from 1 and increase their IDs upon each message. If you restart they start from 1 again. I think Pidgin did something funny too (at one point)
  581. mathieui jubalh, is it still the case though? (for the increasing onces) I though every client switched to some kind of uuid
  582. Ge0rG jubalh: yeah, that was funny.
  583. Ge0rG mathieui: BWAHAHAHA
  584. Ge0rG sorry.
  585. mathieui let me dream Ge0rG
  586. mathieui you evil man
  587. millesimus has joined
  588. mukt2 has left
  589. Zash Why did I even click a link to MySQL docs‽
  590. jubalh mathieui: I'm not sure. I just remember seeing it. And I think Profanity was using the increasing IDs too. And one of my first contributions was to switch it to UUIDs if I remember correctly.
  591. Ge0rG there was a "nice" bug in bifröst, where its xmpp backend de-duplicated stanzas based on their ID, and presence stanzas that didn't have an ID got into the same deduplication slot and were dropped
  592. Ge0rG smack will use $random_prfix-$autoincrement
  593. Kev ids do have a max length, BTW.
  594. Andrzej has joined
  595. Zash Kev, ~10MB?
  596. Ge0rG Kev: where is it defined? In XML?
  597. jubalh Kev: which is? And where is it written?
  598. Kev Because a stanza is allowed to have a max length of anything down to 10k, it means an id can’t be longer than that, less the rest of the stanza ;)
  599. jubalh you see guys. So Profanity is all good. Maybe we should stay as is then :)
  600. Kev I’d say you had a bit more room to play with, even.
  601. jubalh I'll think of something
  602. Zash (unique stream-id + counter), Ge0rG? Like the thing we keep mentioning as The Best Thing? 🙂
  603. Ge0rG Kev: there is no upper limit on the upper limit for stanza sizes, so technically it's unbounded.
  604. Kev hmac(base64(stanza))?
  605. Ge0rG Zash: not quite.
  606. mathieui jubalh, tbh if you get the binary uuid & hash and encode it in ascii85 (instead of picking the ascii repr and growing it with base64) you would fit easily into most lower limits without losing information :p
  607. Zash Almost
  608. adiaholic has left
  609. adiaholic has joined
  610. steffen has joined
  611. Ge0rG Zash: https://github.com/igniterealtime/Smack/blob/48f5e349b9a318ba2a1d82aef9fa069e62da10bb/smack-core/src/main/java/org/jivesoftware/smack/packet/id/StandardStanzaIdSource.java#L30
  612. Zash Ge0rG, so, per process?
  613. pjn has left
  614. pjn has joined
  615. Ge0rG Zash: yes
  616. ti_gj06 has left
  617. adiaholic has left
  618. adiaholic has joined
  619. Andrzej has left
  620. deuill Perhaps the there can/should be an XEP that provides some sort of best practice for ID generation? There's been a number of advances over UUID algorithms that avoid clashes while retaining sortability.
  621. Zash deuill, are you volunteering? 😉
  622. deuill Twitter Snowflake IDs were, I think, the first of their kind, but others have emerged since.
  623. Ge0rG deuill: yes, and that XEP should be RFC6120'
  624. Zash I looked at those. Also LUID and various variants of concat(timestamp, random)
  625. jonas’ ITYM ULID
  626. Zash [IDLU]{4} 🤷️
  627. mathieui IIII
  628. deuill Actually, maybe that's a good way for me to contribute. What I can't tell is why the original RFC says stanzas SHOULD have a unique ID assigned (not MUST?). I need to re-read those passages.
  629. Zash For fire-and-forget, who cares what the ID is
  630. deuill I think some of these algorithms assume Infinite computational power as well, or at least cycles to spare.
  631. deuill Conversations apparently tries to de-dup based on ID (even empty IDs)? People's definition of fire-and-forget may vary lol
  632. Zash Here's a start: ``` xeps$ pandoc -t ./tools/2xep.lua >inbox/best-id.xml <<. > % Best practices for stanza IDs > > Use UUIDv4. > . ```
  633. Aleksej has joined
  634. Zash runs away and hides `base64url(random.bytes(12))`
  635. Aleksej has left
  636. deuill Co-Authored-By: Alex P
  637. deuill Thanks Zash
  638. Calvin has joined
  639. Ge0rG jonas’: I didn't make a github PR for the CVE formatting back then, but I'd still love to move forward with it.
  640. Ge0rG jonas’: with your Editor hat on, what do you suggest me to do next?
  641. jonas’ Ge0rG, remove the background color, make a PR?
  642. Ge0rG jonas’: but I like the background color!
  643. Zash Does anyone know offhand where it says that 128 bit IDs should be enough until the end of time, for use as reference?
  644. Zash (UUID is less because version numbers and stuff tho)
  645. jonas’ Ge0rG, I don’t, it makes for a lack of contrast. And if even *I* find the contrast lacking, any a11y tool will throw it in your face.
  646. Freddy has left
  647. jonas’ Zash, we use 128 bit strength for cryptography, suggesting that you cannot reasonably brute-force a 128 bit thing
  648. Zash jonas’, cargo cult?
  649. deuill (Tangentially related but this was an interesting comparison of GUID algorithms, albeit all implemented in Go: https://blog.kowalczyk.info/article/JyRZ/generating-good-unique-ids-in-go.html)
  650. jonas’ Zash, https://crypto.stackexchange.com/a/48669/16902
  651. hamish has left
  652. Ge0rG jonas’: you only disliked the contrast to the links, right? Can I make the links red-colored in the cve box to satisfy you?
  653. jonas’ Ge0rG, no
  654. jonas’ also the text<->background was lacking IMO
  655. jonas’ but I may be misremembering
  656. jonas’ you could refresh my memory with a screenshot
  657. Ge0rG jonas’: https://op-co.de/tmp/xep-template.html#example-1
  658. jonas’ so red-on-red would definitely make this worse
  659. jonas’ and yeah, weave is contrast-error marking all of that
  660. jonas’ ok, the black-on-red not, but green-on-red it doesn’t like
  661. mukt2 has joined
  662. Ge0rG jonas’: I've reduced contrast of the red, can you shift+reload
  663. Ge0rG maybe you still have my old version cached
  664. Zash jonas’, IIRC even counting to 2⁶⁴ in boil-the-oceans levels, but for IDs it's more about the chances of accidentally generating the same ID twice during the lifetime of the scope.
  665. jonas’ Ge0rG, same
  666. jonas’ z https://en.wikipedia.org/wiki/Birthday_attack#Mathematics
  667. Zash jonas’, IIRC even counting to 2⁶⁴ is boil-the-oceans levels, but for IDs it's more about the chances of accidentally generating the same ID twice during the lifetime of the scope.
  668. jonas’ Zash, https://en.wikipedia.org/wiki/Birthday_attack#Mathematics
  669. Ge0rG jonas’: maybe it's because the default text color is #444
  670. Zash Oh look, it has a table
  671. jonas’ Ge0rG, it’s complaining about the coloured text, not about the grayscale text
  672. hamish has joined
  673. Ge0rG jonas’: another shift-reload?
  674. jonas’ I don’t see the link as link anymore
  675. jonas’ looks black to me
  676. xecks has left
  677. jonas’ (but weave is happy about the contrast… which is pointless though)
  678. jonas’ welcome to the world of making an accessible thing.
  679. Ge0rG jonas’: is your monitor calibrated?
  680. jonas’ do I need a calibrated monitor to read XEPs?
  681. xecks has joined
  682. Ge0rG jonas’: you need a calibrated monitor to complain about lack of contrast ;)
  683. jonas’ no, I don’t
  684. Ge0rG jonas’: I *really* want that reddish background, because without it just looks naked
  685. jonas’ sorry for your loss
  686. papatutuwawa has joined
  687. jonas’ I won’t accept a reddish background just because you prefer it if it renders XEPs less readable for people with visual deficiencies or under bad lighting conditions or whatever
  688. jonas’ I took great care during the XEP redesign to avoid such pitfalls, I’m not going to let you ruin that ;P
  689. Ge0rG said the person who uses #444 instead of black for text.
  690. Ge0rG jonas’: shift-reload again for the naked box.
  691. Daniel > said the person who uses #444 instead of black for text. That's better than #666
  692. jonas’ Ge0rG, LGTM
  693. Ge0rG Le Sigh.
  694. Ge0rG now how do I add a huge red warning sign there?
  695. jonas’ but I knew that already, I tested your design with background-color disabled and was immediately happy
  696. Ge0rG so we can't both be happy, right?
  697. jonas’ yes
  698. Ge0rG well, I can be happy if that box has a huge red ⚠️ in the left, but I don't know how to make it
  699. jonas’ Ge0rG, you need to do something with <img/> or background-image
  700. steffen has left
  701. Kev Why should we be making these things prominent anyway?
  702. jonas’ to get a warning sign without disturbing a11y tools
  703. Kev Security considerations aren’t, for example.
  704. Sam Yah, this seems like something to be aware of but not something that you absolutely definitely must see at all costs (as opposed to security considerations which are that)
  705. Sam These are just non-normative examples of what can go wrong.
  706. jonas’ and examples of where the security considerations have been ignored, so placing them really prominently is something I’d deem useful
  707. Ge0rG What jonas’ said
  708. Sam Prominent placement is fine, but it's not important to specifically draw the users attention to them over other things like the security considerations
  709. Ge0rG let's add a red background to the security considerations then!
  710. mathijs has left
  711. chronosx88 has left
  712. chronosx88 has joined
  713. jonas’ and make them blinking /s
  714. Ge0rG jonas’: at least it won't complain about contrast then!
  715. Zash `<blink><marquee>🚨️ ⚠️ ACHTUNG!</blink></marquee>`
  716. jonas’ so my opinion is roughly: If you don’t read the security considerations, you are a bad developer. No matter how emphasized they are compared to other sections. But there’s nothing wrong with us pointing out and highlighting exceptional cases where there are documented, wide-spread exploits because of such neglect with extra emphasis.
  717. steffen has joined
  718. Kev This is not a hill for me to die on, but I don’t understand why we would say the most important thing about a XEP is a section saying someone once got it wrong.
  719. Sam +1 ^
  720. mukt2 has left
  721. jonas’ do you have other proposals to improve the situation that people clearly ignore security considerations?
  722. Kev Accept that it’s not the spec author’s responsibility, nor is it within their ability, to make implementors read the spec?
  723. Ge0rG write shorter specs.
  724. Ge0rG also: write specs that are harder to implement in insecure ways.
  725. Kev Focus on writing clear specs that are easy to get right.
  726. jonas’ Kev, that’s not an improvement to the situation, only to your (our) perception of it
  727. Sam What Ge0rG said.
  728. jonas’ but we can’t fix e.g. carbons and such
  729. Ge0rG XMPP 2.0!
  730. larma has left
  731. larma has joined
  732. Sam I don't think this will do what you think you're doing either though. This is just a distraction that may or may not actually have anything to do with the security considerations and may or may not actually contain anything of value that's likely to be repeated.
  733. Sam It's a nice thing to have, it just doesn't seem like the thing we want to drag users eyes to (and possibly away from other important normative things like security considerations)
  734. Sam Everyone only reads the examples and not the normative text, let's not also make them only read the CVEs and not the security considerations.
  735. jonas’ Sam, but they’re *already* not reading the security considerations.
  736. Sam So don't make it worse.
  737. Sam It's a separate problem is what I'm saying
  738. MattJ I don't have full context here, and don't have time to review the entire conversation, but if this is about relevant CVEs being highlighted in XEPs, that's definitely a thing we should do
  739. Sam Add CVEs, that's a good idea I think. If you want to make people read the security considerations, highlight that, not the new non-normative may or may not exist or be relevant examples.
  740. adiaholic has left
  741. Ge0rG MattJ: it's about the format of that: https://op-co.de/tmp/xep-0280.html#security
  742. Sam I have no strong feelings about how this should be formatted, FWIW, I just want to suggest that adding more and more stuff isn't doing what you think it's doing.
  743. Sam On first impressions the one Ge0rG just linked looks great to me and is enough extra formatting.
  744. Kev Especially without context.
  745. mathijs has joined
  746. MattJ Ok, if it's just about bikeshed formatting, I definitely have other things to do... :)
  747. MattJ Oh no, but I can't help it... FWIW I would group all the CVEs into a single box with "The following security vulnabilities have previously been found in some implementations of this specification:"
  748. Ge0rG MattJ: that can be achieved by different XSLT, I'm sure.
  749. Kev MattJ: This isn’t all CVEs though, Jonas’ said it’s only those that were widely applicable.
  750. jonas’ "worth highlighting" for whatever definition of that
  751. MattJ I didn't say "all", did I?
  752. Kev Oh, and exploited widely, in fact.
  753. Kev You didn’t, but just saying “here are some CVEs” implies it’s somewhat more exhaustive than CVEs that have been widely exploited.
  754. MattJ Then insert "notable" somewhere, or something. Or don't :)
  755. Kev Anyway, if we’re only talking about vulnerabilities that were widely exploited (which has been precisely 0 vulneralibilities that I can remember), my concerns about them being overemphasised are probably overblown.
  756. jonas’ Kev, sorry, I didn’t mean to say "exploited"
  757. jonas’ but widely exploitable with simple-enough PoCs
  758. Andrzej has joined
  759. jonas’ but I am also fine with less strict constraints
  760. karoshi has left
  761. Freddy has joined
  762. flow listing related CVEs is probably fine, but not like https://op-co.de/tmp/xep-0280.html#security please
  763. flow the text of the security considerations is more improtant than the related CVEs. but the currently proposed visualization puts the focus on the CVEs
  764. Andrzej has left
  765. Andrzej has joined
  766. jonas’ flow, see above for my rationale for that
  767. flow jonas’, not sure if I looked at the right rationale, at least I fail to see how this counters my argument
  768. ti_gj06 has joined
  769. jonas’ > so my opinion is roughly: If you don’t read the security considerations, you are a bad developer. No matter how emphasized they are compared to other sections. But there’s nothing wrong with us pointing out and highlighting exceptional cases where there are documented, wide-spread exploits because of such neglect with extra emphasis.
  770. werdan has joined
  771. flow that is what I read. But I don't interpret this as something that argues in favor of making the CVEs visually more prominent than the security considerations
  772. flow if anything, be sparse with visual effects
  773. karoshi has joined
  774. jonas’ -ENOTIME
  775. flow It feels like Ge0rG had the changelog of a software in mind when he designed this
  776. BASSGOD has left
  777. Sam What flow says. I don't have strong feelings about the current formatting, but we definitely shouldn't do much more than this (stop signs and big red backgrounds and whatever was being discussed before). And even as is now I still think it will be just like examples where users automatically read the shiny things and ignore the text assuming the examples (or CVEs) cover all the things they need to know.
  778. Ge0rG Sam: if the people read the CVE, that's a huge win already.
  779. Sam I kind of doubt it in most cases, especially if it comes at the cost of ignoring the text, but maybe.
  780. Ge0rG Sam: as jonas’ said before, the text is already being ignored
  781. flow I am not sure if adding big red boxes under the text being ignored helps with that
  782. Sam Ge0rG: right, and this won't fix it and could make it worse.
  783. Sam And now the only thing they maybe look at is some random examples that may or may not actually be a good representation of the actual problems and weren't actually a part of the XEP process.
  784. flow If anything, a short, potentially visually featured, sentenced at the beginning of the xep that states "This XEP has Security Considerations, make sure to read them", would be better IMHO
  785. flow If anything, a short, potentially visually featured, sentence at the beginning of the xep that states "This XEP has Security Considerations, make sure to read them", would be better IMHO
  786. adiaholic has joined
  787. Ge0rG well, if they read the CVE text, the chances are higher that they'll come to the same conclusion that's implied in the security considerations
  788. Sam I doubt it. I'd bet most of them end up with one or two things that are mostly unrelated, or only cover one tiny part of the security considerations.
  789. BASSGOD has joined
  790. Steve Kille has left
  791. Ge0rG Well, the list of CVEs is evidence that the current aproach does *not* work. Let's try the alternative suggestion as an A/B test then
  792. Sam If that's actually the problem you're trying to solve, flow's alternative seems better.
  793. adiaholic has left
  794. Zash A/B tests \o/
  795. mukt2 has joined
  796. adiaholic has joined
  797. Sam (FWIW if we had a way to actually A/B test this that would be great, but I don't think we do)
  798. Ge0rG let's bikeshed A/B testing infrastructure then!
  799. Daniel > Well, the list of CVEs is evidence that the current aproach does *not* work. Let's try the alternative suggestion as an A/B test then Do we have evidence that the clients effected by the CVE ever read the xeps?
  800. jonas’ how would the know how to enable carbons if not?
  801. Daniel The developers of those clients
  802. Ge0rG Daniel: are you saying that you can implement a XEP without reading it?
  803. Daniel jonas’: gajim XML console
  804. jonas’ Daniel, please no
  805. Daniel Looking at other implementations
  806. jonas’ please no.
  807. jonas’ I’m going to get dinner now
  808. moparisthebest reading the xeps don't even matter, what clients/servers send/accept in practice is what matters :D
  809. jonas’ because I can’t take that
  810. Daniel I'm fairly convinced that this is how a lot of those clients were developed
  811. flow ahh, the thought of XMPP devs not even looking briefly at XEPs when implementing them
  812. flow enough xsf@ for today
  813. jonas’ cries
  814. Kev I *know* there have been implementations of features done by looking at sent/received protocol, and not the XEPs.
  815. Kev That’s not even hypothetical :)
  816. Steve Kille has joined
  817. Daniel That's how I implemented <session/>
  818. moparisthebest aren't there plenty of things that are well known not to even be implementable looking at XEPs ? just "shared knowledge" stuff ?
  819. Daniel Didn't know what it was. Just knew that sending this magic made things work
  820. Sam I'd be willing to be that between what Daniel said, looking at the XEP but only at the examples, and copy/paste from Stack Overflow you'd cover over 99% of all XMPP development. I don't think I'm joking when I say that I'd put money on this.
  821. moparisthebest if a client dev implemented OMEMO from the XEP today they'd probably be pretty sad when they couldn't interop with a single other client ?
  822. Sam *bet
  823. Sam And I'd bet that the other <1% are 99% people in this room :)
  824. moparisthebest there is a massive difference between what client/servers *should* accept/handle and what they actually *will* accept/handle in practice, you can't get that from looking at XEPs
  825. Ge0rG moparisthebest: that's actually also a statement about the horrible state of the OMEMO XEP
  826. moparisthebest same situation with RFCs, and everything in web-land too
  827. moparisthebest computers: they bad
  828. mukt2 has left
  829. mathieui Sam, knowing ex-coworkers who have worked on XMPP for a client website project, that probably sums up 99% of all private-sector XMPP development for people not familiar with standards, yes
  830. mathieui "I just loaded xmpp.js, why doesn’t it work!"
  831. moparisthebest when I implemented XEP-0368 in Conversations I didn't know the XSF or XEPs existed
  832. Sam mathieui: indeed, I was specifically thinking of a colleague at HipChat who asked me a question about the protocol and I wasn't sure off the top of my head so I said "Here, pull up RFC 6120" and their response was "wait, you actually read these things?"
  833. Sam Although as far as libraries go, "I just loaded <library>, it should work" seems reasonable.
  834. moparisthebest my reasoning was roughly: email clients are fine doing direct-tls instead of starttls without any formal specification, why not XMPP
  835. Sam I mean, assuming they actually called it somehow, you know what I mea.n
  836. paul has left
  837. mathieui Sam, well, except you need to at least know some part of the semantics and how they relate with what you want to do
  838. paul has joined
  839. Kev I think there’s multiple things here. * People understanding how they should learn what to do * People being willing to do stuff properly * People being competent to do stuff properly * Doing stuff properly being possible to do * Doing stuff properly being easy to do
  840. Kev And probably others.
  841. mathieui Most certainly others, yes.
  842. BASSGOD has left
  843. Sam mathieui: yah, I feel like that's a library design problem though. For most people I suspect they want to call conn = xmpp.Connect("domain.com"); conn.SendMessage("Hi") or something. I really want to eventually get my own stuff to that point
  844. Zash Do we need to stick "The Official XMPP $Language SDK" sticker on some libraries?
  845. Kev I think it’s unduly naive to think we can have much influence over some of those, and showing that people aren’t getting it Right doesn’t, in itself, mean that if we just shout at them louder it’ll get better.
  846. Sam What Kev said.
  847. debacle has left
  848. Kev OTOH, some of them (particularly the last two, but also the first) are entirely within our remit.
  849. mathieui Sam, well, if I remember correctly it was something like they did not expose bosh or websocket in their ejabberd container
  850. mukt2 has joined
  851. goffi has left
  852. Sam Fair; ops is hard no matter what.
  853. moparisthebest and don't get me wrong XEPs are super valuable and we should cram all the relevant info needed in them, if only for a place to point to other than "look what client X does" which sucks
  854. moparisthebest still, many times you have to dig into what X does, and assume many/most people use this instead of XEPs on how to learn it
  855. adiaholic has left
  856. moparisthebest TLS had the same problem with people hardcoding version numbers right?
  857. moparisthebest "it works for the current input" not realizing it'd break on 1.3, 1.3 ended up working around it entirely
  858. adiaholic has joined
  859. debacle has joined
  860. BASSGOD has joined
  861. paul has left
  862. paul has joined
  863. derwin has left
  864. derwin has joined
  865. derwin has left
  866. derwin has joined
  867. Andrzej has left
  868. paul has left
  869. paul has joined
  870. adiaholic has left
  871. arcxi has left
  872. arcxi has joined
  873. papatutuwawa has left
  874. arcxi has left
  875. arcxi has joined
  876. arcxi has left
  877. arcxi has joined
  878. peetah has left
  879. paul has left
  880. paul has joined
  881. paul has left
  882. paul has joined
  883. mukt2 has left
  884. Andrzej has joined
  885. moparisthebest https://mastodon.xyz/@nextcloud/106058947562901204 :)
  886. peetah has joined
  887. BASSGOD has left
  888. mukt2 has joined
  889. arcxi has left
  890. adiaholic has joined
  891. arcxi has joined
  892. debacle has left
  893. debacle has joined
  894. BASSGOD has joined
  895. adiaholic has left
  896. arcxi has left
  897. arcxi has joined
  898. BASSGOD has left
  899. mukt2 has left
  900. werdan has left
  901. BASSGOD has joined
  902. ti_gj06 has left
  903. mukt2 has joined
  904. adiaholic has joined
  905. papatutuwawa has joined
  906. mathijs has left
  907. mathijs has joined
  908. mukt2 has left
  909. BASSGOD has left
  910. adiaholic has left
  911. adiaholic has joined
  912. mukt2 has joined
  913. adiaholic has left
  914. paul has left
  915. adiaholic has joined
  916. BASSGOD has joined
  917. mukt2 has left
  918. adiaholic has left
  919. karoshi has left
  920. karoshi has joined
  921. mukt2 has joined
  922. pasdesushi has joined
  923. BASSGOD has left
  924. Andrzej has left
  925. Wojtek has left
  926. BASSGOD has joined
  927. adiaholic has joined
  928. Yagiza has left
  929. adiaholic has left
  930. arcxi has left
  931. pasdesushi has left
  932. pasdesushi has joined
  933. papatutuwawa has left
  934. pasdesushi has left
  935. mukt2 has left
  936. BASSGOD has left
  937. adiaholic has joined
  938. BASSGOD has joined
  939. adiaholic has left
  940. ti_gj06 has joined
  941. BASSGOD has left
  942. BASSGOD has joined
  943. hamish has left
  944. hamish has joined
  945. LNJ has left
  946. Syndace has left
  947. Syndace has joined
  948. chronosx88 has left
  949. arcxi has joined
  950. pasdesushi has joined
  951. goffi has joined
  952. BASSGOD has left
  953. murabito has joined
  954. mukt2 has joined
  955. BASSGOD has joined
  956. murabito has left
  957. neshtaxmpp has left
  958. lovetox_ has joined
  959. Syndace has left
  960. chronosx88 has joined
  961. Syndace has joined
  962. adiaholic has joined
  963. lovetox_ has left
  964. mathijs has left
  965. lovetox_ has joined
  966. lovetox_ has left
  967. lovetox_ has joined
  968. adiaholic has left
  969. LNJ has joined
  970. BASSGOD has left
  971. andy has left
  972. Syndace has left
  973. Syndace has joined
  974. alameyo has joined
  975. BASSGOD has joined
  976. Syndace has left
  977. Syndace has joined
  978. arc has joined
  979. arc has left
  980. arc has joined
  981. goffi has left
  982. arc has left
  983. arc has joined
  984. alameyo has left
  985. arc has left
  986. arc has joined
  987. arc has left
  988. arc has joined
  989. chronosx88 has left
  990. chronosx88 has joined
  991. arc has left
  992. arc has joined
  993. arc has left
  994. arc has joined
  995. arc has left
  996. arc has joined
  997. neshtaxmpp has joined
  998. mukt2 has left
  999. lovetox_ has left
  1000. ti_gj06 has left
  1001. Aleksej has joined
  1002. Adi has left
  1003. arc has left
  1004. arc has joined
  1005. arc has left
  1006. mukt2 has joined
  1007. arc has joined
  1008. arc has left
  1009. arc has joined
  1010. Aleksej has left
  1011. Maranda has left
  1012. arc has left
  1013. Aleksej has joined
  1014. arc has joined
  1015. Maranda has joined
  1016. Tobias has left
  1017. menel has left
  1018. arc has left
  1019. arc has joined
  1020. arc has left
  1021. arc has joined
  1022. eevvoor has left
  1023. Adi has joined
  1024. chronosx88 has left
  1025. chronosx88 has joined
  1026. DebXWoody has left
  1027. alameyo has joined
  1028. arc has left
  1029. arc has joined
  1030. arc has left
  1031. arc has joined
  1032. Seve has left
  1033. DebXWoody has joined
  1034. mathijs has joined
  1035. pasdesushi has left
  1036. pasdesushi has joined
  1037. DebXWoody has left
  1038. pasdesushi has left
  1039. pasdesushi has joined
  1040. steffen has left
  1041. pasdesushi has left
  1042. pasdesushi has joined
  1043. arc has left
  1044. arc has joined
  1045. arc has left
  1046. arc has joined
  1047. pasdesushi has left
  1048. lorddavidiii has left
  1049. pasdesushi has joined
  1050. adiaholic has joined
  1051. arc has left
  1052. arc has joined
  1053. BASSGOD has left
  1054. arc has left
  1055. arc has joined
  1056. croax has left
  1057. pasdesushi has left
  1058. pasdesushi has joined
  1059. pasdesushi has left
  1060. pasdesushi has joined
  1061. adiaholic has left
  1062. alameyo has left
  1063. BASSGOD has joined
  1064. pasdesushi has left
  1065. bean has left
  1066. alameyo has joined
  1067. pasdesushi has joined
  1068. pasdesushi has left
  1069. pasdesushi has joined
  1070. hamish has left
  1071. hamish has joined
  1072. pasdesushi has left
  1073. sebastian has left
  1074. pasdesushi has joined
  1075. pasdesushi has left
  1076. rdelaage has left
  1077. dos1 has left
  1078. antoine has left
  1079. superkuh has left
  1080. pasdesushi has joined
  1081. pasdesushi has left
  1082. pasdesushi has joined
  1083. emus has left
  1084. karoshi has left
  1085. govanify has left
  1086. govanify has joined
  1087. pasdesushi has left
  1088. pasdesushi has joined
  1089. sebastian has joined
  1090. karoshi has joined
  1091. pasdesushi has left
  1092. pasdesushi has joined
  1093. pasdesushi has left
  1094. karoshi has left
  1095. arc has left
  1096. arc has joined
  1097. karoshi has joined
  1098. rdelaage has joined
  1099. dos1 has joined
  1100. antoine has joined
  1101. superkuh has joined
  1102. arc has left
  1103. Calvin has left
  1104. arc has joined
  1105. pasdesushi has joined
  1106. pasdesushi has left
  1107. LNJ has left
  1108. arc has left
  1109. arc has joined
  1110. arc has left
  1111. arc has joined
  1112. karoshi has left
  1113. pasdesushi has joined
  1114. BASSGOD has left
  1115. arc has left
  1116. arc has joined
  1117. pasdesushi has left
  1118. pasdesushi has joined
  1119. arc has left
  1120. arc has joined
  1121. steffen has joined
  1122. karoshi has joined
  1123. pasdesushi has left
  1124. pasdesushi has joined
  1125. BASSGOD has joined
  1126. stp has left
  1127. pasdesushi has left
  1128. arc has left
  1129. arc has joined
  1130. arc has left
  1131. arc has joined
  1132. strypey has joined
  1133. strypey has left
  1134. strypey has joined
  1135. strypey has left
  1136. Calvin has joined
  1137. pasdesushi has joined
  1138. chronosx88 has left
  1139. chronosx88 has joined
  1140. hamish has left
  1141. pasdesushi has left
  1142. hamish has joined
  1143. arc has left
  1144. arc has joined
  1145. arc has left
  1146. arc has joined
  1147. arc has left
  1148. arc has joined
  1149. chronosx88 has left
  1150. chronosx88 has joined
  1151. debacle has left
  1152. arc has left
  1153. arc has joined
  1154. arc has left
  1155. arc has joined
  1156. mukt2 has left