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


  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.


  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


  420. ralphm


  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


  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


  460. Zash


  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


  479. pep.


  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


  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


  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.


  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


  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


  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.


  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


  813. dwd


  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


  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


  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