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?
Link Mauve
Sam Whited, this one does: https://crates.io/crates/sasl
Sam Whited
Thanks
pulkomandyhas left
pulkomandyhas joined
lovetoxhas left
pulkomandyhas left
pulkomandyhas joined
lovetoxhas joined
pulkomandyhas left
pulkomandyhas joined
Yagizа
Hello!
Yagizа
I have more questions about OMEMO.
goffihas left
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 :)
Link Mauve
^^'
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?
lovetox
use XEP-0380
sonnyhas left
sonnyhas joined
Zash
lovetox, is that understood by clients?
lovetox
is this a trick question? :d
Zash
Is this implemented in any client?
lovetox
yes in many
lovetox
i would guess at least every client that has some encryption possibility
lovetox
which makes already for a long list
Ge0rGmumbles "TLS"
Yagizа
Do we need XEP-0380 to be implemented in clients, which implement XEP-0384?
lovetox
its not a dependency if thats the question
lovetox
380 is useful for all clients
lovetox
it gives you the possibility to recognize encrypted messages, even if you never heard or implemented it
Zash
But the value of 380 would be in clients that *don't* support encryption
Zash
Or don't support the specific method of encryption you use
lovetox
No clients that dont support a specific encryption
lovetox
ergo all
lovetox
because all clients dont support at least one encryption
lovetox
its a trivial XEP to implement for any client
lovetox
the only reason for a fallback body in my opinion is
lovetox
if you specifically want to support very old unmaintained legacy clients
lovetox
then 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.
lovetox
Yagizа, 380 gives only examples of encryptions
lovetox
its encryption agnostic
Zash
So far I've only found that Conversations sends it, but doesn't care about it on incoming messages
lovetox
it does work for all and every encryption in the future universe
Beherithas left
adrienhas left
lovetox
Zash how do you determine that it does not care about it on incoming?
Zash
Code search
Yagizа
lovetox, I consider using <body/> element in the <message/> with encrypted content as a hint for a user rather than a fallback.
Zash
Only found code that added it to messages
lovetox
Yagizа, i dont see the difference
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
Zash
But then the Github code search might not be that great
lovetox
maybe with hints how to use that encryption in my client
lovetox
this is impossible with a fallback body
Zash
A <body> also usually ensures that the message goes into the archive and through carbons etc.
lovetox
thats the worst reason of all to include one :D
Zash
Modern servers should use EME tho.
lovetox
and we have storage hints for that
Ge0rG
I have to agree with lovetox on this one.
Ge0rG
Council took away hints from us.
Zash
EME is a hint!
Ge0rG
Zash: but is EME a typical IM payload?
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.
Zash
Hope you like encrypted chat states
Ge0rG
This chat state was not encrypted for your device.
Zash
Wasn't it decided on a summit to move that kind of thing to directed presence?
Ge0rG
Zash: yes. and then nothing happened
Ge0rG
also see my last mail to standards
Ge0rG
lovetox: you might also be interested in "[Standards] Sprint for Message Routing"
Ge0rG
and Zash too, we need server folks there
Ge0rG
not only zinid
paulhas left
adrienhas joined
paulhas joined
rionhas left
rionhas joined
pulkomandyhas left
adrienhas left
pulkomandyhas joined
adrienhas joined
pulkomandyhas left
pulkomandyhas joined
adrienhas left
adrienhas joined
pulkomandyhas left
kikuchiyohas left
pulkomandyhas joined
kikuchiyohas joined
pulkomandyhas left
pulkomandyhas joined
Zash
Ge0rG, your message routing post is missing the most important thing!
Zash
a coffee break!
kikuchiyohas left
Zash
then it'll be perfect
Ge0rG
😁
Yagizа
So, what's the conclusion? Do I have to add <body/> element along to <encrypted/> one or not?
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.
Ge0rG
Yagizа: add a body along the lines of this:
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
Yagizа
Ge0rG, yes, that's the message I meant.
Ge0rG
Yagizа: 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.
Ge0rG
Yagizа: it doesn't matter.
Ge0rG
Yagizа: it is good practice to also add a XEP-0380 tag when sending, even if you can't read the tag yet.
kikuchiyohas joined
Yagizа
Ge0rG, ok, thanx.
Zash
There's also https://xmpp.org/extensions/xep-0428.html which overlaps with 380 ...
lovetox
yes a little little bit
lovetox
but 428 is not specific for encryptions
Yagizа
IC
Zash
Still not entirely sure if it should mean anything to a server.
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.
Zash
But you already do that based on the <body/>
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
Zash
But clients could display it in some way to indicate that it's not quite meant to look like that.
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
sonnyhas left
sonnyhas joined
Sam Whited
This⤴️
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
goffihas joined
pulkomandyhas joined
Zash
Tricky to do anything about that without time travel unfortunately
pulkomandyhas left
paulhas left
waqashas joined
etahas left
pulkomandyhas joined
lovetoxhas left
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.
Yagizаhas left
Yagizаhas joined
paulhas joined
sonnyhas left
sonnyhas joined
lovetoxhas joined
kikuchiyohas left
Ge0rG
Zash: yes, it was that message routing sprint post