Sam WhitedIs 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?
Link MauveSam Whited, this one does: https://crates.io/crates/sasl
YagizаI have more questions about OMEMO.
Sam WhitedAh 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 :)
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.
YagizаBut there is no mention about it in the XEP.
YagizаIs it ok to do the same in the implementations of the recent versions of the XEP?
Zashlovetox, is that understood by clients?
lovetoxis this a trick question? :d
ZashIs this implemented in any client?
lovetoxyes in many
lovetoxi would guess at least every client that has some encryption possibility
lovetoxwhich makes already for a long list
YagizаDo we need XEP-0380 to be implemented in clients, which implement XEP-0384?
lovetoxits not a dependency if thats the question
lovetox380 is useful for all clients
lovetoxit gives you the possibility to recognize encrypted messages, even if you never heard or implemented it
ZashBut the value of 380 would be in clients that *don't* support encryption
ZashOr don't support the specific method of encryption you use
lovetoxNo clients that dont support a specific encryption
lovetoxbecause all clients dont support at least one encryption
lovetoxits a trivial XEP to implement for any client
lovetoxthe only reason for a fallback body in my opinion is
lovetoxif you specifically want to support very old unmaintained legacy clients
lovetoxthen its the only way
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.
lovetoxYagizа, 380 gives only examples of encryptions
lovetoxits encryption agnostic
ZashSo far I've only found that Conversations sends it, but doesn't care about it on incoming messages
lovetoxit does work for all and every encryption in the future universe
lovetoxZash how do you determine that it does not care about it on incoming?
Yagizаlovetox, I consider using <body/> element in the <message/> with encrypted content as a hint for a user rather than a fallback.
ZashOnly found code that added it to messages
lovetoxYagizа, i dont see the difference
lovetoxif an encrypted message arrives i like to give my user a message in *his* language, a message that i as a client developer decide
ZashBut then the Github code search might not be that great
lovetoxmaybe with hints how to use that encryption in my client
lovetoxthis is impossible with a fallback body
ZashA <body> also usually ensures that the message goes into the archive and through carbons etc.
lovetoxthats the worst reason of all to include one :D
ZashModern servers should use EME tho.
lovetoxand we have storage hints for that
Ge0rGI have to agree with lovetox on this one.
Ge0rGCouncil took away hints from us.
ZashEME is a hint!
Ge0rGZash: but is EME a typical IM payload?
ZashGe0rG, I would argue that you can't know that it isn't if there's an encrypted payload, so it should be stored.
ZashHope you like encrypted chat states
Ge0rGThis chat state was not encrypted for your device.
ZashWasn't it decided on a summit to move that kind of thing to directed presence?
Ge0rGZash: yes. and then nothing happened
Ge0rGalso see my last mail to standards
Ge0rGlovetox: you might also be interested in "[Standards] Sprint for Message Routing"
Ge0rGand Zash too, we need server folks there
Ge0rGnot only zinid
ZashGe0rG, your message routing post is missing the most important thing!
Zasha coffee break!
Zashthen it'll be perfect
YagizаSo, what's the conclusion? Do I have to add <body/> element along to <encrypted/> one or not?
> 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.
Ge0rGYagizа: add a body along the lines of this:
Ge0rGI sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemo
YagizаGe0rG, yes, that's the message I meant.
Ge0rGYagizа: yes, add such a message
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.
Ge0rGYagizа: it doesn't matter.
Ge0rGYagizа: it is good practice to also add a XEP-0380 tag when sending, even if you can't read the tag yet.
YagizаGe0rG, ok, thanx.
ZashThere's also https://xmpp.org/extensions/xep-0428.html which overlaps with 380 ...
lovetoxyes a little little bit
lovetoxbut 428 is not specific for encryptions
ZashStill not entirely sure if it should mean anything to a server.
ZashIf 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.
ZashBut you already do that based on the <body/>
ZashBut clients could display it in some way to indicate that it's not quite meant to look like that.
Ge0rGI 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
Ge0rGOTOH, 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
ZashTricky to do anything about that without time travel unfortunately
ZashGe0rG, 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.
Ge0rGZash: yes, it was that message routing sprint post