XSF Discussion - 2018-08-02

  1. peter has left
  2. jjrh has left
  3. kasper.dement has joined
  4. 404.city has left
  5. lskdjf has joined
  6. kasper.dement has joined
  7. moparisthebest has left
  8. moparisthebest has joined
  9. waqas has joined
  10. blabla has left
  11. Syndace has left
  12. Syndace has joined
  13. labdsf has left
  14. labdsf has joined
  15. rishiraj22 has left
  16. rishiraj22 has joined
  17. dos has left
  18. mrdoctorwho has joined
  19. Zash has left
  20. rishiraj22 has left
  21. rishiraj22 has joined
  22. kasper.dement has joined
  23. kasper.dement has joined
  24. mrdoctorwho has left
  25. rishiraj22 has left
  26. Dave Cridland has left
  27. Dave Cridland has joined
  28. Dave Cridland has left
  29. Dave Cridland has joined
  30. Dave Cridland has left
  31. Dave Cridland has joined
  32. Dave Cridland has left
  33. Dave Cridland has joined
  34. anjan has joined
  35. 404.city has joined
  36. labdsf has left
  37. labdsf has joined
  38. kasper.dement has left
  39. kasper.dement has joined
  40. mimi89999 has joined
  41. mimi89999 has joined
  42. mimi89999 has joined
  43. moparisthebest has left
  44. moparisthebest has joined
  45. rishiraj22 has left
  46. kasper.dement has left
  47. daniel has left
  48. daniel has joined
  49. Dave Cridland has left
  50. Dave Cridland has joined
  51. Dave Cridland has left
  52. Dave Cridland has joined
  53. kasper.dement has joined
  54. Dave Cridland has left
  55. Dave Cridland has joined
  56. Chobbes has joined
  57. Dave Cridland has left
  58. Dave Cridland has joined
  59. Tobias has left
  60. Tobias has joined
  61. ta has joined
  62. kasper.dement has left
  63. kasper.dement has joined
  64. Andrew Nenakhov has left
  65. Dave Cridland has left
  66. Dave Cridland has joined
  67. Andrew Nenakhov has joined
  68. ta has joined
  69. kasper.dement has left
  70. jere has joined
  71. kasper.dement has joined
  72. intosi has left
  73. rishiraj22 has left
  74. 404.city has left
  75. mimi89999 has left
  76. moparisthebest has joined
  77. moparisthebest has joined
  78. kasper.dement has left
  79. ThibG has joined
  80. ThibG has joined
  81. ta has left
  82. ta has joined
  83. kasper.dement has joined
  84. Tobias has left
  85. Tobias has joined
  86. Nekit has joined
  87. mrdoctorwho has joined
  88. goffi has joined
  89. Dave Cridland has left
  90. kasper.dement has left
  91. kasper.dement has joined
  92. intosi has joined
  93. double has joined
  94. double has left
  95. double has joined
  96. double has left
  97. double has joined
  98. Dave Cridland has left
  99. Dave Cridland has joined
  100. intosi has left
  101. waqas has left
  102. daniel has left
  103. daniel has joined
  104. kasper.dement has joined
  105. karp has left
  106. karp has joined
  107. Guus has left
  108. Guus has joined
  109. ta has joined
  110. rishiraj22 has left
  111. kasper.dement has joined
  112. ta has joined
  113. intosi has joined
  114. Martin has left
  115. Martin has left
  116. jonasw 18:38:57 lovetox> one could do it that way, but then you would have to check from time to time, if your db stored prekeys are really the ones that are published you have to do that anyways because PEP services tend to "forget" your stuff from time to time
  117. Guus has left
  118. Guus has joined
  119. Guus has left
  120. Guus has joined
  121. Martin has left
  122. mrdoctorwho has joined
  123. Guus has left
  124. Guus has joined
  125. lnj has joined
  126. kasper.dement has joined
  127. kasper.dement has joined
  128. karp has left
  129. karp has joined
  130. kasper.dement has left
  131. mikaela has joined
  132. Dave Cridland has left
  133. Dave Cridland has joined
  134. rishiraj22 has left
  135. Dave Cridland has left
  136. Dave Cridland has joined
  137. kasper.dement has joined
  138. labdsf has left
  139. Guus has left
  140. Guus has joined
  141. alacer has joined
  142. Guus has left
  143. Guus has joined
  144. Ge0rG Isn't it awesome how the xmpp and OMEMO identity models extend each other?
  145. jonasw I sense sarcasm
  146. kasper.dement has joined
  147. rishiraj22 has left
  148. Guus Ge0rG, sarcasme? Nahhh...
  149. la|r|ma has joined
  150. Guus raises fist to autocorrect.
  151. lskdjf has joined
  152. flow Ge0rG, while it's trivial to change that?
  153. Dave Cridland has left
  154. Dave Cridland has joined
  155. kasper.dement has joined
  156. Dave Cridland has left
  157. Dave Cridland has joined
  158. Martin has left
  159. Ge0rG flow: one of the strong opinions that I hold is: if you want cryptographic identities, you should have a protocol using those as a first-level citizen, not tacked upon another routing protocol
  160. labdsf has joined
  161. marc has joined
  162. labdsf has left
  163. labdsf has joined
  164. flow Ge0rG, I know. But what do you suggest an xmpp based e2ee protocol should do? Using the public key as one's JID localpart?
  165. mikaela has left
  166. Guus has left
  167. Guus has joined
  168. moparisthebest has joined
  169. Ge0rG flow: I think there needs to be a stronger cryptographic link between the user identity, the key material and the JID.
  170. Ge0rG flow: if I was doing things, I'd go with user keys that contain a signature of the JID, plus maybe an S/MIME like CA system
  171. flow "signature of the JID"?
  172. flow or a signed statement of the user's JID?
  173. mikaela has joined
  174. Ge0rG The latter.
  175. flow I'm also not sure how that prove ownership of the JID
  176. Ge0rG It doesn't. But it means you can't move a key to a different JID
  177. flow And preventing that is desirable because?
  178. Nekit has left
  179. Nekit has joined
  180. marc has left
  181. Guus has left
  182. Guus has joined
  183. Ge0rG flow: I'm not sure. It's just a bad gut feeling, nothing specific. Maybe abuse of sloppy implementations leading to impersonation of other users...
  184. labdsf has left
  185. labdsf has joined
  186. rion has left
  187. 404.city has joined
  188. flow Ge0rG, So if you would be designing things, the main difference would be an additional signed statement of the JID and that only because of a gut feeling that it would possibly beneficial. Or did I miss something?
  189. kasper.dement has joined
  190. Guus has left
  191. Guus has joined
  192. Steve Kille has left
  193. Steve Kille has left
  194. Ge0rG flow: the main difference is: I would go with a two or three layer architecture. A user has their identity key (or primary device key), and signs their secondary keys. Plus a means to have a CA signing user keys bound to JIDs
  195. Steve Kille has joined
  196. Guus has left
  197. Guus has joined
  198. labdsf has left
  199. Guus has left
  200. Guus has joined
  201. flow Let me focus on the CA thingy first: What is the advantage over a CA verifying the "identity" by signing user keys compared to the public key in PEP? If you consider Let's Encrypt, then LE just checks that you have control over a certain "namespace", which is pretty much what public key in PEP provides.
  202. flow What additional benefit do you envison could a CA provide?
  203. 404.city has left
  204. Guus has left
  205. Guus has joined
  206. Guus has left
  207. Guus has joined
  208. kasper.dement has joined
  209. matlag has left
  210. Ge0rG flow: good point. A public CA doesn't help in needing to trust the server, and no amount of OOB will help
  211. andy has joined
  212. andy has left
  213. andy has joined
  214. Ge0rG A corporate CA might help, but then it's probably operated by the same people the server is
  215. mrdoctorwho has left
  216. mrdoctorwho has left
  217. daniel has left
  218. daniel has joined
  219. Martin has left
  220. 404.city has joined
  221. Martin has left
  222. Martin has left
  223. Martin has left
  224. Martin has left
  225. Martin has joined
  226. Martin has left
  227. Dave Cridland has left
  228. Dave Cridland has joined
  229. mrdoctorwho has joined
  230. la|r|ma has joined
  231. la|r|ma has joined
  232. kasper.dement has joined
  233. Ge0rG The major problem I see with OMEMO is multi-device key management. A client message of "You seem to have added a new device at 12:10, with the following fingerprint: ... - correct? [Yes] [No]" with a cross-key signing is vastly better than forcing every one of your contacts to manually verify that fact.
  234. j.r has joined
  235. jubalh has joined
  236. j.r has left
  237. muppeth has joined
  238. muppeth has joined
  239. daniel has left
  240. daniel has joined
  241. lskdjf has left
  242. Syndace Ge0rG: I like the idea a lot! Has this been discussed before?
  243. Ge0rG Syndace: I suggested that to daniel back when OMEMO was being designed.
  244. Ge0rG The idea was not approved.
  245. Syndace Hmm, is there a mailing list thread or do you remember the reason?
  246. Ge0rG Apparently because automatically trusting a new key which is signed by your friend's old key is a security issue.
  247. Ge0rG Or maybe because signing keys is not trivial. Or both.
  248. daniel Why not share the key?
  249. daniel That seems easier than cross signing
  250. Ge0rG daniel: what exactly do you mean by "share the key"
  251. daniel Using the same key
  252. daniel Like OX
  253. Ge0rG daniel: ah, a user key as opposed to a device key
  254. Syndace How do you get the key to the new device
  255. Ge0rG Syndace: QR code with a red border:P
  256. daniel Yeah. Or put it in the cloud
  257. Syndace True, but then again, if one device gets compromised, all of them are
  258. Ge0rG Syndace: yes
  259. Ge0rG Syndace: but that doesn't matter in practice.
  260. daniel And that's the same as cross signing
  261. Ge0rG Syndace: if one if your devices is compromised, the attacker gets the local history of that device and everything sent to you
  262. Syndace The cross signing issues don't matter as well
  263. Ge0rG daniel: as stated above, I prefer user keys to device keys.
  264. Ge0rG daniel: I thought that OMEMO required device keys anyway, so a two-tier key arch was my second best suggestion
  265. jonasw daniel, no, it’s not the same as cross-signing. a malicious key added by cross-signing can be removed individually and the damage is contained. if all your devices share the same key, you have to roll your key over entirely to fix the damage. right?
  266. Ge0rG or cross-signing
  267. daniel How do you revoke a key though
  268. Ge0rG start with a new user key.
  269. daniel I mean in case of device keys
  270. daniel What I'm saying is that I don't see the benefits of cross signing of sharing the private key
  271. Ge0rG daniel: you *could* add revocations to cross-signatures.
  272. jonasw hm
  273. Ge0rG the point that I made in the beginning (and am still making) is: with the user managing their own keys, you have O(1) key management overhead. With the contacts managing the user's keys you have O(N) for N contacts, and you have zero decision agency
  274. Ge0rG did Daniel just buy a new Pixel phone, or is the NSA impersonating? How am I supposed to know?
  275. daniel It's not news that trust is hard
  276. Ge0rG daniel: and you are making it even harder.
  277. rishiraj22 has left
  278. daniel Than?
  279. daniel Otr?
  280. Ge0rG daniel: harder than needed
  281. daniel Otr allowed for funny questions that I didn't knew the answer to
  282. daniel That was pretty fun
  283. Ge0rG daniel: are you still on holiday? Have a nice time and let's talk seriously when you're back
  284. j.r has joined
  285. lumi has joined
  286. la|r|ma has joined
  287. kasper.dement has joined
  288. rishiraj22 has left
  289. rishiraj22 has joined
  290. rishiraj22 has left
  291. rishiraj22 has joined
  292. kasper.dement has left
  293. kasper.dement has joined
  294. Guus has left
  295. Dave Cridland has left
  296. Guus has joined
  297. Guus has left
  298. Dave Cridland has left
  299. Guus has joined
  300. kasper.dement has left
  301. daniel has left
  302. daniel has joined
  303. andy has left
  304. jubalh has joined
  305. daniel has left
  306. daniel has joined
  307. intosi has joined
  308. double has left
  309. double has joined
  310. flow Ge0rG, I still don't know how "xmpp and OMEMO identity models extend[ing] each other" fits into the picture, and what you suggest should change
  311. daniel has left
  312. daniel has joined
  313. remko has joined
  314. kasper.dement has joined
  315. Ge0rG flow: apparently it wasn't clear to everybody. My statement was utterly sarcastic.
  316. flow Ge0rG, so besides cross-signing keys, you are happy with omemo?
  317. Ge0rG flow: I'm happy with ignoring its existence.
  318. Dave Cridland has left
  319. flow It appears you are not very good at it
  320. Dave Cridland has left
  321. 404.city has left
  322. Dave Cridland has left
  323. Ge0rG flow: for practical matters, I am.
  324. Dave Cridland has left
  325. Dave Cridland has left
  326. kasper.dement has joined
  327. daniel has left
  328. daniel has joined
  329. Dave Cridland has left
  330. Valerian has joined
  331. Dave Cridland has left
  332. jubalh has joined
  333. Dave Cridland has left
  334. daniel has left
  335. Ge0rG obviously, I can't completely ignore it with my Council member hat on.
  336. daniel has joined
  337. kasper.dement has joined
  338. kasper.dement has left
  339. kasper.dement has joined
  340. nyco has left
  341. nyco has joined
  342. Syndace alright honestly, why is the hate against omemo so huge in this whole community? I haven't had problems with it, not one single time.
  343. kasper.dement has joined
  344. Syndace because checking fingerprints is a pain? because "This message is OMEMO encrypted, your client does not seem to support it"?
  345. daniel A little bit of both probably. And people also like to complain about things
  346. winfried has joined
  347. Syndace that's far from enough reason to spread such hate
  348. daniel That's the internet
  349. Kev I don't think anyone /hates/ it, it's a protocol. I think several people see there are issues with it.
  350. Ge0rG And other people think that E2EE should be enforced upon everyone, which leads to hate indeed.
  351. MattJ that isn't specific to OMEMO
  352. Ge0rG E2EE by means of OMEMO.
  353. Ge0rG And then non-technical users complain that their messages don't get delivered, and we have one *additional* place to look for.
  354. MattJ Someone spent months trying to contact me once, but they had mod_require_otr enabled on their server and I couldn't reply
  355. MattJ and the only contact I had for them was their JID
  356. MattJ I had a similar situation where I logged into my account with Conversations to test something, and then a bunch of people couldn't message me anymore
  357. Ge0rG MattJ: should've sent them "?OTRv2 hi please disable mod_require_otr"
  358. jonasw Ge0rG, more than one place, because OMEMO is such a mess of moving parts
  359. Ge0rG MattJ: yes, publishing an OMEMO pre-key wreaks havoc to all your other clients.
  360. MattJ I don't consider myself an "OMEMO hater" though, I think I've rarely mentioned it... I've many other things to complain about before I could get to that :)
  361. MattJ jonasw, is it such a mess?
  362. Syndace > MattJ: yes, publishing an OMEMO pre-key wreaks havoc to all your other clients. What?
  363. jonasw MattJ, with the unstable PEP implementations out there and inconsistency in handling of OMEMO messages with and without surrogate body (on all levels), yes
  364. MattJ Both seem like things that could be relatively easily fixed
  365. MattJ A non-PEP key distribution protocol would be pretty trivial
  366. andy has joined
  367. Ge0rG MattJ: > Both seem like things that could be relatively easily fixed The story of XMPP.
  368. MattJ Ge0rG, some things are more easily fixed than others :)
  369. MattJ OMEMO does not seem like our worst problem by far
  370. kasper.dement has joined
  371. MattJ Syndace, some of my clients don't support OMEMO, I don't particularly want to use OMEMO either
  372. Syndace What about: When starting a new chat, the client sends the messages unencrypted in the message body AND encrypted using OMEMO at the same time and based on whether the response is OMEMO encrypted the client decides whether to stick with omemo or go on plaintext
  373. MattJ Syndace, I think my problem is more with the way Conversations enforces it, than the protocol
  374. Ge0rG Syndace: doesn't work in multi-client scenarios
  375. Syndace What does mutli client scenario mean? group chat?
  376. MattJ Syndace, multiple clients on the same account
  377. MattJ which just about every XMPP developer has
  378. Syndace True, all of them need OMEMO to receive the message
  379. Ge0rG all of them need to support OMEMO and have their prekey published and trusted by the sender
  380. Ge0rG that's a large number of moving parts.
  381. Syndace yeah i see
  382. Ge0rG especially if you test multiple desktop clients, multiple mobile clients and do web sessions from time to time
  383. vanitasvitae has left
  384. Ge0rG so you either end up with one client polluting your PEP with keys, leading to all your contacts sending you garbage, or with other corner cases of the protocol
  385. Kev As long as clients don't go enabling omemo for you automatically, which would obviously be broken, I don't see this as particular problem.
  386. Kev Or, rather, not something that can be solved.
  387. Kev Because once you hit the "I want to e2e" switch, you *want* to avoid non-e2e clients getting plaintext.
  388. Ge0rG Kev: I've heard that Conversations will auto-enable E2EE.
  389. Kev And so you're just not going to flick that switch if you want to use non-e2e clients. Irrespective of whether that's omemo or other.
  390. jonasw Ge0rG, Conversations *does* auto-enable E2EE
  391. jonasw even if no keys are seen.
  392. jonasw (you get a warninng and an option to disable when you send a message then)
  393. Ge0rG Besides of this, there is no secure way to communicate the status of that hypothetical "I want to e2ee" switch.
  394. rishiraj22 has left
  395. jonasw 't
  396. Ge0rG now attempts to rhyme "e2ee" to "break free"
  397. Kev Ge0rG: Well, there's HSTS-ish at least.
  398. Kev Ge0rG: You want to rhyme it to "to break free"
  399. Kev Then it works.
  400. Ge0rG Kev: except that HSTS relies on a semi-corrupt CA hierarchy
  401. MattJ Syndace, and here you get the problem described by XMPP developers. When we (e.g. I'm a server developer) have to deal with users who encounter these problems and want to know why their messages are not being delivered... it's extremely difficult to help them
  402. Kev Do I not mean HSTS? I mean "Ok, I'm telling you now, don't use me in the future if I stop encrypting", anyway.
  403. Ge0rG I don't want to be used by Kev
  404. Ge0rG irregardless of E2EE
  405. MattJ Syndace, I think that could be solved with better tooling (as well as improving client UIs)
  406. jonasw Ge0rG, lol
  407. Kev That's what you think, but you're mistaken (Ge0rG)
  408. jonasw get a room
  409. ta has joined
  410. Ge0rG jonasw: if only MUC invitations were working reliably.
  411. Syndace I think it's a very bad idea that clients enable encryption even if they know that one of the receiving devices does not support it. Silently dropping messages is a super bad idea confusing WhatsApp-level users
  412. Ge0rG Syndace: there is no notion of "user's devices" so it's impossible to know whether all devices support OMEMO
  413. jonasw Syndace, problem is: if you don’t do that, servers (which are the bad guys™ in the e2ee scenario) can trivially downgrade you to plaintext
  414. Kev jonasw: They have to do it from the get-go, though.
  415. jonasw Kev, in your case, yes
  416. Kev Well, depending on exactly what's implemented :)
  417. Kev Right.
  418. 404.city has joined
  419. 404.city has left
  420. double has left
  421. Str4tocaster has joined
  422. Str4tocaster has left
  423. Str4tocaster has joined
  424. Dave Cridland has left
  425. Dave Cridland has left
  426. kasper.dement has joined
  427. kasper.dement has joined
  428. mrdoctorwho has left
  429. intosi has joined
  430. daniel has left
  431. daniel has joined
  432. kasper.dement has left
  433. kasper.dement has joined
  434. vanitasvitae has left
  435. kasper.dement has left
  436. Guus has left
  437. Guus has joined
  438. blabla has joined
  439. Guus has left
  440. Guus has joined
  441. blabla has joined
  442. kasper.dement has joined
  443. karp has left
  444. karp has joined
  445. blabla has joined
  446. Guus has left
  447. Guus has joined
  448. Guus has left
  449. Guus has joined
  450. winfried has joined
  451. Dave Cridland has left
  452. kasper.dement has joined
  453. Zash has joined
  454. winfried has joined
  455. jere has joined
  456. kasper.dement has joined
  457. rishiraj22 has left
  458. Steve Kille has left
  459. Str4tocaster has left
  460. Str4tocaster has joined
  461. Str4tocaster has left
  462. blabla has joined
  463. rishiraj22 has left
  464. Holger has left
  465. mimi89999 has left
  466. kasper.dement has joined
  467. mrdoctorwho has joined
  468. ta has left
  469. andy has left
  470. kasper.dement has joined
  471. winfried has left
  472. Guus has left
  473. Guus has joined
  474. winfried has joined
  475. Str4tocaster has joined
  476. Guus has left
  477. Guus has joined
  478. Guus has left
  479. Guus has joined
  480. Guus has left
  481. Guus has joined
  482. Guus has left
  483. Guus has joined
  484. ralphm has joined
  485. intosi has left
  486. dos has joined
  487. matlag has left
  488. marc has joined
  489. dos has left
  490. dos has joined
  491. Str4tocaster has left
  492. kasper.dement has joined
  493. flow has left
  494. Kev has left
  495. kasper.dement has joined
  496. Str4tocaster has joined
  497. Str4tocaster has left
  498. Steve Kille has left
  499. vanitasvitae has left
  500. Guus has left
  501. Guus has joined
  502. Chobbes has joined
  503. Guus has left
  504. Guus has joined
  505. Guus has left
  506. Guus has joined
  507. Guus Made it just in time 🙂
  508. MattJ The question is, who else did? :)
  509. Guus You, for one. 🙂
  510. MattJ nyco, around?
  511. MattJ ralphm seems to have been popping in and out, I think he's on mobile
  512. Guus nyco mailed that he was not going to be here today.
  513. kasper.dement has joined
  514. Guus Martin?
  515. MattJ Oh, missed that
  516. MattJ Oh, Gmail marked that thread as "Not important" and I overlooked it
  517. Guus that'll teach you to have such a filter activated on my name. 🙂
  518. rishiraj22 has left
  519. Guus Shall we try this again next week?
  520. MattJ Yeah, I think so
  521. MattJ btw, Martin != Martin Hewitt
  522. intosi has left
  523. intosi has joined
  524. Guus ah. didn't know, tx
  525. Guus ok, I'm off for a bit then. ttyl!
  526. MattJ See you :)
  527. kasper.dement has joined
  528. Guus has left
  529. dos has left
  530. dos has joined
  531. vanitasvitae has left
  532. Dave Cridland has left
  533. kasper.dement has left
  534. vanitasvitae has left
  535. Alex has joined
  536. vanitasvitae has left
  537. vanitasvitae has left
  538. dos has left
  539. matlag has joined
  540. matlag has joined
  541. tux has joined
  542. kasper.dement has joined
  543. jjrh has left
  544. jjrh has left
  545. daniel has left
  546. daniel has joined
  547. jjrh has left
  548. kasper.dement has left
  549. kasper.dement has joined
  550. dos has joined
  551. lskdjf has joined
  552. mrdoctorwho has joined
  553. Guus has left
  554. Guus has left
  555. vanitasvitae has left
  556. Guus has left
  557. vanitasvitae has left
  558. vanitasvitae has left
  559. rishiraj22 has left
  560. rishiraj22 has left
  561. vanitasvitae has left
  562. Ge0rG has left
  563. rishiraj22 has left
  564. Ge0rG has left
  565. Guus has left
  566. vanitasvitae has left
  567. blabla has left
  568. blabla has joined
  569. tux has joined
  570. ralphm has joined
  571. Valerian has left
  572. tux has joined
  573. rishiraj22 has left
  574. la|r|ma has left
  575. Kev has left
  576. Guus has left
  577. Guus has left
  578. Martin has left
  579. Chobbes has joined
  580. vanitasvitae has left
  581. vanitasvitae has left
  582. vanitasvitae has joined
  583. blabla has joined
  584. tux has joined
  585. Guus has left
  586. jubalh has joined
  587. Guus has left
  588. vanitasvitae has left
  589. Guus has left
  590. Guus has left
  591. Guus has left
  592. peter has joined
  593. Nekit has left
  594. Guus has left
  595. Guus has left
  596. Nekit has joined
  597. vanitasvitae has left
  598. Yagiza has joined
  599. jubalh has left
  600. Chobbes has joined
  601. Syndace So, I collected the OMEMO issues that I was able to filter from the short discussion earlier and wrote down my thoughts and ideas about them: https://hackmd.io/x70DAtLgSHqBzke49_vBrg I'd like to hear whether I grasped the core of the issues and whether my thoughts/ideas make any sense lol. Also please tell me what's missing and feel free to add your own ideas and comments.
  602. Dave Cridland Syndace, Are you aware of the MLS work under way in the IETF?
  603. jubalh has left
  604. Syndace Oh boy, I was not
  605. MattJ Dave Cridland, I'm assuming you are following it because you keep talking about it. How far is it from something everyone can implement?
  606. Guus has left
  607. mrdoctorwho has joined
  608. Valerian has joined
  609. Guus has left
  610. goffi Syndace: we can't send some data becose there is not full stanza encryption. I'm specially missing xml:lang like I've explained on the @standard list (and some other like message markup).
  611. jonasw Syndace, section 1, Idea #2 seems waaaay too complex
  612. Guus has left
  613. Syndace jonasw, well but I think it would fix all issues at once
  614. Dave Cridland MattJ, Early days. But it's got some serious people working on it. You can actually get libraries and work with the current design, but it's approximately as scary as using TLS 1.3 draft 3 - chances of everything interopping in the future are pretty low.
  615. jonasw at the cost of UX, Syndace
  616. Guus has left
  617. Dave Cridland MattJ, I'm not saying we should switch now. I'm just saying we should be prepared to write off OMEMO as an experiment in a year or so.
  618. Syndace jonasw: True
  619. Syndace Dave Cridland: Well great.
  620. jonasw solving bad UX by making it worse doesn’t seem good to me :)
  621. Syndace jonasw: Not worse I think
  622. MattJ Dave Cridland, I don't think that's a reason to not attempt to fix problems we have today in parallel
  623. Guus has left
  624. MattJ If MLS is ready in a year, it's another 2-3 years before clients implement it widely enough
  625. Syndace jonasw: Do you think it's a super UX killer if you have to select which devices you want to exchange encrypted data with?
  626. MattJ meanwhile OMEMO is already quite popular today, even Pidgin supports it
  627. Dave Cridland MattJ, Well, I think we have an opportunity to show XMPP can be leading edge in this kind of thing.
  628. MattJ Sure, I'm up for that
  629. MattJ But the carousel of E2EE solutions is also a bit of a joke by now
  630. jonasw Syndace, yes, other systems have E2EE without such annoyinaces
  631. Dave Cridland MattJ, Yes, indeed.
  632. jonasw MattJ, no, pidgin *does not* support it.
  633. MattJ Let's not leave what we have working today at 90% for the next 1-3 years
  634. jonasw pidgin has two plugins both of which have their own quirks
  635. jonasw and it doesn’t even "have" those plugins as in they’re distributed, no, you have to get them from somewhere.
  636. MattJ jonasw, that worked against my argument, so I glossed over that (but yeah)
  637. jonasw Dave Cridland, MattJ, if we’re going to do another round in the E2EE protocol carousel (good term by the way), I’d suggest to tackle (nearly) full stanza encryption, to at least give it a benefit over staying with status quo
  638. Syndace jonasw: Is there a comparable system which allows multi-device e2ee where some devices do e2ee and some don't?
  639. ta has joined
  640. jonasw Syndace, I don’t know, actually. but users won’t care about that
  641. jonasw in the end, you can have signal/whatsapp/whatever on botth your laptop and your phone and it works just fine -- even if on your laptop, you just view stuff which is on your phone via webrtc or something
  642. jonasw and competing against that with a complex selection dialog whenever you want to do e2ee, just nope
  643. kasper.dement has joined
  644. Guus has left
  645. jubalh has joined
  646. Syndace jonasw: We could reduce it to "start private chat" which just starts the chat with all OMEMO-enabled devices and doesn't ask which devices should be included
  647. Syndace That way it would be a button click
  648. jonasw Syndace, and then we’re exactly where we are right now
  649. MattJ but not by default
  650. Dave Cridland jonasw, Sure. But given MLS also handles group chat (in fact, it *doesn't* handle anything but), that shoudl also provide impetus.
  651. jonasw Dave Cridland, OMEMO handles group chat today
  652. Syndace jonasw: Not really, because it's two seperate chats: One plaintext and one encrypted and the important thing: The user is aware that not all devices will get all messages
  653. goffi jonasw: is there a spec for that?
  654. Dave Cridland jonasw, Sort of. It handles groupchats by keying M times. MLS does it in one.
  655. jonasw goffi, dunno
  656. jonasw Dave Cridland, sorry, I have no idea
  657. jonasw I just know that it is possible
  658. Guus has left
  659. Dave Cridland goffi, Good grief no. Did you think OMEMO was one of those *open* standards?
  660. goffi I know Conversation and Gajim handle it, but I think it's unofficial for now (i.e. no XEP)
  661. jonasw Syndace, "but other systems do have e2ee by default, why can’t you?"
  662. lovetox has joined
  663. Guus has left
  664. Syndace jonasw: Because we don't forve you to use it. You can though, by clicking this button right here
  665. Zash e2ee as an afterthought is going to be infinite pain whatever way you do it
  666. MattJ goffi, I'm not sure a spec is really needed
  667. jonasw Syndace, that doesn’t need any additional magic though. just *some* clients stepping back from the "OMEMO by default and everywhere" paradigm
  668. MattJ goffi, it's just MUC, you fetch the keys of all participants
  669. Guus has left
  670. Syndace goffi, I think they just parse the MUC-style JID into the normal JID and then use OMEMO as usual
  671. Guus has left
  672. jonasw Zash, WhatsApp supposedly managed to do it as an afterthought
  673. goffi Gajim told me last time I was in a MUC for testing, that it was working with member only rooms something like that (don't remember the message)
  674. Syndace jonasw: WhatsApp has one binary and forces usage of e2ee, would be easy with these preconditions
  675. goffi this should be explained in a XEP, even if it's short
  676. Syndace (or three binaries for each OS, whatever)
  677. Guus has left
  678. Zash jonasw: supposedly. also they're one company who do all the clients
  679. waqas has joined
  680. Guus has left
  681. Dave Cridland I suspect we'll need an HSTS equivalent for E2EE, certainly, and then move plaintext->opportunistic->e2ee-always
  682. Zash if clients were registered and known by the server then maybe
  683. goffi we are still blocking a bunch of XEP with OMEMO by default
  684. Guus has left
  685. goffi as long as there is no full stanza encryption
  686. Guus has left
  687. Dave Cridland Zash, I suspect client registration has ot become a Thing, anyway. There's a whole lot of optimizations we could do if we had that.
  688. Guus has left
  689. goffi no more last message correction, no more in band real time text, no more, no more language detection, no more markup.
  690. Zash goffi: but we have the markdown-ish thing now /s
  691. jonasw goffi, but markup is in the <body/> nowadays anyways!!
  692. Guus has left
  693. Dave Cridland goffi, Honestly, you needn't argue for full-stanza. ESessions had that a decade ago, I have no idea why OMEMO doesn't.
  694. Zash jonasw^5
  695. goffi Zash: don't tell me :'(
  696. jonasw Dave Cridland, possibly because time-to-market mattered more than doing things right?
  697. jonasw Zash, ^5
  698. Dave Cridland jonasw, Probably.
  699. jonasw Dave Cridland, I’d love if we could maybe not repeat the same mistake with whatever MLS integration will happen.
  700. Dave Cridland jonasw, Yes. I'd like to do that one right.
  701. vanitasvitae has left
  702. Syndace Any info on how/whether MLS handles mixed plaintext-only clients and encrypting clients?
  703. jonasw Dave Cridland, Zash, if it ever gets less hot so I can think straight for more than 5 minutes in a row, I’m going to try to make some device identification thing in prosody. I need per-device passwords anyways.
  704. Dave Cridland has left
  705. Syndace If we had device identification we could issue a simple warning: "If you send this message encrypted, only jid: phone and jid: laptop can receive the message. jid: web and jid: work can not."
  706. goffi I would argue that I rather use OX by default, I'm less interested in PFS that in mentioned features.
  707. Zash jonasw: I hear MattJ was working on that
  708. goffi and OX do full stanza encryption.
  709. MattJ jonasw, er, yeah, I have a mod_device_tracker
  710. MattJ I can publish it later today or tomorrow
  711. jonasw MattJ, I’m thinking about doing things in SASL
  712. pep. MattJ: tracker!! I knew it
  713. MattJ pep., it's ok, it asks for consent
  714. Zash jonasw: FWIW you could have per-device usernames too (or username+device), since they need have no relation to the bound JID
  715. jonasw Zash, I was more thinking of using the second identity one can pass in sasl
  716. jonasw if it’s a full JID with the bare JID equal to the one you’re authing for, the resource is the device ID
  717. Zash jonasw: modulo client support
  718. jonasw Zash, yeah...
  719. jonasw but do clients support getting forced to a different bare JID?
  720. Zash Sure
  721. jonasw I need to have tests for that.
  722. jonasw I’m not sure what aioxmpp would do
  723. Zash +1
  724. Zash Moar tests :)
  725. jonasw Zash, fun fact, I’ll probably go for device@username for per-device-passwords in IMAP :)
  726. Dave Cridland jonasw, See https://tools.ietf.org/html/draft-cridland-kitten-clientkey-00
  727. Zash jonasw: Have you noticed the client-uses-full-bind-something pidgin sends in the stream start?
  728. jonasw Zash, no
  729. Zash jonasw: Which had something to do with GTalk
  730. jonasw Dave Cridland, in my scenario, the devices would never learn the actual account password
  731. jonasw which is something I’d like to have
  732. jonasw actually, this is uspposed to be client certificates lite
  733. jonasw because client certs are hard
  734. vanitasvitae has left
  735. Zash It could assign you a different hostname even, if you had whatever the hosted domain thing was
  736. jonasw Zash, crazy stuff
  737. jonasw need to keep that in mind; that might be useful to have to support legacy clients
  738. Zash sure
  739. Zash There are some modules in Prosody where the SASL username ends up differently from the JID localpart
  740. jonasw interesting
  741. Zash Some PHP forum one for example
  742. Zash One where you can have characters in the username that don't pass nodeprep
  743. Dave Cridland jonasw, Do a PIN-check on another session? But anyway, I'm happy to knock around idea on that with you.
  744. jonasw Dave Cridland, sounds good, but as I said .... it’s too hot here to think
  745. ta has joined
  746. jonasw Dave Cridland, my idea was somewhat like this: - to add a new device, you generate an auth-code on your first device and enter that in the new device. it performs either something SASL2 or a variant of IBR to set a password for itself (the password is never shown to the user) - it will always authenticate with that password (somewhat like your CLIENT-KEY I suppose) - server can now track the device, which also means that a user can revoke any device at any time (e.g. lost or stolen)
  747. Valerian has left
  748. jonasw Dave Cridland, IIRC, client key had the issue that when the counter goes out-of-sync, you need to re-authenticate using the normal SASL mechanisms?
  749. alacer has left
  750. alacer has joined
  751. Dave Cridland jonasw, Yes. It's designed as a "Remember this device" to go along with TOTP, and not exactly wehat you're after.
  752. jonasw mmmhm
  753. Martin has left
  754. Dave Cridland jonasw, But that counter is intentional - anyone stealing the credential from the client cannot use it from another device if the original device is still in use - the counter gets out of sync and the server-side token is killed.
  755. jonasw I think CLIENT KEY is orthogonal to this, yeah. It could be used in a, as you say, "Remember this device" fashion to temporarily replace the SCRAM-with-device-password+TOTP flow if TOTP is used,.
  756. Chobbes has joined
  757. jonasw Dave Cridland, yupp, that’s good
  758. Dave Cridland jonasw, Oh, and it's designed such that you can't DoS the token by guesswork or stealing it from the server.
  759. muppeth has joined
  760. muppeth has joined
  761. jonasw it looked pretty solid when I looked at it back then, yeah
  762. jonasw but IANAC
  763. 404.city has joined
  764. Dave Cridland C = Cryptographer?
  765. jonasw yes
  766. Dave Cridland Nor am I, but I play one on TV.
  767. jonasw :D
  768. Valerian has joined
  769. Chobbes has joined
  770. daniel has left
  771. pep. has joined
  772. alacer has left
  773. vanitasvitae has left
  774. muppeth has joined
  775. Guus has left
  776. Guus has left
  777. pep. Syndace: in your pad, section 4 before idea1, you are confusing omemo and e2ee. e2ee doesn't require PFS
  778. vanitasvitae has left
  779. jubalh has joined
  780. Martin has left
  781. vanitasvitae has left
  782. vanitasvitae has left
  783. Martin has left
  784. Syndace pep.: Right.
  785. daniel has joined
  786. Guus has left
  787. Guus has left
  788. jonasw people suggesting: > In general, a short “yo, please deactivate OMEMO” plaintext answer should be enough. But this can be annoying if it happens too often! clearly have no idea at which level of technological literacy some people operate
  789. pep. Indeed
  790. jonasw Syndace, append to your list please "I re-installed Conversations and now I can’t access my history anymore", because people aren’t expecting PFS.
  791. Syndace jonasw: lol, yes I know that some people don't know what OMEMO is and how to disable it, come on don't take this so literal :D
  792. pep. Syndace: this is a real world issue :x
  793. nyco has left
  794. labdsf has joined
  795. Syndace jonasw: Better example of what to write?
  796. Guus has left
  797. Andrew Nenakhov Our take on encrypted conversations that we plan to implement soon is to have separate encrypted and decrypted chats. Like telegram's secret chats.
  798. Guus has left
  799. vanitasvitae Syndace: after having implemented OX (OpenPGP for XMPP) I think one huge improvement that OX is having over OMEMO is the ability to encrypt arbitrary extension elements. I think full stanza encryption is rather unrealistic for xmpp, but you can put all the sensitive data into an encrypted container and be done :)
  800. vanitasvitae We should really port this to OMEMO / put it in a standalone XEP and let OX and OMEMO depend on it
  801. Andrew Nenakhov Telegram also solves multidevice e2ee quite simply: secret chats are one on one device only.
  802. Syndace Andrew Nenakhov: Interesting, who is "our"?
  803. Andrew Nenakhov Xabber.
  804. vanitasvitae Andrew Nenakhov: the single device part is one of the things that keep me from using secret chats :/
  805. Guus has left
  806. Guus has left
  807. Andrew Nenakhov I also hate pfs obsession
  808. Valerian has left
  809. lovetox nobody has a pfs obsession
  810. lovetox its just what we have
  811. Andrew Nenakhov Publish a pgp key, share it to all devices, have your history everywhere.
  812. vanitasvitae Moxie does :D
  813. lovetox we cant just snip our fingers and invent super secure encryption protocols
  814. lovetox Andrew Nenakhov, yes you can do that with OX
  815. Andrew Nenakhov If you care that much about privacy, don't lose that key.
  816. lovetox Omemo was just there first, and its easier to implement
  817. Andrew Nenakhov > Moxie does :D A lot of other guys do too. Constantly bombard our issue trackers with demands.
  818. vanitasvitae :D I have heard of that infamous bug report ;)
  819. Syndace What about a mechanism to synchronize local history from another device? xD
  820. Andrew Nenakhov :-D
  821. Andrew Nenakhov That bug report is, yes, epic
  822. blabla has joined
  823. MattJ Syndace, that has been discussed in the past - the protocol is already there - XEP-0313 could work between clients just as it does between client and server
  824. Zash has left
  825. Andrew Nenakhov Btw, why would people want "full stanza encryption"?
  826. Zash has joined
  827. Andrew Nenakhov If you encrypt whom you address stanza, it'll never be delivered 😂
  828. rishiraj22 has left
  829. vanitasvitae At FOSDEM I heard the idea of establishing encrypted XML streams between clients :D
  830. lovetox obviously not the top element..
  831. MattJ vanitasvitae, that has also been discussed and done before
  832. Steve Kille has left
  833. Steve Kille has left
  834. labdsf MattJ: gajim recently removed this feature
  835. Syndace MattJ: Wondering how serious to take this idea
  836. Andrew Nenakhov What is there to encrypt besides top element 😂😂😂
  837. lovetox every child element?
  838. Syndace Would be pretty cool to have history even on fresh OMEMO devices
  839. MattJ Andrew Nenakhov, OOB element for file transfers, for example
  840. labdsf has left
  841. labdsf has joined
  842. Andrew Nenakhov > Would be pretty cool to have history even on fresh OMEMO devices As I understand OMEMO, this wish goes against all it stands for. :-/
  843. Syndace Not if you can sync the local history from your other devices or your chat partners
  844. labdsf Andrew Nenakhov: Signal has synchronization between start vices
  845. labdsf Between devices*
  846. lovetox it can provide this, because it does not have to deal with different clients
  847. Syndace lovetox: Doesn't sound very hard to throw the serialized XML into OMEMO instead of a plaintext message for nearly-full-stanza-encryption
  848. lovetox this would mean making a protocol for exchanging databases
  849. Steve Kille has joined
  850. lovetox who said full stanza encryption is hard? as some people point out this exists probably for a decade in xmpp
  851. Syndace What about substanzas that are meant for the server (like hints)?
  852. lovetox you obviously cant encrypt them because then they are useless
  853. Syndace I was wondering whether to treat them in a special way or to just ignore them
  854. lovetox with full stanza encryption we dont mean full like everything
  855. lovetox we mean all data that are not necessary for the server to function
  856. Guus has left
  857. nyco has left
  858. Andrew Nenakhov > Andrew Nenakhov: Signal has synchronization between start vices Doing that is definitely possible in a number of ways, every single of them denying all advantages their protocol has over PGP.
  859. Andrew Nenakhov You can sync history directly between devices. You can share keys and download and decipher messages from server archive
  860. Andrew Nenakhov But why bother using omemo if you plan to do that?
  861. 404.city has left
  862. Syndace signal uses omemo aswell (basically)
  863. Syndace why do you think they do it that way? because its convenient probably
  864. vanitasvitae If you do the backup exchange using OMEMO, you dont lose any advantages of OMEMO
  865. jjrh has left
  866. vanitasvitae if you do it via OpenPGP however, your whole history is on the server twice, once OMEMO encrypted and once via OpenPGP. In that case you lost pfs due to the OpenPGP copy which can in theory be decrypted in the future.
  867. jjrh has left
  868. vanitasvitae So for backup exchange you'd want to generate a single-use key.
  869. Andrew Nenakhov Why twice? One openpgp is enough.
  870. Andrew Nenakhov Backup exchange is also bad ux by the way.
  871. Andrew Nenakhov You want your messages everywhere at once.
  872. Andrew Nenakhov So in the end if you want security and convenience , just run your own server.
  873. vanitasvitae Then you need OpenPGP and you cannot have pfs
  874. Andrew Nenakhov Because in xmpp the only ones who are affected by e2ee are server operators.
  875. jjrh has left
  876. goffi ho Gajim removed direct stream encryption? What a pity, I find it the most secure way if you have something really sensitive to say
  877. goffi I guess same effect can be achieved with XEP-0396 nowaday
  878. Guus has left
  879. lovetox Gajim never head direct stream encryption
  880. Guus has left
  881. lovetox and why is it a pity if no client supported that?
  882. Dave Cridland has left
  883. Guus has left
  884. dos has left
  885. labdsf has left
  886. moparisthebest has joined
  887. moparisthebest has joined
  888. Link Mauve Hi, what should happen with MAM when a client did a <query/> without specifying a @queryid? Should the <result/>s also not contain one?
  889. Link Mauve So far I made it required in my parser but I guess it should be optional due to that.
  890. lovetox yes Link Mauve correct
  891. lovetox dont add a query element if the client doesnt set one
  892. lovetox makes no sense, because its a identifier for the client
  893. lovetox if it set none it doesnt need it
  894. Link Mauve Yup.
  895. Guus has left
  896. Guus has left
  897. karp has left
  898. karp has joined
  899. Alex has left
  900. Guus has left
  901. kasper.dement has joined
  902. Link Mauve Wut, the changelog of RSM says that the <index/> element has been removed, but it is still present thrice in the text (including twice in examples).
  903. jonasw maybe a different <index/> element? *hope*
  904. flow Link Mauve, attribute vs element?
  905. Link Mauve Nope, I checked already.
  906. Link Mauve flow, nope.
  907. flow ahh right, the elemnt still appears in the text
  908. Link Mauve Hmm, I think I should split my RSM element into query and result, that would make it a lot easier to understand what’s going on.
  909. flow Who is 'vm'?
  910. Link Mauve Someone from before my time, I guess.
  911. rion has left
  912. kasper.dement has joined
  913. michael has joined
  914. jonasw This one just came up in another room: https://xmpp.org/extensions/xep-0238.html
  915. jonasw do we maybe want to deprecate/obsolete/reject that?
  916. jonasw it seems to be ... way out of date
  917. jonasw and there doesn’t seem to be any interest in refining it
  918. karp has left
  919. karp has joined
  920. michael has left
  921. Chobbes has joined
  922. lskdjf has joined
  923. karp has left
  924. karp has joined
  925. alacer has joined
  926. Link Mauve jonasw, +1, although in the past we’ve considered deferred as a tombstone.
  927. Link Mauve But I’m still +1 to explicitly obsolete it.
  928. kasper.dement has joined
  929. jonasw yeah, deferred isn’t explicit enough
  930. Link Mauve And I think we shouldn’t let XEPs stay in limbo like that forever.
  931. Yagiza If I implement deffered XEP in my software, may it change its status?
  932. Link Mauve Yagiza, you should send an email to standards@ to explain why imo, then someone will most likely revisit it.
  933. Zash Yagiza: Possibly, especially if you write to the standards@ list or the author with feedback
  934. jonasw Yagiza, there are two types of deferred XEPs (and you cannot tell them apart by the status): those which are abandoned, and those which are "good enough" and which are silently implemented everywhere
  935. jonasw Yagiza, so if you implement a deferred XEP, post any feedback you have to standards@ (even if it’s just "implemented it, it solves my issue X"), that might trigger advancement to Draft
  936. Link Mauve You may also send a change, anything, something you found missing/misformulated/anything in the text, which would automatically put it back to Experimental.
  937. Zash jonasw: I'd say there's some gray area inbetween, where the author just happens to be busy with other stuff
  938. jonasw Zash, I’d call that "abandoned", even though that’s harsh
  939. Link Mauve Zash, can confirm. :-°
  940. 404.city has joined
  941. Zash jonasw: sounds intentional then, which it might not be
  942. jonasw hm, ok
  943. Yagiza I just want to try implementing XEP-0371 in my client as a good solution for file transfer.
  944. jonasw Yagiza, uh... in combination with XEP-0234?
  945. Alex has left
  946. Yagiza Yes, of course
  947. Yagiza Also, its implementation may increase chances of successful Jingle RTP session.
  948. Link Mauve This one is an instance of the good kind of deferred XEP.
  949. lorddavidiii has joined
  950. mikaela has joined
  951. Guus has left
  952. muppeth has left
  953. muppeth has joined
  954. Yagiza Link Mauve, so, if I implement it, it may make things better?
  955. jonasw yes
  956. Yagiza Ok. Sounds good.
  957. karp has left
  958. karp has joined
  959. Zash Higher chance of things becoming better if you send feedback to standards :)
  960. waqas has left
  961. karp has left
  962. karp has joined
  963. karp has left
  964. karp has joined
  965. Alex has joined
  966. dos has joined
  967. Link Mauve In pubsub#event, I see @node being defined on item, but I don’t see it used anywhere in the XEP.
  968. Link Mauve What and where could it be used for?
  969. Alex has joined
  970. Zash Section?
  971. Link Mauve XML Schema.
  972. Zash https://xmpp.org/extensions/xep-0060.html#example-2 that @node ?
  973. Dave Cridland has left
  974. Link Mauve This is on items, not on item.
  975. mrdoctorwho has joined
  976. Dave Cridland has left
  977. Zash Wait where do you see a node attr?
  978. Link Mauve Line 7007 of the XML file in the xeps repository.
  979. Zash Which object? :)
  980. Link Mauve What do you mean?
  981. jonasw https://github.com/xsf/xeps/blob/master/xep-0060.xml#L7001
  982. jonasw Link Mauve, might’ve been a mistake
  983. jonasw node doesn’t make sense on item
  984. Zash semi-serious reference to git object
  985. jonasw hm, unless items from different nodes are batched in a single event
  986. Link Mauve I’ve never seen that done.
  987. Link Mauve But everytime I read this XEP, I learn new things.
  988. jonasw everybody seems to say that about '60
  989. Valerian has joined
  990. waqas has joined
  991. Link Mauve And items@ver isn’t specified in the schema. :|
  992. jonasw lovely
  993. Zash https://xmpp.org/extensions/attic/jep-0060-1.7.html#schemas-event https://xmpp.org/extensions/attic/jep-0060-1.8.html#schemas-event
  994. Link Mauve Oh no, this is commented in the XML file.
  995. Zash has left
  996. jonasw Link Mauve, where?
  997. jonasw ah nevermind
  998. Guus has left
  999. Guus has left
  1000. Guus has left
  1001. Guus has left
  1002. Link Mauve Is it actually possible to have a <{pubsub#event}items/> with neither <item/>s nor <retract/>s inside?
  1003. Yagiza Zash, that's implied
  1004. pep. has left
  1005. lskdjf has left
  1006. lskdjf has left
  1007. karp has left
  1008. karp has joined
  1009. Guus has left
  1010. marc has left
  1011. Guus has left
  1012. Zash has left
  1013. karp has left
  1014. karp has joined
  1015. Zash has joined
  1016. marc has joined
  1017. lskdjf has joined
  1018. Zash has left
  1019. labdsf has joined
  1020. jubalh has joined
  1021. jubalh has left
  1022. lskdjf has left
  1023. karp has left
  1024. karp has joined
  1025. lskdjf has left
  1026. lskdjf has left
  1027. lskdjf has joined
  1028. lskdjf has left
  1029. karp has left
  1030. lskdjf has left
  1031. karp has joined
  1032. lskdjf has joined
  1033. SamWhited has left
  1034. dos has left
  1035. Dave Cridland has left
  1036. lumi has left
  1037. lskdjf has joined
  1038. rishiraj22 has left
  1039. karp has left
  1040. karp has joined
  1041. Yagiza has left
  1042. kasper.dement has joined
  1043. kasper.dement has joined
  1044. labdsf has left
  1045. labdsf has joined
  1046. rishiraj22 has left
  1047. lskdjf has left
  1048. lskdjf has left
  1049. karp has left
  1050. karp has joined
  1051. karp has left
  1052. karp has joined
  1053. kasper.dement has left
  1054. lskdjf has left
  1055. kasper.dement has joined
  1056. goffi has left
  1057. lskdjf has joined
  1058. lskdjf has joined
  1059. lskdjf has joined
  1060. Dave Cridland has left
  1061. Dave Cridland has joined
  1062. lskdjf has joined
  1063. lskdjf has joined
  1064. valo has left
  1065. jubalh has joined
  1066. valo has joined
  1067. kasper.dement has left
  1068. karp has left
  1069. karp has joined
  1070. lskdjf has left
  1071. lskdjf has left
  1072. lskdjf has left
  1073. lskdjf has left
  1074. valo has left
  1075. lskdjf has joined
  1076. kasper.dement has joined
  1077. lskdjf has joined
  1078. lskdjf has left
  1079. lskdjf has left
  1080. jere has left
  1081. j.r has joined
  1082. valo has joined
  1083. kasper.dement has left
  1084. lskdjf has left
  1085. Dave Cridland has left
  1086. Dave Cridland has joined
  1087. Dave Cridland has left
  1088. Dave Cridland has joined
  1089. Dave Cridland has left
  1090. Dave Cridland has joined
  1091. karp has left
  1092. karp has joined
  1093. Dave Cridland has left
  1094. Dave Cridland has joined
  1095. kasper.dement has joined
  1096. dos has joined
  1097. Dave Cridland has left
  1098. Dave Cridland has joined
  1099. lskdjf has joined
  1100. Dave Cridland has left
  1101. Dave Cridland has joined
  1102. jere has joined
  1103. lumi has joined
  1104. Chobbes has joined
  1105. j.r has joined
  1106. j.r has joined
  1107. remko has left
  1108. karp has left
  1109. karp has joined
  1110. kasper.dement has joined
  1111. karp has left
  1112. karp has joined
  1113. karp has left
  1114. karp has joined
  1115. marc has left
  1116. marc has joined
  1117. jubalh has joined
  1118. kasper.dement has joined
  1119. Link Mauve “19:09:00 vanitasvitae> At FOSDEM I heard the idea of establishing encrypted XML streams between clients :D”, yes, XEP-0246, XEP-0247 and XTLS. ^^
  1120. vanitasvitae Link Mauve: yeah I think we talked about it right?
  1121. Link Mauve Yes, on the last day, outside K.
  1122. vanitasvitae Right :D
  1123. Guus has left
  1124. mikaela has left
  1125. Kev has left
  1126. lovetox has left
  1127. marc has left
  1128. Valerian has left
  1129. Valerian has joined
  1130. kasper.dement has joined
  1131. kasper.dement has joined
  1132. blabla has joined
  1133. jjrh has left
  1134. Alex has left
  1135. kasper.dement has joined
  1136. Guus has left
  1137. kasper.dement has joined
  1138. Dave Cridland has left
  1139. Dave Cridland has joined
  1140. Chobbes has joined
  1141. Nekit has joined
  1142. dos has left
  1143. j.r has joined
  1144. rion has joined
  1145. kasper.dement has left
  1146. Valerian has left
  1147. blabla has left
  1148. blabla has joined
  1149. lskdjf has left
  1150. kasper.dement has joined
  1151. jjrh has left
  1152. kasper.dement has left
  1153. moparisthebest has joined
  1154. ThibG has joined
  1155. daniel has left
  1156. daniel has joined
  1157. dos has joined
  1158. lskdjf has joined
  1159. kasper.dement has joined
  1160. lskdjf has joined
  1161. lskdjf has joined
  1162. Guus has left
  1163. kasper.dement has joined
  1164. Valerian has joined
  1165. lskdjf has joined
  1166. lskdjf has left
  1167. lskdjf has left
  1168. lskdjf has left
  1169. lskdjf has left
  1170. lskdjf has left
  1171. kasper.dement has joined
  1172. waqas has left
  1173. kasper.dement has left
  1174. Chobbes has joined
  1175. lumi has left
  1176. kasper.dement has joined
  1177. Valerian has left
  1178. daniel has left
  1179. daniel has joined
  1180. nyco has left
  1181. MattJ has joined
  1182. lskdjf has left
  1183. kasper.dement has left
  1184. Guus has left
  1185. kasper.dement has joined
  1186. lskdjf has joined
  1187. waqas has joined
  1188. lskdjf has left
  1189. lskdjf has left
  1190. moparisthebest has joined
  1191. SamWhited has left
  1192. ta has joined
  1193. la|r|ma has joined
  1194. peter has left
  1195. Chobbes has joined
  1196. lskdjf has joined
  1197. lskdjf has left
  1198. kasper.dement has left
  1199. lskdjf has left
  1200. Syndace has left
  1201. Syndace has joined
  1202. lskdjf has joined
  1203. Guus has left
  1204. Guus has left
  1205. kasper.dement has joined
  1206. lnj has left