Modify

#1239 new enhancement

OMEMO / Axolotl Support

Reported by: anonymous Owned by:
Priority: normal Milestone:
Component: Jabber Version: Unspecified
Keywords: OMEMO Acolotl Cc:
IRC client+version: Client-independent Operating System: Linux
OS version/distro:

Description

Support for OMEMO/Axolotl XMPP Encryption

"OMEMO is an XMPP Extension Protocol (XEP) for secure multi-client end-to-end encryption. It is an open standard based on Axolotl and PEP which can be freely used and implemented by anyone."

Overview: http://conversations.im/omemo/

Draft XEP: http://conversations.im/xeps/multi-end.html http://conversations.im/xeps/omemo-filetransfer.html

Attachments (0)

Change History (9)

comment:1 Changed at 2016-01-13T20:30:18Z by divan@…

This would be great. So far, just conversations (Android) and gajim (https://github.com/kalkin/gajim-omemo) support it.

Hopefully bitlbee can be one of the first desktop apps to support it.

comment:2 Changed at 2016-04-26T10:52:53Z by anonymous

+1

comment:3 Changed at 2016-06-17T01:57:19Z by Hund

I +1 this as well. I'm using Conversations and OMEMO is really simple and straightforward. I really like it.

comment:4 Changed at 2016-06-21T22:39:46Z by anonymous

+1

comment:5 Changed at 2016-07-07T17:47:38Z by anonymous

+1

comment:6 Changed at 2016-07-10T16:35:42Z by ilf

+1. We also have bitlbee-plugin-otr. This could be "the future"(TM).

comment:7 Changed at 2016-07-10T17:52:20Z by dx

While I agree this is important, personally, I'm not touching this for the following reasons (quoting myself, adapted from things I repeated a few times on irc)

  1. I don't have a lot of time to spend on bitlbee stuff lately and OMEMO means a lot of time to spend.
  2. I don't want to implement huge crypto features without knowing a group of people capable of assisting with implementation issues (libotr is painful enough already)
  3. It's not even a proper XEP yet.

One of the reasons I (over)heard for #3 is that there's no complete specification of the protocol to reference - the reference implementation doesn't count. This is not a showstopper for me, but it's a good reason to wait for it to be established.

More on #2 (also quoting myself):

When I had problems with OTR, it was clear that I had no idea what was going on, and there was no one to help me. #otr exists, but they also lack people who have the knowledge to handle this *and* happen to be available to answer questions. Ian Goldberg exists in the mailing list, but can't rely on his free time either.

With signal-based protocols it's going to be worse than that, and asking moxie isn't an option

I'd be delighted to be proven wrong with this.

Having said this, I'm always available on #bitlbee to provide assistance implementing this (or any other feature).

But for this to be merged, the person who implements this needs to stay around for the foreseeable future to provide support and handle any issues that appear, because otherwise that person is going to be me and I can't take that weight.

comment:8 Changed at 2017-02-03T14:47:07Z by samba@…

Hi, I agree about the pain of libotr and I see this as an opportunity to get rid of libotr, and push the XMPP protocol to a better solution.

About people involved, there's already some people progressing with the topic here:

https://github.com/anurodhp/Monal/issues/9

and seems we have a XEP specification defined now:

https://xmpp.org/extensions/xep-0384.html

I'd like to help with the implementation in bitlbee, anyone else?

Add Comment

Modify Ticket

Action
as new The ticket will remain with no owner.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.