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