@vecna forgot to mention, files won't be opened in both directions
on Conversations you can click on the link to view the file but on SiskinIM you can not decrypt it
@Muto @vecna The problem with OMEMO and files is that... it's not standardised in any way (there is proto-XEP inboxed: https://xmpp.org/extensions/inbox/omemo-media-sharing.html but that's just about it); second problem (slightly related) is that Coversations doesn't check (it's not specified in said XEP) whether other party could handle encrypted file and sends it blindly; we should improve XEP to add discovery functionality (features) and then clients should check those before sending files blindly.
To be fair, the difference between sending blind and not sending at all is close to zero, other than to make the recipient (as opposed to the sender) aware that their client lack support for that feature.
A bit of bandwidth and server storage wasted, but otherwise no big deal
I don't think that's an option as it would greatly undermine the purpose of encryption in the first place, and it would add technical debt without offering a long term solution.
If anything, it's the other end that'd need to catch up and handle encrypted files.
I'm in two minds regarding discovery. You could say that you should only advertise encryption if you can handle it completely, OTOH not everyone needs to send files.
I agree that XEP-0384 needs an upgrade. For a start, its discovery mechanism (§ 4.2) is non-standard. It should advertise itself via XEP-0030 instead, and then it could also inform peers of whether out of band data is also encrypted (and how) or not.
Thanks for the clarification. That is correct, you'd have to wait until a pair of devices come online concurrently at least once in order to use encryption.
I can see what the rationale might have been for doing discovery via #PEP in this case. It is basically saying that it is not the device but the JID that supports encryption or not.
In this case, XEP-0030 could be redundant.
So what are the options?
* Mandate that encryption MUST include both in band and out of band data.
* Specify that encryption SHOULD include IB & OOB data. Clients that don't are still conforming and it's up to the parties to arrive at a solution.
* As above but MAY. Provide discovery mechanism.
@vanitasvitae @tigase @0 @Muto @vecna @xmpp Sure! Another thing that would be cool if addressed in the spec is some kind of old-key-signs-new-key procedure. Where if you have a new device, your old device can notice and ask you to verify the new key and then provide a signature on it, so that any client that trusts the old key also trusts the new key.
I believe that would make OMEMO a lot more easy to use.
@vanitasvitae @tigase @0 @Muto @vecna @xmpp Revocation can be done by removing the PEP node, no?
Yeah about extension/base spec, I don't have experience with XEP structuring etc. But given that a user should accept keys that are signed by a key they trust and other users expect that, things wouldn't work if this was an opt-in extension of OMEMO.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!