XSF Discussion - 2019-09-09

  1. zach has left

  2. zach has joined

  3. pdurbin has joined

  4. neshtaxmpp has joined

  5. mukt2 has left

  6. pdurbin has left

  7. mukt2 has joined

  8. mukt2 has left

  9. mukt2 has joined

  10. UsL has left

  11. UsL has joined

  12. zach has left

  13. zach has joined

  14. mukt2 has left

  15. wurstsalat has left

  16. mukt2 has joined

  17. mukt2 has left

  18. aj has joined

  19. krauq has left

  20. krauq has joined

  21. Zash has left

  22. mukt2 has joined

  23. mukt2 has left

  24. mukt2 has joined

  25. matkor has left

  26. Chobbes has joined

  27. mukt2 has left

  28. neshtaxmpp has left

  29. neshtaxmpp has joined

  30. matkor has joined

  31. mukt2 has joined

  32. Chobbes has left

  33. mukt2 has left

  34. Douglas Terabyte has left

  35. Douglas Terabyte has joined

  36. kokonoe has left

  37. kokonoe has joined

  38. pdurbin has joined

  39. lskdjf has left

  40. pdurbin has left

  41. j.r has left

  42. j.r has joined

  43. mukt2 has joined

  44. ths has left

  45. ths has joined

  46. mukt2 has left

  47. zach has left

  48. zach has joined

  49. adiaholic has joined

  50. mukt2 has joined

  51. mukt2 has left

  52. mukt2 has joined

  53. Yagiza has joined

  54. mukt2 has left

  55. mukt2 has joined

  56. Maranda has left

  57. Maranda has joined

  58. zach has left

  59. zach has joined

  60. mimi89999 has left

  61. mimi89999 has joined

  62. mukt2 has left

  63. Tobias has joined

  64. mukt2 has joined

  65. mukt2 has left

  66. pdurbin has joined

  67. mukt2 has joined

  68. ths has left

  69. matkor has left

  70. matkor has joined

  71. ths has joined

  72. zach has left

  73. zach has joined

  74. j.r has left

  75. j.r has joined

  76. Maranda has left

  77. Maranda has joined

  78. zach has left

  79. zach has joined

  80. karoshi has joined

  81. Maranda has left

  82. pdurbin has left

  83. pdurbin has joined

  84. zach has left

  85. zach has joined

  86. winfried has left

  87. winfried has joined

  88. mukt2 has left

  89. mukt2 has joined

  90. zach has left

  91. zach has joined

  92. goffi has joined

  93. neshtaxmpp has left

  94. winfried has left

  95. winfried has joined

  96. zach has left

  97. zach has joined

  98. UsL has left

  99. LNJ has joined

  100. zach has left

  101. zach has joined

  102. winfried has left

  103. winfried has joined

  104. UsL has joined

  105. winfried has left

  106. winfried has joined

  107. debacle has joined

  108. jabberjocke has joined

  109. zach has left

  110. zach has joined

  111. mukt2 has left

  112. waqas has left

  113. mukt2 has joined

  114. Guus

    > any of our france friends here in contact with the person? Flow, the person that took over the project got in touch with us, to get it listed at the website again.

  115. Guus


  116. Maranda has joined

  117. Ge0rG

    This is frightening.

  118. Ge0rG

    Admittedly, the README is not the first place to change when resurrecting a new project.

  119. Steve Kille has left

  120. Daniel

    What is that the left overs of that Google thing?

  121. Daniel


  122. Daniel can't be bothered to follow the link

  123. jonas’

    Daniel, it’s an xmppd

  124. Steve Kille has joined

  125. mukt2 has left

  126. Mikaela has joined

  127. mukt2 has joined

  128. zach has left

  129. winfried has left

  130. winfried has joined

  131. zach has joined

  132. Zash has joined

  133. winfried has left

  134. winfried has joined

  135. jubalh has joined

  136. winfried has left

  137. winfried has joined

  138. mukt2 has left

  139. Zash has left

  140. Nekit has joined

  141. linkmauve has joined

  142. zach has left

  143. zach has joined

  144. mukt2 has joined

  145. mukt2 has left

  146. Dele (Mobile) has joined

  147. Dele (Mobile) has left

  148. Dele (Mobile) has joined

  149. mukt2 has joined

  150. zach has left

  151. zach has joined

  152. debacle has left

  153. Zash has joined

  154. mukt2 has left

  155. wurstsalat has joined

  156. mukt2 has joined

  157. mukt2 has left

  158. lumi has joined

  159. zach has left

  160. zach has joined

  161. mukt2 has joined

  162. mukt2 has left

  163. madhur.garg has left

  164. kokonoe has left

  165. mukt2 has joined

  166. kokonoe has joined

  167. kokonoe has left

  168. kokonoe has joined

  169. kokonoe has left

  170. Douglas Terabyte has left

  171. Douglas Terabyte has joined

  172. mukt2 has left

  173. kokonoe has joined

  174. kokonoe has left

  175. zach has left

  176. zach has joined

  177. debacle has joined

  178. mimi89999 has left

  179. larma has left

  180. zach has left

  181. zach has joined

  182. Nekit has left

  183. larma has joined

  184. Nekit has joined

  185. j.r has left

  186. mukt2 has joined

  187. jubalh has left

  188. jubalh has joined

  189. mukt2 has left

  190. mimi89999 has joined

  191. zach has left

  192. zach has joined

  193. goffi has left

  194. goffi has joined

  195. marc_ has joined

  196. LNJ has left

  197. zach has left

  198. zach has joined

  199. pdurbin has left

  200. mukt2 has joined

  201. jabberjocke has left

  202. UsL has left

  203. marc_ has left

  204. marc_ has joined

  205. goffi has left

  206. mukt2 has left

  207. lovetox_ has joined

  208. adiaholic has left

  209. adiaholic has joined

  210. jabberjocke has joined

  211. mukt2 has joined

  212. j.r has joined

  213. karoshi has left

  214. karoshi has joined

  215. mukt2 has left

  216. adiaholic has left

  217. zach has left

  218. zach has joined

  219. mukt2 has joined

  220. zach has left

  221. zach has joined

  222. Nekit has left

  223. mukt2 has left

  224. mukt2 has joined

  225. lskdjf has joined

  226. Nekit has joined

  227. lskdjf has left

  228. winfried has left

  229. ralphm


  230. ralphm


  231. jonas’

    fasten your seatbelts

  232. ralphm


  233. winfried has joined

  234. ralphm

    It is a long piece based on recent discussions and took me more time than I anticipated. Plenty examples!

  235. lskdjf has joined

  236. winfried has left

  237. winfried has joined

  238. mukt2 has left

  239. zach has left

  240. zach has joined

  241. jabberjocke has left

  242. UsL has joined

  243. flow

    +1 for examples

  244. ralphm


  245. winfried has left

  246. winfried has joined

  247. mukt2 has joined

  248. jabberjocke has joined

  249. jabberjocke has left

  250. pdurbin has joined

  251. winfried has left

  252. winfried has joined

  253. winfried has left

  254. winfried has joined

  255. remko has joined

  256. zach has left

  257. zach has joined

  258. winfried has left

  259. winfried has joined

  260. Chobbes has joined

  261. jabberjocke has joined

  262. mukt2 has left

  263. pdurbin has left

  264. zach has left

  265. zach has joined

  266. winfried has left

  267. winfried has joined

  268. mukt2 has joined

  269. Chobbes has left

  270. Chobbes has joined

  271. winfried has left

  272. Chobbes has left

  273. Chobbes has joined

  274. mukt2 has left

  275. mukt2 has joined

  276. winfried has joined

  277. alameyo has left

  278. alameyo has joined

  279. remko has left

  280. zach has left

  281. zach has joined

  282. wurstsalat

    ralphm: thank you for taking the time to write this up (also +1 for :parrot:)

  283. ralphm

    wurstsalat: you're welcome!

  284. mukt2 has left

  285. winfried has left

  286. winfried has joined

  287. pep.

    It's funny because I was taking part in a discussion this morning about XMPP in general on a Japanese channel, and they were saying it's not easy to get people off LINE (which is the defacto whatsapp-like app there), whereas here in our european (XSF?) circles, most of the time I hear about Slack, twitter etc.

  288. mukt2 has joined

  289. pep.

    Reading your article made me think of that

  290. Chobbes has left

  291. ralphm

    Sure. Another example is WeChat, but I think most of my audience is from the so-called Western world.

  292. ralphm

    I also forgot to mention Facebook Templates.

  293. remko has joined

  294. pep.

    <mention jid="room@muc.this.example/ralphm"/> btw, what about occupant-id?

  295. zach has left

  296. zach has joined

  297. ralphm

    You mean making it more explicit what kind of jid is referred to?

  298. pep.

    no I mean https://xmpp.org/extensions/xep-0421.html

  299. Yagiza has left

  300. pep.

    It'd be nice if that was also allowed in there

  301. Yagiza has joined

  302. pep.

    Not especially mandated

  303. Yagiza has left

  304. pep.

    I know some people will oppose the de-pseudonymisation

  305. Yagiza has joined

  306. pep.

    Also what do people have with this "@" :x

  307. pep.

    Quite annoying to see this on the wire everywhere

  308. ralphm

    I'm not sure, I haven't read that in detail.

  309. ralphm

    Also curious how it'd be different in MIX

  310. adiaholic has joined

  311. MattJ

    pep., that's why the "proxy JIDs for MUC" idea would be slightly better, since it's a drop-in replacement for a real JID

  312. ralphm

    pep.: I don't see a problem with @. It would be something people type and a client could choose to strip it with references.

  313. pep.

    MattJ, yeah.. I see that

  314. MattJ

    Nobody (generally) has to know what kind of JID it is, it's just a JID

  315. ralphm

    MattJ: right, and for the rest there is disco

  316. pep.

    ralphm, I see a problem with @, why would we even bother to have a <reference/><mention/> tag otherwise? Why not just put @ralphm in there and let the receiving client deal with it

  317. pep.

    Client SHOULD NOT include any marker in the body for this

  318. pep.

    There is no point

  319. pep.

    On the wire, that is

  320. ralphm

    It could, but the thing prefixed by @ can be interpreted by a server. Maybe it has a nick registration service and allows for referencing non-accupants.

  321. pep.

    Maybe then the service can also read <reference/> instead

  322. pep.

    I'm going to start including @s everywhere just to make fun of that service

  323. ralphm

    My examples show that the original didn't have a reference

  324. pep.

    It's about the same crap idea as 393.

  325. ralphm

    Let's agree to disagree on this point.

  326. pep.

    You agree that this is a character that carries meaning, no?

  327. pep.

    I mean essentially that's the goal

  328. ralphm

    By the way, the @ might also serve as an explicit marker to notify whoever is mentioned, as apposed to unprefixed strings that happen to also be a nick. Like someone having a nick 'nick'.

  329. pep.

    That can be done in the input format yes

  330. pep.

    Doesn't have to be on the wire, again.

  331. ralphm

    My vantage point is a thin(ner) client

  332. ralphm

    And not touching what the user typed

  333. pep.

    What about them? They shouldn't have to care about semantics and throw everything in body because?

  334. pep.

    Why do we even bother with <reference>, somebody remind me please

  335. ralphm

    Or XMPP

  336. pep.

    Or XMPP

  337. rion has left

  338. pep.

    Let's not take Slack as an exemple, it's an implementation not a protocol, and it doesn't try to be compatible with anything else

  339. ralphm

    I think it is useful, you may disagree, and the post shoes how it could be done.

  340. pep.

    Of course references are useful. I was saying that because of your loose use of "@"

  341. ralphm

    I do take Slack as an example, as it is done well and we can learn from it.

  342. ralphm

    So @pep. if you don't like @'s, I am not sure what to do about it.

  343. pep.


  344. pep.

    I don't like the meaning you attach to it

  345. pep.

    On the wire

  346. ralphm

    I didn't. It is something somebody typed and the MUC service then interpreted it as a mention. Has nothing to do with the wire protocol.

  347. pep.

    "Here the MUC service marks up the original messages with an explicit link reference." wait

  348. pep.

    Yes I just read that

  349. Chobbes has joined

  350. pep.

    That's even more awful than I thought

  351. mukt2 has left

  352. Chobbes has left

  353. Chobbes has joined

  354. pep.

    So yes you did

  355. pep.


  356. ralphm

    I'm sorry I broke your world. I'm a terrible person.

  357. pep.

    I'm actually amazed you are seriously considering this

  358. pep.

    To put it as an exemple

  359. ralphm

    Seriously, this is exactly how existing services do things. It is not something*I* invented.

  360. zach has left

  361. zach has joined

  362. pep.

    services like? Slack?

  363. Kev

    It's not even an example ralphm wrote, it came from my gist. I think getting caught up on what hypothetical service the example shows isn't the right thing here.

  364. pep.

    Kev, it's just that I see this coming back often

  365. jonas’

    ralphm, I’ll dump a bunch of random thoughts on your article on-list

  366. jonas’

    I can’t follow xsf@ right now

  367. remko has left

  368. Kev

    @pep: Because it's something easy to understand for examples.

  369. ralphm

    Also Twitter, as mentioned at the top of my post.

  370. ralphm

    I think WeChat, as well. WhatsApp, Facebook, etc.

  371. pep.

    ralphm, yes and as I said, they're not interoperable protocols, they don't care. they don't especially have to account for let's say, offline users that the MUC doesn't know about anymore (how would it know it has to have a reference there?) etc.

  372. pep.

    Or for me using @ in a totally different way

  373. pep.

    The UX in these product is particularly annoying when you just want to use @ and not highlight anybody

  374. pep.

    The UX in these products is particularly annoying when you just want to use @ and not highlight anybody

  375. pep.

    But I guess that's a UI issue anyway, for this last message

  376. pep.

    They still could do that and not include it on the wire

  377. pep.

    Kev, also my nick is "pep." :)

  378. pep.

    But I guess you can't autocomplete anymore with the @ in front :p

  379. ralphm

    Well, MUC's model is rather dated, and I think we need to move on from it. I think MIX solves a bunch of that, and I always try to look ahead, while learning from others. For this I don't care about how Evil those other entities or solutions are. Something like an @-mention is near ubiquitous outside our little bubble and I think the least-surprise angle works in its favour.

  380. rion has joined

  381. mukt2 has joined

  382. pep.

    I'm going to repeat myself: That doesn't mean it has to be on the wire.

  383. pep.

    That's my only concern

  384. ralphm

    Really, it is just something somebody typed.

  385. Kev


  386. pep.

    With an associated meaning to it

  387. pep.

    No it's not just an example.

  388. pep.

    It's definitely not the first time I see it. I even mentioned it last time when there was this references discussion.

  389. ralphm

    If you don't want your service to interpret @ signs, hack it to oblivion.

  390. pep.

    Of course I don't, why would I. My service could interpret <references> very well though

  391. ralphm


  392. ralphm

    Do you have any other insights?

  393. pep.


  394. pep.


  395. jonas’

    sent my feedback on the list

  396. zach has left

  397. zach has joined

  398. ralphm

    Cool. Thanks!

  399. ralphm

    Also, I am a bit done with negative attitudes.

  400. ralphm

    So, sorry if I was a bit harsh, pep.

  401. mukt2 has left

  402. jonas’

    I’m gonna re-state it publicly: Thanks for taking the time for the blog post, I think it’s very valuable. My mail on-list is concise and short to save everyones time, but there needs to be time for praise for work done, ralphm.

  403. ralphm


  404. Ge0rG

    ralphm: thanks for taking the time and moving things forward!

  405. pep.

    fwiw I have not much to say about references in the article, that looks good.

  406. ralphm


  407. pep.

    I know some people were not particularly fond of the mandatory <reference> for SIMS, but in this case it makes sense to me. I guess having SIMS being used instead of oob as it currently is could not require it, though?

  408. ralphm

    Yeah, my thing with oob is that it is very unspecific.

  409. pep.

    Sure. I'm talking about SIMS specifically, I'm not fond of the current practice

  410. pep.

    (with oob)

  411. ralphm

    Using a jingle file allows for thumbnails and hash references and titles and descriptions, etc.

  412. ralphm

    I suppose you could also have a naked one, without body and without the references wrapper

  413. ralphm

    If you just wanted to send a picture

  414. mukt2 has joined

  415. pep.

    Yeah, that's a concern I've heard multiple times

  416. Ge0rG

    ralphm: this is a major use case

  417. pep.

    Re Jingle, there's no URI format atm right?

  418. pep.

    Or is there?

  419. Zash

    ralphm, do you by any chance have a source format for that post publicly anywhere?

  420. zach has left

  421. zach has joined

  422. j.r has left

  423. j.r has joined

  424. pdurbin has joined

  425. andy has left

  426. andy has joined

  427. adiaholic has left

  428. adiaholic has joined

  429. pdurbin has left

  430. UsL has left

  431. Yagiza has left

  432. Yagiza has joined

  433. j.r has left

  434. j.r has joined

  435. zach has left

  436. zach has joined

  437. marc_ has left

  438. marc_ has joined

  439. jabberjocke has left

  440. zach has left

  441. zach has joined

  442. j.r has left

  443. ralphm

    Zash: not automatically, no. But I uploaded the source for this post here: https://ralphm.net/~ralphm/tmp/2019-09.xml. I hope you can appreciate it.

  444. Ge0rG

    let's bikeshed about the use of XML as a source format!

  445. ralphm

    Not just any XML format. It is actually very much derived from DocBook XML

  446. Zash

    In this case it doesn't reduce the effort in turning it into epub

  447. Zash

    DocBook enough that pandoc can read it?

  448. ralphm

    It does. You can use pandoc with docbook as input format

  449. ralphm

    But you'd have to fix the custom additions

  450. Ge0rG recently successfully converted a PDF ebook into epub, and even was able to remove the nasty-watermark-on-each-pdf-page with sed.

  451. remko has joined

  452. adiaholic has left

  453. adiaholic has joined

  454. lovetox_ has left

  455. zach has left

  456. zach has joined

  457. patrick has joined

  458. winfried has left

  459. winfried has joined

  460. adiaholic has left

  461. adiaholic has joined

  462. winfried has left

  463. winfried has joined

  464. Chobbes has left

  465. Chobbes has joined

  466. adiaholic has left

  467. zach has left

  468. zach has joined

  469. alameyo has left

  470. Chobbes has left

  471. Chobbes has joined

  472. jubalh has left

  473. aj has left

  474. mukt2 has left

  475. mukt2 has joined

  476. zach has left

  477. zach has joined

  478. Chobbes has left

  479. Chobbes has joined

  480. mukt2 has left

  481. ؜ has joined

  482. Neustradamus has left

  483. Tobias has left

  484. mukt2 has joined

  485. stpeter has joined

  486. stpeter has left

  487. peter has joined

  488. peter has left

  489. ؜

    ralphm, hi, someone friendly has linked me your post on @mentions. i remember a certain discussion in the gajim chatroom >10 years ago. gajim at the time was highlighting the user if any part of a message contained the user's nickname (iirc). so if someone had a nickname of "kate", someone typing "skateboarding" would trip the highlight. gajim changed that to match a fixed word (iirc it was '\bkate\b'), and then people started complaining that declension happens (e.g. "kate's"). do you think you could make @mentions somehow work with that?

  490. Dele (Mobile) has left

  491. jonas’

    what the

  492. ؜

    oh, hi jonas!

  493. pep.

    jonas’, indeed

  494. ralphm

    jonas’: you scared from my log source?

  495. Ge0rG

    what are you, a RTL modifier?

  496. jonas’

    ؜, noone will read what you wrote. your nickname is empty, that baffles everyone

  497. ؜

    that would be impolite… 😛

  498. zach has left

  499. zach has joined

  500. Ge0rG

    jonas’: looks like it's actually http://www.fileformat.info/info/unicode/char/00061C/index.htm

  501. ralphm

    I don't see anything, nor do our logs? http://logs.xmpp.org/xsf/2019-09-09

  502. pep.

    Yeah, conversations also seem to ignore it :)

  503. jonas’

    ralphm, https://sotecware.net/images/dont-puush-me/NUWuPgMbAgbvAn1d8N7yi2ohr4zvDuzpIFANrw5I8_I.png

  504. jonas’

    ؜, look at this, they can’t even read what you’re writing

  505. pep.

    jonas’, I'd want to say "our tools are broken"? :x

  506. ؜

    oh. i should have seen that coming

  507. Ge0rG


  508. pep.

    They should be refused by the muc

  509. jonas’

    they should

  510. jonas’

    if only we had our stuff pinned to a single version of Unicode

  511. Ge0rG

    jonas’: nice how your text is RTL formatted :P

  512. jonas’

    if only we had our stuff pinned to a single version of Unicode everyone agrees on

  513. jonas’


  514. patrick has left

  515. Ge0rG

    pasting cropped yaxim screenshots into yaxim makes my head spin

  516. Zash


  517. pdurbin has joined

  518. ralphm

    Yup, Conversations gives up on this. Nameless RTL person, I read your message through the screenshot above, but your unique setup triggers bugs in several clients and will make discussion very hard. If you can it might be good to write a reply on the standards@xmpp.org mailing list.

  519. Ge0rG

    ralphm: triggering bugs in implementations is actually a Good Thing™

  520. pep.

    Zash, so logs ignore it but MUC lets it pass?

  521. pep.

    how come

  522. Zash


  523. ralphm

    Well yes, it is surely a nice test case

  524. Lance has joined

  525. Ge0rG

    pep.: I've actually copy&pasted it from the http log

  526. MattJ

    pep., it's in the logs

  527. pep.


  528. Ge0rG

    pep.: it's just.... _invisible_!

  529. pep.

    Sorry I was reading ralphm above who said it wasn't

  530. pep.

    I see

  531. MattJ

    Though it might not look that way, since there is no nick rendered

  532. ralphm

    Ah, I see now

  533. mukt2 has left

  534. linkmauve

    I can read it in the logs just fine.

  535. Ge0rG

    linkmauve: you can read it?

  536. MattJ

    Nice way to make the logs look like someone said something they didn't

  537. ؜ has left

  538. pep.


  539. Nameless RTL person

    my job here is done, i guess

  540. ralphm

    Nameless RTL person: haha

  541. Ge0rG

    Nameless RTL person: please meet my friend, 🤖

  542. linkmauve

    Ge0rG, yes, it’s present in the logs.

  543. Ge0rG

    linkmauve: that's not what you said

  544. linkmauve

    I can read it there.

  545. Nameless RTL person

    i remember pasting 4MB of text into a status message and crashing all the psi clients out there. that was fun

  546. Ge0rG

    linkmauve: how can you read it if it's invisible?

  547. linkmauve

    Ge0rG, it isn’t though.

  548. Ge0rG

    linkmauve: I'm speechless.

  549. ralphm

    xmpp:xlwj4vdisilfdp2r@anon.xmpp.org nice

  550. pdurbin has left

  551. alameyo has joined

  552. linkmauve


  553. linkmauve

    Ge0rG, ↑

  554. Ge0rG

    linkmauve: so you can read *them*, not *it*.

  555. ralphm

    Nameless RTL person: in any case, there's differing opinions on whether a MUC service should do such interpretation. I do think that an explicit marker in front of the mention, whether processed at the client or by a service, helps disambiguation.

  556. Nameless RTL person

    i assume it's not an important matter whether the @marker works for some unusual nicknames, either?

  557. Zash

    Why doesn't resourceprep normalize eat it, whatever it is?

  558. Ge0rG


  559. remko has left

  560. ralphm

    Nameless RTL person: like RTL markers?

  561. Nameless RTL person


  562. Nameless RTL person

    or, let's make it simpler, spaces in nicknames

  563. zach has left

  564. zach has joined

  565. adiaholic has joined

  566. LNJ has joined

  567. Nameless RTL person

    or one of my favorites: combining characters vs. precombined characters, typed by different people in different way

  568. david has left

  569. remko has joined

  570. Zash

    Pretty sure those are normalized at least

  571. Nameless RTL person

    within message bodies too?

  572. Daniel

    Zash: not if you let the muc server do the mention

  573. Daniel

    Which is the point Nameless RTL person is trying to make I guess

  574. Zash

    Myeah I don't believe in that

  575. DebXWoody has left

  576. david has joined

  577. DebXWoody has joined

  578. Daniel

    However I see ralphm blog post only as an example for references

  579. ralphm

    I assume existing implementationa just do prefix matching as main heuristic. And give up with"weird" stuff like RTL markers.

  580. Daniel

    Not as a general recommendation that all mentions should be server side

  581. ralphm

    No, indeed

  582. adiaholic has left

  583. adiaholic has joined

  584. APach has left

  585. ralphm

    Having followed Slack for quite a while, I believe they initially did server side mentions (only) and then added client side support.

  586. APach has joined

  587. Zash

    Converse.js does something

  588. pep.

    Indeed. It uses <references type='mention'/> and strips the "@"

  589. ralphm

    My mail to standards@ shows the alternative (for links, but would work for mentions just as well).

  590. mukt2 has joined

  591. linkmauve has left

  592. Link Mauve has joined

  593. j.r has joined

  594. ralphm

    I still think that typing an @, v.s. not, has an implicit request for notifying the mentioned individual. I wonder if that should trigger explicit server side notification, rather than client side highlighting, esp. with offline mobile clients and Push.

  595. pep.

    ralphm, note that I never disagreed on this ^

  596. Daniel

    ralphm: your muc push could also parse the reference (instead of jumping on the @)

  597. Lance has left

  598. Nameless RTL person

    tbh, i'd feel uneasy if someone used my nickname and i wasn't highlighed, whether there was an @ character before my nickname or not

  599. Nameless RTL person

    it would feel as if someone talked behind my back

  600. Zash

    Nickname registration in MUC is a thing

  601. Zash

    Oh, nm

  602. ralphm

    Daniel: I mean that if you have a client side generated mention, the server could explicitly notify / wake up the recipient. Maybe with a special out-of-band message.

  603. ralphm

    By the way, example 2019-09-02-3 shows client side mention.

  604. ralphm

    Nameless RTL person: services like Slack let you get notified for user defined keywords.

  605. ralphm

    I usually set that up with my nick, name, and 'xmpp'.

  606. pep.

    Nameless RTL person, your client could very well get over this and _also_ highlight you if you so chose, by parsing body. But that's a choice of the receiving client, and I'm fine with that

  607. Nameless RTL person

    so do xmpp clients. but in the xmpp world you may have different nicknames in different chatrooms, etc.

  608. Nameless RTL person

    so the client must be smart enough to allow different hl words for different chatrooms

  609. murabito has left

  610. mukt2 has left

  611. murabito has joined

  612. Nameless RTL person

    and then the pain is on user to manually configure it

  613. Daniel

    And that's why we can't have nice things

  614. ralphm


  615. ralphm

    I like that in MIX, much like Slack, is decoupled from the (proxy) JID.

  616. mukt2 has joined

  617. Nameless RTL person

    is this place using mix?

  618. ralphm

    I think that especially for group services like those hosted by the XSF, service wide nick registration would be a good thing.

  619. ralphm

    Nameless RTL person: no

  620. zach has left

  621. zach has joined

  622. remko has left

  623. Nameless RTL person

    still, thanks to federation, even with registration, the nicknames can be different within a single client's opened chat windows

  624. ralphm

    Yes, for sure

  625. adiaholic has left

  626. ralphm

    But highlighting $current_nick should be easy.

  627. ralphm

    And separate from that server-assisted notification would be a thing that could be implemented.

  628. Nameless RTL person

    yeah. so if the receiver client's already implementing it, why bother with the server doing it too?

  629. ralphm

    Your client might be offline (Doze mode or iOS equivalent). Having server support for this allows for waking up such clients.

  630. Nameless RTL person

    but if it's a custom highlight word, it won't

  631. Nameless RTL person


  632. ralphm

    Especially in the context of MIX, where you are always in the room, even though you have no active resources.

  633. ralphm

    Nameless RTL person: you could register custom highlights with your server.

  634. matkor has left

  635. ralphm

    And finally, if you get mentioned in rooms you're not in.

  636. Nameless RTL person

    ok, that would be nice if there was a subprotocol for that

  637. ralphm

    Nameless RTL person: let's say I've thought about this stuff for a while

  638. Nameless RTL person

    i guessed so, this blog post is quite thoughtful

  639. Nameless RTL person

    in essence, you'd like to move more of muc complexity onto the server. that's something i can empathize with

  640. Nameless RTL person

    however, having the api between the thin client and the server be a plaintext api, as opposed to xml, feels wrong in the context of xmpp…

  641. ralphm

    Well, not just for MUCs. In fact, I think we've come to a point where we need a lot more server involvement to match functionally in other services. That's why I believe something like MIX is better equipped for that world. Another topic is voice/video calls.

  642. Nameless RTL person

    moreover, a plaintext api which the user types themselves, making it more difficult to provide a different type of ux than just a text field, if it's desirable within the client's requirements

  643. ralphm

    Nameless RTL person: sure, having clients mark up stuff is very useful

  644. zach has left

  645. zach has joined

  646. ralphm

    But the example of link references shows the two extremes. When mentioning a URL, do you want your client to go and fetch the page, scan for meta tags, craft a format for representaion, and only then send it (or maybe later as self-fastening) or let the server do that for you?

  647. Nameless RTL person

    even more, a plaintext api which is not discoverable by the client. or are you going to make it discoverable whether mix/muc adds annotations automatically or not?

  648. ralphm

    I would definitely, yes. With opt-in/out for your own messages.

  649. Nameless RTL person

    maybe. if i know that the mix/muc itself can't access the site i link, and my thick client can, then i would do so

  650. ralphm

    Nameless RTL person: yes, you could still, or course. It is not an exclusive choice.

  651. adiaholic has joined

  652. Ge0rG

    Configurability everywhere!

  653. ralphm

    But having worked on a (closed) XMPP platform, putting it in the server makes it a lot easier.

  654. ralphm

    If you then have thick clients, you see them already having marked up things and leave it alone.

  655. Ge0rG

    If your options don't have options, you're doing it wrong!

  656. Steve Kille has left

  657. Nameless RTL person

    to me it slowly starts looking like privacy lists, but i'm fine with that

  658. Chobbes has left

  659. ralphm

    Nameless RTL person: privacy lists were hard because it made routing expensive. I think this kind of thing is different.

  660. Nameless RTL person

    so, let say, my thick client, when connecting to a mix/muc, could say "i can do references alone, please don't mess with my messages", and my thin client could say "help me, mix/muc, you're my only hope". a per-session setting would look nice, i guess

  661. ralphm

    I'd probably use a disco feature for it.

  662. Nameless RTL person

    who'd disco whom?

  663. ralphm

    The room/service would disco you

  664. ralphm

    It does so anyway

  665. Nameless RTL person

    the only worry at this point would be the observable inconsistencies in behavior between messages from different clients. but xmpp users should all be used to that anyway, i guess

  666. Nameless RTL person

    i see

  667. ralphm

    I switch between desktop and mobile all the time

  668. Steve Kille has joined

  669. Chobbes has joined

  670. Nameless RTL person

    ok. would that work in 1-1 chats too?

  671. Nameless RTL person

    the job of implementing the annotations would have to be shared between the mix/muc implementation and the, i don't know how it's called… core server?

  672. ralphm

    I don't see why your own server couldn't mark up stuff for you

  673. Nameless RTL person

    would the recipient's server mark things up if the sender's server didn't?

  674. ralphm

    (if you want that)

  675. ralphm

    I'm not sure. In MUC, there is a separate entity in the conversation, from which annotations could come.

  676. ralphm

    In 1-on-1, you don't have that, so I'd expect only my own server touching my messages and sending them from my bare JID.

  677. pep.

    Validations the source jid for references won't be a requirement?

  678. pep.


  679. pep.

    Though MUCs can also impersonate you if they want to..

  680. Nameless RTL person

    right, this third-party annotator service would have to be trusted

  681. ralphm

    pep.: access control is definitely a thing, and feature dependent

  682. pep.


  683. ralphm

    E.g. reactions can come from anyone. Edits not so much.

  684. ralphm

    An alternative is not actually having one-on-ones, but all your conversations as rooms. I think BuddyCloud did this, as does Slack.

  685. zach has left

  686. zach has joined

  687. Nekit has left

  688. Nekit has joined

  689. ralphm

    This also allows for smart bots that suggest movie times when you mention The Lion King.

  690. ralphm

    And yes this is invasive, but there's a value proposition there.

  691. adiaholic has left

  692. adiaholic has joined

  693. Nameless RTL person

    i guess i wouldn't mind. my primary client does that anyway, mostly

  694. matkor has joined

  695. ralphm

    Sure. I think there's a limit to what you want to stuff in your server, though.

  696. Chobbes has left

  697. ralphm

    But maybe a model where everyone runs their own server is compelling in the long run.

  698. Nameless RTL person

    serverless messaging isn't used anyway, i think

  699. Nameless RTL person

    the last time i tried doing so, i got enough spam to leave the xmpp world for close to ten years

  700. ralphm


  701. ralphm

    The thing is, if you don't trust your server, there are suddenly a lot of things you can't do.

  702. Nameless RTL person

    i want to trust the server in the capacity of routing messages correctly, not much more than that

  703. Zash


  704. Nameless RTL person

    hi Zash!

  705. jubalh has joined

  706. ralphm

    Take those emoji reactions. If all the exchanges have e2ee, you can't do summaries efficiently.

  707. ralphm

    (in MAM)

  708. Link Mauve has left

  709. Nameless RTL person

    my perfect setup would be a server whose only job is to route messages within a federated network, a thick "xmpp client" set up on my private always-on account somewhere, and a thin non-xmpp client connecting to that thick client and only do UX

  710. ralphm

    Hm. I'd probably shift the thick bits to the server and just use thin clients.

  711. Nameless RTL person

    a bit like irc server/irc bouncer/irc client setup used to be popular

  712. ralphm

    Even for annotations, by server could intercept outgoing messages and send extra stanzas.

  713. Link Mauve has joined

  714. Nekit has left

  715. Nameless RTL person

    the bouncer part would implement the hard bits of the client, like maybe encryption, annotation, etc. and would run either on my local machine, or somewhere in the cloud under my control.

  716. winfried has left

  717. winfried has joined

  718. ralphm

    I have at some played with the idea of bare-account-jid-components

  719. winfried has left

  720. winfried has joined

  721. ralphm

    Which is mostly that

  722. Nameless RTL person

    and if we could deal away with JIDs used as personalities, that'd be perfect. they're good for routing, but not much more than that in my opinion

  723. ralphm

    A special client connection that doesn't bind a resource and can manipulate traffic.

  724. Nameless RTL person

    but at that point it wouldn't be xmpp anymore

  725. ralphm


  726. ralphm

    I don't have a very strict concept of what can be called XMPP.

  727. Nameless RTL person

    not interoperable enough with clients implementing 3920/3921

  728. ralphm

    In fact, you can totally do XMPP Core only.

  729. ralphm

    There are situations where you'd only do s2s, not c2s, e.g. to federate an existing system with XMPP.

  730. ralphm

    From the other side, you wouldn't be able to tell.

  731. winfried has left

  732. winfried has joined

  733. Nameless RTL person

    oh. then i'm happy to be informed that icq was an xmpp client thanks to transports

  734. winfried has left

  735. winfried has joined

  736. ralphm

    I've implemented and run services with an XMPP PubSub interface that didn't support the publishing and node creation bits of the protocol. Nodes magically existed as a function of business logic.

  737. zach has left

  738. zach has joined

  739. adiaholic has left

  740. Nameless RTL person

    i see.

  741. ralphm

    Nameless RTL person: well sure, the transports were basically IRC etc. clients that magically made other IRC users have a JID.

  742. Nameless RTL person

    then i used wrong name.

  743. ralphm

    I am a strong believer in the protocols. I don't care much about the things behind the scenes.

  744. adiaholic has joined

  745. mukt2 has left

  746. Nameless RTL person

    "then it wouldn't be xmpp instant messaging anymore"

  747. Ge0rG

    Nameless RTL person: if you create an identity model that's not based on xmpp JIDs, suddenly many xmpp features stop making sense.

  748. Nameless RTL person

    Ge0rG, exactly what i meant by that sentence

  749. Ge0rG

    If you want decentralized identities, you end up with public keys being user identifiers, and then every message must be a signed (+ encrypted) blob and routing follows some overlay structure.

  750. Ge0rG

    And then xmpp is only a hindrance

  751. ralphm

    Ge0rG: yup, I agree with that. But there's no reason why you couldn't have a thing that sits with the bare JID and manipulate incoming and outgoing traffic to assist regular clients.

  752. Ge0rG

    You could of course use the xmpp message format inside the encrypted blob, so that you can have all the client side XEPs

  753. Ge0rG

    ralphm: but the bare JID is owned by your server, not by you!

  754. Ge0rG

    And the server is mostly trusted

  755. ralphm

    If my server allows for a special API, e.g. with a kind of client-component, to act on behalf of my bare JID, why not?

  756. Nameless RTL person

    i'd be fine with user-visible JIDs, as long as there was a metaprotocol stating that those several JIDs are all me, other people can discover these other JIDs easily, and normal users could be made oblivious to their existence

  757. Ge0rG

    ralphm: what would that give you that can't be given by the server directly?

  758. goffi has joined

  759. ralphm

    Always on scriptability, and other stuff you want to have, your server might not provide, and offloads clients.

  760. ralphm

    But annotations could be one example.

  761. Ge0rG

    Nameless RTL person: so you want to use xmpp as the routing layer for a p2p protocol based on a cryptographic identity?

  762. Nameless RTL person

    a simplest solution would be a simple discovery protocol of "how can i contact you in other ways" + crypto signing of auth requests

  763. Nameless RTL person

    and keep all the rest of xmpp intact

  764. Ge0rG

    Nameless RTL person: then it's just a very sophisticated mechanism to exchange encrypted blobs.

  765. Ge0rG

    No benefit on top of protobuf over DTLS with TURN

  766. adiaholic has left

  767. pep.

    not reinventing all the things? If you can use client XEPs for example

  768. Nameless RTL person

    in this sense, xmpp itself is just a very sophisticated mechanism to exchange xml on top of tcp

  769. ralphm

    Oh, if you want Jingle-negotiated p2p XML Streams, why not?

  770. Nameless RTL person

    i've never written anywhere i want p2p or jingle

  771. ralphm

    Much like Local Link Messaging

  772. ralphm

    Nameless RTL person: true

  773. Ge0rG

    pep.: yes, but you need to map your cryptographic identity scheme to faux JIDs to make most client XEPs work

  774. pep.

    Ge0rG, something like <fp>@domain? That you could change at will

  775. Ge0rG

    Nameless RTL person: p2p is just the consequence of decoupling your identity from your JID

  776. Ge0rG

    pep.: `0xdeadbeef@onion/yaxim`

  777. Nameless RTL person

    except by having actual xmpp servers, i don't need to do routing, offline storage, etc.

  778. pep.

    Ge0rG, that :)

  779. Ge0rG

    With onion being the verbatim name of the used cryptographic identity protocol

  780. Ge0rG

    Nameless RTL person: which server would keep your offline messages if you have three different JIDs?

  781. Nameless RTL person

    all of them.

  782. Nameless RTL person

    depending on which on received a given message

  783. Nameless RTL person

    depending on which one received a given message

  784. Ge0rG

    As if deduplication wasn't hard enough already

  785. Ge0rG

    Nameless RTL person: so if one of them fails, you only receive two thirds of your backlog?

  786. Nameless RTL person


  787. pep.

    (which is already the case anyway)

  788. pep.

    (I mean, if your server fails, you receive 0/1 of your backlog)

  789. Nameless RTL person

    ⅔ > 0

  790. Ge0rG

    Congratulations! You've created a protocol that combines the drawbacks of xmpp with the drawbacks of p2p!

  791. Nameless RTL person

    thank you, i'm very happy

  792. marc_ has left

  793. adiaholic has joined

  794. Nameless RTL person

    it's still better than not having any means to move accounts between servers in case of problems, or in case of, let say, just being disappointed with the server operator

  795. Ge0rG

    Nameless RTL person: ask pep. about Moved.

  796. pep.

    True, that helps with <moved/>. And that's kind of where changes on that XEP are leading anyway..

  797. ralphm

    Well for what it is worth, running my own server, e2ee is overrated at best and a pain at worst.

  798. pep.

    ralphm, lots of people in this room specifically agree with you. Not so many outside of it :)

  799. Ge0rG

    ralphm: welcome to the club of OMEMO rejects.

  800. Nameless RTL person

    i talked to pep. about it, yes. i don't find it a good solution

  801. Nameless RTL person

    besides, what's wrong with just stating my other JIDs? i can make a contact in my smartphone having multiple phone numbers and it works

  802. zach has left

  803. zach has joined

  804. ralphm

    pep.: Is moved more than https://xmpp.org/rfcs/rfc6120.html#stanzas-error-conditions-gone with forwarding address?

  805. ralphm

    pep.: yes I am aware

  806. Ge0rG

    Nameless RTL person: your contacts are managed by you. Your "friend's" alternative JIDs are managed by them

  807. ralphm

    pep.: I also have issues with crypto-currencies.

  808. Nameless RTL person

    yeah, and we're in an era where computers are supposed to help managing things up

  809. pep.

    ralphm, yes it's more than <gone/>. We discussed it a few times, I could grep through the logs, I don't remember much off-hand

  810. Ge0rG

    ralphm: the biggest issue with Moved is that all mechanisms it provides are ephemeral

  811. ralphm

    pep.: yeah, I vaguely remember. Happy to pick that back up at some point.

  812. mukt2 has joined

  813. pep.

    What Ge0rG says

  814. pep.

    You can very well make it so the current <moved/> is changed minimally and serves some part of the requirements

  815. pep.

    But there's a demand for more and that would likely require crypto identities

  816. pdurbin has joined

  817. ralphm

    Ge0rG: I added node delete + forwarding address notification, to cover that case with nodes-as-things, and implement moving 'things' between websites, habing all subscribers rewrite their references

  818. Ge0rG

    But you'd need pep to persist the tombstone

  819. Ge0rG

    ralphm: yes

  820. pep.

    Ah yes the tombstone. That you should keep on the old server and that your contacts should keep on their servers as well..

  821. adiaholic has left

  822. Nameless RTL person has left

  823. ؜

    see ya!

  824. pep.

    Anyway. "Not today!"

  825. adiaholic has joined

  826. Ge0rG

    ralphm: when I first looked at Moved, I was under the impression that all it needs are two or three minor changes to work in today's environment. But it turned out to be a bottomless pit

  827. pdurbin has left

  828. ؜ has left

  829. gav has left

  830. mukt2 has left

  831. Zash has left

  832. mimi89999 has left

  833. gav has joined

  834. gav has left

  835. gav has joined

  836. gav has left

  837. gav has joined

  838. gav has left

  839. gav has joined

  840. gav has left

  841. gav has joined

  842. gav has left

  843. ؜x has left

  844. gav has joined

  845. Daniel

    Do I have to send presence to a muc before I create/configure it over iq?

  846. zach has left

  847. zach has joined

  848. pep.

    "has left the room due to an error (Kicked: jid malformed)" oops?

  849. Zash has joined

  850. flow

    another testcase for the jid corpus \o/

  851. debacle has left

  852. mr.fister has joined

  853. zach has left

  854. zach has joined

  855. mimi89999 has joined

  856. mimi89999 has left

  857. Tobias has joined

  858. Tobias has left

  859. pep.

    Zash, which ones of your clients got kicked btw?

  860. Zash


  861. pep.

    Zash has left the room due to an error (Kicked: jid malformed)

  862. Zash

    Got an exact timestamp?

  863. Zash

    Or aproximate

  864. pep.


  865. Zash

    ... got it in UTC+2?

  866. mimi89999 has joined

  867. ralphm


  868. pep.


  869. pep.

    what, my vps is in Japan, still..

  870. Zash

    That's in the future :|

  871. ralphm

    If Zash can't do substractions, why are we letting him write code?

  872. pep.

    wait, 20:39

  873. ralphm

    Or pep.

  874. Zash

    It's late and I'm tired

  875. pep.

    I got confused by tmux showing me the current datetime

  876. pep.


  877. Link Mauve has left

  878. Zash

    ralphm, you know how brains are really terrible at basic math, while pretty good at extremely complicated tasks like walking without falling over?

  879. pep.


  880. pep.

    (Yes that's a nested tmux)

  881. ralphm

    Zash: I'm not sure if that's true at all.

  882. ralphm

    It is likely dependent on how often you it.

  883. Zash

    Hush, I read it on the Internet, it must be true. And then it's totally sensible that I'd be terrible at math while being good at telling computers to do math.

  884. Zash

    Also, I'm lazy and tired.

  885. Zash

    And it's late.

  886. ralphm

    Zash: no worries

  887. Zash

    pep., http://paste.debian.net/1099725/

  888. Zash

    ``` 00000000: 6672 6f6d 3d27 7873 6640 6d75 632e 786d from='xsf@muc.xm 00000010: 7070 2e6f 7267 2fd8 9c27 pp.org/..' ```

  889. Ge0rG

    Zash: what's /x?

  890. Zash


  891. pep.

    Zash, yes, that's U+061C and x

  892. DebXWoody has left

  893. Zash

    Where did my paste go

  894. DebXWoody has joined

  895. Ge0rG

    Zash: your server complained about the X, not about the RTL

  896. Zash


  897. Zash

    less wins over lnav Sep 09 20:39:28 stanzarouter warn Received stanza with invalid source JID: xsf@muc.xmpp.org/<U+061C>x

  898. ralphm

    less is more

  899. ralphm

    So a modifier by itself is ok, but modifying x is not?

  900. Zash

    LATIN SMALL LETTER X isn't arabic, so I guess

  901. ralphm

    Can you tell what rule fails?

  902. UsL has joined

  903. ralphm

    I'm not behind a machine to check right now

  904. Zash

    Looks like this behaves differently between libidn and ICU

  905. Zash

    ICU rejects, libidn accepts

  906. Ge0rG

    Yay for consistency

  907. Zash

    Robot face bug again

  908. Ge0rG

    Zash: why is your server enforcing it on incoming s2s?

  909. Zash

    I'm using ICU, libidn is usually the default.

  910. ralphm

    Isn't rejecting invalid stuff at your edge perfectly fine?

  911. pep.

    So we don't have specs saying what's actually valid?

  912. Zash

    pep., we do. three of them.

  913. pep.


  914. Ge0rG

    ralphm: is getting kicked from a MUC because somebody sent junk perfectly fine?

  915. Zash

    Ge0rG, at least it should be fine with robot face now

  916. Ge0rG

    ralphm: some servers will even tear down s2s

  917. ralphm

    Well, yeah, that sucks

  918. Ge0rG

    Zash: don't challenge me

  919. pep.

    Ge0rG: I'd say the MUC should kick them

  920. Zash

    The two libraries differ in how they treat unassigned code points. ICU rejects by default, libidn accepts by default.

  921. Ge0rG

    pep.: yes, but it doesn't. What now?

  922. zach has left

  923. zach has joined

  924. Zash

    That's why you got robot face bug in the past, getting ICU-users kicked.

  925. jonas’

    we do have specs which do checks against RTL-weirdness, specifically stringprep

  926. jonas’

    RFC 6122 has wording on that

  927. Zash

    But prosody if built with ICU now (in trunk) will tell ICU to behave like libidn.

  928. jonas’

    https://tools.ietf.org/html/rfc6122#appendix-A.6 https://tools.ietf.org/html/rfc3454#section-6

  929. jonas’

    2) If a string contains any RandALCat character, the string MUST NOT contain any LCat character. 3) If a string contains any RandALCat character, a RandALCat character MUST be the first character of the string, and a RandALCat character MUST be the last character of the string.

  930. Zash

    And the MUC here uses libidn

  931. jonas’

    pep., ^

  932. Zash

    jonas’, TL;DR rejecting is correct?

  933. jonas’

    Zash, probably, I’d have to check the categories of the involved characters

  934. Zash


  935. jonas’

    u+061c is invalid because it’s unassigned to my validator

  936. Zash

    Hm, is that going to bypass the rule forbidding empty nicknames;

  937. jonas’

    Zash, but yes, if we used a newer unicode version: U+061C is AL, thus RandALCat as per StringPrep, U+0078 is bidi category L, which is LCat, which MUST NOT occur in a string with RandALCat

  938. ralphm

    One of the issues might be that resourceprep is defined using Unicode 3.2 and this codepoint is 6.3.

  939. jonas’

    fun fact: that’s the kind of stuff which may change breakably between unicode versions, which is why PRECIS will be all kinds of interop hell

  940. jonas’

    ralphm, yeah, that’s what I meant when I said "u+061c is invalid because it’s unassigned to my validator"

  941. jonas’

    Zash, so, yes, rejecting is valid, but only if you also reject U+061C on its own

  942. jonas’

    otherwise you’re rejecting based on the wrong reasons, at least if you’re using resourceprep from RFC 6122 as basis

  943. jonas’

    (if you’re using PRECIS, I don’t know)

  944. ralphm

    Probably something is using newer tables for normalization.

  945. Zash

    Not using PRECIS

  946. Zash

    Neither of the two libraries I can currently choose between has PRECIS

  947. jonas’

    Zash, then something is wrong on your end if it allows U+061C, but not U+061C U+0078

  948. Ge0rG

    So the logical consequence is to reject strictly on c2s and less strictly on s2s?

  949. ralphm

    Also no 🥓 or 🦒 in resources

  950. jonas’

    Ge0rG, I think that’s the only sane way forward

  951. Ge0rG

    So you can't get kicked because of somebody else

  952. pep.

    "Ge0rG> pep.: yes, but it doesn't. What now?" You also validate and reject it (send message errors)

  953. ralphm

    Ge0rG: why wouldn't a server reject incoming invalid JIDs on s2s?

  954. ralphm

    That other server is clearly not checking properly

  955. Zash

    Problem: Allowing unassigned code points has been the default (probably unintentionally) too long. Everything will be painful.

  956. Ge0rG

    ralphm: because what happened to Zash in this MUC today

  957. ralphm

    So xmpp.org is at fault

  958. debacle has joined

  959. j.r has left

  960. ralphm

    It apparently accepted the bad jid and then also sent it on?

  961. j.r has joined

  962. Zash

    In turn because libidn and relaxed defaults.

  963. pep.

    ralphm, yes

  964. jabberjocke has joined

  965. jabberjocke has left

  966. zach has left

  967. zach has joined

  968. jabberjocke has joined

  969. peter has joined

  970. peter has left

  971. stpeter has joined

  972. stpeter has left

  973. ؜ has left

  974. Link Mauve has joined

  975. Nekit has joined

  976. flow

    > jonas’> fun fact: that’s the kind of stuff which may change breakably between unicode versions, which is why PRECIS will be all kinds of interop hell Isn't this only true if we accept unassigned codepoints?

  977. pdurbin has joined

  978. Zash

    Postulate that we do.

  979. Zash

    flow, jonas’ stated that there may be things that normalize to different things between versions

  980. winfried has left

  981. winfried has joined

  982. winfried has left

  983. winfried has joined

  984. flow

    unicode standard versions?

  985. Zash


  986. flow

    Potentially yes, but I'd expect that to be very rare. Could be wrong though

  987. pdurbin has left

  988. Zash

    flow, also, as I mentioned earlier, accepting unassigned codepoints is the default in libidn and thus prosody for some reason

  989. Zash

    and probably other users of libidn

  990. Yagiza has left

  991. flow

    Something else ftw

  992. zach has left

  993. zach has joined

  994. Dele (Mobile) has joined

  995. flow

    Just reading ralphm blog post. So 2019-09-02-14 attaches to 2019-09-02-11, but since -11 has been corrected multiple times, it actually attches to 2019-09-02-13?

  996. ralphm

    flow: as currently envisioned, attaching is solely to the original stanza.

  997. Dele (Mobile) has left

  998. ralphm

    But I agree this part is something needing more thought.

  999. ralphm

    It might be useful to specify a second id, in this case the edit

  1000. flow

    well that id you already have, the <stanza-id/> of the stanza performing the edit, no?

  1001. ralphm

    "apply to 1, as modified by 2"

  1002. Zash

    Wave but not quite?

  1003. flow

    ralphm, xep372 begin/end are zero indexed

  1004. ralphm

    Because it depends on semantics of the thing being attached.

  1005. flow

    it appears you use 1-index in your examples

  1006. Dele (Mobile) has joined

  1007. flow

    Yeah, I also think how much we potentially could learn from wave

  1008. ralphm

    flow: oh, I'll check that tomorrow

  1009. flow

    A look at the wave spec couldn't hurt

  1010. Zash

    Protobufs, just like Ge0rG wanted

  1011. ralphm

    E.g. for reactions you generally apply to the 'message' irregardless of edits.

  1012. ralphm

    But references break with edits.

  1013. ralphm

    Yeah Ge0rG and stanza versioning has come up a few times in private discussions I've had in this.

  1014. LNJ has left

  1015. marc_ has joined

  1016. mtavares has left

  1017. Ge0rG

    I was not involved in any backroom deals!

  1018. flow

    I've just read up on U+061C, it's assigned since 2013 and in the Cf category, which means it is a control character and hence disallowed in resourceparts

  1019. dele has joined

  1020. dele has left

  1021. mtavares has joined

  1022. mukt2 has joined

  1023. remko has joined

  1024. U+061C has joined

  1025. Nekit has left

  1026. U+061C

    yay, protobufs, this NIH thing known only because google invented it

  1027. zach has left

  1028. zach has joined

  1029. Zash

    It also magically solves all protocol problems

  1030. adiaholic has left

  1031. pep.

    Isn't that just a serialisation format? (I've never actually used it)

  1032. U+061C

    indeed. seen a bad case of hyperprotobufoxia before

  1033. Zash

    Why does XMPP even exist when protobufs can do all that?

  1034. Zash

    Or was it MQTT?

  1035. Zash

    pep.: I haven't used it either, which makes me qualified to describe exactly what it is. And I say "versioned structs".

  1036. Neustradamus has joined

  1037. mukt2 has left

  1038. U+061C

    pep., yes, it's a serialization format that's mediocre at what it can express (lots of great prior work) with somewhat good tooling (something that, i think, was the actual breakthrough of protobufs)

  1039. pep.

    So it's like JSON?

  1040. U+061C

    more strongly typed

  1041. pep.

    I see

  1042. U+061C

    also, binary

  1043. Zash

    It's like C structs

  1044. Zash

    With version numbers!

  1045. U+061C

    and not self-describing, ie. you can't parse a protobuf binary encoding unless you know the spec used to generate it

  1046. U+061C

    and not self-terminating either, ie. if you have a binary message, only part of it being a protobuf, you need to figure out where it ends on your own (e.g. sending length separately)

  1047. Zash

    So you write some C struct definition and then run some tooling that spits out tons of boilerplate for whatever language.

  1048. U+061C

    both of these result in shorter messages though

  1049. marc_ has left

  1050. Zash

    Not being self-describing will do that for you

  1051. U+061C

    chat states in this webchat thing are so annoying

  1052. U+061C

    it's not a bad tool, but those google folks could have instead support an existing standard instead. that's why it's NIH

  1053. mr.fister has left

  1054. remko has left

  1055. moparisthebest has left

  1056. jubalh has left

  1057. neshtaxmpp has joined

  1058. ralphm

    flow: but it being unassigned in Unicode 3.2 makes the rest of your argument moot anyway?

  1059. ralphm

    Or are you looking at Précis?

  1060. zach has left

  1061. zach has joined

  1062. goffi has left

  1063. karoshi has left

  1064. karoshi has joined

  1065. jabberjocke has left

  1066. lumi has left

  1067. jabberjocke has joined

  1068. moparisthebest has joined

  1069. Mikaela has left

  1070. pdurbin has joined

  1071. edhelas has left

  1072. edhelas has joined

  1073. zach has left

  1074. zach has joined

  1075. sonny has joined

  1076. UsL has left

  1077. pdurbin has left

  1078. U+061C has left

  1079. marc_ has joined

  1080. ralphm

    So I guess 🥓 being a So makes it acceptable for a resource?

  1081. pep.

    Bacon is always acceptable

  1082. andy has left

  1083. waqas has joined

  1084. UsL has joined

  1085. remko has joined

  1086. marc_ has left

  1087. marc_ has joined

  1088. Dele (Mobile) has left

  1089. mukt2 has joined

  1090. Dele (Mobile) has joined

  1091. matkor has left

  1092. matkor has joined

  1093. karoshi has left

  1094. mukt2 has left

  1095. wurstsalat has left

  1096. remko has left

  1097. waqas has left

  1098. waqas has joined

  1099. zach has left

  1100. zach has joined

  1101. UsL has left

  1102. UsL has joined

  1103. dele has joined

  1104. dele has left

  1105. Dele (Mobile) has left