XSF Discussion - 2020-06-05

  1. Neustradamus

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

  2. Ge0rG

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

  3. 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?

  4. Zash

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

  5. Guus

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

  6. Guus

    Will look into it further

  7. lovetox

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

  8. Guus

    lovetox: why is that?

  9. lovetox

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

  10. lovetox

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

  11. lovetox

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

  12. lovetox

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

  13. Kev

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

  14. Kev

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

  15. Kev

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

  16. Kev

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

  17. Guus

    What Kev said, and: thanks Kev.

  18. Kev

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

  19. 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

  20. 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.

  21. Kev

    Sorry Guus.

  22. Guus

    No worries, that's only to be expected.

  23. Guus

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

  24. jonas’

    classic IRC netsplit

  25. jonas’

    lovetox, it happens "all the time" on IRC

  26. 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

  27. 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

  28. Guus

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

  29. Zash

    MUC-to-MUC MAM?

  30. Holger


  31. Zash

    Not until start trying to merge those histories

  32. Holger

    Matrix in broken.

  33. Kev

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

  34. Guus

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

  35. Zash

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

  36. 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.

  37. DebXWoody

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

  38. lovetox

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

  39. moparisthebest

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

  40. lovetox

    i tell you what i implement

  41. 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

  42. flow

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

  43. lovetox

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

  44. flow


  45. DebXWoody


  46. lovetox

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

  47. flow

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

  48. lovetox

    signed by who?

  49. flow

    signed by the master key

  50. lovetox

    and who signes the expiry date of the master key

  51. lovetox

    or does the key i generate sign the packet itself

  52. flow

    basically yes

  53. lovetox

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

  54. flow

    yes expiries are typical not useful for the average user

  55. lovetox

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

  56. flow


  57. 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.

  58. flow

    openpgp provides a lot of freedom

  59. lovetox

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

  60. lovetox

    and the XEP basically lets many things open

  61. flow

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

  62. lovetox

    and i fear this will make it not interoperable

  63. flow

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

  64. lovetox

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

  65. flow

    no I don't think so

  66. lovetox

    which makes it less likely to implement

  67. flow

    MUAs shows that this is possible

  68. 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.

  69. lovetox

    MUAs? whats that

  70. flow

    mail clients

  71. lovetox

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

  72. DebXWoody


  73. flow


  74. lovetox

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

  75. flow

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

  76. 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)

  77. flow

    please completely ignore the web of trust

  78. flow

    its nonsense

  79. flow

    its nonsenses

  80. flow

    its nonsense

  81. lovetox

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

  82. flow

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

  83. flow

    keyring even

  84. 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)

  85. lovetox

    and this needs totally different development approach

  86. flow

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

  87. lovetox

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

  88. lovetox

    they cannot work together

  89. flow

    why not?

  90. DebXWoody

    This is why I would like to talk about it.

  91. flow

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

  92. 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

  93. flow

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

  94. DebXWoody

    lovetox, I think pinentry will do it.

  95. lovetox

    i dont undestand the question flow

  96. lovetox

    how is multiple device related to a password

  97. flow

    lovetox, do you want to support multiple devices?

  98. lovetox

    of course

  99. flow

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

  100. flow

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

  101. lovetox

    are you talking about your AES backup code?

  102. lovetox

    AES encrypted secret key in the PEP node

  103. lovetox


  104. lovetox

    im not talking about that, that is fine

  105. flow

    ok, but then where is the problem?

  106. 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

  107. flow

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

  108. flow

    (as developer)

  109. flow

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

  110. flow

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

  111. flow

    I see other potential issues maybe

  112. flow

    but not htis

  113. flow

    but not this

  114. 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

  115. flow

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

  116. flow

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

  117. DebXWoody

    I think this is not fully clearly defined.

  118. 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

  119. lovetox

    then both clients are incompatible

  120. lovetox

    regarding secret key sharing

  121. flow

    now you have really confused me

  122. 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

  123. flow

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

  124. lovetox

    yes obvious

  125. lovetox

    but implementing this yields not necessarily a useable key

  126. flow

    and why is that?

  127. lovetox

    because PGP keys can be password protected

  128. flow

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

  129. flow

    would be pretty silly to have another potential encryption layer here

  130. flow

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

  131. lovetox

    ahh i didnt know that

  132. flow

    glad we could clarify that :)

  133. 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

  134. lovetox

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

  135. flow

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

  136. flow

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

  137. flow

    btw, I would recommend using sequoia pgp instead of gpg

  138. DebXWoody

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

  139. pep.

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

  140. pep.

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

  141. 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

  142. 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

  143. 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

  144. lovetox

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

  145. lovetox

    that this is unencrypted?

  146. DebXWoody

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

  147. pep.

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

  148. pep.

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

  149. lovetox

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

  150. lovetox

    none of the documentation refers to rfc4880 11.2

  151. pep.

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

  152. pep.

    (or not, but signal it somehow)

  153. lovetox

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

  154. 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

  155. lovetox

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

  156. 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.

  157. DebXWoody

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

  158. lovetox

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

  159. DebXWoody


  160. pep.

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

  161. pep.

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

  162. Zash

    Sort of

  163. 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

  164. pep.

    Also anybody implemented burner jids yet?

  165. 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."

  166. pep.

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