XSF Discussion - 2020-01-08


  1. Shell has left
  2. karoshi has left
  3. mukt2 has joined
  4. waqas has joined
  5. beta has left
  6. beta has joined
  7. mukt2 has left
  8. stpeter has left
  9. beta has left
  10. mukt2 has joined
  11. Lance has left
  12. mukt2 has left
  13. UṣL has left
  14. mukt2 has joined
  15. winfried has left
  16. winfried has joined
  17. winfried has left
  18. winfried has joined
  19. debacle has left
  20. mukt2 has left
  21. mukt2 has joined
  22. mukt2 has left
  23. mukt2 has joined
  24. mukt2 has left
  25. mukt2 has joined
  26. stpeter has joined
  27. winfried has left
  28. winfried has joined
  29. winfried has left
  30. winfried has joined
  31. winfried has left
  32. winfried has joined
  33. winfried has left
  34. winfried has joined
  35. mukt2 has left
  36. calvin has joined
  37. paul has left
  38. winfried has left
  39. winfried has joined
  40. winfried has left
  41. winfried has joined
  42. mukt2 has joined
  43. mr.fister has left
  44. mukt2 has left
  45. stpeter has left
  46. stpeter has joined
  47. lskdjf has left
  48. mukt2 has joined
  49. Lance has joined
  50. beta has joined
  51. winfried has left
  52. winfried has joined
  53. mukt2 has left
  54. winfried has left
  55. winfried has joined
  56. winfried has left
  57. winfried has joined
  58. winfried has left
  59. winfried has joined
  60. winfried has left
  61. winfried has joined
  62. winfried has left
  63. winfried has joined
  64. winfried has left
  65. winfried has joined
  66. winfried has left
  67. winfried has joined
  68. winfried has left
  69. winfried has joined
  70. calvin has left
  71. mukt2 has joined
  72. beta has left
  73. mukt2 has left
  74. waqas has left
  75. adiaholic has joined
  76. mukt2 has joined
  77. beta has joined
  78. Daniel has left
  79. beta has left
  80. mukt2 has left
  81. Daniel has joined
  82. mukt2 has joined
  83. Daniel has left
  84. beta has joined
  85. mukt2 has left
  86. Daniel has joined
  87. wurstsalat has left
  88. beta has left
  89. mukt2 has joined
  90. beta has joined
  91. adiaholic has left
  92. adiaholic has joined
  93. beta has left
  94. Vaulor has left
  95. Vaulor has joined
  96. stpeter has left
  97. Alex has left
  98. Alex has joined
  99. mukt2 has left
  100. winfried has left
  101. winfried has joined
  102. beta has joined
  103. mukt2 has joined
  104. beta has left
  105. mukt2 has left
  106. adiaholic has left
  107. adiaholic has joined
  108. mukt2 has joined
  109. lorddavidiii has joined
  110. Kev has joined
  111. beta has joined
  112. mukt2 has left
  113. Tobias has joined
  114. mukt2 has joined
  115. pdurbin has joined
  116. paul has joined
  117. beta has left
  118. beta has joined
  119. pdurbin has left
  120. beta has left
  121. pdurbin has joined
  122. karoshi has joined
  123. wurstsalat has joined
  124. sonny has left
  125. sonny has joined
  126. lorddavidiii has left
  127. Arc has left
  128. Arc has joined
  129. lorddavidiii has joined
  130. sonny has left
  131. sonny has joined
  132. mimi89999 has left
  133. sonny has left
  134. sonny has joined
  135. lorddavidiii has left
  136. lorddavidiii has joined
  137. lorddavidiii has left
  138. sonny has left
  139. sonny has joined
  140. lorddavidiii has joined
  141. lorddavidiii has left
  142. lorddavidiii has joined
  143. Douglas Terabyte has left
  144. lorddavidiii has left
  145. lorddavidiii has joined
  146. Nekit has joined
  147. beta has joined
  148. lorddavidiii has left
  149. emus has joined
  150. lorddavidiii has joined
  151. mukt2 has left
  152. mukt2 has joined
  153. marc has left
  154. lorddavidiii has left
  155. sonny has left
  156. sonny has joined
  157. lorddavidiii has joined
  158. Douglas Terabyte has joined
  159. j.r has left
  160. beta has left
  161. marc has joined
  162. j.r has joined
  163. sonny has left
  164. mathijs has left
  165. mathijs has joined
  166. sonny has joined
  167. UṣL has joined
  168. marc has left
  169. mukt2 has left
  170. goffi has joined
  171. goffi has left
  172. goffi has joined
  173. marc has joined
  174. Vaulor has left
  175. Vaulor has joined
  176. mathijs has left
  177. mathijs has joined
  178. j.r has left
  179. sonny has left
  180. j.r has joined
  181. marc has left
  182. mathijs has left
  183. mathijs has joined
  184. mukt2 has joined
  185. krauq has left
  186. vanitasvitae has left
  187. beta has joined
  188. sonny has joined
  189. adiaholic has left
  190. paul has left
  191. adiaholic has joined
  192. paul has joined
  193. vanitasvitae has joined
  194. beta has left
  195. marc has joined
  196. mukt2 has left
  197. karoshi has left
  198. karoshi has joined
  199. marc has left
  200. beta has joined
  201. marc has joined
  202. mimi89999 has joined
  203. Steve Kille has joined
  204. marc has left
  205. zukzuk has joined
  206. flow https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F01bb8j,%2Fg%2F11bv302qqv
  207. flow I find the world map comparision especially interesting. Germany appears to have a very high search-interest in Matrix
  208. adiaholic has left
  209. adiaholic has joined
  210. zukzuk has left
  211. sonny has left
  212. sonny has joined
  213. jonas’ probably because we love the movie
  214. sonny has left
  215. sonny has joined
  216. flow what's a little bit sad is that the search interest for xmpp decreased by 50% in the last 5 years
  217. flow jonas’, if only they made a sequel of that movie
  218. jonas’ flow, if only
  219. Ge0rG aren't they?
  220. jonas’ unobstrusively pulls out a wrench
  221. sonny has left
  222. beta has left
  223. sonny has joined
  224. beta has joined
  225. eevvoor has joined
  226. pep. There's a Matrix 4 coming
  227. pep. https://www.imdb.com/title/tt10838180/
  228. jonas’ different director and writer. could be less terrible.
  229. Zash ITYM Matrix 2
  230. mukt2 has joined
  231. krauq has joined
  232. Ge0rG ITYM Synapse 1.8.0
  233. pep. Synapse, Matrix, it's all the same
  234. mukt2 has left
  235. larma has left
  236. winfried has left
  237. winfried has joined
  238. winfried has left
  239. winfried has joined
  240. larma has joined
  241. Daniel has left
  242. Daniel has joined
  243. Daniel has left
  244. Daniel has joined
  245. Daniel has left
  246. Daniel has joined
  247. Nekit has left
  248. mukt2 has joined
  249. Lance has left
  250. goffi has left
  251. strypey has joined
  252. emus has left
  253. Lance has joined
  254. lskdjf has joined
  255. Daniel has left
  256. Daniel has joined
  257. Daniel has left
  258. Daniel has joined
  259. Dele (Mobile) has joined
  260. Lance has left
  261. strypey has left
  262. mukt2 has left
  263. sonny has left
  264. lorddavidiii has left
  265. lorddavidiii has joined
  266. Lance has joined
  267. goffi has joined
  268. Shell has joined
  269. sonny has joined
  270. emus has joined
  271. ralphm jonas’, what do you mean different writer?
  272. pdurbin has left
  273. Lance has left
  274. beta has left
  275. sonny has left
  276. mukt2 has joined
  277. sonny has joined
  278. Wojtek has joined
  279. sonny has left
  280. sonny has joined
  281. larma has left
  282. Shell has left
  283. sonny has left
  284. Shell has joined
  285. marc has joined
  286. larma has joined
  287. beta has joined
  288. alameyo has left
  289. alameyo has joined
  290. mukt2 has left
  291. Shell has left
  292. mukt2 has joined
  293. sonny has joined
  294. strypey has joined
  295. strypey has left
  296. Zash Hm, going here didn't give me what I hoped for: https://xmpp.org/rfcs/
  297. Max has left
  298. Max has joined
  299. marc has left
  300. marc has joined
  301. larma has left
  302. MattJ I always go there, it's handy
  303. larma has joined
  304. Zash Was looking for RFC 7712 tho
  305. jonas’ but the RFCs are rendered terribly :-X
  306. sonny has left
  307. beta has left
  308. Zash Not that bad IMO
  309. Alex has left
  310. jonas’ yeah I know it’s an unpopular opinion of mine, hence the :-X
  311. Zash Could be better
  312. jonas’ sure, for example the official IETF html rendering
  313. jonas’ sure, for example: https://tools.ietf.org/html/rfc6120
  314. Zash This is kinda nice tho: https://www.rfc-editor.org/rfc/rfc8700.html
  315. jonas’ oh that’s true
  316. jonas’ font could be slightly larger
  317. jonas’ reminds me of the XEP renderings
  318. sonny has joined
  319. Alex has joined
  320. beta has joined
  321. sonny has left
  322. mukt2 has left
  323. beta has left
  324. mukt2 has joined
  325. beta has joined
  326. Lance has joined
  327. pdurbin has joined
  328. pdurbin has left
  329. j.r has left
  330. j.r has joined
  331. sonny has joined
  332. Lance has left
  333. lorddavidiii has left
  334. lorddavidiii has joined
  335. lorddavidiii has left
  336. lorddavidiii has joined
  337. lorddavidiii has left
  338. mukt2 has left
  339. lorddavidiii has joined
  340. lorddavidiii has left
  341. lorddavidiii has joined
  342. mukt2 has joined
  343. lorddavidiii has left
  344. sonny has left
  345. sonny has joined
  346. lorddavidiii has joined
  347. eevvoor has left
  348. eevvoor has joined
  349. eevvoor has left
  350. Ge0rG jonas’ [13:17]: > sure, for example: https://tools.ietf.org/html/rfc6120 That's the worst skeuomorph in the history of the Internet
  351. Ge0rG The XSF renderings are plain awesome in comparison
  352. eevvoor has joined
  353. Shell has joined
  354. Ge0rG And rfc editor isn't rendering any old RFCs in the nice html, so only the 50 years one?
  355. Ge0rG The mandatory page breaks make my eyes bleed, and I don't even want to try to read that on an e book reader.
  356. Zash Only a few very recent ones
  357. Ge0rG And I'm sure they actually have semantically structured source code, so this is absolutely self inflicted
  358. Steve Kille There was a LOT of argument that ASCII is the only thing everone can handle.
  359. Ge0rG Steve Kille: I'm not opposed to having an ASCII version, not even in 2020. What infuriates me is what they call "html" rendering.
  360. jonas’ Ge0rG, it’s still better than the kilometers of line length on the XSF rendering
  361. Ge0rG jonas’: you are doing Browser wrong.
  362. jonas’ no, the XSF rendering is doing typography wrong
  363. beta has left
  364. Ge0rG Whereas the official rendering is also doing accessibility and readability wrong.
  365. j.r has left
  366. beta has joined
  367. Shell has left
  368. Shell has joined
  369. Ge0rG > If only a web browser is available, the PDF rendering of an RFC is often the better choice than the HTML version. > Starting with RFC 8651, RFCs are published as XML files [..]
  370. Steve Kille should have been done a LONG time ago
  371. Zash Like XEPs! 🙂
  372. Ge0rG it only has sustained for so long because of bearded old men (and I mean men who are both more bearded and older than me)
  373. ralphm [citation needed]
  374. Ge0rG 🤷
  375. j.r has joined
  376. j.r has left
  377. j.r has joined
  378. Shell has left
  379. Shell has joined
  380. ralphm Come on, you can throw around general dismissive statements like this, but at least provide _something_ to back it up. A few months ago there was a discussion on us using XML as the format for XEPs, and I contemplated the impact on moving to, e.g. ReST or some Markdown dialect, but such an effort is not trivial by any means. The IETF is so much more bigger in reach, older, etc. that I am not surprised it took a while to come up with a plan forward. RFC 7990 provides some more insight.
  381. mathijs has left
  382. mathijs has joined
  383. Zash ralphm: Fun fact: I have mostly working scripts for translating XEP XML to and from Markdown
  384. ralphm E.g. “In order to respond to concerns regarding responses to subpoenas and to understand the legal requirements, advice was requested from the IETF Trust legal team regarding what format or formats would be considered reasonable when responding to a subpoena request for an RFC.”
  385. jonas’ A subpoena request for a thing which is public?
  386. stpeter has joined
  387. ralphm This is about subpoena's where the response would need to include an RFC.
  388. ralphm jonas’ simply sending a URL is probably not sufficient.
  389. Shell has left
  390. Shell has joined
  391. stpeter has left
  392. Ge0rG ralphm: I'm not involved in the RFC process, and maybe my impression that any RFC has a semantic source code and could be trivially rendered the same way as we did for https://xmpp.org/rfcs/rfc6120.html is wrong. However, the ASCII paginated format is not in wide use in the IT industry for over thirty years now.
  393. neshtaxmpp has left
  394. Ge0rG And I'm sure people can come up with a saner mechanism in much less than thirty years, if they actually see a need.
  395. ralphm Up until this RFC, the canonical version is been plain-text, in that paginated formatting.
  396. Ge0rG Probably even a mechanims to retro-fit the old ASCII submissions into a new format.
  397. ralphm And it is not that people didn't use XML as the actual source format, but this change lifts a lot of restrictions.
  398. Ge0rG RFC8651 has been published last October.
  399. goffi has left
  400. ralphm Right, its HTML rendering is based on the XML file, not on the plain text.
  401. Ge0rG Yeah, it's the first one.
  402. Ge0rG But as I said, this has taken thirty years.
  403. Ge0rG The printer that I got with my first computer, purchased used in 1993, was able to render proper typography, given the right software and drivers.
  404. beta has left
  405. ralphm It would be awesome if older RFCs that have been crafted in an XML format, like I believe all XMPP related ones authored by stpeter, could be re-processed, but I'm not sure if their processes allow this to be done retroactively.
  406. Ge0rG OTOH, I can't read most RFCs on my smartphone screen because the fixed-width fixed-page-width mandatory-line-breaks format is just bonkers.
  407. Ge0rG ralphm: given sufficient motivation, processes can be changed.
  408. ralphm Ge0rG, sure, and there are histerical raisins for this.
  409. ralphm And they did, eventually.
  410. Ge0rG ralphm: maybe because the IETF members realized that they are getting older and that their eyes are getting worse, so they can't read the RFCs any more.
  411. ralphm We can complain about the speed of it, but I think that's too easy.
  412. ralphm And not a very productive attitude.
  413. debacle has joined
  414. edhelas did some of you already played with http://sylkserver.com/ ?
  415. Ge0rG ralphm: I can't fix _all_ the things.
  416. edhelas does it act as a nice XMPP-SIP bridge, at least for IM ?
  417. ralphm Ge0rG, I think the bar I set was lower than _all_ :-D
  418. ralphm edhelas, SIMPLE is still a thing?
  419. edhelas yup
  420. ralphm wow
  421. Shell has left
  422. edhelas I'm currently working at the company behind Linphone and they are developping IM features within their clients :)
  423. beta has joined
  424. edhelas https://www.linphone.org/technical-corner/flexisip
  425. sonny has left
  426. lorddavidiii has left
  427. MattJ I installed their Android app the other day, it was the only one I could get to work reliably
  428. lorddavidiii has joined
  429. MattJ For SIP, not SIMPLE :)
  430. edhelas i'm looking for SIP-XMPP gateways
  431. Ge0rG ralphm: well yes, but I read your statement as an equivalent to "provide patches"
  432. Steve Kille do you mean SIMPLE-XMPP?
  433. edhelas ah it's not SIMPLE based actually
  434. edhelas my bad
  435. emus has left
  436. lorddavidiii has left
  437. lorddavidiii has joined
  438. UṣL has left
  439. Shell has joined
  440. krauq has left
  441. ralphm Ge0rG, no my statement is more "we can all do a lot better than making dismissive or facetious comments about the work of others."
  442. ralphm edhelas, what it is then?
  443. Ge0rG ralphm: well, that's true
  444. lorddavidiii has left
  445. lorddavidiii has joined
  446. Shell has left
  447. Lance has joined
  448. lorddavidiii has left
  449. pdurbin has joined
  450. Nekit has joined
  451. lorddavidiii has joined
  452. ralphm By the way, I think that https://xmpp.org/rfcs/rfc6120.xml is using the xml2rfc v1 format. I'm sure it would be relatively easy to have that processed as the newer XEPs are.
  453. sonny has joined
  454. pdurbin has left
  455. calvin has joined
  456. krauq has joined
  457. mukt2 has left
  458. mukt2 has joined
  459. ralphm https://upload.ik.nu/upload/TJ3QpLXv5HuZn_mQ/such_reactions.png
  460. Zash Eh
  461. pep. Of course there's an animated parrot in there
  462. Zash party parrot!
  463. ralphm This is a message from a few minutes ago in my company Slack. To provide an idea of how reactions can be used in practice.
  464. pep. "badly"? :)
  465. Zash I haven't seen anything that bad in Slack or similar yet.
  466. ralphm While I was blurring this screenshot, 5 other reaction emoji were added and a bunch more counts.
  467. ralphm Zash: this is why I am posting it :-D
  468. Zash I'm not sure we should start by optimizing for that
  469. Ge0rG This MAM response will only contain non-messages!1!!
  470. ralphm I think we might have to.
  471. krauq has left
  472. ralphm I'm sure dwd can appreciate the picture.
  473. pep. How do you even fit all that on a phone screen
  474. Lance has left
  475. ralphm pep., hold on
  476. pep. It eats like 50% of the usable area?
  477. krauq has joined
  478. ralphm https://upload.ik.nu/upload/y8ugHA41aaG2UpcK/such_reactions_mobile.png
  479. pep. right
  480. Link Mauve ralphm, is that exceptional or do most messages contain that kind of reactions?
  481. ralphm No this is not common. The message was meant for a different channel, with a smaller audience, but funny in the context of this channel, which is appropriately named has virtual all employees in it.
  482. ralphm virtually
  483. sonny has left
  484. ralphm I do think, however, that we should expect exceptions like this to be good test case for reactions in XMPP, and particularly for how we handle this in MAM context.
  485. edhelas XEP-xxxx: Kindly ask XMPP users to not send too much Reactions in chats (Informational
  486. ralphm heh
  487. edhelas or we go full ascii ¯\_(ツ)_/¯
  488. pep. This is not ascii
  489. dwd What I find interesting is that there are very few Unicode reactions there; they're mostly custom images.
  490. pep. (-̀◞८̯◟-́)
  491. edhelas ╯°□°)╯︵ ┻━┻
  492. Zash So limiting reactions to emoji is meh
  493. pep. ┗(•̀へ •́ ╮ )
  494. pep. (people have lots of imagination)
  495. pep. XEP-XXXX: Reactions + bob?
  496. Wojtek has left
  497. dwd Also I quite like the notion of having sequences like ╯°□°)╯︵ ┻━┻ as reactions.
  498. pep. I'm curious if other solutions allow that. I don't think I've seen it in Mattermost or Slack
  499. Zash And 'wat'
  500. pep. щ(ºДºщ)
  501. pep. ("Why?!")
  502. sonny has joined
  503. Wojtek has joined
  504. mukt2 has left
  505. dwd pep., No, I haven't either, but it seems potentially useful.
  506. pep. well it's doable in the current spec. "Just" include that in <reaction/>
  507. dwd Oooh. Polls. Those'd work as fastenings with MAMFC very easily.
  508. mukt2 has joined
  509. Lance has joined
  510. beta has left
  511. pep. dwd, for polls I do want the whole history of who voted what, and if they changed their votes etc. :x
  512. pep. Reactions might be ok for quick polls, but for more serious stuff you probably don't want that
  513. pep. You want the possibility to comment alongside your vote, at least. (that is, your message referencing your action of voting, or sth..)
  514. dwd The moment you want anonymous polls it gets a bit harder, true.
  515. beta has joined
  516. pep. Right also that
  517. j.r has left
  518. j.r has joined
  519. stpeter has joined
  520. emus has joined
  521. Lance has left
  522. ralphm Yeah, simple polls are pretty much the same as reactions. And indeed, in all Slacks I've been in, most reactions were using Slackmoji (custom emoji). That's also why I used that in my blog post.
  523. lorddavidiii has left
  524. lorddavidiii has joined
  525. adiaholic has left
  526. debacle has left
  527. goffi has joined
  528. mathijs has left
  529. mathijs has joined
  530. j.r has left
  531. adiaholic has joined
  532. pep. To come back to the OMEMO talk (from council@): Note that I'm not opposing getting rid of OMEMO.
  533. ralphm larma: regarding the discussion on OMEMO in council@ just now. If the XEP is moved to Proposed, a Last Call process will start. During this time, people can provide their comments. Then Council can decide to do one out of three things: 1) move back to Experimental, judging it not ready to move forward, and allowing the author or others to amend it to their instructions (e.g. fix the license issue), 2) reject it definitively, 3) accept.
  534. pep. Just that we don't have anything to replace it.
  535. pep. And I hate the message that this is sending
  536. pep. "We don't care about e2ee"
  537. jonas’ context for the above: https://logs.xmpp.org/council/2020-01-08#2020-01-08-40325e18d4aac62b
  538. tao has joined
  539. Max has left
  540. jonas’ pep., though Daniel proposed to write a blogpost which explains the rationale and why this is a good thing actually.
  541. pep. Is it a good thing
  542. ralphm pep. we can control the narritive ourselves. E.g. by launching the SIG and announcing an effort to work within the IETF to have an MLS spec for XMPP.
  543. Max has joined
  544. jonas’ and I think we can do things to make this blog post discoverable, including but not limited to: - mention it in the editor notification - mention it in the council decision - link it from the top of the XEP
  545. jonas’ pep., yes, it is a good thing for implementation freedom
  546. pep. And what in the meantime? "yeah well you can use that deprecated-or-rejected XEP, because everybody else use it"
  547. pep. "yay standards"
  548. ralphm pep., this is nothing new
  549. pep. To me the XSF is shooting itself in the foot
  550. jonas’ pep., yes, and no. Push OX forward, push FSE+OX forward, and if you have to, use OMEMO which is why I want to keep this XEP in place, albeit frozen in stasis.
  551. jonas’ or even push SEX forward, with a slightly less awful name
  552. pep. These are not OMEMO replacements
  553. ralphm People have used non-SASL authentication for ages after we obsoleted it.
  554. pep. they're perfectly valid encryption mechanisms for sure, but they don't do PFS (not that I'm arguing in favor of PFS)
  555. jonas’ pep., I’d also argue that OMEMO is not a good solution
  556. Shell has joined
  557. jonas’ and the replacements I mentioned are all better than OMEMO for the general userbase
  558. pep. jonas’, that's another debate
  559. pep. I also agree
  560. jonas’ so this is another reason why this is a good thing™
  561. Zash OMEMO is popular. Popularity does not equal quality.
  562. j.r has joined
  563. jonas’ it encourages the deployment of (for some metric) better alternatives
  564. pep. I also agree getting rid of PFS for the masses is a good thing. But that's not the debate at hand
  565. ralphm pep. and I think everybody agrees that the E2EE situation in XMPP has been an issue for a very long time. This is why I do like the proposal to form a SIG.
  566. larma ralphm, the current best thing we have is OMEMO. It's not good, but it's the best we have
  567. ralphm larma, yes, and it doesn't meet our objectives, so that's terrible.
  568. larma Which objective?
  569. ralphm larma: #4 of XEP-0001
  570. jonas’ larma, https://xmpp.org/extensions/xep-0001.html#objectives number 4
  571. pep. "good is the enemy of perfect"?
  572. larma It doesn't strictly violate it either
  573. larma it just lacks documentation
  574. jonas’ larma, I think it does
  575. jonas’ even if it is strictly legal, the ambiguity of the situation is encumberence enough
  576. dwd pep., Not good is the enemy of good, too.
  577. larma what ambiguity?
  578. jonas’ larma, whether it is a legal thing to do without using the GPL
  579. ralphm larma: if it is just lacking documentation, the onus is on whoever wants to progress the XEP to resolve this before it can move forward in our process.
  580. jonas’ where "it" is "implementing and using the Signal protocol"
  581. pep. dwd, what's the actual reason behind this move?
  582. Nekit has left
  583. dwd pep., I've explained that several times.
  584. larma well "Signal" is probably a trademark and thus can't be used in the XEP, I agree
  585. larma but that's again a documentation issue
  586. jonas’ larma, I’m talking about the protocol, not the name
  587. dwd pep., Unless by "actual" you're trying to imply I'm not really saying.
  588. larma the cryptographic protocol is pretty well specified in their public domain documents
  589. pep. That it can't be implemented in proprietary products etc.(?)
  590. ralphm larma, there have been efforts to reimplement the protocol in a library for other languages that the official libsignal, and they were considered derivative works, and thus subject to the GPL.
  591. ralphm I think there even was a library that changed licenses for this.
  592. jonas’ pep., that it can’t be implemented *in non-GPL products
  593. ralphm pep., and yes, the XSF expressly supports implementations open or closed alike.
  594. pep. jonas’, sure. I doubt this is really in issue in practice though.
  595. jonas’ pep., that’s not the point.
  596. jonas’ it violates objective 4
  597. larma well if you create a derivative work of libsignal it has to be under GPL, but I doubt that you have to do so
  598. dwd pep., Why do you think that's not an issue?
  599. jonas’ whether it’s a prolbem in practice because everyone who does OMEMO also happens to be okay with the GPL is a different issue
  600. ralphm Companies and proprietary implementations of our open protocols are not a bad thing, and explicitly part of the XSF's DNA.
  601. pep. That I can see indeed
  602. ralphm pep., I don't understand why you want to argue against this.
  603. flow I feels like the discussion around rejecting xep384 distracts from the really important question: Why wasn't the pull request that helps making xep384 independent of the libsignal wire protocol and move towards the open standard double ratched implementation merged?
  604. jonas’ flow, URL?
  605. jonas’ I guess the log in the PR would explain the reasons
  606. pep. I don't especially agree, but that debate is different from the points I'm bringing forward with OMEMO
  607. pep. ralphm, ^
  608. flow jonas’, no it doesn't, editor closed it
  609. dwd pep., Put it this way - if OMEMO genuinely cannot be implemented without a GPL library, should we kill it?
  610. jonas’ flow, URL please then?
  611. jonas’ that was probably me, and I might know more
  612. jonas’ (when I see the PR)
  613. flow jonas’, https://github.com/xsf/xeps/pull/460
  614. larma dwd, I personally agree to that
  615. Half-Shot has left
  616. pep. dwd, that's not my point in this debate. I'm not answering this question
  617. jonas’ pep., but that’s the *reason* for this debate
  618. ralphm pep., except it isn't. Because if the argument is not clearly worded, it might taken as a Board stance.
  619. jonas’ flow, ah, the reason is right there: inactivity.
  620. jonas’ I didn’t get a reply from the author in weeks
  621. flow jonas’, of course the question is "why went the author silent"
  622. pep. I'm saying "it has been accepted in experimental, deal with it as long as it's not proposed" (and the author hasn't, for good reasons)
  623. jonas’ flow, that I cannot anwser
  624. pep. We are sending a message that I don't want to send
  625. flow and there is a larger backstory to that behind what you can read from the comments in the PR
  626. ralphm pep., and I want to clearly communicate to everyone in our community that we definitely consider companies and proprietary implementations as part of our community.
  627. dwd pep., One problem here is that it forces other projects to send the same message.
  628. pep. Which projects?
  629. Daniel flow, that is an interesting question; which i would like to slightly repharse to "why isn’t the work on 'OMEMO 2.0'" moving faster? (i think the actual PR that was on the table had some minor problems; but it doesn’t really matter because some members of the 'OMEMO community' have working drafts for 'OMEMO 2' on their hard drives)
  630. dwd pep., Look at, for example, the OMEMO ticket against Swift.
  631. dwd pep., There's people there saying that the Swift leadership doesn't care about E2EE, which is incorrect - but they cannot implement OMEMO (or feel they cannot).
  632. pep. So you need to kill it as long as we don't have a replacement. Like it's become a mission right now?
  633. Daniel so why don’t we have omemo 2? - i think the answer to that is: omemo 2 is not backward compatible and for the vast amount of stakeholders (=people who actually do the work) omemo 1.0 is good enough; despite problems
  634. pep. Swift can very well implement OX
  635. pep. Gajim also supports OX. Swift can also drive the adoption around OX
  636. pep. I'm sure others would implement it
  637. jonas’ pep., the problem (the XEP violates a criterium for XEPs) was spotted, the problem is known, and it needs to be fixed now.
  638. pep. (I would)
  639. Daniel the combination of not being able to solve backward compat and good enough lessens the incentives to work on 'omemo 2'
  640. jonas’ if we want to further represent our objectives
  641. flow Daniel, why isn't omemo2 backwards compatible? Couldn't clients just use the same key material and crypto primitives with OMEMO1 and OMEMO2?
  642. jonas’ it sohuld never have come this far, but here we are
  643. jonas’ flow, it won’t be compatible on the wire by definition, that’s incompatibility enough
  644. Daniel it's probably not backward compat in a non-gpl way
  645. flow jonas’, not in my book
  646. dwd pep., Are you arguing, then, that since OMEMO has a viable replacement it's OK to get rid of it?
  647. jonas’ flow, in practice it is
  648. jonas’ OMEMO1 clients won’t be able to read OMEMO2 messages
  649. pep. dwd, when, not since
  650. Daniel hardcoded strings and unspeced protobuf
  651. flow jonas’, sure the XML element definition will be different, but the keys could be the same
  652. jonas’ it’s "This message is OMEMO encrypted ..." all over again
  653. Daniel that may or may not be gpl
  654. dwd pep., Because you cannot argue that Swift can just implement OX unless you believe that OX is a replacement.
  655. Daniel plus if we are going to introdcue breaking changes we also might want to fix other things
  656. jonas’ something second system syndrome
  657. pep. dwd, replacement as in "widely used encryption mechanism". It's not exactly a replacement for OMEMO in the sense that it doesn't have Forward Secracy (but I'm of those that say that most don't need it)
  658. flow jonas’> OMEMO1 clients won’t be able to read OMEMO2 messages sure but there is nothing one can do about it
  659. jonas’ flow, and that’s why people don’t want to move from OMEMO1
  660. larma Just my feelings to this whole story: nobody wants to implement the full protocol. Mostly because crypto is hard to get right and thus implementing it is timely and expensive. Those that are GPL-compliant are mostly fine with using libsignal (or creating a derivative thereof), but those that aren't GPL-compliant cannot and thus are in the situation that the feature of implementing OMEMO is requested but can't be realized. OMEMO puts non-GPL-compliant implementations at a financial disadvantage.
  661. Daniel jonas’, well yes and no. there are some relatively low hanging fruit that could be fixed
  662. Daniel but not backwards compatible
  663. ralphm A lot of this is a rehash of earlier discussions, but we never made it explicit that the XEP in its current form is not acceptable to our process. Also see remko's efforts in https://github.com/xsf/xeps/pull/463
  664. Daniel ralphm, i think nobody is denying that it is a shitty xep
  665. jonas’ Daniel, cp xep-0384.xml inbox/daniels-omemo2.xml and get started? ;)
  666. flow jonas’> flow, and that’s why people don’t want to move from OMEMO1 IMHO OMEMO1 has enough issues to be incentived to move away from it, but YMMV
  667. Daniel jonas’, not _my_ harddrive 🙂
  668. ralphm larma: and I also think that this is *the* reason why accepting OMEMO, even as historical or informational, doesn't send the right message from the XSF.
  669. jonas’ flow, IMO, OMEMO can die in a housefire, but that’s just me. I think we’re quite alone on that island ;)
  670. ralphm jonas’ not at all
  671. flow jonas’, It's fine if you don't care about a XEP if you don't actively fight it
  672. pep. larma, to this specific comment I can say "I'm fine with it. That's the whole point of GPL." (independently of OMEMO being a XEP) :X
  673. jonas’ flow, I don’t "fight" it for those reasons.
  674. jonas’ flow, I fight it because I think that ralphm and dwd are right.
  675. Half-Shot has joined
  676. jonas’ my fight against OMEMO itself mostly consists of "No omemo here" replies to messages which are OMEMO encrypted *shrug*
  677. flow ok, let me specifiy this "if you don't actively fight it's development"
  678. ralphm pep., yes, the choice of GPL is intentional, and detrimental to open protocol development.
  679. pdurbin has joined
  680. ralphm (because there is no protocol spec)
  681. jonas’ flow, I’m just trying to make a point that for many people, OMEMO1 is just good enough, even if there are many reasons why it should not.
  682. jonas’ flow, thus supporting your YMMV
  683. larma ralphm, is it against the XSF objective 4 if implementing a protocol using a GPL library is cheaper than implementing it without?
  684. jonas’ larma, no, but the question here is whether it is legally POSSIBLE to implement it without the GPL library.
  685. flow that ^
  686. jonas’ and this question is not answered without a lawyer and probably a court case. and this is why this is an encumberence, even if it IS legally possible to do so
  687. ralphm larma, using a GPL library is fine. Having the GPL library being the only source of information to implement it independently, without it being a derivative work and thus subject to the GPL *is*
  688. larma jonas’, you could argue the same for *every* XEP
  689. jonas’ larma, no
  690. jonas’ XEPs which fully describe the protocol can clearly be implemented non-GPL
  691. jonas’ because they are under XSF IPR
  692. jonas’ XEPs which rely solely on other open standards (e.g. RFCs)are the same
  693. larma jonas’, sure, so if I just put all the required stuff in the XEP what happens then?
  694. jonas’ larma, then you’re liable
  695. jonas’ if that’s under GPL and you passed it to the XSF while having the IPR signed
  696. jonas’ you will be liable for that when moxie sues an implementation
  697. jonas’ the implementation can point at the XEP, the XSF can point at you
  698. dwd jonas’, Actually I suspect the XSF might be liable.
  699. Zash Isn't that how cleanroom implementations are done? One team looks at gpl code and writes docs.
  700. jonas’ dwd, at this point, probably yes, because we already have publicly stated that we have doubts
  701. flow "it doesn’t really matter because some members of the 'OMEMO community' have working drafts for 'OMEMO 2' on their hard drives" It would be great if that development of OMEMO2 wouldn't happen on ppls hard drives but instead in a public repo (with rendered htmls put online somewhere). I don't even say that it has to happen within the XSF
  702. ralphm dwd: that's an interesting point that might graduate it to Board territory.
  703. flow Daniel, ^
  704. larma As mentioned on list, I have no problem with publishing all the protocol details that are missing under a permissive license, I just don't know what exactly is missing
  705. ralphm So I guess we can point to Daniel.
  706. jonas’ larma, nobody who hasn’t implemented it without libsignal does.
  707. ralphm (who put in the dependency on libsignal, if I remember correctly)
  708. eevvoor has left
  709. flow larma, please do so
  710. pep. flow, one of the reasons why the SIG is happening I think
  711. jonas’ larma, i.e., to find out, try that
  712. pep. flow, I also want that, transparency
  713. flow I think it is easy to find out what is missing. Just add everything that is missing from the XEP
  714. flow pep., that nice, but you don't have to form a SIG to invite people to collaborate ;)
  715. ralphm flow this
  716. pep. Well.. people are what they are
  717. larma If OMEMO2 is only using a different wire protocol (replacing protobuf with xml) than that should be easy, because the wire protocol is protobuf
  718. pep. You need to get them motivated to do things
  719. pep. We're not all paid to do stuff
  720. ralphm a SIG is not super special. I would also like to point to XEP-0019 for a bit of history of SIGs.
  721. pep. I've read that one yes
  722. tao has left
  723. Daniel flow, if it were my harddrive i would
  724. Shell has left
  725. ralphm pep., I'm not payed to this stuff, either. Interestingly, commercial entities generally are, and they can't implement OMEMO in its current form for the arguments-discussed-at-length. Moxie at some point said they'd provide a spec, but things were still in flux.
  726. dwd pep., You know, I'm not sure any of us are paid to do this anymore.
  727. Daniel however it doesn’t really solve the "we don’t know how to migrate" issue
  728. dwd Daniel, Well, non-migration between crypto protocols isn't unique to OMEMO.
  729. ralphm They'll probably remain in flux, so depending on an everchanging library isn't a great place to be, and not having a matching spec is not an acceptable starting point.
  730. flow Daniel, it appears there is no good solution besides probably a grace period where clients send OMEMO1 and OMEMO2 together
  731. flow don't ask me how long that period should be
  732. sonny has left
  733. dwd Daniel, And is a particular problem with E2EE in IM. Long talks about that in the MLS WG as well.
  734. flow OTOH it appears that most OMEMO developers are agile
  735. pep. flow, at this point I'd start working on MLS rather than having a migration period of "forever" already between OMEMO1 and OMEMO2
  736. mukt2 has left
  737. ralphm pep., great!
  738. pep. (not me personally)
  739. flow pep., do ash you like, but I think it is sensible to put effort into OMEMO2
  740. pep. And another migration period of "forever" between OMEMO2 and MLS
  741. ralphm pep., (aw)
  742. sonny has joined
  743. pep. ralphm, as funny as it might seem from me arguing about all this, I don't use e2ee very much myself :)
  744. ralphm I think it would be a worthwhile excercise to see what needs to be done to do MLS in XMPP, compared to potential work on OMEMO.
  745. pep. I think the migration effort outweights everything
  746. pep. Debian, RHEL, $things
  747. pep. In 10 years we're still sending OMEMO1
  748. ralphm pep., I personally really dislike the way OTR and OMEMO have worked so far, and any solution that has a similar pattern will be vigorously disabled by me.
  749. jonas’ ralphm, I’m curious which aspect you’re talking about, because my experience with OTR was quite pleasant, while OMEMO was terrible.
  750. jonas’ s/was/was and still is/
  751. jonas’ s/was/was and still is/g
  752. pep. jonas’, I'm also curious which aspect of OTR you find pleasant
  753. pep. (compared to OMEMO)
  754. Daniel and yes being unsure if we even want to solve the migration to omemo 2 or start working on 'something else' is also a hurdle that prevents people from working on omemo 2
  755. dwd Jr fubhyq nyy hfr EBG13
  756. ralphm jonas’, I have been using XMPP since 2000, and have seen a lot, using multiple clients simultaneously, and every time somebody tried to send me a message with OTR or OMEMO, I ran into issues of not being able to read it.
  757. jonas’ pep., it isn’t instrusive like OMEMO is.
  758. dwd jonas’, Also you can type OTR manually.
  759. pep. dwd, https://ppjet.bouah.net/rot13.py (poezio plugin)
  760. jonas’ pep., I get OMEMO encrypted messages forever just because I have Conversations installed, but 2 out of 3 of my clients don’t support OMEMO, and two out of three never will.
  761. pep. Ah wait I have a better one now that we have the E2EE API :p
  762. pep. jonas’, I remember mod_otr in prosody preventing you from sending messages that were not OTR encrypted.
  763. pep. I don't think that's really better
  764. jonas’ pep., that’s a problem of a server deployment
  765. jonas’ not a general problem of the thing
  766. pep. But you got to get the green checks
  767. mukt2 has joined
  768. pep. :)
  769. jonas’ pep., missing the point
  770. Zash jonas’: green checkmarks!!!1!1!eleven
  771. pep. I don't think OMEMO is worse in this regard tbh
  772. Zash MUST HAVE GREEN CHECKMARKS AND E2EE!!!!
  773. pep. That's a policy of the clients. Enabling OTR/OMEMO by default
  774. pep. Whether you are capable of receiving it or not
  775. Zash MUST HAVE GREEN CHECKMARKS AND E2EE ENABLED BY DEFAULT!!!
  776. debacle has joined
  777. pdurbin has left
  778. ralphm Additionally, I think that there are features in XMPP that compete with the notion of E2EE and the kinds of protections it provides to the end user. To the point that I'm sure you can always make the argument that e2ee in XMPP remains insufficient to some groups of users.
  779. jonas’ pep., no, the difference is the mechanism of discovery of support
  780. jonas’ the one used by OMEMO is unreliable
  781. jonas’ ("are keys published?")
  782. jonas’ the one used by OTR is reliable, barring server intervention ("is the secret whitespace handshake sent?")
  783. jonas’ the one used by OTR is reliable, barring server intervention ("is the secret whitespace handshake sent in the message I just got?")
  784. pep. Ok, on the theory maybe
  785. jonas’ ralphm, agreed
  786. jonas’ pep., in practice.
  787. pep. In practice clients would probably just enable OTR because what Zash said
  788. jonas’ also, you notice when the OTR handshake fails and don’t blindly send encrypted messages which won’t be readable
  789. jonas’ because OTR has a handshake
  790. krauq has left
  791. mathijs has left
  792. mathijs has joined
  793. jonas’ pep., "would" -- OTR has been around since forever. There is no "would" here, we can look at the state of what clients are still doing.
  794. calvin has left
  795. pep. Ok
  796. jonas’ (or what they did before they dropped support for OTR in favour of OMEMO)
  797. !XSF_Martin jonas’: A Chatsecure always sent me otr garbage although I had never otr enabled with any client on that jid …
  798. pep. (There are still new clients getting OTR support fwiw)
  799. jonas’ !XSF_Martin, neat, that’s the first time I hear that. However, that garbage was most certainly not a message you missed.
  800. jonas’ in contrast to OMEMO
  801. mukt2 has left
  802. dwd pep., libotr is LGPL...
  803. pep. dwd, context?
  804. dwd > (There are still new clients getting OTR support fwiw)
  805. mathijs has left
  806. mathijs has joined
  807. pep. I was thinking about a fork of conversations. That also removed OMEMO support iirc
  808. pep. But I'm sorry I don't understand what you want to say
  809. Zash pep.: Not all those forks that just did search and replace on everything, including the OMEMO siacs namespace?
  810. dwd pep., I mean, not only does OTRv3 have a detailed specification including wire format, but it also has a library that's more easily used, license-wise.
  811. pep. Ah my bad it's not a fork of conversations. I was thinking of https://github.com/coyim/coyim
  812. dwd ?OTRv23?
  813. dwd Anyone?
  814. dwd :-)
  815. pep. dwd, sure. That's not exactly compatible with how we want to use XMPP in the open world (from what I understand), but that's a direction a set of products can take for sure
  816. tao has joined
  817. ralphm ?OTRvTemp?
  818. pep. (multiple devices anyone?)
  819. mukt2 has joined
  820. Tobias has left
  821. Tobias has joined
  822. Lance has joined
  823. krauq has joined
  824. mukt2 has left
  825. mukt2 has joined
  826. tao has left
  827. Steve Kille has left
  828. Steve Kille has joined
  829. mathijs has left
  830. mathijs has joined
  831. rion Are you guys taking about deprecating omemo in favor of otr?
  832. Zash I don't think so
  833. mukt2 has left
  834. Dele (Mobile) has left
  835. mathijs has left
  836. mathijs has joined
  837. dwd rion, No.
  838. moparisthebest I think deprecating omemo in favor of $some_future_protocol_that_might_be_better ?
  839. dwd rion, For two reasons: Firstly, we don't deprecate "in favour of" anything. Secondly, we all agree that OTR is a bit pants.
  840. dwd rion, That said, there *is* an OTR XEP, and everyone is, I think, confident it can be implemented by anyone.
  841. moparisthebest when you say "implemented by everyone" are you speaking technically or legally ?
  842. pep. rion, indeed we're not deprecating in favor of anything..
  843. moparisthebest because surely omemo and otr are both capable of being implemented by anyone from a technical perspective right?
  844. dwd I said "implemented by anyone", meaning that anyone *could* implement. There is both technical information available and no licensing restrictions upon it.
  845. moparisthebest legally, well depending on how licenses are interpreted in a given jurisdiction, or whether encryption is illegal or not, "it depends" for both otr and omemo
  846. moparisthebest so I guess you are saying the XSF is in the business of interpreting license legality across jurisdictions around the world, which seems insane to me
  847. rion in Russia any encryption unavailable for deciphering by the government is illegal. But anyway I hope nothing was implemented in vain :)
  848. dwd moparisthebest, Are you saying the XSF should take the position that all IPR is meaningless?
  849. moparisthebest there are probably other reasons to do OMEMO differently, I just don't think licensing of any code should be one of them
  850. dwd moparisthebest, And you are very much in the minority there.
  851. rion I think those XEPs should have something about availability for government :)
  852. moparisthebest sure, otherwise it's illegal in russia and probably china, better remove TLS too since not everyone can implement it
  853. mukt2 has joined
  854. moparisthebest /sarcasm (just to be clear :) )
  855. rion we just need some xeps how to properly implement backdoors on servers
  856. moparisthebest I do hate how all this looks to an outsider, not just this, but we are in a similar position with a lot of protocols aren't we?
  857. dwd moparisthebest, No, I don't think so.
  858. moparisthebest Q: "how can I add color to my messages in XMPP?" A: "well we had xhtml-im and some things implement it, but it's deprecated, one day we might have a good way to do it"
  859. dwd moparisthebest, Oh, deprecation you mean.
  860. moparisthebest Q: "how can I do sane group chat in XMPP with mobile etc?" A: "well we have a group chat that doesn't work so well in mobile, but we refuse to improve it, there is a proposal for one that'll probably work good one day but nothing implements it"
  861. moparisthebest Q: "how can I do e2e in XMPP?" A: "well any of 4 or so ways, the most widely deployed is now deprecated and we might have a replacement one day"
  862. moparisthebest it's almost a theme isn't it?
  863. dwd moparisthebest, I've implemented MIX twice. That whole situation frustrates the hell out of me, too.
  864. dwd moparisthebest, But XHTML-IM... Yeah, I'm not sorry to see that one go.
  865. moparisthebest it seems like XSF is working/waiting on the *perfect* solution, while everyone else trudges along with *good enough*
  866. dwd moparisthebest, Also I think I'm probably right if I asserted that OTR is the most widely deployed outside this bubble.
  867. rion xhtml-im was good. maybe not that good as markdown but good anyway.
  868. moparisthebest rion, as has been pointed out countless times, we don't have anything resembling a markdown XEP :)
  869. dwd rion, Yes, except literally every client that implemented it had a security issue relating to it.
  870. moparisthebest (also markdown doesn't support coloring)
  871. Zash markdown is a html superset, therefore it also sucks
  872. dwd moparisthebest, Honestly, does anyone care about colouring? I mean, during the whole discussion I think Ge0rG mentioned it about source-code highlighting in messages, which is pretty niche.
  873. moparisthebest also I understand the whole xhtml-im thing and even agree with it, just pointing out how all of these things must look to an outsider
  874. rion dwd: well I filtered it in iris. everything but css styles which made a lot of fun to filter out =)
  875. calvin has joined
  876. Zash moparisthebest: everything is terrible
  877. dwd rion, "fun" is not what I want in security-sensitive code. :-)
  878. moparisthebest I was trying to decide if I was more frustrated with MUC/MIX or e2e, and I guess it's gotta be MUC/MIX because at least the (deprecated) e2e has deployed running code :)
  879. Zash So, who wants to cp xep-0071.xml inbox/xhtmlim-but-better.xml ? Link Mauve?
  880. winfried has left
  881. winfried has joined
  882. rion I understand that but when on 1st april you inject a style which put a group chat up side down it looks awesome :)
  883. rion for everyone ))
  884. dwd moparisthebest, I've argued before that I'm concerned we may have gone in a bad direction with MIX.
  885. winfried has left
  886. winfried has joined
  887. Link Mauve Zash, sure.
  888. dwd moparisthebest, I joke that I've lost two jobs due to MIX, and I'm not entirely exaggerating either.
  889. rion inbox/xhtmlim-this-time-serous.xml works better ;-)
  890. dwd We did that joke, I think.
  891. moparisthebest any better time to try and fix it than now maybe dwd ? :)
  892. dwd rion, https://xmpp.org/extensions/xep-0402.html
  893. Zash XHTML-IM 2: Electric Boogaloo
  894. dwd moparisthebest, Yeah, lots of good times, like when I'm not swamped by both work and taking on too much from fastenings.
  895. flow dwd, you lost jobs due to MIX?
  896. dwd flow, As I say, it's something of an exaggeration.
  897. dwd flow, But my last job fell to pieces in part because of MUC vs MIX, and the difficulty in doing MIX without any client implementations.
  898. j.r has left
  899. dwd flow, The other one was more that the project I was working on - with MIX in both client and server - got canned and everyone else left, so eventually I did too.
  900. Shell has joined
  901. j.r has joined
  902. dwd flow, But had MIX been widely deployed in, erm, March last year, I'd probably still have the job I had then.
  903. j.r has left
  904. flow I see. And I assume the resources (people, money, bitcoin, …) to implement MIX where not available?
  905. j.r has joined
  906. mukt2 has left
  907. moparisthebest maybe we should have a new business rule, that if an experimental xep doesn't have a single complete implementation in 7 years it's moved to deprecated/historical or something
  908. mukt2 has joined
  909. rion what if MIX didn't exist and had to be designed again. would it go as an extension to MUC instead of completely separate protocol?
  910. flow Link Mauve, do you have stats from jabber.fr about the current usage of e2ee in xmpp? something like x% of the messages of the past 30 days where encrypted with y?
  911. flow https://stats.jabberfr.org/d/000000002/jabberfr?orgId=1&fullscreen&panelId=36&from=now-7d&to=now is not really helpful to get an idea how widespread which encryption scheme is
  912. Link Mauve flow, I do have stats of that at https://stats.jabberfr.org/
  913. krauq has left
  914. Link Mauve Hmm, how do you do queries to Prometheus again?
  915. Link Mauve flow, seems like out of all of the encryption methods, OTR is by far the most popular.
  916. moparisthebest rion, the 2 I can pull up immediatly are https://xmpp.org/extensions/inbox/muc-light.html and https://docs.ejabberd.im/developer/xmpp-clients-bots/extensions/muc-sub/
  917. moparisthebest I think Xabber has their own, can't recall if it was submitted or not
  918. mathijs has left
  919. mathijs has joined
  920. moparisthebest I could be mistaken here, but I'm under the impression Xabber has put the most thought into "how can I make this work on the trash platform that is iOS", which requires insane measures
  921. Alex has left
  922. Alex has joined
  923. rion > Occupants cannot hide behind nicks. Their real bare JID is always visible to everyone I like this (no sarcasm)
  924. moparisthebest have you noticed there are virtually no useable iOS XMPP clients? and that's even just for regular private XMPP, it's worse for MUCs
  925. Alex has left
  926. Alex has joined
  927. Daniel muc/sub is mainly an attempt to fix push with the rest of it being an aftertought that didn’t really felt like anyone before me had implemented it
  928. Daniel and if you just look at who else has custom shit to fix the push issue tigase is also on the list
  929. rion > No exchange of any <presence/> stanza inside the room. online/offline status still has to be somehow reflected
  930. Link Mauve Hmm, Error executing query: parse error at char 40: range specification must be preceded by a metric selector, but follows a *promql.AggregateExpr instead
  931. Link Mauve sum(prosody_message_e2ee{type="plain"})[30d] doesn’t seem to work.
  932. karoshi has left
  933. karoshi has joined
  934. larma sum_over_time(prosody_message_e2ee{type="plain"}[30d]) ?
  935. Link Mauve Nor does taking the sum out.
  936. krauq has joined
  937. Link Mauve flow, 25543 plain messages, vs. 12286 encrypted ones.
  938. flow Link Mauve, I assume plain only includes message stanzas with <body/>?
  939. Link Mauve Out of those, 9742 OTR, 1917 OMEMO, 626 legacy OpenPGP, 0 OX.
  940. !XSF_Martin has left
  941. Link Mauve flow, messages with <body/> which don’t have one of the encrypted payloads too.
  942. flow Link Mauve, thanks
  943. flow Maybe you could make a graphana graph with sum_over_time?
  944. Link Mauve The source code of this module is here: https://hg.prosody.im/prosody-modules/file/70e5bab388d8/mod_measure_message_e2ee/mod_measure_message_e2ee.lua
  945. Link Mauve flow, sure!
  946. Link Mauve That could be more useful than the raw data.
  947. dwd Wow. I thought OTR might have a slim lead, not that it would have 4.5 times the number.
  948. flow dwd, maybe it's just two people heavily using OTR ;)
  949. flow Link Mauve, could you further filter this down by unique bare sender JID?
  950. mathieui dwd, there are probably bots talking to each other using OTR, to be fair
  951. Link Mauve flow, I don’t have this information available.
  952. flow Link Mauve, so one would need to modify the prosody module to count not only the stanzas but also the unique senders per encryption scheme
  953. Zash that sounds suddenly a lot more complex
  954. flow not sure if this would violate your privacy policy
  955. mathieui flow, that would probably suck privacy-wise and the prometheus efficiency would be awful
  956. mathieui one time series per JID is terrible.
  957. rion muc-sub is nice. if a server will still show the unavailable participant like he is still in muc but offline and with working private messaging with such a contact, that would be perfect.
  958. flow mathieui, it's not a time series per JID, but a time series per unique JID/encryption scheme
  959. flow I think
  960. mathieui which is worse :p
  961. flow something like "in the last 1h X unique jids used encryption Y"
  962. flow I don't see how this is worse to what you already do
  963. flow (performance wise)
  964. Link Mauve flow, so Prosody would also have to remember and flush out unique JIDs? :/
  965. Link Mauve That’s starting to get expensive.
  966. rion moparisthebest: I would definitely implemented muc-sub if it ever comes to a real xep and wrt to my notes above.
  967. Zash flow: what it currently does is just keeping simple incrementing counters
  968. !XSF_Martin has joined
  969. krauq has left
  970. krauq has joined
  971. marc has left
  972. Link Mauve flow, the graph with sum_over_time() is seriously slowing down Prometheus.
  973. Link Mauve It’s using 100% of the CPU for quite some time. :/
  974. Link Mauve 9s of 100% CPU just for 1h.
  975. Link Mauve 1h for the past seven days.
  976. Link Mauve mathieui, we’re losing values from before ~eleven days ago, is it a Prometheus configuration issue?
  977. mathieui we might want to purge the database
  978. mathieui I haven’t done anything serious prometheus since 2 years ago
  979. marc has joined
  980. Tobias has left
  981. j.r has left
  982. j.r has joined
  983. Tobias has joined
  984. j.r has left
  985. j.r has joined
  986. Shell has left
  987. Shell has joined
  988. calvin has left
  989. sonny has left
  990. winfried has left
  991. winfried has joined
  992. pdurbin has joined
  993. calvin has joined
  994. sonny has joined
  995. Wojtek has left
  996. pdurbin has left
  997. lovetox has joined
  998. sonny has left
  999. Dele (Mobile) has joined
  1000. sonny has joined
  1001. debacle has left
  1002. sonny has left
  1003. Nekit has joined
  1004. Vaulor has left
  1005. Vaulor has joined
  1006. aj has joined
  1007. aj has left
  1008. aj has joined
  1009. dwd rion, muc-sub is almost MIX, except that MIX delivers messages as traditional message stanzas, and presence likewise, whereas muc-sub doesn't do that.
  1010. adiaholic has left
  1011. aj has left
  1012. aj has joined
  1013. dwd rion, MUC Light is basically a MUC butchered into not being presence-driven. It works, but it's also a dead end.
  1014. adiaholic has joined
  1015. aj has left
  1016. aj has joined
  1017. sonny has joined
  1018. Daniel And minus mix pam
  1019. sonny has left
  1020. sonny has joined
  1021. adiaholic has left
  1022. aj has left
  1023. aj has joined
  1024. waqas has joined
  1025. sonny has left
  1026. aj has left
  1027. lovetox has left
  1028. lovetox has joined
  1029. joerg has joined
  1030. sonny has joined
  1031. moparisthebest did the Xabber guys ever end up actually proposing somehing?
  1032. moparisthebest that at least has running code...
  1033. dwd moparisthebest, Yes, running code is good. Although it does have a tendency to risk entrenching a bad solution, so there's that too.
  1034. moparisthebest yep
  1035. dwd moparisthebest, I mean, if my employer imposes its running code on you, you'd really hate some of the stuff that's been done for expediency.
  1036. moparisthebest oh no I'm well aware of "seems to work, ship it!", unfortunately
  1037. dwd moparisthebest, It's why I try to write specs on what we *should* have done...
  1038. Zash What came first, the spec or the implementation?
  1039. mathijs has left
  1040. mathijs has joined
  1041. pdurbin has joined
  1042. Maranda has left
  1043. Maranda has joined
  1044. sonny has left
  1045. pdurbin has left
  1046. sonny has joined
  1047. joerg has left
  1048. j.r has left
  1049. Dele (Mobile) has left
  1050. sonny has left
  1051. Dele (Mobile) has joined
  1052. Nekit has left
  1053. calvin has left
  1054. sonny has joined
  1055. mr.fister has joined
  1056. calvin has joined
  1057. sonny has left
  1058. sonny has joined
  1059. mathijs has left
  1060. mathijs has joined
  1061. calvin has left
  1062. calvin has joined
  1063. mukt2 has left
  1064. Shell has left
  1065. neshtaxmpp has joined
  1066. Dele (Mobile) has left
  1067. Dele (Mobile) has joined
  1068. dwd Zash, For almost everything I've done that I'm happy with, spec->implementation->spec.
  1069. Tobias has left
  1070. Zash has left
  1071. andy has left
  1072. calvin has left
  1073. karoshi has left
  1074. winfried has left
  1075. winfried has joined
  1076. calvin has joined
  1077. lorddavidiii has left
  1078. andy has joined
  1079. andrey.g has left
  1080. Dele (Mobile) has left
  1081. Dele (Mobile) has joined
  1082. krauq has left
  1083. Dele (Mobile) has left
  1084. Dele (Mobile) has joined
  1085. Dele (Mobile) has left
  1086. Dele (Mobile) has joined
  1087. Dele (Mobile) has left
  1088. winfried has left
  1089. winfried has joined
  1090. Dele (Mobile) has joined
  1091. Dele (Mobile) has left
  1092. lovetox has left
  1093. winfried has left
  1094. winfried has joined
  1095. winfried has left
  1096. winfried has joined
  1097. gav has left
  1098. gav has joined
  1099. calvin has left
  1100. calvin has joined
  1101. debacle has joined
  1102. moparisthebest has left
  1103. mukt2 has joined
  1104. wurstsalat has left
  1105. pdurbin has joined
  1106. Shell has joined
  1107. krauq has joined
  1108. goffi has left
  1109. calvin has left
  1110. mukt2 has left
  1111. pdurbin has left
  1112. mukt2 has joined
  1113. mukt2 has left
  1114. mukt2 has joined
  1115. Daniel has left
  1116. Daniel has joined
  1117. Daniel has left
  1118. mukt2 has left
  1119. andy has left
  1120. moparisthebest has joined
  1121. moparisthebest has left
  1122. moparisthebest has joined
  1123. paul has left
  1124. mukt2 has joined
  1125. Daniel has joined
  1126. andrey.g has joined