@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.
@0 @tigase @Muto @email@example.com well if there was a way for the sender to make the decision to not send or send unencrypted, that'd be strictly better than the message not being shown to the recipient, IMO.
I agree discovery could be part of the XEP.
@tigase habe you contacted Daniel about this?
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.
@stevenroose Not about this particular issue, no.
@0 we do agree that this would undermine encryption (and we are working on adding this feature) but at the same time we are in weird situation where we relay on feature discovery discovery yet in this particular case it's OK to ignore it. Would you say that sending encrypted messages without checking if the other party is also OK (not encrypting it would still undermine security)? We should either mandate it in XEP-0384 or add feature support
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.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!