jdev - 2020-05-15

  1. djffk

    which client

  2. djffk

    ??

  3. djffk

    hey listen

  4. djffk

    nice to meet you guys i am natasha

  5. djffk

    😂

  6. Sam Whited

    Is anyone aware of a SASL implementation (preferably a generic one, but XMPP specific is fine too) that handles both the client and server side of SASL that I could look at?

  7. Link Mauve

    Sam Whited, this one does: https://crates.io/crates/sasl

  8. Sam Whited

    Thanks

  9. Yagizа

    Hello!

  10. Yagizа

    I have more questions about OMEMO.

  11. Sam Whited

    Ah too bad, that SASL package works almost exactly the same as mine and I was looking to find new API ideas since I don't love the one I've got; oh well :)

  12. Link Mauve

    ^^'

  13. Yagizа

    Old implementations of OMEMO (e. g. Conversations) sends in OMEMO messages along with encrypted content <body/> element with a notice for clients, which do not support OMEMO.

  14. Yagizа

    But there is no mention about it in the XEP.

  15. Yagizа

    Is it ok to do the same in the implementations of the recent versions of the XEP?

  16. lovetox

    use XEP-0380

  17. Zash

    lovetox, is that understood by clients?

  18. lovetox

    is this a trick question? :d

  19. Zash

    Is this implemented in any client?

  20. lovetox

    yes in many

  21. lovetox

    i would guess at least every client that has some encryption possibility

  22. lovetox

    which makes already for a long list

  23. Ge0rG mumbles "TLS"

  24. Yagizа

    Do we need XEP-0380 to be implemented in clients, which implement XEP-0384?

  25. lovetox

    its not a dependency if thats the question

  26. lovetox

    380 is useful for all clients

  27. lovetox

    it gives you the possibility to recognize encrypted messages, even if you never heard or implemented it

  28. Zash

    But the value of 380 would be in clients that *don't* support encryption

  29. Zash

    Or don't support the specific method of encryption you use

  30. lovetox

    No clients that dont support a specific encryption

  31. lovetox

    ergo all

  32. lovetox

    because all clients dont support at least one encryption

  33. lovetox

    its a trivial XEP to implement for any client

  34. lovetox

    the only reason for a fallback body in my opinion is

  35. lovetox

    if you specifically want to support very old unmaintained legacy clients

  36. lovetox

    then its the only way

  37. Yagizа

    I don't see any reason in implementation of XEP-0380 for XEP-0384, 'cause XEP-0384 is too XMPP-ish and XEP-0380 looks more like crutches for the old encryption technologies, like PGP or OTR.

  38. lovetox

    Yagizа, 380 gives only examples of encryptions

  39. lovetox

    its encryption agnostic

  40. Zash

    So far I've only found that Conversations sends it, but doesn't care about it on incoming messages

  41. lovetox

    it does work for all and every encryption in the future universe

  42. lovetox

    Zash how do you determine that it does not care about it on incoming?

  43. Zash

    Code search

  44. Yagizа

    lovetox, I consider using <body/> element in the <message/> with encrypted content as a hint for a user rather than a fallback.

  45. Zash

    Only found code that added it to messages

  46. lovetox

    Yagizа, i dont see the difference

  47. lovetox

    if an encrypted message arrives i like to give my user a message in *his* language, a message that i as a client developer decide

  48. Zash

    But then the Github code search might not be that great

  49. lovetox

    maybe with hints how to use that encryption in my client

  50. lovetox

    this is impossible with a fallback body

  51. Zash

    A <body> also usually ensures that the message goes into the archive and through carbons etc.

  52. lovetox

    thats the worst reason of all to include one :D

  53. Zash

    Modern servers should use EME tho.

  54. lovetox

    and we have storage hints for that

  55. Ge0rG

    I have to agree with lovetox on this one.

  56. Ge0rG

    Council took away hints from us.

  57. Zash

    EME is a hint!

  58. Ge0rG

    Zash: but is EME a typical IM payload?

  59. Zash

    Ge0rG, I would argue that you can't know that it isn't if there's an encrypted payload, so it should be stored.

  60. Zash

    Hope you like encrypted chat states

  61. Ge0rG

    This chat state was not encrypted for your device.

  62. Zash

    Wasn't it decided on a summit to move that kind of thing to directed presence?

  63. Ge0rG

    Zash: yes. and then nothing happened

  64. Ge0rG

    also see my last mail to standards

  65. Ge0rG

    lovetox: you might also be interested in "[Standards] Sprint for Message Routing"

  66. Ge0rG

    and Zash too, we need server folks there

  67. Ge0rG

    not only zinid

  68. Zash

    Ge0rG, your message routing post is missing the most important thing!

  69. Zash

    a coffee break!

  70. Zash

    then it'll be perfect

  71. Ge0rG

    😁

  72. Yagizа

    So, what's the conclusion? Do I have to add <body/> element along to <encrypted/> one or not?

  73. Ge0rG

    Yagizа: > Entities SHOULD include a non-encrypted body as possible, since older clients not supporting this protocol might otherwise ignore messages sent with an unknown encryption, making both the sender frustrated that their message did not get an answer, and the recipient frustrated that they never saw any message.

  74. Ge0rG

    Yagizа: add a body along the lines of this:

  75. Ge0rG

    I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemo

  76. Yagizа

    Ge0rG, yes, that's the message I meant.

  77. Ge0rG

    Yagizа: yes, add such a message

  78. Yagizа

    Ge0rG, but the cite you pasted above is from XEP-0380, not from XEP-0384. And my client do not support XEP-0380 so far.

  79. Ge0rG

    Yagizа: it doesn't matter.

  80. Ge0rG

    Yagizа: it is good practice to also add a XEP-0380 tag when sending, even if you can't read the tag yet.

  81. Yagizа

    Ge0rG, ok, thanx.

  82. Zash

    There's also https://xmpp.org/extensions/xep-0428.html which overlaps with 380 ...

  83. lovetox

    yes a little little bit

  84. lovetox

    but 428 is not specific for encryptions

  85. Yagizа

    IC

  86. Zash

    Still not entirely sure if it should mean anything to a server.

  87. Zash

    If something was important enough to warrant a fallback-<body/> then it's probably about as important as a message with a <body/>, so should be treated as one.

  88. Zash

    But you already do that based on the <body/>

  89. Zash

    But clients could display it in some way to indicate that it's not quite meant to look like that.

  90. Ge0rG

    I think that 0428 is similar to Hints. It's a central place trying to define semantincs for something which should better be defined in the individual XEPs that implement fallback bodies

  91. Sam Whited

    This⤴️

  92. Ge0rG

    OTOH, I don't see (much) harm in a hint that says "the body of this message is a fallback" - except that now all the "old" uses of fallback bodies are suddenly incompliant

  93. Zash

    Tricky to do anything about that without time travel unfortunately

  94. Zash

    Ge0rG, you were talking about your last post to standards, was that the message routing sprint post? I read it as if it was some different post but I'm not seeing any later one.

  95. Ge0rG

    Zash: yes, it was that message routing sprint post

  96. Zash

    k