XSF logo XSF Discussion - 2017-10-05


  1. Guus has left
  2. Tobias has left
  3. Wiktor has left
  4. Wiktor has joined
  5. Tobias has joined
  6. Tobias has left
  7. jere has left
  8. jere has joined
  9. waqas has left
  10. Tobias has joined
  11. Valerian has left
  12. Valerian has joined
  13. Tobias has left
  14. lovetox has left
  15. Valerian has left
  16. lskdjf has joined
  17. la|r|ma has joined
  18. tux has left
  19. lskdjf has left
  20. lskdjf has joined
  21. tux has left
  22. tux has left
  23. tux has joined
  24. lskdjf has joined
  25. lskdjf has joined
  26. Tobias has joined
  27. efrit has left
  28. tim@boese-ban.de has left
  29. tim@boese-ban.de has joined
  30. intosi has left
  31. jjrh has left
  32. Lance has joined
  33. Lance has left
  34. Lance has joined
  35. jjrh has left
  36. waqas has joined
  37. Tobias has joined
  38. Lance has left
  39. lskdjf has joined
  40. lskdjf has joined
  41. la|r|ma has joined
  42. la|r|ma has joined
  43. lskdjf has joined
  44. jjrh has left
  45. jjrh has left
  46. jjrh has left
  47. jjrh has left
  48. tim@boese-ban.de has left
  49. Tobias has left
  50. tux has left
  51. tux has joined
  52. tim@boese-ban.de has joined
  53. la|r|ma has joined
  54. jere has left
  55. jere has joined
  56. nyco has left
  57. zinid has left
  58. zinid has joined
  59. jjrh has left
  60. jjrh has left
  61. jere has left
  62. jere has joined
  63. SamWhited has left
  64. jjrh has left
  65. daniel has joined
  66. sezuan has joined
  67. uc has joined
  68. daniel has left
  69. zinid has left
  70. jubalh has joined
  71. zinid has joined
  72. waqas has left
  73. jubalh has left
  74. jubalh has joined
  75. Guus has left
  76. daniel has joined
  77. Tobias has left
  78. jubalh has left
  79. stefandxm has left
  80. stefandxm has joined
  81. uc has joined
  82. Guus has left
  83. uc has joined
  84. jonasw moparisthebest, a change from SHOULD to MAY is a technical change. However, given that there has no advancement been made to the XEP yet, that’ll be fine
  85. jonasw I guess this is what the CFE is for
  86. jubalh has joined
  87. stefandxm has left
  88. Guus has left
  89. uc has joined
  90. daniel has left
  91. Kev Well, it's for Council to decide whether it's fine or not, no?
  92. jonasw Kev, yes
  93. stefandxm has joined
  94. jonasw you’re right about that
  95. jonasw what I meant is: it is not absolutely not fine
  96. jonasw and also council members brought that change I assume moparisthebest will do up in the discussion, so ... ;-)
  97. daniel has joined
  98. Guus has left
  99. goffi has joined
  100. intosi has joined
  101. tim@boese-ban.de has left
  102. tim@boese-ban.de has joined
  103. Tobias has left
  104. daniel has left
  105. daniel has joined
  106. Guus Kev (others): please elevate me from member to owner on our github repo, add me to the team on dockerhub, and provide me with the twitter credentials. It'd be good to have someone else be available to help people out with requests in order to speed up things (and as I'm currently the requestee most of the time, who's also in iteam, I'd be a logical candidate).
  107. Guus has left
  108. Kev What's your name on the docker hub?
  109. edhelas has left
  110. Kev You've got ownership of the github org now, I'll sort out docker at some point later when I know your account, and Twitter I need to sort out password changing and distribution of the password.
  111. Kev Please don't change things without discussion.
  112. edhelas has joined
  113. Guus Thanks, I won't
  114. Guus I'm guusdk on dockerhub
  115. uc has joined
  116. daniel has left
  117. daniel has joined
  118. tim@boese-ban.de has joined
  119. tim@boese-ban.de has joined
  120. Guus has left
  121. Ge0rG has left
  122. Kev has left
  123. tim@boese-ban.de has joined
  124. tim@boese-ban.de has joined
  125. jcbrand has joined
  126. nyco has left
  127. sezuan has left
  128. sonny has joined
  129. Ge0rG has left
  130. jcbrand has left
  131. zinid has left
  132. zinid has left
  133. zinid has joined
  134. uc has joined
  135. winfried has joined
  136. winfried has left
  137. Ge0rG has left
  138. jubalh has joined
  139. Ge0rG has left
  140. tim@boese-ban.de has joined
  141. tim@boese-ban.de has joined
  142. winfried has left
  143. Martin has joined
  144. Ge0rG has left
  145. uc has joined
  146. tim@boese-ban.de has joined
  147. Ge0rG has left
  148. winfried has left
  149. Zash has left
  150. winfried has joined
  151. jubalh has joined
  152. Ge0rG has left
  153. zinid has left
  154. zinid has left
  155. Ge0rG has left
  156. Martin has left
  157. Guus has left
  158. Ge0rG has left
  159. Martin has joined
  160. Ge0rG has left
  161. lumi has joined
  162. andrey.g has left
  163. sonny has left
  164. andrey.g has joined
  165. lovetox has joined
  166. andrey.g has joined
  167. stefandxm has left
  168. Ge0rG has left
  169. lovetox has left
  170. lovetox has joined
  171. andrey.g has joined
  172. mimi89999 has joined
  173. andrey.g has joined
  174. Guus when establishing (direct) ssl, is more than one socket connection involved (is a connection re-established?)
  175. zinid has left
  176. matlag has left
  177. matlag has joined
  178. andrey.g has joined
  179. zinid has left
  180. Alex has joined
  181. andrey.g has joined
  182. jonasw Guus, no
  183. Guus has left
  184. jonasw you start TLS over the existing TCP connection
  185. stefandxm has joined
  186. Zash Just like STARTTLS, except without the negotiation
  187. Guus sounds like it's time to shout at apache mina again then
  188. Link Mauve Zash, s/without \(.*\)/with \1 done by the TLS library instead of by the XMPP one/
  189. Zash That hurt my head
  190. lovetox has left
  191. Zash Depends on how your libraries work I guess
  192. stefandxm has left
  193. lumi has left
  194. mimi89999 has joined
  195. Ge0rG has left
  196. Kev has left
  197. Guus has left
  198. Zash has left
  199. Zash has left
  200. Zash has joined
  201. winfried has joined
  202. winfried has joined
  203. Guus has left
  204. Ge0rG It's a great way to shave off some round-trips, though
  205. Guus has left
  206. jubalh has joined
  207. jubalh has left
  208. Alex has left
  209. Ge0rG Kev: "undesirable"... I love your choice of words!
  210. Alex has joined
  211. jonasw undesirable in that context might be the XMPP-related understatement of the decade :-)
  212. Ge0rG Kev: killing GC1 was brought up to the council, but without a well worded motivation. I also agree we need to kill it, but it is to some degree a better resync mechanism than nothing at all.
  213. Kev It is definitely better than nothing at all.
  214. Kev I've long held that opinion. But if we're providing something better now, maybe it can retire.
  215. Ge0rG Kev: except when you end up seeing ghosts in the MUC.
  216. zinid has left
  217. Kev You see ghosts in the MUC with or without gc1 joins, without another mechanism.
  218. Kev Without gc1, everyone you see (as a client) is a ghost :)
  219. lumi has joined
  220. Ge0rG Kev: yes, but then you realize that as soon as you send a message.
  221. Kev That is true.
  222. Ge0rG Kev: my point is that it's not always better than nothing.
  223. Zash If we get rid of gc1, isn't a normal presence the same as <presence><I-expect-to-still-be-in-the-room/></p>
  224. Kev If you're referring to (3), then no.
  225. jonasw Zash, yes, but we can’t simply get rid of GC1, can we?
  226. Zash Can we?
  227. Kev jonasw: Can't we? :)
  228. jonasw Kev, council was against it.
  229. jonasw I mean, we can re-try, but ...
  230. jonasw speaking of council, still no (re-)applications?
  231. Kev Council may have been against it when there wasn't a better option, they may not be after this.
  232. Kev Only Joe Demo, by the look of it.
  233. Kev I hear good things about that guy.
  234. jonasw like Boaty McBoatface?
  235. Ge0rG Again, I want to propose Boardy McBoardface for Council.
  236. jonasw not Council McCouncilface?
  237. Ge0rG jonasw: no. C McC should apply for Board instead.
  238. la|r|ma has joined
  239. jonasw for maximum confusion, I see
  240. Ge0rG I wonder if I should apply for Council, and then try to aggressively push the XMPP 2.0 / Easy Jabber agenda.
  241. Ge0rG has left
  242. Ge0rG Killing GC1.0 would be my major campain promise.
  243. jonasw hm, one can’t really make promises, can one?
  244. jonasw when running for council
  245. zinid has left
  246. jonasw (well, one can... but in the end it all depends on who else gets elected. then again, that’s the same for all elections)
  247. Guus has left
  248. Kev I kinda think that what xmpp2/easyjabber needs most, in some ways, is implementation and deployment experience.
  249. andrey.g has left
  250. jonasw you can’t really do implementation without some specification
  251. Kev Of course you can.
  252. Zash Just type code into your thing!
  253. Kev You try something and see if it works.
  254. jonasw well, you shouldn’t
  255. jonasw hm
  256. Kev Also, completely untrue.
  257. Zash So you are a specification before implementation person?
  258. Kev Protocol documents based on people actually trying things is a jolly good thing.
  259. Zash Some are the other way around. Some think both at the same time!
  260. jonasw yeah, I see where you’re coming from
  261. Kev Everything has its place. Except the things that don't.
  262. jonasw I’m not necessarily, but Session 2.0 is a thing where many parties need to play together, so there needs some kind of coordination, that is, specification, on what the parties implement each
  263. Kev jonasw: Nothing says that has to happen in advance.
  264. jubalh has joined
  265. Ge0rG Kev: I could implement Session 2.0, but then it would only work for IM.
  266. Kev e.g. if I had spare person-hours, I'd have something that worked implemented in M-Link and the Swifts, and we could use that experience to feed into the specs.
  267. uc has joined
  268. Kev Ge0rG: Sure. But 'try stuff and see if it works' doesn't mean 'specify what was implemented and treat it as set in stone because you coded some prototype'.
  269. andrey.g has joined
  270. Guus has left
  271. Ge0rG has left
  272. Ge0rG Kev: I also need to read up what I have "proclaimed" in the last two years under the "MUC-subscription" label. I think it's all the same basic idea, and maybe I forgot something important in the last iteration
  273. jonasw itym MAM-subcsription
  274. Ge0rG jonasw: right. Sorry. I won't LMC that now.
  275. Kev Ge0rG: I *think* the important thing there is simply that everything that's chat-related you want both in your archive and on all your devices.
  276. Kev So all we need to do is achieve that :D
  277. Zash So how do we determine if a message is "chat-related"?
  278. Kev I did the hard work of coming up with the high-level direction. Someone else can work on the details.
  279. Zash type=chat would have been nice
  280. Ge0rG Kev: you are a genius! Why didn't anyone else think of that before? :D
  281. Ge0rG Zash: 0184 and CSNs happen to be type=random.
  282. nyco has left
  283. jonasw also, what about type=normal? :)
  284. Zash Aren't those chat related?
  285. Guus has left
  286. Ge0rG Zash: maybe they are.
  287. jonasw that certainly has messaging use-cases too, and wouldn’t you want to sync them, too?
  288. mimi89999 has joined
  289. Ge0rG jonasw: chat is the new normal.
  290. jonasw that’s your opinio.n
  291. jonasw ;-)
  292. Ge0rG jonasw: that's what implementations do
  293. jonasw because no implemntation has a UI for type=normal
  294. jonasw except pidgins "let’s show this in a separate window focus stealingly" counts as UI
  295. Ge0rG jonasw: I think many client authors don't care about "normal" vs. "chat", and end up sending non-body messages with "normal"
  296. jonasw meh.
  297. Ge0rG Like for example ACKs.
  298. Zash -xep 304
  299. Bunneh Zash: XEP-0304: Whitespace Keepalive Negotiation (Standards Track, Deferred, 2011-08-18) See: https://xmpp.org/extensions/xep-0304.html
  300. Ge0rG jonasw: also guess which message type is mandated by [xep 0184]
  301. jonasw "whatever works"?
  302. Zash Ge0rG: {}
  303. Ge0rG Zash: -ETOOMANYDIFFERENTBOTS
  304. Zash Bots bots bots
  305. Ge0rG can't we just have all bot react to all patterns, instead of putting the cognitive load onto people?
  306. Zash Wasn't both 184 and csn using the standard reply pattern? Ie same type
  307. Ge0rG -xep standard reply pattern
  308. Bunneh Ge0rG: XEP-0068: Field Standardization for Data Forms (Informational, Active, 2012-05-28) See: https://xmpp.org/extensions/xep-0068.html
  309. andrey.g has joined
  310. Zash Copy attributes, swap to/from. If it's an error, set type=error.
  311. Ge0rG Zash: There is no such primitive in the XMPP lib I'm using.
  312. jonasw Ge0rG, switch XMPP libs then!
  313. Ge0rG has left
  314. jonasw Zash, also, you shouldn’t be copying the @id for anything except IQ, I think
  315. Ge0rG Zash: I'm not even convinced this is a good thing, generally. Maybe type=headline would be more appropriate for ACKs and CSNs?
  316. Kev I think acks you probably want stored in your archive, while CSNs you certainly don't.
  317. Zash Kev: Are you sure?
  318. Ge0rG Right. ACKs need to be archived.
  319. Kev Actually, I'm fairly sure you want something more sophisticated than just putting acks in your archive, but I'm not sure how revolutionary I should be today.
  320. jonasw Kev, as much as possible, of course.
  321. Ge0rG Kev: it's all about synchronizing a chat database.
  322. Ge0rG Kev: yes please. Make the most revolutionary proposal you can imagine.
  323. winfried has joined
  324. Kev Have your server handle your acks for you. Also have the server archive read receipt status for your messages.
  325. Kev Have the ability to collate messages that operate on each other in the archive, so they can be returned as state on the MAM results.
  326. Ge0rG Kev: I think MAM would be indeed a good place to send 0184 acks, from the bare JID
  327. Kev Delivered, Read, LMC. Store them, but on the message they affect, not on their own.
  328. Ge0rG Kev: that message collation would work much better if we had properly-generated UUIDs
  329. Ge0rG Does "unique" also mean that there should be only one UUID per message?
  330. Zash Kev: I object to anything that makes it impossible to do MAM in an append-only log store thing.
  331. Ge0rG Kev: BTW that almost sounds like a multi-table relational database
  332. Zash I object to anything that requires a relational database.
  333. Ge0rG Zash: better apply for Council now, then
  334. Kev I think the most sensible way to implement MAM is with a database of some description. But clearly it's not needed.
  335. Ge0rG Kev: how would clients synchronize? Atomic replacement of [Message, Delivered, Read, [LMCs], [Reactions]] n-tuples? Or do we need a separate chronological history?
  336. Kev Synchronise in which sense?
  337. Ge0rG This is again the fully-synchronized fat client vs. load-on-demand thin client debate I think
  338. Kev Possibly.
  339. Ge0rG For load-on-demand it makes sense to initially query for n-tuples, and then to receive a stream of deltas.
  340. Ge0rG For fat clients it makes sense to receive a stream of stored deltas, followed by live deltas.
  341. Kev That is possibly true.
  342. Ge0rG Now this is another thing I had in MAM-sync: push of MAM-IDs for sent messages.
  343. Martin has left
  344. jonasw isn’t that already a thing in {XEP 0280}?
  345. jonasw damnit
  346. Zash -xep carbons
  347. Ge0rG jonasw: no
  348. Bunneh Zash: XEP-0280: Message Carbons (Standards Track, Proposed, 2017-02-16) See: https://xmpp.org/extensions/xep-0280.html
  349. jonasw no, I misremember
  350. Ge0rG jonasw: I tried to bring that up a year ago or two, and there were very loud voices arguing against that, because of sysload
  351. Yagiza has joined
  352. Zash I think someone (mattj?) suggested a carbons extension/change where you'd get your own messages reflected back
  353. jonasw what
  354. Zash syswhat
  355. Kev I'm not entirely convinced that just mirroring the entire (annotated) stanza back isn't sensible.
  356. Ge0rG If I were redoing XMPP, I'd glue together session, MAM ID reflection and 0198
  357. lumi has left
  358. Ge0rG Kev: maybe except for https://xmpp.org/extensions/xep-0047.html#message
  359. jonasw what’s session in this context?
  360. Ge0rG jonasw: that thing you bind.
  361. jonasw ah
  362. Ge0rG jonasw: what I mean is: have a separate session type (XMPP2, MAM-sub or whatever you name it), which replaces carbons and 0198 with a logic that feeds back MAM IDs for sent messages and either Carbons or direct messages of all incoming data
  363. Ge0rG has left
  364. Ge0rG I'm not opposed to the Carbons wire format, just the current processing logic is insane.
  365. jonasw sounds reasonable
  366. jonasw still possible to do that even without redoing xmpp
  367. Kev Everything's possible without redoing xmpp :)
  368. Ge0rG jonasw: still doesn't solve the persistency/urgency problem.
  369. jonasw Ge0rG, that needs fixes to MAM, Carbons, CSI and Push. All of which aren’t final yet, right?
  370. Ge0rG jonasw: are there any final XEPs at all? I thought Draft is the new Final.
  371. jonasw XEP-0030 :)
  372. jonasw (for example)
  373. moparisthebest I'm pushing to make 368 final
  374. moparisthebest but also considering I nor any current editors have ever seen a move to final
  375. moparisthebest no
  376. valo has joined
  377. jonasw moparisthebest, no worries :)
  378. jonasw just prepare your PR and see what council says.
  379. lumi has joined
  380. moparisthebest yea I'm just agreeing with Ge0rG here, final isn't a thing, draft is final
  381. daniel has left
  382. daniel has joined
  383. jere has joined
  384. daniel has left
  385. daniel has joined
  386. Ge0rG has left
  387. Kev I think that might have something to do with our habit of getting something 'good enough' but not quite right, and so not being willing to advance it further.
  388. Guus has left
  389. daniel has left
  390. daniel has joined
  391. sonny has joined
  392. Ge0rG has left
  393. lskdjf has joined
  394. la|r|ma has joined
  395. uc has joined
  396. uc has joined
  397. winfried has joined
  398. lumi has left
  399. waqas has joined
  400. Ge0rG has left
  401. Martin has joined
  402. Ge0rG has left
  403. Ge0rG has joined
  404. Wiktor has joined
  405. Wiktor has left
  406. Wiktor has joined
  407. winfried has joined
  408. Flow has joined
  409. tux has joined
  410. Wiktor has joined
  411. Wiktor has left
  412. Wiktor has joined
  413. Flow has left
  414. Flow has joined
  415. stefandxm has left
  416. Flow isn't the question what the benefit of final XEPs is, over draft XEPs?
  417. Flow as far as I can tell, final only has disadvantages
  418. jonasw Flow, what advantages does Draft have over Experimental? :)
  419. Flow jonasw: another review round at least by the council and probably by the xmpp community
  420. jonasw okay
  421. jonasw then final probably doesn’t bring you anything :)
  422. Flow plus at least so und so many implementations IIRC
  423. jonasw that’s only with Final IIRC
  424. Flow ahh right
  425. Ge0rG has left
  426. Flow ok, so after reading xep1 once more and to sum up: final has the disadvantage that no namespace bumps can be made, which is probably not an issue (see ecaps2). And the advantage that feedback was given and there are multiple interoperable implementations required
  427. Flow (I was thinking that this was for draft)
  428. jubalh has joined
  429. la|r|ma has joined
  430. lskdjf has joined
  431. Ge0rG has left
  432. daniel has left
  433. daniel has joined
  434. intosi has left
  435. Martin has left
  436. stefandxm has joined
  437. jubalh has left
  438. jubalh has joined
  439. Martin has joined
  440. jubalh has left
  441. jubalh has joined
  442. daniel has left
  443. Ge0rG There is no technical difference between a namespace bump and a new namespace, so why are we forbidding them?
  444. intosi has joined
  445. stefandxm has left
  446. SamWhited Ge0rG: they are not treated differently, changing the namespace is forbidden in final.
  447. Ge0rG SamWhited: yes, so we end up with a new XEP with a new namespace instead.
  448. SamWhited Ge0rG: Yes, that's the point, after something has reached final if you want to replace it you need to create a new XEP.
  449. Ge0rG has left
  450. Ge0rG SamWhited: yes, I'm merely questioning the wisdom of that
  451. SamWhited I don't even know where to begin with that… you want XEPs to never stabalize? We have enough problems with people not wanting to implement experimental XEPs because they're a moving target without saying that all XEPs have the potential to change and break compatibility and fragment the ecosystem at any time.
  452. SamWhited I'm all for going to final slowly, it's nice to have the flexibility to change things, but at some point when things are widely implemented we need to stop breaking compatibility and call it "good enough".
  453. Flow has left
  454. stefandxm has joined
  455. Ge0rG has left
  456. Flow has joined
  457. daniel has joined
  458. Guus has left
  459. Flow has left
  460. lumi has joined
  461. la|r|ma has joined
  462. Guus has left
  463. Ge0rG SamWhited: I'm just some random smartass, questioning everything. But I also wondered if other parts of our process might be improvable.
  464. Ge0rG has left
  465. Ge0rG has left
  466. Guus has left
  467. Ge0rG has left
  468. Guus has left
  469. stefandxm has left
  470. savostin has joined
  471. nyco has left
  472. Guus has left
  473. matlag has left
  474. Martin has left
  475. Martin has joined
  476. matlag has left
  477. Guus has left
  478. Martin has left
  479. matlag has left
  480. SamWhited I definitely think there's room for improvement, but never stabalizing anything probably isn't it.
  481. matlag has left
  482. Martin has joined
  483. daniel has left
  484. mhterres has joined
  485. mhterres has left
  486. nyco has left
  487. Ge0rG has left
  488. uc has joined
  489. matlag has left
  490. waqas has left
  491. Ge0rG has left
  492. Ge0rG has left
  493. jubalh has joined
  494. jere has joined
  495. jubalh has joined
  496. jere has joined
  497. jubalh has left
  498. waqas has joined
  499. lumi has left
  500. mimi89999 has joined
  501. Ge0rG has left
  502. Ge0rG has left
  503. sonny has left
  504. sonny has joined
  505. jjrh has left
  506. Ge0rG has left
  507. Yagiza has left
  508. intosi has left
  509. mimi89999 has joined
  510. emxp has joined
  511. emxp has joined
  512. jjrh has left
  513. mimi89999 has joined
  514. jjrh has left
  515. jjrh has left
  516. Martin has left
  517. Martin has joined
  518. nyco has left
  519. sonny has left
  520. sonny has joined
  521. stefandxm has joined
  522. Valerian has joined
  523. winfried has joined
  524. ralphm has left
  525. Valerian has left
  526. Flow has joined
  527. Flow has left
  528. Flow has joined
  529. stefandxm has left
  530. Valerian has joined
  531. Valerian has left
  532. mimi89999 has joined
  533. Flow has left
  534. Flow has joined
  535. jonasw yeah
  536. jonasw I’m already not happy with XEPs changing at all
  537. Ge0rG Except when they are made better?
  538. jonasw even draft xeps sometimes undergo massive changes, see Bookmarks.
  539. Ge0rG I'm not implementing Bookmarks. Because the RECOMMENDED way doesn't work, and the working way is Historical.
  540. moparisthebest same with omemo?
  541. jubalh has joined
  542. jonasw no, OMEMO has a XEP reflecting the current state now
  543. Ge0rG I'm not implementing OMEMO because the deployed protocol is not specified, the specified protocol is not deployed, because it adds major UX bumps and because I don't believe in E2EE.
  544. Ge0rG jonasw: oh, it does?
  545. jonasw it uses the siacs namespace at least
  546. zinid the problem with namespaces bump is that I need to maintain all the code for previous namespaces, blowing the codebase, this is annoying
  547. jonasw another issue I have with that is that old versions are barely discoverable
  548. jonasw you could see a XEP for the first time a day after the last namespace bump, implement it, and see that nobody implements that version in the wild yet
  549. Ge0rG zinid: we can't bump the namespace on MUC, fortunately.
  550. zinid Ge0rG: and we resorted to replace this monster with another monster?
  551. Ge0rG zinid: MUC is not a monster. It's ugly, but it's not too large.
  552. zinid I have 4000 LOC of mod_muc* modules, isn't this a monster?
  553. Martin has left
  554. zinid if it's not a monster, then what it is? I can recall pubsub only
  555. Zash Huh
  556. Ge0rG zinid: you know, bad specification is not the only cause of bloated software.
  557. Ge0rG Sometimes the problem is in front of the terminal, actually.
  558. jubalh has left
  559. jubalh has joined
  560. moparisthebest ‎[02:06:51 PM] ‎Ge0rG‎: *snip* I don't believe in E2EE.
  561. moparisthebest what
  562. moparisthebest what possible reason could you not believe in E2EE, and in what way
  563. Zash It's not the golden saviour of humanity as some would have you believe
  564. Ge0rG moparisthebest: E2EE is often advertised as the solution to dragnet surveillance, but it doesn't fix the biggest problem: three-letter agencies are interested in meta-data more than in actual content.
  565. Zash Also it invalidates a bunch of the assumptions XMPP is built on
  566. Ge0rG moparisthebest: just the fact that Facebook-WhatsApp rolled out E2EE should make you think.
  567. mimi89999 has joined
  568. Ge0rG moparisthebest: if you really want to prevent meta-data collection, you must run your own server for family&friends. And then you don't need E2EE any more.
  569. jonasw (I find that argument rather convincing, by the way. And I belong to the group of people who’re still using OTR, because reasons)
  570. moparisthebest so I agree, it doesn't solve everything, nothing does, it also doesn't harm anything either though
  571. jonasw it does
  572. moparisthebest I run my own server but still use E2E, what if the mam database is compromised or otherwise exposed?
  573. jonasw take a look at the number of people complaining about issues with OMEMO and blaming it on XMPP
  574. jonasw like losing messages in groupchats
  575. jonasw they don’t think the issue might be the experimental E2EE implementation they’re using.
  576. jonasw (or, maybe worse, blaming it on the server)
  577. Ge0rG moparisthebest: OMEMO failed to address the device migration use case, among others.
  578. Ge0rG moparisthebest: my position is: XMPP is already f***ing complicated and has too many corner cases that break the UX. We shouldn't be adding yet another one.
  579. Flow uh Ge0rG droped the E2EE bomb
  580. Flow where is my popcorn? ☺
  581. Flow Ge0rG: you have a point here. But I'm not sure if E2EE couldn't be made user friendly
  582. stefandxm has joined
  583. Ge0rG Flow: what bomb? I'm making this points for years now.
  584. Flow Ge0rG: well I know, but obviously there are still people who act a little bit shocked when you say that
  585. moparisthebest your arguments all apply to OTR
  586. moparisthebest not at all to PGP
  587. moparisthebest and only a little bit to OMEMO
  588. moparisthebest so
  589. Ge0rG Flow: I'm sure it's possible to make E2EE more user-friendly than it is now. However, it won't be as polished as WhatsApp E2EE any time soon, and we (as the Jabber community) already lack the resource to make XMPP more user-friendly.
  590. Ge0rG moparisthebest: my arguments apply to all E2EE on top of XMPP
  591. moparisthebest also Ge0rG your argument was if you want privacy have all your friends have an account on your server? kind of kills federation no?
  592. Valerian has joined
  593. Flow moparisthebest: surely the problem isn't E2EE *on* XMPP
  594. Flow moparisthebest: no, he (and I) want you to run your own XMPP service
  595. Flow and federate with your the XMPP server that is run by your friends
  596. moparisthebest so every user runs their own server?
  597. Holger moparisthebest: "not at all to PGP" -- no matter what E2EE you're using, you either don't verify keys or break communication by insisting on verified keys.
  598. Flow We need to go away from big centralized XMPP services like jabber.ccc.de or jabber.at
  599. Holger moparisthebest: No matter what E2EE you're using, you can't do server-side search on your archive.
  600. Holger moparisthebest: No matter what E2EE you're using, you can't do server-side spam filtering.
  601. Flow And to achieve that, we need to enable non-tech savy users to run their XMPP server on a vServer or on their home router
  602. Flow under their own domain
  603. jonasw Holger, incorrect, WhatsApp does server-side spam filtering only with metadata.
  604. Flow Holger: Now that you said it: I never received OpenPGP encrypted spam. wonder when that is going to start
  605. emxp has joined
  606. moparisthebest Holger, as Ge0rG said you have metadata, most filtering is on that anyhow?
  607. jonasw moparisthebest, it doesn’t work with XMPP, you need to have control over all servers to effectively filter spam on metadata
  608. moparisthebest in fact all the current 'must be on roster' filtering works with e2e
  609. jonasw (well, it’s not exactly like that, but federation makes it so much more difficult)
  610. jonasw must-be-on-roster is a very very bad spam filter
  611. Flow yep, bad idea
  612. lumi has joined
  613. moparisthebest I agree
  614. Holger jonasw, moparisthebest: I doubt that filtering purely on metadata can get you an accuracy anywhere near to filters that also take the body into account.
  615. emxp has joined
  616. emxp has joined
  617. moparisthebest saying e2e is a bit hard so we shouldn't support it is dumb though, it's perfectly legitimate and if done right basically free
  618. Holger Flow: It'll start once OX is ubiquitous of course :-)
  619. Flow hehe
  620. Flow sadly new clients still implement xep27 ;(
  621. Holger moparisthebest: Yeah, dumb. In practice people just give up this XMPP shit due to the E2EE breakage we introduce.
  622. Holger (I've seen *two* people saying just that *today*.)
  623. moparisthebest it's better than nothing (xep27)
  624. Flow moparisthebest: I don't think so. OpenPGP without a replay mitigation is worser than no verification at all
  625. Flow for example
  626. moparisthebest replay is a type of attack, sometimes it doesn't matter
  627. Flow ?
  628. jonasw Holger, whatsapp apperently does it quite well
  629. jonasw but I only heard that second- or third-hand
  630. moparisthebest Flow, sometimes you just need to protect content and don't care about replay
  631. jonasw moparisthebest, I don’t say we shouldn’t support e2ee at all. but Jabber as an IM system has much worse problems than not supporting E2EE currently.
  632. jonasw we need to solve those firts
  633. moparisthebest it's always going to have problems, everything does
  634. jonasw *especially* with security systems you can’t simply handwave problems away
  635. Flow moparisthebest: but especially in IM you want to know that the "I aggree" from the other side was a current response, and not from days ago
  636. jonasw people don’t expect replay attacks to work
  637. Holger jonasw: Yes much better than we do, mostly because they hide verification very well and don't have MAM/multi-device support. (And of course because they avoid implementation issues by controlling the clients.)
  638. jonasw and you can’t expect people to understand that
  639. jonasw Holger, they don’t have multi-device support?
  640. jonasw I thought they did.
  641. jonasw but how does that relate to spam filtering?
  642. Holger jonasw: No, they just have a web client that talks to your phone.
  643. jonasw eww
  644. mimi89999 has joined
  645. stefandxm has left
  646. zinid has left
  647. moparisthebest Flow, yes the "I agree" replay is potentially a problem, the "here is your report for 2017-01-01 08:32 bla bla bla" is not
  648. moparisthebest but uh, "replay" is also a huge problem without e2e, so
  649. jjrh has left
  650. jjrh has left
  651. zinid has left
  652. jjrh has left
  653. zinid has left
  654. Ge0rG has left
  655. pep. has joined
  656. Ge0rG Holger: and because they have millions of dev budget.
  657. Ge0rG has left
  658. Flow moparisthebest: "the "here is your report for 2017-01-01 08:32 bla bla bla" is not"?
  659. moparisthebest Flow, if I get a dated report from last month I'll be pretty sure it's a replay I guess
  660. Holger Ge0rG: RIght.
  661. moparisthebest what is the argument here? xep27 is bad because it's vulnerable to replay so use no encryption? (which is also vulnerable to replay)
  662. Holger That's not my argument, no. I use 0027 with the two-and-a-half geeks that manage to cope with key deployment in my roster myself.
  663. moparisthebest anecdote of course but I switched to xmpp specifically so I could use PGP, then omemo came along and I use it sometimes, PGP still has a place
  664. moparisthebest now I'd much rather use OX than 27, but 27 is better than nothing
  665. Flow moparisthebest: The point is that xep27 is badly designed, allowing for replay attacks because the recipient (and a timestamp) is not part of the secured data
  666. Ge0rG moparisthebest [21:22]: > Flow, if I get a dated report from last month I'll be pretty sure it's a replay I guess And if the report author gets a "the report is okay, publish it", you can't know for sure
  667. Holger moparisthebest: Yes, "no forward secrecy" and "one key per contact rather than per device" are clearly features I appreciate compared to OTR/OMEMO.
  668. moparisthebest right I completely agree OX is better Flow , but 27 is better than nothing
  669. Flow OpenPGP certainly has it's place
  670. Flow moparisthebest; And that is where I disagree with you ☺
  671. moparisthebest I find it most handy for where I used to send cronjob output as pgp encrypted email from my servers
  672. moparisthebest a sendxmpp that does OMEMO seems, hard
  673. Flow true
  674. moparisthebest Flow, how could 27 possibly be worse than no encryption exactly
  675. moparisthebest it doesn't prevent replay or spoofing, neither does no encryption
  676. Holger Wrong sense of security.
  677. Flow moparisthebest: what holger said
  678. moparisthebest it does protect content
  679. moparisthebest that's all it does, I know that, I'm fine with that
  680. Flow it may be sufficently secure for the use case you described
  681. Flow but not for the gernal IM use case
  682. moparisthebest 100% agree OX should be pushed forward and I will drop 27 first :P but until then
  683. Flow OX would be able to prevent spoofing, xep27 is not
  684. Flow It's such a pitty that there is no high level OpenPGP library for java
  685. moparisthebest you could do android first :)
  686. moparisthebest in fact there was a WIP OX pull request for conversations
  687. Flow (Java/Android that is)
  688. moparisthebest android has an excellent openpgp implementation/app
  689. Flow I know, OX was born because I meet the OpenKeychain dev's at the GSOC mentor's sumimt 2015
  690. Flow *met
  691. Flow I've been begging them to factor out the OpenPGP part of OpenKeychain into a library for Java and Android
  692. moparisthebest on android at least it's better as-is isn't it?
  693. moparisthebest as a PGP app that's usable by other apps
  694. Flow I'm sorry, I don't know how to parse that
  695. Flow Ahh yes, that was our idea for the conversations OX implemenation
  696. moparisthebest I don't want to import my key into conversations, and k9mail, and oandbackup
  697. moparisthebest I instead import it into OpenKeychain, and it does all the lifting, and the other apps just talk to it
  698. Flow OK (OpenKeychain) was missing a few additional exposed APIs for OX in conversations
  699. Flow but the effort stalled
  700. Holger moparisthebest: I don't want to import any keys anywhere.
  701. zinid > incorrect, WhatsApp does server-side spam filtering only with metadata. No surprise, for centralized servers it's much easier to fight against spam when you control *every* user
  702. Holger moparisthebest: The key should silently be created by the app I'm using and auto-deployed to any other devices. Anything else will end up being completely unusable.
  703. moparisthebest oh well that's a different thing, yea I'm sure they'd add additional apis
  704. moparisthebest Holger, omemo?
  705. Holger moparisthebest: OX, maybe.
  706. Holger moparisthebest: https://xmpp.org/extensions/xep-0373.html#synchro-pep
  707. moparisthebest hmm I'm not sure 1 key being automagically distributed is better than one key per device
  708. moparisthebest yea I remember reading it, I'm not convinced I want my encrypted key on my server
  709. Holger moparisthebest: IMO it makes the difference between "completely unusable" and "maybe somewhat usable" by non-geeks.
  710. Holger moparisthebest: Do you have a single non-geek in your roster you're talking PGP to?
  711. moparisthebest I think you are right actually
  712. moparisthebest in that the normal case it should do that
  713. moparisthebest but should also allow me to use my already-set-up-not-on-server key
  714. moparisthebest Holger, uh yes, but you didn't ask if I had to set up their pgp key for them or not :)
  715. Holger Yah I'm not discussing Advanced -> Expert -> Special options.
  716. jere has joined
  717. moparisthebest do I have anyone in my roster I talk to with PGP that I didn't fully set up their key manually for them for? no :'(
  718. Holger I had like five and am down to three I think.
  719. Holger Of my ~150 contacts.
  720. Holger If which 100+ are geeks :-)
  721. Holger s/If/Of
  722. moparisthebest what client(s) do you use?
  723. Holger MCabber and Conversations.
  724. moparisthebest ah ok, I started with gajim and it didn't actually do carbons+pgp right, I got the impression no one else had tried
  725. Holger I heard of various issues with Gajim's PGP support but never tried myself.
  726. Holger Works just fine with my two clients.
  727. moparisthebest I put in a patch to fix that and it worked great for years until new gpg broke the python gpg lib, and I haven't looked at it
  728. Holger Ah right gpg2 is a PITA for MCabber as well. The fix is sticking to gpg1.
  729. Holger (Though McKael is somehow using gpg2 I think ...)
  730. jere has joined
  731. moparisthebest iirc it worked fine with gpg 2 but 2.1 broke it
  732. moparisthebest I think the python lib is hardcoded to treat unknown errors fatally instead of a generic error and that breaks everything
  733. moparisthebest I need to look into it one day
  734. zinid I'm not a security expert, but what is a problem to keep private key securely on a server?
  735. McKael Holger: Yes I'm using GPG2 but it's painful, indeed.
  736. moparisthebest McKael, have any patches laying about or a terrible wrapper script or what? :)
  737. zinid can't I just encrypt it using my password which is supposedly stored hashed as well?
  738. McKael moparisthebest: No, lately I've been using the default pinentry and it messes things up
  739. McKael Not sure how I got rid of that before, I forgot :/
  740. jubalh has left
  741. Wiktor zinid: defense in depth, one can tell that your server is already protected by password so no need for PGP private key passwords, but you use it anyway to have layers of protection
  742. zinid I don't understand, according to e2e proponents, they don't trust server admins
  743. Holger zinid: Yes that's how I'd do it. Not sure how to survive forgotton/restored passwords though. Maybe each client needs an unencrypted copy of the key to re-encrypt it on password change or something ...
  744. tim@boese-ban.de has joined
  745. Wiktor zinid: you don't store the private key even encrypted because loss of password would compromise the key
  746. zinid has left
  747. Wiktor I'm not using PGP with xmpp though
  748. mimi89999 has joined
  749. Wiktor But usually you don't even store the private key in software but use hardware token
  750. daniel has joined
  751. Wiktor To further protect the key
  752. zinid but you can also lose private key
  753. Holger "usually" :-)
  754. zinid Holger: lol :)
  755. matlag Holger, I would separate the account's PW from the key's encryption PW, then the server also stores the latest modif of the encryption PW, when the user connects, the client checks if its stored PW is the latest, and if not prompt the user for the new one
  756. zinid and typically you lose private key with losing phone for example
  757. zinid still not clear
  758. zinid I cannot believe there is no solutions for this problem, key servers? kerberos? just to mention, I know jack shit about these :)
  759. Holger matlag: The server has a clear-text copy of the key encryption PW??
  760. matlag no, only the date of the latest change
  761. Holger Ah.
  762. Holger So simply a separate passphrase?
  763. matlag yep
  764. Holger "Hello User, please type your password! ... thanks, now please type your other password!"
  765. zinid which will be the same for the majority of users :)
  766. Holger They'll love you.
  767. Wiktor zinid: truly paranoid store their private key copies only on offline, airgapped machines, then load it on OpenPGP smart card
  768. Wiktor Note I'm not advocating for that
  769. zinid Wiktor: are we building a network for trully paranoid?
  770. zinid Wiktor: can we just have non-paranoid mode/
  771. zinid ?
  772. matlag well, currently the risk is "Hello User, please type your password! ... now please type your entire private key"
  773. Wiktor I'm not building anything just saying there are various threat models in existence
  774. matlag zinid, you need to fit all the needs! so paranoid should be an option
  775. zinid matlag: sure, don't store private keys on server, keep them on hardwared device
  776. zinid I mean it's totally opaque for the server where you keep your keys
  777. Holger matlag: My point was about increasing the usablity of E2EE, not about increasing it's security. The latter is easier, the problem is just that you end up with zero users of your secure solution.
  778. zinid but still a problem with password restoration indeed
  779. Holger matlag: As a well-hidden *option* you can make it as secure and unusable as you like. The interesting part to achieve is to implement a default behavior that doesn't break day-to-day communication.
  780. zinid I agreed
  781. matlag I admit it's not so friendly, but on the other hand, you can store the key PW on the client and then you don't need to change it as long as you don't change the key PW
  782. zinid currently users are trying to use OMEMO, they fail and resort not to using OMEMO at all
  783. zinid so probably better to use less secure option?
  784. matlag I mean: is that so much more cumbersome than changing your home's wifi password?
  785. Holger zinid: They resort to ditching the non-working XMPP crap.
  786. Holger matlag: The point is it's so much more cumbersome than just using WhatsApp/Signal/whatever.
  787. zinid matlag: did you really contact with a regular user? my wife's mother cannot configure wifi for example, but she loves whatsapp, so a potential user
  788. matlag Yeah, ok, point taken
  789. moparisthebest what if you make them have 16 character passwords and take the first 8 for the key password and send the second 8 to the server for login
  790. moparisthebest either way yea I want to decrypt my pgp key with a seperate password, normal users probably don't need it encrypted on the device at all
  791. zinid but all 16 characters will be lost?
  792. Holger moparisthebest: Won't help much if you're trying to protect against the case where the password is lost.
  793. zinid because they are stored in a single place, no?
  794. matlag moparisthebest, They end up typing the 16 characters and that's the same as having hte same PW for both
  795. Flow has left
  796. Holger (zinid was faster.)
  797. Ge0rG What would be great is an xmpp server that encrypts everything for a user with a key pair where the private key is only unlocked while the user is logged in.
  798. Wiktor If your target user is a mother in law you shouldn't be talking about encryption because she probably doesn't care if whatsapp is encrypted but of easy contact discovery and on boarding process
  799. zinid Wiktor: but usually I'm not talking about e2e :)
  800. zinid I think it's still just a toy
  801. moparisthebest Ge0rG, meh that's still just fully trusting the server
  802. moparisthebest I mean you already have full disk encryption and such on the server
  803. Holger Wiktor: Agreed! I'd just disable encryption by default. But everyone is telling me it MUST be enabled by default, or even always.
  804. Zash Ge0rG: Wanna the crypto design and audit?
  805. Wiktor zinid: agreed, but for me it's a toy for power users, like PGP itself
  806. matlag So let's assume most users don't care about encryption but you want a default encryption for them: most can use the same PW for account and private key, others can have them separated?
  807. moparisthebest or just don't have a password on the local pgp key
  808. Holger Wiktor: So I'm getting to think about how to enable E2EE in order to make the geek marketing department happy without breaking stuff for the mother in law :-)
  809. zinid Wiktor: then nothing should be changed, everything is great
  810. moparisthebest it's storing full conversations in plain text anyway, most likely
  811. Wiktor Holger: on my client it's disabled by defiant and I use it with one contact for 239 unencrypted
  812. Wiktor For me that's a good ratio
  813. Holger Wiktor: The Conversations tracker is full of people complaining how OMEMO is optional and non-default.
  814. Wiktor zinid: w.r.t. To omemo just add support for key migration / rotation and easier adding of new devices
  815. Zash I did a prototype of a thing where some data is encrypted using a key derived from a SCRAM thing that you only have during login
  816. Ge0rG Zash: maybe one day I'll find a corporate customer that will pay for it
  817. moparisthebest because default is how it stays 99% of the time
  818. Ge0rG Zash: I remember that, yeah
  819. moparisthebest and if we've learned anything over the past 5 years or whatever, encryption should always be default
  820. moparisthebest at least, most people have learned that
  821. Holger Wiktor: ^ see?
  822. zinid :D
  823. Wiktor Hshshw
  824. Holger Wiktor: So how to deal with all the moparisthebests in the community? :-)
  825. Wiktor Hahaha*
  826. Zash moparisthebest: I'm not convinced that XMPP is the right thing if you wanna have a protocol where everything is encrypted.
  827. moparisthebest :)
  828. Wiktor Great point Holger
  829. moparisthebest Zash, do you know of better ones that don't eat battery due to p2p ?
  830. Zash XMPP is a giant compromise. Compromise between p2p and centralized.
  831. SamWhited > encryption should always be default Define "encryption"? Are you still talking about e2e encryption like most of this conversation (I've just been passively following)
  832. moparisthebest all of it, imho
  833. moparisthebest I mean, TLS/transport encryption should be mandatory with no cut-off
  834. Wiktor moparisthebest: well it is on xmpp since 2014?
  835. moparisthebest e2e should be default, with the ideal of no cut-off
  836. Holger moparisthebest: Apart from that, I should be rich!
  837. moparisthebest that's the ideal isn't it? :P
  838. daniel has left
  839. Wiktor moparisthebest: what is your threat model? Why do you want e2e6by default? Do you understand that without face to face fingerprint comparisons e2e does not provide any significant advantages?
  840. moparisthebest I tend to agree current pgp/omemo isn't quite ready for default enforced prime-time, that's just where we should be aiming
  841. moparisthebest Wiktor, it still defeats passive surveillance which is ubiquitous
  842. Wiktor Tls defeats passive surveillance
  843. moparisthebest also all the server hack leaks everywhere
  844. stefandxm has joined
  845. SamWhited Why? What is the actual thing you are trying to accomplish by making e2e encryption the default?
  846. Zash moparisthebest: By whom? e2e protects against some cases of evil server, but in XMPP, if your server is evil, you are screwed
  847. moparisthebest you don't have to trust your server, so why trust your server
  848. moparisthebest and, your chat partner's server if not the same
  849. zinid Zash: the point I'm told is that the remote server can be evil and you can do nothing with it
  850. Wiktor Zash: exactly. moparisthebest If your server lies about your keys and you don't compare them live then the security model has been broken
  851. Valerian has left
  852. moparisthebest also define 'screwed', it can block your messages, it can't do anything else with e2e
  853. moparisthebest Wiktor, again an active attack that you can detect before, during, or after
  854. Zash zinid: Sure, you have to trust that your chat partner picked a trustworthy server too.
  855. moparisthebest vs you having no idea who has your messages when
  856. Wiktor Well usually only your server and your friend's has messages, in xmpp they are directly connected.
  857. zinid Zash: I agree you cannot build security without trust, the question is how paranoid we should be
  858. SamWhited It sounds like "encryption" is being equated with "security" here, and that's always dangerous. If you ignore the user aspect (you're making all sorts of trade offs by forcing everything to be e2e encrypted) they'll just go somewhere else or develop bad habits that make things worse. If you can't clearly articulate a reason other than "why not?" you may want to think about it more. That's never an okay way to approach thinking about security.
  859. moparisthebest Wiktor, do I know if they are connected securely
  860. Valerian has joined
  861. moparisthebest do I know if the other users server mandates encryption on c2s
  862. moparisthebest tls in this case
  863. Wiktor Well your server should mandate your security standards
  864. moparisthebest but if you sign up for newhotserver.im
  865. moparisthebest you think key verification is the problem
  866. waqas has left
  867. moparisthebest but the solution is to personally trust your server operator?
  868. moparisthebest seems suspicious
  869. Wiktor Then do you know if your friends computer is not compromised by malware?
  870. moparisthebest it's about minimizing risk, that's a risk either way
  871. moparisthebest you have to trust your friend's endpoint
  872. moparisthebest you don't have to trust everything in between
  873. Wiktor Key verification is always the biggest problems :)
  874. Wiktor Yes it's about minimizing risk but if the advantage is small enough then it's not ok to mandate e2e everywhere
  875. SamWhited Or if it actually makes things worse…
  876. moparisthebest what if it doesn't have any disadvantages
  877. Wiktor Yes, exactly. There are always trade offs
  878. zinid moparisthebest: but it does
  879. moparisthebest you mean some current systems do
  880. zinid yes
  881. Wiktor > what if it doesn't have any disadvantages I've never seen a solution to anything without disadvantages. There are always constraints.
  882. Valerian has left
  883. zinid and security is always inversly proportional to usability
  884. zinid whatever encryption you suggest, you lower the usability part
  885. zinid so users should clearyl understand why they suffer
  886. moparisthebest that's not true though
  887. moparisthebest do you have your laptop hard drive encrypted?
  888. zinid moparisthebest: that's not even my words, Schneier said that :)
  889. zinid moparisthebest: no, I don't
  890. moparisthebest even great guys can be wrong sometimes haha
  891. moparisthebest ok well that's just inexcusable why? :P
  892. moparisthebest I guess if it never leaves your house it's probably fine
  893. zinid moparisthebest: I don't know how to do this
  894. Wiktor HD encrypted can be a usability nightmare if you have your keys only in TPM and TPM died :)
  895. zinid is it ok answer? :)
  896. matlag moparisthebest, In this case, for example, the only way to have a solution that guarantees no user intervention is to have the private key stored on server and encrypted with the user's account PW: no degradation of usability, BUT: not nearly as safe as the blows and whistle you hear for great E2E
  897. moparisthebest the point I was going to make was it's the same either way, you type a password to get into it regardless, and nowadays it doesn't even run slower
  898. SamWhited I have two laptops, one has the disk encrypted and one doesn't. The one with the disk encrypted I have to type a password in every time I boot and if the sector that contains the key gets corrupt the whole harddrive is lost instead of just that one sector.
  899. SamWhited That is a trade off.
  900. SamWhited I only chose to make it on one laptop because I have a very specific threat I am trying to protect against with that specific machine.
  901. matlag if you increase security, then you need the user intervention, and as you increase it, more and more user intervention
  902. moparisthebest a few sectors include the key normally SamWhited
  903. SamWhited Doesn't matter, it is more likely that I lose all the data (I do actually have it in two key slots, I also keep an offsite backup, another tradeoff I made)
  904. goffi has left
  905. SamWhited The point is there are tradeoffs to the thing you used as an example too. If you don't even know what threat you're trying to protect against, there's little point in making some of these trade offs.
  906. moparisthebest really that's a bad example anyway, the users I see generally expect chat to be ephemeral anyway
  907. moparisthebest so if they forget their password and don't have logs from yesterday, oh well
  908. moparisthebest I guess it's a trade off but also maybe what they expect?
  909. zinid a good example is probably how PKIX is used currently in browsers
  910. moparisthebest (I'm basing this on all the users that want to be able to delete shared pictures from http upload)
  911. Ge0rG I expect IM history to be eternal. Maybe I'm different.
  912. zinid very little inconvenience
  913. moparisthebest Ge0rG, then you already have backups and such and will get that with e2e also
  914. efrit has joined
  915. Ge0rG moparisthebest: e2ee is more complicated than not having it.
  916. Ge0rG moparisthebest: the people who are the loudest to demand e2ee have the least understanding of it, usually.
  917. stefandxm has left
  918. Ge0rG And I'm on the road for almost eight hours now. German public transportation has been severely impacted by some storm.
  919. moparisthebest I guess everything is more complicated than not having it
  920. Ge0rG moparisthebest: Easy XMPP is an exception
  921. zinid xmpp2 !!!111
  922. moparisthebest still more code
  923. lovetox has joined
  924. zinid Ge0rG: btw, your subject about message routing didn't route further in the standards@ :)
  925. zinid Ge0rG: my guess is that nobody knows how to fix stuff, lol
  926. waqas has joined
  927. moparisthebest can we make direct tls the only way to connect in xmpp2 ? :P
  928. zinid adding more xeps => sucks breaking compatiblity => sucks
  929. zinid moparisthebest: is it the major problem? :)
  930. moparisthebest no just another nice-to-have
  931. moparisthebest also I don't see any trade-offs with this one haha
  932. la|r|ma has joined
  933. lskdjf has joined
  934. zinid the trade-off is more implementation
  935. zinid poor library support
  936. moparisthebest for direct TLS ?
  937. moparisthebest surely it's the opposite
  938. zinid yes
  939. moparisthebest every TLS lib ever vs xmpp-specific-libs ?
  940. zinid you need to support SNI in server, that's some work if you use openssl ;)
  941. zinid ejabberd doesn't support it for this reason, the API is ugly as hell
  942. moparisthebest you are already doing far more work for everything else in xmpp2 surely
  943. zinid I need to be a man and implement it
  944. moparisthebest anyway it gives you tons of other advantages
  945. moparisthebest 0-rtt, false start, everything fancy https gets
  946. zinid isn't this the trade-off we're talking about? :)
  947. zinid you get all these goods, but need to put more code, at least server side
  948. zinid and ALPN is only supported in openssl 1.0.2, some systems still don't have it yet
  949. moparisthebest you are talking about xmpp2 though, it's all more code
  950. MattJ I think I'd rather rewrite everything XMPP from scratch than spend time near OpenSSL's API again
  951. zinid moparisthebest: that was a joke actually :) obviously transition to xmpp2 will bring lots of pain
  952. moparisthebest also zinid 1.0.1 is already dead so I don't think anyone should care, hopefully :(
  953. moparisthebest yea openssl is the perfect example of a footgun api
  954. zinid moparisthebest: surprisingly, we get complains from time to time about cutting edge version requirement (1.0.1), lol :)
  955. Holger "zinid 1.0.1 is already dead"
  956. zinid ah
  957. Holger goes updating zinid.
  958. zinid2.0 has joined
  959. zinid_2.0 has joined
  960. moparisthebest context, it's all about context :P
  961. Ge0rG has left
  962. Valerian has joined
  963. zinid but still I think direct tls is a great idea
  964. stefandxm has joined
  965. Guus has left
  966. tim@boese-ban.de has joined
  967. waqas has left
  968. Tobias has joined
  969. jjrh has left
  970. jubalh has joined
  971. Alex has left
  972. jubalh has left
  973. moparisthebest has joined
  974. winfried has joined
  975. intosi has joined
  976. jubalh has joined
  977. andrey.g has joined
  978. uc has joined
  979. SamWhited has left
  980. ralphm has joined
  981. andrey.g has joined
  982. andrey.g has left
  983. waqas has joined
  984. Valerian has left
  985. jubalh has left
  986. la|r|ma has joined
  987. lskdjf has joined
  988. jubalh has left
  989. andrey.g has joined
  990. winfried has joined
  991. jjrh has left
  992. andrey.g has joined
  993. Valerian has joined
  994. uc has joined
  995. Tobias has joined
  996. zinid has left
  997. andrey.g has joined
  998. jjrh has left
  999. andrey.g has left
  1000. la|r|ma has joined
  1001. zinid has left
  1002. zinid has joined
  1003. zinid has left
  1004. matlag has left
  1005. lskdjf has joined
  1006. zinid has joined
  1007. jjrh has left
  1008. jjrh has left
  1009. Valerian has left
  1010. Valerian has joined
  1011. Zash has left
  1012. waqas has left
  1013. ThurahT has left
  1014. lovetox has left
  1015. ThurahT has joined
  1016. ThurahT has left
  1017. waqas has joined
  1018. ThurahT has joined
  1019. Guus has left