@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: xmpp.org/extensions/inbox/omem 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

@Muto @vecna

@0 @tigase @Muto @vecna@www.librepunk.club 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.

@tigase @Muto @vecna

@Muto @vecna

@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


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.

@Muto @vecna @stevenroose

@0 @tigase @Muto @vecna @stevenroose if you use xep-30 to do feature discovery, the other device must be online. So you cannot send messages to offline devices if you want to depend on xep-30.


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.

@tigase @Muto @vecna @stevenroose

@vanitasvitae @tigase @Muto @vecna @stevenroose

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.

* ???

Sign in to participate in the conversation
unidentified instance

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!