Bug 93090

Malte: This is a PEP for XMPP. Wouldn't this enhancement be for the gabble component then?

Paul Bryan: I don't understand the technical details. Is there any reason OMEMO would not work with other protocols? Maybe somebody more experienced could answer that question and possibly change the component of this bug accordingly. Since OTR has some serious problems when it comes to usability, it may be desirable to use OMEMO on other protocols as well. Although I see no reason why somebody using a third party client would not have an XMPP account as well.

(In reply to Malte E. from comment #2)

> Paul Bryan: I don't understand the technical details. Is there any reason
> OMEMO would not work with other protocols?

OMEMO relies on XMPP PEP for publishing key information, so it will require changes to run over other protocols.

It is definitely alright, to make this part of Telepathy’s XMPP component.

In fact it would be preferred by me, if unencrypted connections weren’t even possible at all on all computer devices on the planet. :)



[Side note about the UI: Generally, the unified UI should be able to manage both encrypted and unencrypted connections and transitions between them, no matter the underlying solution. In any case, it just needs to show if the conversation is encrypted, if the message will be encrypted when sending, and a dialog for key fingerprint verification.]

see https://github.com/WhisperSystems/libsignal-protocol-c for the protocol library

Maybe telepathy-gabble could benefit from Google Summer of Code or similar in this case?

If I understand the Proto-XEP (https://conversations.im/xeps/multi-end.html) correctly, OMEMO needs XEP-0280 (https://bugs.freedesktop.org/show_bug.cgi?id=78093) and XEP-0313 (https://bugs.freedesktop.org/show_bug.cgi?id=90838) to fully function. So these should be tackled first.

Regarding the standardization process at the XSF, everything points to the direction that the standard definition of Olm will be used (https://matrix.org/docs/spec/olm.html) as well as their reference implementation (https://matrix.org/git/olm/tree/)

OMEMO is now published as XEP-0384 https://xmpp.org/extensions/xep-0384.html

When I had previously skimmed the OMEMO spec I saw it referring to Message Carbons (XEP-00280) and Message Archive Management (XEP-0313) which we don't have yet. (I think there are patches in bugzilla that need review and merging).

But it looks like all we actually need for OMEME to at least partially work Personal Eventing Protocol (XEP-0163)? The other protocols are just for a better usability?

Yes, I first had the same impression, but it really seems that Message Carbons and MAM just add another comfort level and the only real hard dependency is PEP.

I believe you are both correct - OMEMO was designed to be a crypto system that was friendly towards MAM and carbons since OTR cannot work with either of them. With OTR, any encrypted communications have to happen live and can only happen from one device to one device. This is pretty limiting if you like the convenience of having message history shared among devices. OMEMO works by encrypting messages for multiple devices and does not require them to be actively online.

However, OMEMO doesn't use either of those extensions to work so it does not require them. Supporting OMEMO would still be beneficial even if telepathy-gabble doesn't support those extensions, because MAM and carbons can happen server-side without client involvement, allowing other clients the user has (like Conversations) to still benefit.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/279.