Support for omemo

[yelloff]

That would be nice.

[ibauersachs]

What is that?

[fippo]

@ibauersachs: an e2e encryption thing:
http://xmpp.org/extensions/inbox/omemo.html -- see also some recent discussion on standards@xmpp.org

[jitsi-developers]

This is extraordinary weird. I just viewed this article 6 hours ago and
suddenly this e-mail came !

https://xmpp.org/2015/12/xmpp-at-the-end-of-the-google-summer-of-code-2015/
(2nd paragraph, Andreas Straub)

On 12/25/2015 09:57 PM, Ingo Bauersachs wrote:

What is that?

—
Reply to this email directly or view it on GitHub
#199 (comment).

---

dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

/Regards/,
/Ahmad/

[yelloff]

I was looking for an xmpp based alternative to Text Secure/Signal. And found this blog:
http://www.titus-stahl.de/blog/2015/09/15/how-to-get-secure-decentralized-chat-working-with-xmpp-both-on-mobile-and-desktop/

[lovetox]

this would be great, there is no desktop client that supports OMEMO
normal OTR from desktop -> phone is not the best UX.

also, all the desktop clients from whatsapp and singal need a phonenumber and a smartphone to activate an account -> horrible.

[Evi1M4chine]

I just came over from Freedesktop’s Bugzilla for Telepathy’s XMPP component (gabble) and while they also have a bug for it, the KDE developers downstream don’t expect much from them. So Jitsi is probably our only hope for now.

(If it would enable chatting with Signal/TextSecure/Axolotl users, that would be the single greatest thing for desktop messaging as of now.)

[ibauersachs]

This would need to come from the community, we simply don't have the resources to develop this.

[lovetox]

there is work on a Gajim Plugin https://github.com/kalkin/gajim-omemo
it already works for me.

@Evi1M4chine how do you think this would enable chatting with Signal or TextSecure Apps?
even if it is the same tech behind it, the companys behind it would have to allow it, if this was possible i think many people already would have made desktop apps for it.

Further does Signal rely on the telephonenumber (which is for me the biggest failure of all the new messaging apps) as kind of JID. i dont see it happen that they would allow to add people to their network based on an normal JID.

[improti]

The implementation contained in https://github.com/siacs/Conversations could also be portable. It's Java on Android, but I got no clue about the libraries used. Any chance to get the developers of these projects to make a common backend and provide their distinct UIs on top of that or something? There was a Jitsi on Android initiative anyways, right? The UI and design principles of Conversations make a really good impression, if you don't know it maybe take a look. It's chat-only though, i.e. without VoIP. Pictures in chats are a killer-feature, imho. Getting that and the OMEMO goodies working between the two (no matter if with common backend or not) would be really awesome.

[Evi1M4chine]

@lovetox:

Why would you think they couldn’t? The protocol is the same, so it’s only a matter of picking the same server to connect to. But you don’t even have to do that, since Signal’s server, being just an XMPP one with Axolotl/Omemo added in, supports federation (which is already used, e.g. with CyanogenMod’s builtin SMS/messaging app).
I also made a Signal fork this morning. Other than warnings about chat partners having different keys there were no problems. So obviously the “companies* behind it” don’t prevent it.

---

• Which I assume are not criminals/psychopaths and hence don’t employ nasty anti-social behavior like exclusivism or trying to corporate-murder each other.

---

@improti:

Signal (formerly TextSecure) itself is already Android/Java. I don’t think it’s a problem to take any necessary code from there. It’s more a problem of: Who wants to do it?

[oodbur]

OMEMO could be significant: The Axolotl ratchet is the much improved and widely used (see WhatsApp and several others) successor to OTR. Now OMEMO integrates this directly into XMPP, so no more of the criticism of operating on the wrong layer of the protocol stack, which hurdled adoption (see Empathy/Telepathy) and is connected to usability problems of OTR.