Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upSupport for omemo #199
Support for omemo #199
Comments
|
What is that? |
|
@ibauersachs: an e2e encryption thing: |
|
This is extraordinary weird. I just viewed this article 6 hours ago and https://xmpp.org/2015/12/xmpp-at-the-end-of-the-google-summer-of-code-2015/ On 12/25/2015 09:57 PM, Ingo Bauersachs wrote:
/Regards/, |
|
I was looking for an xmpp based alternative to Text Secure/Signal. And found this blog: |
|
this would be great, there is no desktop client that supports OMEMO also, all the desktop clients from whatsapp and singal need a phonenumber and a smartphone to activate an account -> horrible. |
|
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.) |
|
This would need to come from the community, we simply don't have the resources to develop this. |
|
there is work on a Gajim Plugin https://github.com/kalkin/gajim-omemo @Evi1M4chine how do you think this would enable chatting with Signal or TextSecure Apps? 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. |
|
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. |
@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).
@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? |
|
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. |
|
if OMEMO is useful/significant/superior to OTR etc etc - could you currently users (incl. myself) are happy that Jitsi client function is On 1/18/16 3:33 PM, oodbur wrote:
|
|
Frankly, without OMEMO, there is no point in even using an IM client. OTR is unacceptable from a usability and design standpoint, and IM clients without push abilities plainly can’t work on mobile devices without dragging down the battery or not receiving messages. So, even more frankly, this is simply a question of life and death for Jitsi. The only thing I am ashamed of, is that I have so little resources to give, to support your great software. |
|
An implementation of OMEMO for XMPP is available (in Java) in the referenced project (https://github.com/siacs/Conversations). I'd very much like to see that becoming used in Jitsi (as well as the Jitsi ZRTP over XMPP becoming used in Conversations). I cannot do that atm due to large overhead involved (I know neither of the projects code-wise). But could you please try to get in touch with them and see if you guys can help each other here? Maybe drop a note in iNPUTmice/Conversations#1646 or something? It might actually be a rather small task if you could exchange code/knowledge here? |
|
Just like it was already mentioned by the devs -- yes, OMEMO is nice thing, but the code has to come from the community. Jitsi is a big project, with lot of work there to maintain it and believe me, the devs won't reject a good code attribution. So once again, it's "talk is cheap, show me the code". |
|
@turint : Here is the code: https://github.com/siacs/Conversations/tree/master/src/main/java/eu/siacs/conversations/crypto/axolotl - as said, I have no clue how Jitsi is build and how to go and integrate it (as I do not know how it is used there) :( If you tell me what info you need I would actually go and try to get it for you, although I think a direct exchange between you guys would be far more effective (and could yield synergies in the future as well?). P.S.: What I do know (might be better to write about that?) is the following though: OMEMO needs a rather new version of ejabberd to work (> 14.x it seems), as it stores things on the server (that's how it works "offline"). PEP was mentioned several times, but I do not know the technical details. If Jitsi hasn't support for those XEPs yet, it will probably need some more work though. There is some technical information I found at https://conversations.im/omemo/ that look like draft specs: XEP-xxxx: OMEMO Encryption and XEP-xxxx: OMEMO Encrypted Jingle File Transfer. For any technically interested person those might be of interest. |
|
@improti i think you misunderstanding him. its not a question of information to make this possible, like you are trying to provide. it seems that the developers dont have time, even if it is a great feature. so if you cant code it yourself or get someone else to code it, you simply cant help. |
|
Hi, |
|
I'm not even capable of maintaining the existing features. So, no. |
|
Maybe there needs to be a bug about creating a funding campaign? :) |
|
I'd love to see OMEMO being supported by Jitsi. |
|
Bounty at bountysource |
|
Added $25 to the bounty. Will add another $100 in if/when someone starts working on it. |
|
can omemo also be used for voice and video communication/streams, or is it just for text messages and file transfers? |
|
@hoijui Text and file transfer, with multi device and group message support. Zrtp is the standard for voice and video encryption - it's what Signal uses too. On June 8, 2016 5:00:30 PM EDT, hoijui notifications@github.com wrote:
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
|
In addition :) |
|
I meanwhile changed to Matrix (https://matrix.org) with the Riot client. Quite happy so far. |
|
(good for you, not that anyone cares? If a moderator could please remove that post and mine along with it, that'd be great.) |
|
I don't think that comment needs to be deleted. You may disagree, and that's fine. |
|
It's off-topic. |
|
Dear All, |
|
Any news? |
|
I'm waiting for OMEMO in Jitsi Desktop and Jitsi Android for XMPP impatiently, could it work soon? Thank you ! |
|
I still have hope for Jitsi Desktop with OMEMO, but not so much with Jitsi Android. |
|
Last time I checked aTalk (and that was a long time ago) it was barely usable. Actually it was unusable as even sending simple messages crashed the app :-/ |
|
Conversations seems to be the only decent client for Android out there. But
it doesn't do audio/video, though...
…On Thu, Nov 22, 2018 at 10:25 AM Wiktor ***@***.***> wrote:
Last time I checked aTalk (and that was a long time ago) it was barely
usable. Actually it was unusable as even sending simple messages crashed
the app :-/
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#199 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA0F3JrbStkfxCDvHh_G0F9DW_m1Dtg5ks5uxnuKgaJpZM4G7Wts>
.
|
|
I'm sure aTalk can need some contributors ;) |
|
aTalk is working well now even for Android 9.0 (Pie) or API-28 . Earlier releases of aTalk was not fully compatible with API-27 and above. Please feedback to me if you still see problems. You may refer to http://omemo.top/ and aTalk online https://atalk.sytes.net |
|
@cmeng-git, I just re-tested aTalk and indeed it works a lot better than before! Audio call works, video didn't (camera permission granted but in settings it just says All in all aTalk looks really good now, I'll definitely keep an eye on it! |
wiktor-k: Can you sent the debug log for my investigation on camera issue type="chat" => Has just fixed in aTalk, but not sure if vanitasvitae should include this fix in Omemo Message instead i.e. By the way can we take the discussion off Jitsi thread - the jitsi team may have some concern. |
|
We are in 2020, any news on it? |
|
@Neustradamus we are in 2020, where is your PR? |
|
calibrates time machine shit. wrong year. |
|
Would also interested in to see OMEMO support in jitsi. Any updates? |
|
my 2 cents:
no updates and probably not occurring in near future: it is both a licence
issue to implement the already existing OMEMO support in the smack library
into jitsi (GPL vs Apache) and of course lack of man power volunteering to
write an OMEMO plugin.
check here my conversion with the jitsi devs about OMEMO on the forum:
https://community.jitsi.org/t/upgrade-to-jitsi-desktop-2-11-5615-on-macos-10-13-wiped-all-xmpp-accounts-new-accounts-not-possible/19545/4
of course I would like to see OMEMO implemented in Jitsi Desktop, imho
usage of XMPP never reached the masses (and will never), currently the
focus using FOSS software in communication (audio/video/chat) is on
Jitsi-Meet/WebRTC, Riot-client/Matrix and Signal.
if Jitsi-meet would implement ZRTP for multiparty videoconferencing (not
sure if technically possible), it would be a killer app (currently WebRTC
is "fully encrypted" but not really end-to-end but only
client-to-server-to-client; unless you setup your own server and trust it
(...) it is still not a 100% secure solution).
I am using Jitsi Desktop since 10 years, however my XMPP buddies are
vanishing to other clients, only one is left...
Am Mi., 25. März 2020 um 10:55 Uhr schrieb Marko <notifications@github.com>:
… Would also interested in to see OMEMO support in jitsi. Any updates?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#199 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIUFSY6O3BW27OV2J6QWWG3RJHIHJANCNFSM4BXNNNWA>
.
|
|
@Neustradamus did the license change? |
|
There is no license anymore, the whole crypto approach is now specified, so one can search librarys that support the primitives and implement the crypto themself. |
|
@damencho: XEP has always like it, in 2020: "© 1999 – 2020 XMPP Standards Foundation" |
|
Sorry @lovetox @Neustradamus, I was talking about https://github.com/igniterealtime/Smack/blob/master/documentation/extensions/omemo.md |
|
@Neustradamus you are mixing things up here. The I'm sure Дамян just asked because Smack was once proposed. Smack is one(!) of those OMEMO implementations(!). But if you want to use Smack in one of your projects, it must to be licensed under the GPLv3 or compatible (like Apache). There are other OMEMO libraries that should be compatible though. For instance the OMEMO library jomemo which uses the Apache license. |
|
The license situation has not changed for smack-omemo-signal, but the XEP now specifies how the crypto works so so its not necessary anymore to depend on code that uses libsignal, someone can now look at the spec and impl the crypto themself in a new library which can be licensed under whatever license the creator wants, after that someone can use that library in the smack plugin and drop smack-omemo-signal |
|
I deliberately designed Smacks OMEMO support with an eventual drop-in replacement of libsignal in mind. While smack-omemo is not yet updated to 0.4.0 (there are some changes needed and all in all the module could use some love), it is totally possible to replace libsignal with another double ratchet library. |
|
Nice, good to know. Anyone willing to do it, just ask me questions for little guidance, I can help. But for now, I haven't heard of anybody willing to do the work. |
and others
That would be nice.