XSF Discussion - 2020-06-05


  1. mukt2 has left

  2. mukt2 has joined

  3. andrey.g has left

  4. Neustradamus

    Ge0rG: Where is the last official Yaxim .SVG icon? (cc rion)

  5. Maranda has joined

  6. Daniel has left

  7. stpeter has left

  8. Daniel has joined

  9. mukt2 has left

  10. LNJ has left

  11. mukt2 has joined

  12. LNJ has joined

  13. murabito has joined

  14. waqas has left

  15. lskdjf has left

  16. Daniel has left

  17. Daniel has joined

  18. lskdjf has joined

  19. mukt2 has left

  20. emus has left

  21. mukt2 has joined

  22. Daniel has left

  23. Daniel has joined

  24. sonny has left

  25. sonny has joined

  26. lskdjf has left

  27. LNJ has left

  28. arc has left

  29. arc has joined

  30. arc has left

  31. arc has joined

  32. arc has left

  33. arc has joined

  34. arc has left

  35. arc has joined

  36. andy has joined

  37. Yagiza has joined

  38. mukt2 has left

  39. murabito has left

  40. murabito has joined

  41. mukt2 has joined

  42. Maranda has left

  43. mimi89999 has left

  44. mimi89999 has joined

  45. Maranda has joined

  46. lovetox has joined

  47. mukt2 has left

  48. Tobias has joined

  49. wurstsalat has joined

  50. Daniel has left

  51. Daniel has joined

  52. Mikaela has joined

  53. mukt2 has joined

  54. Daniel has left

  55. paul has joined

  56. Yagiza has left

  57. Yagiza has joined

  58. Daniel has joined

  59. lorddavidiii has joined

  60. Yagiza has left

  61. Yagiza has joined

  62. winfried has left

  63. winfried has joined

  64. werdan has joined

  65. Bezi has left

  66. Bezi has joined

  67. bear has left

  68. winfried has left

  69. winfried has joined

  70. werdan has left

  71. neshtaxmpp has left

  72. neshtaxmpp has joined

  73. neshtaxmpp has left

  74. neshtaxmpp has joined

  75. mukt2 has left

  76. winfried has left

  77. winfried has joined

  78. mukt2 has joined

  79. adiaholic_ has joined

  80. winfried has left

  81. winfried has joined

  82. winfried has left

  83. winfried has joined

  84. lovetox has left

  85. neshtaxmpp has left

  86. neshtaxmpp has joined

  87. Ge0rG

    rion: Neustradamus: https://github.com/yaxim-org/yaxim/blob/master/asset-graphics/yak/yak-front-grass.svg

  88. lovetox has joined

  89. bear has joined

  90. karoshi has joined

  91. neshtaxmpp has left

  92. neshtaxmpp has joined

  93. goffi has joined

  94. mukt2 has left

  95. bear has left

  96. Maranda has left

  97. bear has joined

  98. neshtaxmpp has left

  99. Nekit has joined

  100. neshtaxmpp has joined

  101. mukt2 has joined

  102. edhelas has left

  103. edhelas has joined

  104. neshtaxmpp has left

  105. marc has left

  106. edhelas has left

  107. edhelas has joined

  108. marc has joined

  109. chyna has joined

  110. adiaholic_ has left

  111. adiaholic_ has joined

  112. neshtaxmpp has joined

  113. Half-Shot has left

  114. uhoreg has left

  115. Half-Shot has joined

  116. uhoreg has joined

  117. Shell has joined

  118. Andrzej has joined

  119. lbocquet has left

  120. Neustradamus has left

  121. Neustradamus has joined

  122. lbocquet has joined

  123. mukt2 has left

  124. sonny has left

  125. sonny has joined

  126. mukt2 has joined

  127. marc has left

  128. mimi89999 has left

  129. mimi89999 has joined

  130. Half-Shot has left

  131. uhoreg has left

  132. Half-Shot has joined

  133. uhoreg has joined

  134. adiaholic_ has left

  135. karoshi has left

  136. adiaholic_ has joined

  137. karoshi has joined

  138. emus has joined

  139. marc has joined

  140. !XSF_Martin has left

  141. lskdjf has joined

  142. !XSF_Martin has joined

  143. Maranda has joined

  144. Steve Kille has left

  145. mukt2 has left

  146. Steve Kille has joined

  147. mukt2 has joined

  148. LNJ has joined

  149. sonny has left

  150. sonny has joined

  151. j.r has left

  152. j.r has joined

  153. paul has left

  154. neshtaxmpp has left

  155. edhelas has left

  156. mukt2 has left

  157. werdan has joined

  158. edhelas has joined

  159. sonny has left

  160. sonny has joined

  161. karoshi has left

  162. karoshi has joined

  163. lskdjf has left

  164. lskdjf has joined

  165. mukt2 has joined

  166. sonny has left

  167. sonny has joined

  168. govanify has left

  169. mukt2 has left

  170. govanify has joined

  171. marc has left

  172. sonny has left

  173. sonny has joined

  174. marc has joined

  175. paul has joined

  176. paul has left

  177. paul has joined

  178. mukt2 has joined

  179. govanify has left

  180. govanify has joined

  181. mukt2 has left

  182. debacle has joined

  183. mukt2 has joined

  184. lskdjf has left

  185. lskdjf has joined

  186. neshtaxmpp has joined

  187. sonny has left

  188. werdan has left

  189. sonny has joined

  190. sonny has left

  191. sonny has joined

  192. karoshi has left

  193. karoshi has joined

  194. Zash has left

  195. Zash has joined

  196. Guus

    FMUC wise, how can the state of federation be reflected to users in the chat? Currently the only way as a user to tell if you've lost federation is that you see people leave the chat, it seems?

  197. Zash

    https://xmpp.org/extensions/xep-0310.xml mayhaps?

  198. Guus

    Thanks. A quick reading does not make me confident that I get its meaning, but it seems at least partially related.

  199. Guus

    Will look into it further

  200. lovetox

    Guus, i would say a user does not need to know that

  201. Guus

    lovetox: why is that?

  202. lovetox

    because its nothing that should happen regulary, its a technical detail of the protocol and infrastructur

  203. lovetox

    you dont get a whatsapp message when one of their server goes offline for a minute

  204. lovetox

    service is not working, i guess the user will notice that if he cant see any people in a MUC anymore

  205. lovetox

    thats all he needs to know, and bug his admin afterwards

  206. sonny has left

  207. sonny has joined

  208. Kev

    I think you're making assumptions there about the nature of the deploymen.

  209. Kev

    I think you're making assumptions there about the nature of the deployment.

  210. Kev

    FMUC is typically deployed places where it is something that may happen frequently, and that the users may well want to know.

  211. Kev

    Guus: From memory, we exit the users from the room with a show saying why.

  212. Guus

    What Kev said, and: thanks Kev.

  213. Kev

    I don't *think* we inject a system message at the same time, but I might misremember that bit.

  214. karoshi has left

  215. karoshi has joined

  216. Guus

    I am compiling a rather long text of XEP feedback - not very structured at the moment, but I guess I should post it somewhere

  217. Kev

    I've had a TODO to look at FMUC for ages, but as no-one else was implementing it it dropped way down my list.

  218. Kev

    Sorry Guus.

  219. Guus

    No worries, that's only to be expected.

  220. Guus

    I'm grateful for the feedback you've been giving me recently

  221. mukt2 has left

  222. Andrzej has left

  223. mukt2 has joined

  224. sonny has left

  225. sonny has joined

  226. sonny has left

  227. sonny has joined

  228. sonny has left

  229. sonny has joined

  230. Nekit has left

  231. Nekit has joined

  232. mukt2 has left

  233. neshtaxmpp has left

  234. mukt2 has joined

  235. karoshi has left

  236. Andrzej has joined

  237. waqas has joined

  238. neshtaxmpp has joined

  239. jonas’

    classic IRC netsplit

  240. jonas’

    lovetox, it happens "all the time" on IRC

  241. jonas’

    and I’m not sure if FMUC can replay history, in which case you’d very well need to know what’s goin gon

  242. jonas’

    and I’m not sure if FMUC can replay history, in which case you’d very well need to know what’s going on

  243. werdan has joined

  244. mukt2 has left

  245. krauq has left

  246. Shell has left

  247. Shell has joined

  248. karoshi has joined

  249. debacle has left

  250. chyna has left

  251. Yagiza has left

  252. mukt2 has joined

  253. stpeter has joined

  254. Shell has left

  255. Shell has joined

  256. remko has joined

  257. krauq has joined

  258. chyna has joined

  259. arc has left

  260. arc has joined

  261. neshtaxmpp has left

  262. neshtaxmpp has joined

  263. mukt2 has left

  264. adiaholic_ has left

  265. paul has left

  266. mukt2 has joined

  267. neshtaxmpp has left

  268. neshtaxmpp has joined

  269. adiaholic_ has joined

  270. Andrzej has left

  271. Andrzej has joined

  272. Wojtek has joined

  273. krauq has left

  274. krauq has joined

  275. krauq has left

  276. krauq has joined

  277. remko has left

  278. remko has joined

  279. Shell has left

  280. Shell has joined

  281. Shell has left

  282. Shell has joined

  283. Nekit has left

  284. arc has left

  285. arc has joined

  286. Syndace has left

  287. werdan has left

  288. Andrzej has left

  289. Andrzej has joined

  290. remko has left

  291. remko has joined

  292. Andrzej has left

  293. Andrzej has joined

  294. mimi89999 has left

  295. Andrzej has left

  296. Andrzej has joined

  297. Shell has left

  298. Shell has joined

  299. alexis has left

  300. Shell has left

  301. Guus

    The history sync is awkward. I haven't figured that out in our implementation.

  302. remko has left

  303. govanify has left

  304. govanify has joined

  305. chyna has left

  306. Steve Kille has left

  307. remko has joined

  308. Steve Kille has joined

  309. govanify has left

  310. govanify has joined

  311. Zash

    MUC-to-MUC MAM?

  312. govanify has left

  313. govanify has joined

  314. govanify has left

  315. govanify has joined

  316. emus has left

  317. xecks has left

  318. Holger

    Matrix.

  319. Zash

    Not until start trying to merge those histories

  320. Holger

    Matrix in broken.

  321. xecks has joined

  322. waqas has left

  323. chyna has joined

  324. emus has joined

  325. Andrzej has left

  326. Andrzej has joined

  327. tom has left

  328. Shell has joined

  329. Andrzej has left

  330. Andrzej has joined

  331. Andrzej has left

  332. Andrzej has joined

  333. Andrzej has left

  334. Andrzej has joined

  335. Andrzej has left

  336. Andrzej has joined

  337. Andrzej has left

  338. Andrzej has joined

  339. Syndace has joined

  340. Andrzej has left

  341. Andrzej has joined

  342. Andrzej has left

  343. Andrzej has joined

  344. Kev

    Guus: Is it that tricky? It's mostly the same as client history.

  345. karoshi has left

  346. Guus

    Kev: which I've never implemented myself either. 😁

  347. Zash

    Kev: Gets tricky if there's history on both sides that the other doesn't have?

  348. Guus

    What I wonder about is injection history mid-session, when a room with existing history and ongoing chat suddenly needs to interweave history from another source that joined.

  349. mukt2 has left

  350. mukt2 has joined

  351. govanify has left

  352. govanify has joined

  353. karoshi has joined

  354. chyna has left

  355. chyna has joined

  356. DebXWoody

    Here little bit feedback / remarks / question for XMPP-OX: https://wiki.xmpp.org/web/Tech_pages/OX

  357. lovetox

    DebXWoody, after reading that my motiviation to implement OX is near zero

  358. werdan has joined

  359. moparisthebest

    so you are saying there is a chance? >:)

  360. lovetox

    i tell you what i implement

  361. lovetox

    - Client generates Key, user can't bring his own - Key has no password - There is only one public key accepted per contact, and the only source of it is PEP

  362. flow

    DebXWoody, read it, pubsub get will get you the latest published item on a node, which is the latest version of the key

  363. lovetox

    Is it possible with pgp to change the expiry date on a key without changing the fingerprint?

  364. flow

    yes

  365. DebXWoody

    yes

  366. lovetox

    how does that work?! surley it has to be protected someway

  367. flow

    lovetox, it's a signed packet added to the keyring

  368. chyna has left

  369. lovetox

    signed by who?

  370. flow

    signed by the master key

  371. lovetox

    and who signes the expiry date of the master key

  372. chyna has joined

  373. lovetox

    or does the key i generate sign the packet itself

  374. flow

    basically yes

  375. lovetox

    Ok, yeah then let me add to that list - No expiry date on keys

  376. flow

    yes expiries are typical not useful for the average user

  377. Andrzej has left

  378. Andrzej has joined

  379. lovetox

    i like OX i think its less complicated than OMEMO and i dont really need the benefits of OMEMO

  380. flow

    depends

  381. DebXWoody

    lovetox, why near zero? I know what has been implemented (at least a little bit). I think your approach is not wrong. I see some pros on your implementation, but also some cons.

  382. flow

    openpgp provides a lot of freedom

  383. lovetox

    but i fear that people go into that with their own ideas how openpgp in xmpp should work

  384. lovetox

    and the XEP basically lets many things open

  385. flow

    and it could happen that OX is grated by different opinions which try to move it toward their choice

  386. lovetox

    and i fear this will make it not interoperable

  387. mimi89999 has joined

  388. flow

    which would be sad, because I think the existing openpgp ecosystem shows that it is interoperable while allowing a high degree of freedom

  389. lovetox

    flow only if you have a client that supports all the freedom

  390. flow

    no I don't think so

  391. lovetox

    which makes it less likely to implement

  392. flow

    MUAs shows that this is possible

  393. DebXWoody

    lovetox, I think we should fine a mix of it, this is the reason why I started this wiki page. I would like to use XMPP with my Nitrokey, this is basically the reason why I prefer to use my own keyring also.

  394. lovetox

    MUAs? whats that

  395. flow

    mail clients

  396. lovetox

    For me OX has to be implemented in a way that it is as invisible and easy to use as OMEMO

  397. DebXWoody

    yes

  398. flow

    sure

  399. lovetox

    yeah but that rules some things out for me that people that use PGP do daily

  400. flow

    probably, but does that mean that your code will not be able to exchange openpgp secured messages with those people?

  401. Andrzej has left

  402. Andrzej has joined

  403. chyna has left

  404. lovetox

    - typing in a password daily to unlock the key - depending on PGP trust states (not sure about that but my feeling is i want to have my own trustmanagement rather than what pgp offers)

  405. chyna has joined

  406. flow

    please completely ignore the web of trust

  407. flow

    its nonsense

  408. flow

    its nonsenses

  409. flow

    its nonsense

  410. lovetox

    its not about sending messages flow, its about sharing your secret key with other devices

  411. flow

    so you want a dedidcated key for xmpp? that's fine

  412. flow

    keyring even

  413. lovetox

    there are the people that want to use their own key and dont trust the application (hence want to use stuff like PGP Agent)

  414. Andrzej has left

  415. Andrzej has joined

  416. lovetox

    and this needs totally different development approach

  417. flow

    sure, those are then probably users that will not be happy with your implementation, if it does not allow for it

  418. lovetox

    yeah but that also means, if some clients support this, some not

  419. lovetox

    they cannot work together

  420. flow

    why not?

  421. DebXWoody

    This is why I would like to talk about it.

  422. chyna has left

  423. flow

    we maybe first have to define "this", but…

  424. chyna has joined

  425. lovetox

    because when you put a password on your key, and i have no GUI where you can put in that passwod, that means you cannot use both clients with the same account

  426. chyna has left

  427. flow

    lovetox, how does your no password approach work with multiple devices?

  428. DebXWoody

    lovetox, I think pinentry will do it.

  429. chyna has joined

  430. lovetox

    i dont undestand the question flow

  431. lovetox

    how is multiple device related to a password

  432. Andrzej has left

  433. Andrzej has joined

  434. flow

    lovetox, do you want to support multiple devices?

  435. lovetox

    of course

  436. flow

    lovetox, how does the onboarding work with your no password approach?

  437. flow

    how does a new device get a hold of the secret key material?

  438. lovetox

    are you talking about your AES backup code?

  439. lovetox

    AES encrypted secret key in the PEP node

  440. lovetox

    ?

  441. lovetox

    im not talking about that, that is fine

  442. flow

    ok, but then where is the problem?

  443. lovetox

    but maybe you remember, you can put a password on a PGP key on creation, and then i have to additionally encrypt it with AES

  444. flow

    if you want to store the key material unencrypted locally, that is your choice

  445. flow

    (as developer)

  446. Andrzej has left

  447. flow

    how an openpgp implementation obtains the secret key material is outside the scope of OX and OpenPGP

  448. flow

    so I don't see how this could cause that some clients are not able to work together

  449. flow

    I see other potential issues maybe

  450. flow

    but not htis

  451. flow

    but not this

  452. lovetox

    how is that out of scope, if you describe in your XEP how the secret key is obtained and even how it has to be encrypted

  453. flow

    that is only to fetch the secret key material if you don't have it

  454. flow

    but once you have it, you would usually store it locally

  455. DebXWoody

    I think this is not fully clearly defined.

  456. lovetox

    ok so if you dont describe this, and i assume all material that i decrypt is not additional secured, and other implementation dont assume that and create only passworded keys

  457. lovetox

    then both clients are incompatible

  458. lovetox

    regarding secret key sharing

  459. chyna has left

  460. chyna has joined

  461. flow

    now you have really confused me

  462. flow

    if the secret key material is shared via the PEP node as specified in xep373 § 5.4, then I'd argue it is clear for the implementations how the data should look like, and especially that it must be encrypted

  463. flow

    storing unencrypted openpgp secret key material in a PEP node would be not ideal

  464. lovetox

    yes obvious

  465. chyna has left

  466. lovetox

    but implementing this yields not necessarily a useable key

  467. flow

    and why is that?

  468. lovetox

    because PGP keys can be password protected

  469. flow

    yes, but the transferable key format (rfc4880 § 11.2) is unencrypted, and that is what xep373 § 5.4 specifies

  470. flow

    would be pretty silly to have another potential encryption layer here

  471. flow

    would be pretty silly to have another *optional* encryption layer here

  472. lovetox

    ahh i didnt know that

  473. flow

    glad we could clarify that :)

  474. lovetox

    this is another problem with the XEP for me, you refering to openpgp rfcs its fine, but you should add examples how one can get these transferable formats from gpg

  475. lovetox

    i think we can assume nobody that implement OX will write its own rfc4880 implementation

  476. flow

    hopefully not, but you need to knowledge about the used building blocks

  477. flow

    hopefully not, but you need some knowledge about the used building blocks

  478. flow

    btw, I would recommend using sequoia pgp instead of gpg

  479. neshtaxmpp has left

  480. neshtaxmpp has joined

  481. DebXWoody

    flow, "please completely ignore the web of trust" why?

  482. pep.

    Well that's up to the client, and I don't think it actually impacts how it's used on XMPP at all.

  483. pep.

    As long as some more technical users don't force that on others for no reason

  484. Shell has left

  485. Shell has joined

  486. pep.

    DebXWoody, it's also just possible for a client to use a freshly created keyring just for XMPP usage, and then a tech user can sign that key with their own if they really want to

  487. Shell has left

  488. Shell has joined

  489. pep.

    It makes it easier for the client because it can use its own assumptions and doesn't have to plan for every all the various differences they can find in the real world

  490. werdan has left

  491. pep.

    It makes it easier for the client because it can use its own assumptions and doesn't have to plan for all the various differences they can find in the real world

  492. remko has left

  493. remko has joined

  494. lovetox

    flow, how do you get from https://tools.ietf.org/html/rfc4880#section-11.2

  495. lovetox

    that this is unencrypted?

  496. DebXWoody

    pep.: To sign a fresh key with a own key will not help to use for instance a OpenPGP SmartCard.

  497. pep.

    DebXWoody, that might be a nice feature but then you're kinda condemning the account to use a key per device

  498. pep.

    Or .. a key for the account and then a specific key for that device. Not sure how that would work

  499. lovetox

    flow further, i looked up the manual of gnupg, it lets me export the key in multiple formats PKCS#1, PKCS#8

  500. lovetox

    none of the documentation refers to rfc4880 11.2

  501. pep.

    DebXWoody, probably something to think about anyway. How to reconcile all these various use-cases..

  502. pep.

    (or not, but signal it somehow)

  503. lovetox

    i doubt 11.2 says anything about if it should be encrypted or not

  504. lovetox

    it just states some packet order, one of the packets is the secret key packet, and it does not say what that packet should contain

  505. lovetox

    and if a secret key is ecnrypted or not, is defined inside the secret key packet

  506. remko has left

  507. remko has joined

  508. DebXWoody

    I can just say what I prefer, but this depends on the user. I think we should try to keep it open. I generate 2 keys. One key is a CA key, one key is my personal key. The CA has been generated on a Smartcard, no backup. My personal key has been moved on a Smartcard for the Desktop and on a Nitrokey for Laptop (an Smartphone). The CA will be used to sign my keys and all friends. The personal is for daily use. Anyway, I will try to write some more information.

  509. neshtaxmpp has left

  510. mukt2 has left

  511. marc has left

  512. mukt2 has joined

  513. Mikaela has left

  514. DebXWoody

    Anyway, I was able to send a message to gajim. It's 50% :-D

  515. lovetox

    DebXWoody, drop me a message if you need help debuging when something does not work

  516. DebXWoody

    thx

  517. mukt2 has left

  518. mukt2 has joined

  519. remko has left

  520. marc has joined

  521. mukt2 has left

  522. Nekit has joined

  523. mukt2 has joined

  524. arc has left

  525. arc has joined

  526. karoshi has left

  527. karoshi has joined

  528. marc has left

  529. Daniel has left

  530. Daniel has joined

  531. remko has joined

  532. chyna has joined

  533. arc has left

  534. arc has joined

  535. arc has left

  536. arc has joined

  537. marc has joined

  538. krauq has left

  539. krauq has joined

  540. marc has left

  541. marc has joined

  542. dwd has left

  543. goffi has left

  544. jonas’ has left

  545. lorddavidiii has left

  546. chyna has left

  547. chyna has joined

  548. chyna has left

  549. chyna has joined

  550. neshtaxmpp has joined

  551. remko has left

  552. Andrzej has joined

  553. remko has joined

  554. alexis has joined

  555. krauq has left

  556. krauq has joined

  557. remko has left

  558. stpeter has left

  559. Andrzej has left

  560. neshtaxmpp has left

  561. stpeter has joined

  562. Daniel has left

  563. Daniel has joined

  564. stpeter has left

  565. karoshi has left

  566. mukt2 has left

  567. adiaholic_ has left

  568. adiaholic_ has joined

  569. karoshi has joined

  570. Daniel has left

  571. Daniel has joined

  572. stpeter has joined

  573. mukt2 has joined

  574. neshtaxmpp has joined

  575. wurstsalat has left

  576. mukt2 has left

  577. andy has left

  578. adiaholic_ has left

  579. arc has left

  580. arc has joined

  581. chyna has left

  582. stpeter has left

  583. mukt2 has joined

  584. Daniel has left

  585. Daniel has joined

  586. neshtaxmpp has left

  587. lovetox has left

  588. karoshi has left

  589. alexis has left

  590. stpeter has joined

  591. alexis has joined

  592. pep.

    It's possible to have one set of identifiers (login/passwd) and multiple Jids right?

  593. Tobias has left

  594. pep.

    Something SASL authz? (just handwaving words I don't really understand)

  595. Zash

    Sort of

  596. pep.

    I know, the next question is gonna be "what do I want", not entirely sure myself. For now I'm trying to see if it's possible to have just one account and multiple identities

  597. neshtaxmpp has joined

  598. arc has left

  599. arc has joined

  600. pep.

    Also anybody implemented burner jids yet?

  601. pep.

    I'm curious if they can be reused. This requirement suggests they might: "As the author of a social website I want to allow users to create ephemeral identities which can be used to contact them even if they have not granted access to their personal information."

  602. emus has left

  603. emus has joined

  604. mukt2 has left

  605. Daniel has left

  606. Daniel has joined

  607. stpeter has left

  608. mukt2 has joined

  609. lovetox has joined

  610. stpeter has joined

  611. mukt2 has left

  612. Shell has left

  613. Shell has joined

  614. waqas has joined

  615. pep.

    https://xmpp.org/extensions/xep-0045.html#createroom-reserved what on earth is a reversed room

  616. lbocquet has left

  617. mukt2 has joined

  618. neshtaxmpp has left