XSF Discussion - 2021-03-23

  1. FILEANCHORS has joined
  2. FILEANCHORS has left
  3. ajeremias has joined
  4. Andrzej has joined
  5. menel has left
  6. emus has left
  7. pjn has left
  8. Calvin has joined
  9. Andrzej has left
  10. pjn has joined
  11. fuana has joined
  12. fuana has left
  13. BASSGOD has left
  14. BASSGOD has joined
  15. pjn has left
  16. pjn has joined
  17. ajeremias has left
  18. pjn has left
  19. pjn has joined
  20. Kev has left
  21. Kev has joined
  22. lskdjf has left
  23. fuana has joined
  24. debacle has left
  25. mimi89999 has left
  26. fuana has left
  27. fuana has joined
  28. alameyo has joined
  29. paul has left
  30. Kev has left
  31. Kev has joined
  32. Andrzej has joined
  33. chronosx88 has left
  34. andrey.g has left
  35. Andrzej has left
  36. Kev has left
  37. Kev has joined
  38. Calvin has left
  39. eevvoor has left
  40. eevvoor has joined
  41. Kev has left
  42. Kev has joined
  43. govanify has left
  44. govanify has joined
  45. govanify has left
  46. govanify has joined
  47. govanify has left
  48. govanify has joined
  49. moparisthebest has left
  50. antranigv has left
  51. antranigv has joined
  52. aidalgol has left
  53. stp has left
  54. croax has joined
  55. jcbrand has joined
  56. govanify has left
  57. govanify has joined
  58. Andrzej has joined
  59. alacer has left
  60. fuana has left
  61. fuana has joined
  62. Kev has left
  63. Kev has joined
  64. ti_gj06 has left
  65. alacer has joined
  66. Andrzej has left
  67. fuana has left
  68. govanify has left
  69. govanify has joined
  70. paul has joined
  71. Yagiza has joined
  72. BASSGOD has left
  73. moparisthebest has joined
  74. BASSGOD has joined
  75. Tobias has joined
  76. Andrzej has joined
  77. Andrzej has left
  78. andy has joined
  79. raghavgururajan has left
  80. raghavgururajan has joined
  81. raghavgururajan has left
  82. raghavgururajan has joined
  83. govanify has left
  84. govanify has joined
  85. aidalgol has joined
  86. ti_gj06 has joined
  87. govanify has left
  88. govanify has joined
  89. Andrzej has joined
  90. wurstsalat has joined
  91. flow has joined
  92. Andrzej has left
  93. xsf has left
  94. chronosx88 has joined
  95. govanify has left
  96. govanify has joined
  97. adiaholic has joined
  98. marc has joined
  99. floretta has left
  100. xsf has joined
  101. Kev has left
  102. Kev has joined
  103. Kev has left
  104. BASSGOD has left
  105. Kev has joined
  106. lovetox has left
  107. BASSGOD has joined
  108. marc has left
  109. chronosx88 has left
  110. chronosx88 has joined
  111. chronosx88 has left
  112. chronosx88 has joined
  113. chronosx88 has left
  114. chronosx88 has joined
  115. mathijs has left
  116. menel has joined
  117. mathijs has joined
  118. chronosx88 has left
  119. chronosx88 has joined
  120. Kev has left
  121. Kev has joined
  122. adiaholic has left
  123. chronosx88 has left
  124. chronosx88 has joined
  125. chronosx88 has left
  126. chronosx88 has joined
  127. chronosx88 has left
  128. chronosx88 has joined
  129. chronosx88 has left
  130. chronosx88 has joined
  131. chronosx88 has left
  132. chronosx88 has joined
  133. adiaholic has joined
  134. marek has left
  135. mimi89999 has joined
  136. marek has joined
  137. emus has joined
  138. adiaholic has left
  139. adiaholic has joined
  140. purplebeetroot has joined
  141. chronosx88 has left
  142. adiaholic has left
  143. Maranda has left
  144. Maranda has joined
  145. adiaholic has joined
  146. chronosx88 has joined
  147. chronosx88 has left
  148. chronosx88 has joined
  149. chronosx88 has left
  150. chronosx88 has joined
  151. karoshi has joined
  152. purplebeetroot has left
  153. purplebeetroot has joined
  154. purplebeetroot has left
  155. adiaholic has left
  156. Freddy has left
  157. APach has left
  158. APach has joined
  159. adiaholic has joined
  160. Freddy has joined
  161. bean has joined
  162. adiaholic has left
  163. adiaholic has joined
  164. Andrzej has joined
  165. purplebeetroot has joined
  166. adiaholic has left
  167. larma I'm kinda confused by this change: https://xmpp.org/extensions/xep-0176.html#revision-history-v1.1 > Make the 'foundation' attribute a string instead of an unsignedByte, in accordance with RFC 8445 [1]. XEP-0176 is meant to implement RFC 5245, XEP-0371 is meant to implement RFC 8445. Why would we adjust XEP-0176 to be in accordance with a related but incompatible RFC?
  168. Daniel i’m confused about the existence of 371
  169. Daniel couldn’t we have just made incremental changes to 176
  170. larma The RFCs are not fully compatible, so, no?
  171. larma I mean apparently a bunch of clients seem to do RFC 8445 over XEP 176 now
  172. larma Because it was already widely used and looked similar to what they're doing I guess
  173. Daniel is there any client doing 371?
  174. adiaholic has joined
  175. larma Don't think so, but most WebRTC clients probably should
  176. larma Assuming they use libwebrtc
  177. larma Given that most (if not all) WebRTC clients are incompatible with what was around before, there really was no reason to stick with the 176...
  178. adiaholic has left
  179. Daniel to be honest for me it was a discovery thing. i didn’t even know about 371
  180. Daniel or have a good enough understanding to be able to tell the differences
  181. Daniel (i still don’t know the difference)
  182. Daniel without putting words into peoples mouths I assume this may have been similiar for the two implementations that predate Conversations
  183. Kev We’ve always struggled for review on Jingle stuff, *especially* Jingle WebRTC stuff. There’s a couple of very knowledgeable people around, but nothing like the volume of knowledge we have relevant to most XEPs.
  184. Daniel larma, 371 used to use 5245 as well and was then upgraded to 8445
  185. Daniel without any problems
  186. Daniel so i'm wondering if the same can not be done for 176
  187. Daniel (possibly with some extra disco features for example for "i support 176 + tcp candidates" or something)
  188. larma I implemented a client of 176 that implements RFC 5245 and it can't be connected from Conversations because libwebrtc implements RFC 8445 (it probably works the other way round because that changes who is the controller). Incompatibility to me sounds like a good reason not to update/change a Draft XEP
  189. larma OTH we now have a bunch of clients claiming 176 conpat in disco that are not fully compatible, so I guess the damage is already here
  190. larma OTOH we now have a bunch of clients claiming 176 conpat in disco that are not fully compatible, so I guess the damage is already here
  191. debacle has joined
  192. adiaholic has joined
  193. Link Mauve larma, I originally only wanted to extend from unsignedByte to unsignedInt, as that was what libwebrtc (and all clients based on it) was doing.
  194. Link Mauve But RFC 5245 was already requesting a string up to 32 characters (whatever that means, probably bytes).
  195. Link Mauve “ foundation = 1*32ice-char”
  196. Link Mauve “ ice-char = ALPHA / DIGIT / "+" / "/"”
  197. deuill has left
  198. larma Link Mauve: I guess I was more confused about the reference to RFC 8445 than the change itself
  199. Link Mauve Ah hmm, maybe I was the one who got confused, as 5245 already had the exact same requirement and we imported it as an unsigned byte instead, probably in accordance with implementations of the day.
  200. Link Mauve larma, AIUI the incompatibility doesn’t come from 5245 vs. 8445, but from mandatory DTLS-SRTP vs. not supported.
  201. larma That's something else
  202. Link Mauve Or maybe you’re aware of some incompatibility between the two RFCs that I’m not?
  203. larma I'm specifically talking about ICE
  204. deuill has joined
  205. Syndace has left
  206. Syndace has joined
  207. larma 8445 allows sending data before candidate nomination, basically making candidate nomination optional (also the reason the got rid of the aggressive nomination mode). 5245 requires nomination before sending. If the controlling side is 8445 they might never nominate a candidate, thus the 5245 side can't send.
  208. larma I had to discover that through wireshark ;)
  209. Link Mauve How is that negociated in non-XMPP deployments?
  210. eric has left
  211. larma They probably all use 8445 nowadays and just updated when Google dictated them to?
  212. Link Mauve All legacy telephony systems?
  213. eric has joined
  214. larma They're not compatible with WebRTC anyway due to dtls-srtp
  215. larma So nobody cares I guess
  216. larma Others would just make their client such that it's compatible with legacy systems (e.g. by nominating a candidate pair even if not required for them)
  217. adiaholic has left
  218. larma If care is taken, you can implement ICE clients that are compatible with different versions of ICE. For example, some early drafts of ICE required sending USERNAME attribute in responses. If you aim for compatibility you can just do it, as adding more attributes than required is allowed and they simply get ignored by RFC implementations
  219. Link Mauve Is “candidate pair” the proper name of a c= line in SDP?
  220. adiaholic has joined
  221. larma No, that's just the candidate
  222. Link Mauve Because I’ve seen implementations include a dummy one.
  223. Link Mauve In the initial offer.
  224. larma The pair is a combination of local and remote candidate
  225. larma Safari does not send proper candidates before granting audio/video permission
  226. larma For privacy reasons
  227. fuana has joined
  228. Daniel larma, if there is any low hanging fruit like sending transport-info/remote candidate or someting that improves the situation for you let me know
  229. larma I guess we'll just make sure to be compatible with RFC 8445 as well when using 176...
  230. fuana has left
  231. adiaholic has left
  232. adiaholic has joined
  233. lskdjf has joined
  234. marc has joined
  235. larma Daniel: you mentioned TCP, do you actually do RTP over TCP?
  236. Daniel larma: I've disabled that because 176 doesn't support it
  237. Daniel Until know I was under the impression that this is the only major difference
  238. Daniel As this is what the introduction of 371 focuses on
  239. Link Mauve That was also my impression btw, which is why I never pushed for 0371.
  240. larma Well ICE-UDP is a datagram transport and ICE-TCP is a stream transport but according to 166 each transport should decide to either be datagram or stream and according to 167 RTP is only allowed over datagram
  241. Link Mauve I referred to the RFC to understand some things, but didn’t compare them thoroughly.
  242. adiaholic has left
  243. larma I think having ICE-UDP and ICE-TCP not in the same XEP or at least not use the same namespace makes sense. I also wonder what libwebrtc does when setting up RTP over TCP because it will need to encapsulate the RTP datagrams somehow so they can go on a stream
  244. Freddy has left
  245. larma (encapsulate can be as easy as prefixing with a length)
  246. Guus has joined
  247. adiaholic has joined
  248. fuana has joined
  249. Freddy has joined
  250. L29Ah are XMPP addresses case-sensitive? couldn't find such info in https://tools.ietf.org/html/rfc6122
  251. Daniel No
  252. Daniel The local part is normalized
  253. Daniel Aka 'fancy lower cased'
  254. stp has joined
  255. Link Mauve The fancy part means you can’t just lowercase it and do the comparison, you have to use stringprep.
  256. Link Mauve Not doing so is a vulnerability awaiting.
  257. fuana has left
  258. fuana has joined
  259. Daniel Yes if you are asking from a developers perspective definitely understand how stringprep works. From a user perspective it's simpler to just think of lower case
  260. Zash L29Ah, so you would look at https://tools.ietf.org/html/rfc6122#appendix-A and then look up the referenced tables in https://tools.ietf.org/html/rfc3454
  261. Guus has left
  262. Zash E.g. https://tools.ietf.org/html/rfc3454#appendix-B.2 is the long version of "lower-case"
  263. LNJ has joined
  264. peetah has left
  265. peetah has joined
  266. fuana has left
  267. adiaholic has left
  268. L29Ah thanks!
  269. dwd Anyone available for doing React and Stanza.js for a contracting gig?
  270. stp has left
  271. stp has joined
  272. MattJ Don't forget https://xmpp.work/
  273. Link Mauve sonny, ↑
  274. fuana has joined
  275. aidalgol has left
  276. sonny nope pretty busy ATM
  277. flow L29Ah, check https://tools.ietf.org/html/rfc7622
  278. fuana has left
  279. fuana has joined
  280. lovetox has joined
  281. eric has left
  282. eric has joined
  283. marek has left
  284. marek has joined
  285. Zash Check this handy graph ```dot digraph "xmpp-addr" { rfc3920 -> idna2003 [label="ref"] rfc3920 -> stringprep [label="ref"] rfc3920 -> rfc6122 [label="update"] rfc6122 -> idna2003 [label="ref"] rfc6122 -> idna2008 [label="ref"] rfc6122 -> stringprep [label="ref"] rfc6122 -> rfc7622 [label="obsolete"] rfc7622 -> idna2008 [label="ref"] rfc7622 -> precis [label="ref"] idna2003 -> idna2008 [label="obsolete"] idna2003 -> stringprep [label="ref"] } ```
  286. lovetox has left
  287. lovetox has joined
  288. Wojtek has joined
  289. MattJ Rendered:
  290. MattJ https://matthewwild.co.uk/uploads/xmpp-addr.png
  291. Kev has left
  292. Kev has joined
  293. fuana has left
  294. fuana has joined
  295. purplebeetroot has left
  296. Nekit has joined
  297. alacer has left
  298. ajeremias has joined
  299. purplebeetroot has joined
  300. chronosx88 has left
  301. chronosx88 has joined
  302. fuana has left
  303. fuana has joined
  304. peetah has left
  305. peetah has joined
  306. alacer has joined
  307. marc has left
  308. marc has joined
  309. lskdjf has left
  310. lskdjf has joined
  311. eric MattJ: what did you use for rendering?
  312. MattJ dot -Tpng
  313. eric Thanks
  314. Zash FTR I pasted the source so that in the far future, after all the http-uploaded files have expired, someone could still see what it was
  315. lovetox has left
  316. ajeremias has left
  317. Calvin has joined
  318. lskdjf has left
  319. purplebeetroot has left
  320. lskdjf has joined
  321. chronosx88 has left
  322. chronosx88 has joined
  323. MattJ This URL isn't expiring any time soon :)
  324. lovetox has joined
  325. eric has left
  326. eric has joined
  327. lskdjf has left
  328. lskdjf has joined
  329. lskdjf has left
  330. lskdjf has joined
  331. chronosx88 has left
  332. chronosx88 has joined
  333. lskdjf has left
  334. lskdjf has joined
  335. L29Ah i have a string, "/"
  336. L29Ah is this a valid XMPP address?
  337. jonas’ no
  338. L29Ah why?
  339. jonas’ oh, it is
  340. jonas’ it gets normalised to `/` which is apparently a valid domain name.
  341. jonas’ I mean "valid"
  342. L29Ah it might be a valid domain name but when parsed as a jid after normalisation it would denote an empty domain name with empty resource
  343. Zash Oh no, is this another case of "turns out a HTTP URL is a valid hostname"?
  344. L29Ah Zash: no, i'm figuring out why i have a failing test in a xmpp library i maintain
  345. jonas’ L29Ah, oh no.
  346. jonas’ that is ... interesting
  347. L29Ah the test suite has come up with such a nice jid
  348. L29Ah that the library can serialise (with normalisation) but can't parse afterwards
  349. Zash It's invalid because `/.` is not an existing top-level domain.
  350. Kev has left
  351. Kev has joined
  352. L29Ah Zash: it might be /.local.
  353. Zash Oh no
  354. Zash But _that_ isn't valid
  355. jonas’ is it not?
  356. Zash empty host, `.local` as resource!
  357. jonas’ no
  358. jonas’ not if written as /.local
  359. jonas’ normalization of the domainpart happens *after* splitting
  360. Zash True
  361. jonas’ can’t be reserialized as JID anymore though :)
  362. Zash Also true
  363. jonas’ L29Ah, congrats, that’s a terrible test case
  364. jonas’ might even warrant an erratum to RFC 6122, would have to check if 7622 has the same issue
  365. L29Ah "awesome test case", you mean?
  366. jonas’ L29Ah, yes, in the original sense of the word
  367. jonas’ well, in both senses that is
  368. jonas’ L29Ah, where did you find it?
  369. L29Ah 16:01:35]<L29Ah> the test suite has come up with such a nice jid
  370. jonas’ which test suite?
  371. L29Ah it generates random strings
  372. L29Ah quickcheck
  373. jonas’ oh
  374. jonas’ awful
  375. jonas’ I mean amazing
  376. jonas’ but awful
  377. jonas’ you know what I mean
  378. Sam ooh, that's a good one. Works, but definitely seems like something we should be making illegal somehow https://play.golang.org/p/F7GRBN3EkDX
  379. fuana has left
  380. fuana has joined
  381. Sam (that example is using 7622, you may have to run it twice for it to cache the library and not timeout because of the download time)
  382. jonas’ Sam, thanks for the 7622 check
  383. Kev “not if written as / .local” Why does that space matter? It’s still split on the / so the latter part is the resource?
  384. Sam Kev: that's not a space :)
  385. jonas’ Kev, it’s not a space, it’s a strange slash character
  386. Sam (it's not a '/' either :) )
  388. Kev Ah, if it’s not / then ok :)
  389. Sam Should be fine because it will never be normalized to '/' in 7622 at least, but it *looks* confusing which is possibly bad
  390. wgreenhouse has left
  391. Kev Yes, “fine” might be quite subjective here :)
  392. Sam Eg. if I buy "google.com/definitelynotevil.com"
  393. Sam "Hi, I'm an important person from Google which you can verify from my JID!, I want to give you 5 million dollars!"
  394. L29Ah ok seems like i need to replace my stringprep stuff with 7622 stuff
  395. Sam L29Ah: does stringprep normalize that to '/'? Yah, that seems like a potential place for serious bugs
  396. L29Ah yes it does
  397. nad200 has joined
  398. Kev Is this the point where I repeat my usual complaint that precis-based JIDs are broken? :)
  399. Sam Kev: in this case it appears to be the stringpep based JID that would break.
  400. Zash Does PRECIS fix this?
  401. Kev Sam: In the sense that there’s no upgrade path from stringprep to precis, and therefore they can’t be safely used on the same network unless they’re compatible, and if they were compatible (they’re not) there’d have been no reason to go to precis.
  402. Sam It just uses IDNA's toUnicode for domains, so yah I guess so. It seems bad that stringprep does more than that, because then you'd end up with domains that are valid but you can't use them for JIDs
  403. Sam But I haven't really looked, so that's assuming this is all true and not a bug in one of our libraries.
  404. Sam Kev: they're compatible enough in the real world. But yah, the upgrade path is tricky. If this is really true though, I'd say it's a huge reason to upgrade. stringprep not allowing valid domains in JIDs seems really bad
  405. Sam Anyways, back in a bit then I need to write some tests around this.
  406. Kev “They’re compatible enough in the real world” is exactly the point. People make that argument, but if it were actually true there’d be no reason to need to go to precis.
  407. L29Ah https://tools.ietf.org/html/rfc3491#section-4 yeah nameprep tells it gets normalized
  408. ben has left
  409. Kev We can’t both have the “stringprep is broken, we must precis” argument and the “but it doesn’t matter because they’re compatible in every way that matters” argument both being true :)
  410. Zash How about we just be very conservative with new usernames and stuff until we're all on PRECIS
  411. Kev Zash: With which unicode version?
  412. papatutuwawa has joined
  413. ajeremias has joined
  414. Zash ASCII!
  415. L29Ah screw that, i'll just sanitize stringprep output for @ and /, and tell that i'm done
  416. Kev AFAIK, you can’t safely mix unicode versions in XMPP (nor in JIDs), and you can’t safely mix precis and stringprep-based JIDs. But we pretend that you can, while pasting “This is fine” GIFs :)
  417. nad200 has left
  418. Sam Kev: I disagree. They're compatible in every way that matters, but stringprep is broken in a way that while it's not likely to be seen in the real world seems bad, but not because of its incompatibility with precis, because of its incompatibility with DNS.
  419. Sam I mean, don't get me wrong, we should come up with a graceful way to upgrade and handle the differences, I'm just saying that 90% of the time it actually is fine and stringprep is apparently broken in ways that have nothing to do with its incompatibilities with precis.
  420. Kev I don’t disagree that precis might be better, I just don’t see how we can be expecting everything to work nicely without upgrade paths.
  421. Sam Yah, we should come up with some of those.
  422. Sam It's just going to be hard to get anyone to do it because it will work well enough, so check your database, if there are no differences in any JID or JID that people are sending to: go ahead and upgrade. If there are, wait for an upgrade path.
  423. jonas’ step 0: find all JIDs in a database
  424. jonas’ that’s a challenge in and of itself
  425. fuana has left
  426. moparisthebest is your database the only one that matters? doesn't it break interop with everyone else too ?
  427. Zash I'm still thinking Be strict when creating local resources (users, rooms, nickname registrations...) Be relaxed with incoming data from other servers.
  428. moparisthebest kinda like if your email server can enforce authenticated TLS only just turn it on, and enjoy your no messages from anyone from that point forward :)
  429. Ge0rG Zash: 🤖 disagrees with that.
  430. Zash 🤖️ doesn't exist, it can't hurt you
  431. purplebeetroot has joined
  432. fuana has joined
  433. Kev It’s even wider than JIDs, actually (Unicode, rather than precis/stringprep).
  434. L29Ah okay, is "foo@bar:666/baz" a valid jid?
  435. Kev Even with message bodies, unicode version changes can break things.
  436. Kev Are those all the characters they look like?
  437. L29Ah
  438. Calvin has left
  439. Zash L29Ah, maybe but I don't like it
  440. Zash IIRC you're allowed to put port numbers in the domainpart, but I doubt it'll be reliable
  441. moparisthebest there's generally a wide difference between "what the spec allows" and "what you can actually use in practice"
  442. Zash L29Ah: `[db8::123:abc]` is a legal domainpart too, and that has `:` in it
  443. L29Ah Zash: oh, thanks
  444. Zash Not completely sure about port numbers
  445. moparisthebest I recall a poor lady named something like Mary O'Toole who's email was Mary.O'Toole@domain.org which is a perfectly valid email that most email systems refused to deliver mail to
  446. Zash not mentioned in 6122
  447. fuana has left
  448. Zash Don't mention email :(
  449. Kev I thought that port numbers weren’t allowed, but would have to scour specs that I don’t want to scour at teh moment.
  450. moparisthebest point being, it's the same in XMPP land, you can't use PRECIS for this reason
  451. L29Ah ok so i just strip / and @ from domainpart, and declare all jids with domainpart that normalizes to a string with those invalid, what do you think?
  452. L29Ah s/and/or/
  453. Andrzej has left
  454. Zash Sounds sensible
  455. Andrzej has joined
  456. mdosch has left
  457. mdosch has joined
  458. Andrzej has left
  459. Zash > Implementation Note: When dividing a JID into its component parts, an > implementation needs to match the separator characters '@' and '/' > before applying any transformation algorithms, which might decompose > certain Unicode code points to the separator characters.
  460. Zash ... but then nothing about what to do if that actually happens 🙁
  461. papatutuwawa has left
  462. flow L29Ah, so what's the lib in question. I only know quickcheck from haskell and there I know one XMPP lib
  463. flow L29Ah, so what's the lib in question? I only know quickcheck from haskell and there I know one XMPP lib
  464. purplebeetroot has left
  465. L29Ah flow: pontarius-xmpp
  466. flow I figured
  467. flow so is pontarius alive again?
  468. L29Ah no
  469. ajeremias has left
  470. L29Ah but i took over to keep pontarius-xmpp in shape and hopefully write a decent XMPP client someday
  471. flow well, you came here and ask the right questions, so I'd say you are on a good way ;)
  472. Andrzej has joined
  473. L29Ah at least now i have a replacement for the bitrotten sendxmpp: https://github.com/l29ah/hsendxmpp
  474. MattJ Everyone does
  475. L29Ah google failed me :(
  476. Zash It's slowly growing into the hello world of XMPP :D
  477. MattJ But everyone who doesn't continues to use the bitrotten version :)
  478. L29Ah bitrotten version stopped working for me
  479. MattJ We need to get some/all of them packaged in distros
  480. MattJ It stopped working for me a long time ago, and then I later heard it was active again (and/or there is a fork with the same name)
  481. L29Ah hsendxmpp is packaged in nixos :]
  482. LNJ has left
  483. L29Ah (as they package everything on hackage automatically)
  484. lovetox has left
  485. flow L29Ah, you may want to consider passing the password as command line argument
  486. L29Ah flow: i do
  487. flow L29Ah, you may want to consider not passing the password as command line argument
  488. L29Ah flow: i also do
  489. moparisthebest L29Ah, yet another https://crates.io/crates/sendxmpp
  490. moparisthebest so many sendxmpp's :P
  491. L29Ah For full functionality of this site it is necessary to enable JavaScript.
  492. moparisthebest ah sorry https://lib.rs/crates/sendxmpp there you go
  493. Sam Wow, there are a lot of these. I think Martin also maintains https://salsa.debian.org/mdosch/go-sendxmpp
  494. Sam And I vaguely remember a Python one a while ago too (though I don't remember if it was maintained)
  495. mdosch Yes, I once listed up those sendxmpps known to me there: https://wiki.ubuntuusers.de/Archiv/sendxmpp/#Alternativen
  496. mdosch German, but shouldn't be an issue in that case.
  497. moparisthebest Sam, that was https://github.com/moparisthebest/sendxmpp-py and supposedly it still works for some people but it quit working for me so I wrote the rust one and abandoned it
  498. Sam Oh yah, that's the one.
  499. flow am I to late for the party? https://github.com/Flowdalic/sendxmpp/blob/master/sendxmpp
  500. lovetox has joined
  501. Sam I've actually got one somewhere too (but it was just an example of using a library, not something I maintain or that's feature complete). More sendxmpps!
  502. floretta has joined
  503. MattJ Maybe we should list all these :)
  504. purplebeetroot has joined
  505. Zash I have an `sendxmpp-curl` that talks to a mod_post_msg I wrote for Prosody a million years ago
  506. pasdesushi has joined
  507. alacer has left
  508. fuana has joined
  509. ti_gj06 has left
  510. pasdesushi has left
  511. pasdesushi has joined
  512. pasdesushi has left
  513. pasdesushi has joined
  514. lskdjf has left
  515. lskdjf has joined
  516. sebastian > I have an `sendxmpp-curl` that talks to a mod_post_msg I wrote for Prosody a million years ago which works great by the way... i receive several dozen messages per day this way :-)
  517. fuana has left
  518. krauq has left
  519. lskdjf has left
  520. lskdjf has joined
  521. krauq has joined
  522. chronosx88 has left
  523. chronosx88 has joined
  524. LNJ has joined
  525. pasdesushi has left
  526. pasdesushi has joined
  527. pasdesushi has left
  528. pasdesushi has joined
  529. pasdesushi has left
  530. pasdesushi has joined
  531. pasdesushi has left
  532. alacer has joined
  533. pasdesushi has joined
  534. pasdesushi has left
  535. pasdesushi has joined
  536. pasdesushi has left
  537. purplebeetroot has left
  538. fuana has joined
  539. Andrzej has left
  540. xecks has left
  541. xecks has joined
  542. peetah has left
  543. peetah has joined
  544. wgreenhouse has joined
  545. ben has joined
  546. lovetox has left
  547. alameyo has left
  548. lovetox has joined
  549. L29Ah
  550. fuana has left
  551. mdosch 🕙
  552. L29Ah If the domainpart includes a final character considered to be a label separator (dot) by [IDNA2003] or [DNS], this character MUST be stripped from the domainpart before the JID of which it is a part is used for the purpose of routing an XML stanza, comparing against another JID, or constructing an [XMPP-URI]. In particular, the character MUST be stripped before any other canonicalization steps are taken, such as application of the [NAMEPREP] profile of [STRINGPREP] or completion of the ToASCII operation as described in [IDNA2003].
  553. Lance has joined
  554. Lance has left
  555. L29Ah so am i compliant if all the dots right before / in any jid are stripped?
  556. L29Ah at the end of domainpart, that is
  557. fuana has joined
  558. Andrzej has joined
  559. flow L29Ah, only the final dot
  560. marc has left
  561. pasdesushi has joined
  562. flow user@example.org is the same as user@example.org.
  563. Sam If there are multiple dots in a row I think that would just be an invalid domain label
  564. flow I think so too
  565. flow btw, this is not an xmpp specific thing, in fact all DNS names have a final dot, we just don't write it usually
  566. L29Ah flow: then it would strip an additional dot at each re-serialization
  567. fuana has left
  568. flow L29Ah, I think the jid should be rejected prior that
  569. flow so exmaple.org... would become example.org.. which hopefully your DNS library would reject as invalid DNS name
  570. pasdesushi has left
  571. L29Ah say i received the jid from a remote party
  572. ajeremias has joined
  573. Andrzej has left
  574. flow but the rules what constitutes a valid domainpart are blury in rfc 7622. I submitted an errata for that, basically you want to allow IPv4 and v6 addresses and DNS names consisting of U-labels in the domainpart
  575. flow but the rules what constitutes a valid domainpart are blurry in rfc 7622. I submitted an errata for that, basically you want to allow IPv4 and v6 addresses and DNS names consisting of U-labels in the domainpart
  576. L29Ah so i just can't handle ⒐ as a domain name in nameprep-based xmpp
  577. Andrzej has joined
  578. L29Ah time to look for PRECIS implementations it seems
  579. flow yes, I would suggest that. but ultimately the question is if ⒐ is valid in an U-label
  580. alacer has left
  581. alacer has joined
  582. L29Ah still, rfc7622 notes the same about dots, so i'll have to strip them all
  583. neshtaxmpp has left
  584. Paganini has left
  585. Zash Ah yes, the `blah..` edge case. Such fun.
  586. Zash Perhaps ".." should be rejected early, before you strip the last "."
  587. L29Ah what about ...?
  588. dwd L29Ah, What about what?
  589. Zash matches ..?
  590. dwd L29Ah, (I'm joking). A domain name is an array of labels, written as a single string with the labels separated by dots, and so if you encounter a zero-length label in a domain name anywhere but the end (where there is one implicitly) then it's an error.
  591. dwd L29Ah, But note it's not just '.', but other separators, like (I think) '·'.
  592. paul has left
  593. paul has joined
  594. Zash What about '·'‽
  595. fuana has joined
  596. marc has joined
  597. flow there a list somewhere™
  598. fuana has left
  599. flow https://github.com/MiniDNS/minidns/blob/ba0619d5404ee90096aa45c8c45c6a7ae26029b8/minidns-core/src/main/java/org/minidns/dnsname/DnsName.java#L59
  600. marc has left
  601. flow Zash, so the answer is "no"
  602. marc has joined
  603. andrey.g has joined
  604. Zash has left
  605. Zash has joined
  606. ajeremias has left
  607. marc has left
  608. L29Ah is there a normal form of domainpart?
  609. fuana has joined
  610. marc has joined
  611. fuana has left
  612. marc has left
  613. werdan has joined
  614. krauq has left
  615. krauq has joined
  616. fuana has joined
  617. neshtaxmpp has joined
  618. marc has joined
  619. marc has left
  620. marc has joined
  621. mathijs has left
  622. mathijs has joined
  623. marc has left
  624. pasdesushi has joined
  625. pasdesushi has left
  626. pasdesushi has joined
  627. croax has left
  628. croax has joined
  629. marc has joined
  630. marc has left
  631. marc has joined
  632. Paganini has joined
  633. pasdesushi has left
  634. fuana has left
  635. marc has left
  636. marc has joined
  637. papatutuwawa has joined
  638. BASSGOD has left
  639. millesimus has left
  640. BASSGOD has joined
  641. mathijs has left
  642. mathijs has joined
  643. pasdesushi has joined
  644. millesimus has joined
  645. menel has left
  646. menel has joined
  647. pasdesushi has left
  648. pasdesushi has joined
  649. ajeremias has joined
  650. purplebeetroot has joined
  651. flow L29Ah, no, which will probably hurt us in case of IPv6
  652. marc has left
  653. pasdesushi has left
  654. BASSGOD has left
  655. pasdesushi has joined
  656. BASSGOD has joined
  657. purplebeetroot has left
  658. Zash Isn't that nameprep?
  659. purplebeetroot has joined
  660. Zash DNS has that, and something something A vs U labels. IPv4 is easy, IPv6 has a canonical form too afaik.
  661. Zash But you don't encounter very many IP literals in the wild. Prosody didn't even support them at all until recently.
  662. pasdesushi has left
  663. pasdesushi has joined
  664. purplebeetroot has left
  665. purplebeetroot has joined
  666. ti_gj06 has joined
  667. Kev I had in my head that they weren’t valid for JIDs for some reason.
  668. papatutuwawa has left
  669. pasdesushi has left
  670. pasdesushi has joined
  671. BASSGOD has left
  672. flow Zash, I don't see no nameprep in rfc7622
  673. purplebeetroot has left
  674. pasdesushi has left
  675. pasdesushi has joined
  676. pasdesushi has left
  677. pasdesushi has joined
  678. fuana has joined
  679. BASSGOD has joined
  680. menel has left
  681. menel has joined
  682. Zash flow: well if you look at rfc7622 then you get to play rfc recursion from https://www.rfc-editor.org/rfc/rfc7622.html#section-3.2 and on
  683. Zash have fun!
  684. pasdesushi has left
  685. pasdesushi has joined
  686. pasdesushi has left
  687. pasdesushi has joined
  688. Wojtek has left
  689. Nekit has left
  690. flow Zash, not sure in which direction you want me to go
  691. flow can you point me to the next step after rfc7622 § 3.2
  692. flow can you point me to the next step after rfc7622 § 3.2 ?
  693. Zash No, sorry, don't wanna risk summoning back the headache that's been looming over my head today.
  694. marc has joined
  695. flow I guess my point is that there is not much to follow, besides probably U-Label
  696. flow but IIRC there is no normal form for U-labels
  697. Zash Aren't there a bunch of RFC links in the following sections?
  698. flow I think so
  699. flow but nothing I connect with domainparts (besides, you guessed it, U-labels)
  700. BASSGOD has left
  701. pasdesushi has left
  702. nad200 has joined
  703. Andrzej has left
  704. arc has left
  705. arc has joined
  706. Lance has joined
  707. Zash Convert to A-labels (that's the pure ASCII one, right?), lowercase. Done! 😀
  708. L29Ah This implies that the string MUST NOT include A-labels as defined in [RFC5890]; each A-label MUST be converted to a U-label during preparation of a string for inclusion in a domainpart slot.
  709. pasdesushi has joined
  710. karoshi has left
  711. flow L29Ah, that's a bit misleading
  712. flow XMPP domainparts should (IMHO) never contain A-labels
  713. flow they are always U-labels
  714. BASSGOD has joined
  715. flow domainparts that form a DNS name, consists of U-labels
  716. flow so that this is trying to say is: if you want to make a domainpart out of something that you know is an A-label, then transform it to an U-label prior creating the domainpart
  717. BASSGOD has left
  718. pasdesushi has left
  719. pasdesushi has joined
  720. karoshi has joined
  721. flow L29Ah, sorry, I somehow missed the 'NOT' in your statement
  722. arcxi has left
  723. arcxi has joined
  724. arcxi has left
  725. arcxi has joined
  726. Yagiza has left
  727. arcxi has left
  728. arcxi has joined
  729. ajeremias has left
  730. BASSGOD has joined
  731. arcxi has left
  732. arcxi has joined
  733. arcxi has left
  734. arcxi has joined
  735. fuana has left
  736. fuana has joined
  737. emus Tatsächlich finde ich jedoch einen Fork für eine Monal Android app garnicht so uninteressant 🤔️
  738. emus .
  739. marc has left
  740. LNJ has left
  741. pasdesushi has left
  742. pasdesushi has joined
  743. Kev has left
  744. Kev has joined
  745. BASSGOD has left
  746. alameyo has joined
  747. Kev has left
  748. Kev has joined
  749. papatutuwawa has joined
  750. arc has left
  751. arc has joined
  752. fuana has left
  753. fuana has joined
  754. papatutuwawa has left
  755. papatutuwawa has joined
  756. BASSGOD has joined
  757. Kev has left
  758. Kev has joined
  759. Kev has left
  760. Kev has joined
  761. chronosx88 has left
  762. wurstsalat has left
  763. wurstsalat has joined
  764. Andrzej has joined
  765. Andrzej has left
  766. Andrzej has joined
  767. nad200 has left
  768. pasdesushi has left
  769. pasdesushi has joined
  770. pasdesushi has left
  771. pasdesushi has joined
  772. pasdesushi has left
  773. pasdesushi has joined
  774. nad200 has joined
  775. arc has left
  776. arc has joined
  777. chronosx88 has joined
  778. LNJ has joined
  779. pasdesushi has left
  780. pasdesushi has joined
  781. pasdesushi has left
  782. pasdesushi has joined
  783. papatutuwawa has left
  784. Andrzej has left
  785. Andrzej has joined
  786. marc has joined
  787. papatutuwawa has joined
  788. BASSGOD has left
  789. raghavgururajan has left
  790. BASSGOD has joined
  791. werdan has left
  792. marc has left
  793. marc has joined
  794. werdan has joined
  795. fuana has left
  796. Maranda has left
  797. Maranda has joined
  798. Andrzej has left
  799. pasdesushi has left
  800. BASSGOD has left
  801. BASSGOD has joined
  802. aidalgol has joined
  803. fuana has joined
  804. marc has left
  805. marc has joined
  806. ti_gj06 has left
  807. BASSGOD has left
  808. BASSGOD has joined
  809. DebXWoody has left
  810. fuana has left
  811. nad200 has left
  812. pasdesushi has joined
  813. BASSGOD has left
  814. eevvoor has left
  815. werdan has left
  816. pasdesushi has left
  817. BASSGOD has joined
  818. fuana has joined
  819. Andrzej has joined
  820. DebXWoody has joined
  821. DebXWoody has left
  822. nad200 has joined
  823. chronosx88 has left
  824. Maranda has left
  825. Maranda has joined
  826. Andrzej has left
  827. bean has left
  828. marek has left
  829. chronosx88 has joined
  830. marc has left
  831. fuana has left
  832. flow L29Ah, FYI there is a cropus if valid/invalid JIDs at https://github.com/igniterealtime/jxmpp/tree/master/jxmpp-strings-testframework/src/main/resources/xmpp-strings/jids
  833. flow but be aware that it is not impossible that some strings are in the wrong category. I am happy about feedback and/or new suggestions
  834. Lance has left
  835. papatutuwawa has left
  836. DebXWoody has joined
  837. BASSGOD has left
  838. DebXWoody has left
  839. BASSGOD has joined
  840. Tobias has left
  841. flow has left
  842. bean has joined
  843. bean has left
  844. pasdesushi has joined
  845. andrey.g has left
  846. pasdesushi has left
  847. pasdesushi has joined
  848. nad200 has left
  849. pasdesushi has left
  850. pasdesushi has joined
  851. Andrzej has joined
  852. pasdesushi has left
  853. pasdesushi has joined
  854. bean has joined
  855. pasdesushi has left
  856. pasdesushi has joined
  857. pasdesushi has left
  858. pasdesushi has joined
  859. pasdesushi has left
  860. pasdesushi has joined
  861. Kev has left
  862. Kev has joined
  863. Andrzej has left
  864. pasdesushi has left
  865. pjn has left
  866. Andrzej has joined
  867. Seve has left
  868. raghavgururajan has joined
  869. bean has left
  870. Vaulor has left
  871. arc has left
  872. arc has joined
  873. pjn has joined
  874. arc has left
  875. Andrzej has left
  876. arc has joined
  877. arc has left
  878. arc has joined
  879. chronosx88 has left
  880. chronosx88 has joined
  881. andy has left
  882. BASSGOD has left
  883. fuana has joined
  884. BASSGOD has joined
  885. arc has left
  886. arc has joined
  887. ajeremias has joined
  888. arc has left
  889. arc has joined
  890. ajeremias has left
  891. ajeremias has joined
  892. BASSGOD has left
  893. croax has left
  894. stp has left
  895. ajeremias has left
  896. BASSGOD has joined
  897. arc has left
  898. arc has joined