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