jdev - 2023-07-03

  1. VesselWave

    Hello! How secure OMEMO is? I want to write a chat bot in python with slixmpp and slixmpp-omemo (and also package those for GNU Guix). Maybe there is a different implementation that is more secure and modern, even for a different language?

  2. Menel

    It is considered secure. It is basically the signal protocol.

  3. VesselWave

    Thanks, python-omemo has been updated to v1.0.2 but slixmpp-omemo uses v0.*.*. Hope some one can help devs to update it

  4. opal

    not every project uses the same versioning scheme

  5. Squeaky Latex Folf

    OMEMO doesn't protect metadata unfortunately

  6. goffi

    VesselWave: python-omemo implements new version (OMEMO:2) which allow to encrypt basically anything, while the legacy version only encrypt body of message. It is still compatible with legacy version which is the most used in the wild.

  7. VesselWave

    I just wasn't sure if I should use this version and package it to Guix, if it's insecure (it's not) and maybe new one will be available soon. Now I see that everything is alright. I will finish packaging and maybe will submit it to Guix. Thank you

  8. Squeaky Latex Folf

    It would be cool if the from attribute could be encrypted in some way as a protection against metadata gathering

  9. msavoritias

    you cant. its a fundamental property of federating systems. unless you mean tls. then yes it is

  10. msavoritias

    we can secure it more by doing stuff like dnssec and other stuff. but not encrypt completely

  11. jonas’

    it would be possible to hide the @to localpart+resource from the sending server, and the @from localpart+resource from the receiving server (with heavy protocol modifications of course)

  12. msavoritias

    while still being federated? sounds interesting.

  13. msavoritias

    provided everybody adopts the modifications of course

  14. jonas’

    msavoritias, the localpart is only required by the domain on which it's hosted

  15. jonas’

    msavoritias, the localpart and resorouce are only required for routing by the domain on which it's hosted

  16. jonas’

    otherwise the servers only need the domain

  17. jonas’

    (and the sender's domain needs to be available in cleartext on the receiver's server to avoid domain spoofing)

  18. msavoritias

    so only the domain has to be in the clear. got it. will make a note of it thanks 😀

  19. jonas’

    but if you actually want to obfuscate the metadata, this needs support throughout all clients participating in a conversation, otherwise it causes havoc.

  20. jonas’

    (though a trusted server could revert this I guess)

  21. msavoritias

    so client and server support yeah

  22. msavoritias

    on that note is there somewhere an article or a document that outlines what are the differences in responsibilities for servers and clients

  23. msavoritias


  24. msavoritias

    i looked at the conformance thing we have and most of the them are both server and client

  25. msavoritias

    afaik its only mam and for some reason storing bookmarks that go to server

  26. msavoritias

    but would love any pointers

  27. jonas’


  28. jonas’

    (i.e. distributing OMEMO keys)

  29. jonas’

    but I don't think there's a single comprehensive document

  30. msavoritias

    distributing omemo keys is only for when the client is offline though right?

  31. msavoritias

    ah also the groups management

  32. jonas’

    don't think so

  33. msavoritias

    so mam and groups are the main things

  34. jonas’

    whatever is in the PEP node (I'm no OMEMO expert) always goes through the server

  35. jonas’

    msavoritias, roster, too :)

  36. jonas’

    (alongside distributing presence)

  37. jonas’

    servers also do various optimisations, such as replying to XEP-0030 queries for known XEP-0115 or XEP-0390 hashes, to not wake up your mobile data modem unnecsesarily.

  38. msavoritias

    but roster is optional too to be there is it not?

  39. jonas’

    MAM is also optional

  40. jonas’

    and groups

  41. jonas’

    for certain definitions of optional

  42. msavoritias


  43. jonas’

    roster is not part of RFC6120 (it's part of RFC6121), but that doesn't mean it's not basically mandated by every client out there.

  44. msavoritias

    I will probably look into what prosody supports then

  45. jonas’

    what's your definition of "optional"?

  46. msavoritias

    optional is something that makes life easier but we can do without. like you cant get my omemo keys and cant message me if my client is offline

  47. msavoritias

    if that makes sense

  48. jonas’

    oh, remember that there's some legacy "offline messages" thing from way before MAM

  49. jonas’

    where the server would just dump any messages received while offline to the first of your clients connecting

  50. msavoritias

    I am basically doing some exploratory documentation and reading into writing a client/server thing and that is why I was interested in the seperation between them

  51. msavoritias


  52. jonas’

    and OMEMO is in my book definitely optional

  53. jonas’

    I almost never use it.

  54. jonas’

    (except on Snikket)

  55. msavoritias


  56. jonas’

    so the definitions vary greatly

  57. jonas’

    and you'll have to define what "makes life easier but we can do without" means exactly d-)

  58. msavoritias

    the stuff that is clearly delegated to the server is to me MAM and groups

  59. jonas’

    and you'll have to define what "makes life easier but we can do without" means exactly :-)

  60. jonas’

    and roster and bookmarks

  61. msavoritias

    both for obvious reasons i hope

  62. msavoritias

    that one is not imo. but I am not sure if its mandated by the protocol

  63. jonas’

    the server needs to know who is in your roster to handle presence probes by other servers correctly

  64. jonas’

    and it needs to know who's in your roster to send presence probes on your behalf when you come online

  65. msavoritias

    > and you'll have to define what "makes life easier but we can do without" means exactly :-) basically MAM needs to be there because sometimes we go offline. and with groups its vastly easier to have the group chat being managed by the server instead of one client

  66. jonas’

    (now you could argue that presence is an obsolete concept, but it's in RFC 6121)

  67. jonas’

    msavoritias, MAM only becomes necessary in multi-client scenarios.

  68. jonas’

    in single-client scenarios the legacy offine messages are well sufficient

  69. msavoritias

    noob question: Why do we need presence probes instead of just sending a message?

  70. jonas’

    they are unrelated to messages

  71. msavoritias

    > in single-client scenarios the legacy offine messages are well sufficient yeah but If I write my server today why would I implement anything but MAM?

  72. jonas’

    you wouldn't

  73. msavoritias


  74. msavoritias

    > they are unrelated to messages im guessing its not omemo either then

  75. jonas’

    presence probes are used by servers to discover the current presence status of remote users with whom you have a presence subscription relation. that's needed because there's no guarantee that your server has the current presence data on file for your contacts if you've been offline for a while (or there has been an s2s disconnection)

  76. msavoritias

    because its older

  77. jonas’

    and presence is basically online/offline status

  78. jonas’

    and presence is basically online/offline status, as shown in some clients

  79. msavoritias

    but why cant the user just send the message?

  80. jonas’

    and presence is basically online/offline/away/… status, as shown in some clients

  81. jonas’

    oh you can

  82. msavoritias

    or just call

  83. jonas’

    but some old-school users like me like to know whether someone is even online

  84. msavoritias

    ah. so presense is technically optional

  85. jonas’

    because if they're not, I might as well go over to them next door and tell them what I need them to know _right now_ in person

  86. msavoritias

    and one of these things where the rfcs need updating i guess

  87. jonas’

    no, *technically* presence is rfc 6121

  88. jonas’

    so not really optional

  89. jonas’

    you meant "personally presence is optional"

  90. msavoritias

    yeah right 😛

  91. jonas’

    technically it is very much not, I think there are even server implementatoins out there which require you to send available presence before you can send IQs or whatnot

  92. msavoritias

    here I should also clarify

  93. msavoritias

    that I am looking to see what I can do with xmpp by "stretching" it a little bit.

  94. jonas’

    (and some servers won't distribute incoming messages to clients which haven't sent available presence)

  95. msavoritias

    yeah makes sense

  96. jonas’


  97. jonas’

    (unless XEP-280 carbons)

  98. msavoritias

    yeah carbons is another one of these things where I am not looking to implement probably

  99. msavoritias

    and go directly for im-ng

  100. jonas’

    was about to say that, yes

  101. msavoritias

    but yeah I am looking into not implementing a lot of "presence" things

  102. msavoritias

    like typing notifications, read notifications and such

  103. Link Mauve

    Those are messages. :p

  104. msavoritias

    if i can also avoid presence all together hmm

  105. Link Mauve

    Entirely up to clients.

  106. msavoritias

    yeah 😛 "presence" in the sense that they are ambient state notifications to the other party

  107. jonas’

    msavoritias, if you have control over both client and server in your setup, you can probably indeed do away with <presence/> stanzas altogether

  108. jonas’

    if you're looking to reuse software, you'll have to at least send available initial presence, but you can otherwise ignore it.

  109. msavoritias

    hmm noted.

  110. jonas’

    (except maybe in places like PEP, which are also only distributed to clients which sent presence, which means you may need a presence subscription between users for that to work)

  111. msavoritias

    well i am looking ideally to write both a server and a client. but I would like them to be some kind of federated

  112. msavoritias

    at some point at least

  113. jonas’

    may I ask why?

  114. msavoritias

    why what

  115. jonas’

    because "at some point federated" is often equivalent to "never"

  116. jonas’

    why rewrite the world instead of using things like prosody?

  117. msavoritias

    ah. because I am looking into mandating stuff like dnssec by default.

  118. jonas’

    what stops you from doing that with existing things?

  119. msavoritias

    I am writing my own to learn guile plus xmpp.

  120. jonas’

    as patches

  121. msavoritias

    will definetily look into contributing patches too

  122. msavoritias

    i have gajim and prosody in mind for example

  123. msavoritias

    and i know that prosody devs do a lot of good work with the modules

  124. msavoritias

    the thing i am writing its to experiment with stuff 😛 and its in fossil for these reasons too

  125. Squeaky Latex Folf

    > it would be possible to hide the @to localpart+resource from the sending server, and the @from localpart+resource from the receiving server (with heavy protocol modifications of course) Well what I was thinking of was to have the from attribute encrypted in a way that only the recipient can decrypt. If I remember correctly Signal does something similar to obfuscate/encrypt metadata

  126. jonas’

    the reciepietns server needs to know the full reciepient for routing

  127. Zash

    An error occurs. How do you route it to the sender?

  128. jonas’

    the sender's server would be the entity encrypting the from localpart, so it should do so in a way which allows decryption.

  129. Zash

    I made some attempts at Venn diagrams for this in a notebook somewhere

  130. jubalh

    What do people usually write in the doap file in <xmpp:since> once a XEP is implemented only in the development version?

  131. lissine

    the number of the first upcoming version implementing it

  132. Zash

    We've got `xmpp:since=trunk` for a thing in Prosody

  133. jubalh

    so i wont break anything if i would add `developemtn` or `master` there? (like the tool the creates the overview on xmpp.org)

  134. Link Mauve

    I usually put NEXT in order to not forget to change it before releasing the next version, then forget to do it.

  135. jubalh


  136. Zash

    Could also guess what the next version will be and put that

  137. jubalh

    Link Mauve: I had the same idea, just with `development`

  138. jubalh

    Ok thanks guys :)

  139. Zash

    Does DOAP-consumers use it for anything but presentation?

  140. pulkomandy

    I guess they could try matching it with the list of releases that's also in the doap? For example to get the release dates from there? But I don't think anything does this yet

  141. cal0pteryx

    > so i wont break anything if i would add `developemtn` or `master` there? (like the tool the creates the overview on xmpp.org) jubalh: should be fine

  142. jubalh


  143. Zash

    I don't think we (prosody) put releases in the DOAP yet

  144. cal0pteryx

    I don't plan to do calculations with `since`

  145. Zash

    The data explorer thing probably lets you group by version, so that's probably enough