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 https://github.com/xsf/xmpp.org/pull/592
  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 Wave
  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 https://ralphm.net/blog/2019/09/09/fastening
  230. ralphm Discuss.
  231. jonas’ fasten your seatbelts
  232. ralphm Indeed
  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 :parrot:
  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. ugh
  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.
  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 Great
  392. ralphm Do you have any other insights?
  393. pep. .
  394. pep. whatever
  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 https://upload.yax.im/upload/y7oYvc1Z5wrQX5tg/Screenshot_20190909-181529_yaxim.jpg
  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’ nice
  514. patrick has left
  515. Ge0rG pasting cropped yaxim screenshots into yaxim makes my head spin
  516. Zash hah
  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. oh
  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. \o/
  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 https://upload.jabberfr.org/Oy8Ag6u4EJUndIbG/wayland-screenshot-2019-09-09_18-24-24.png
  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 yeah
  559. remko has left
  560. ralphm Nameless RTL person: like RTL markers?
  561. Nameless RTL person yep.
  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 Mwoh
  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 inconsistency
  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. (btw)
  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. *validating
  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 Heh
  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 U+061C ARABIC LETTER MARK wha
  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 Why?
  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 yep.
  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 Huh?
  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. 03:39:29+09:00
  865. Zash ... got it in UTC+2?
  866. mimi89999 has joined
  867. ralphm Dude
  868. pep. 21:39
  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. *time
  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. https://ppjet.bouah.net/tmux-time.png
  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 Huh
  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. Great
  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
  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 Yes
  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