INinputmice·Apr 27, 2020Submission
Conversations, Android XMPP client, gains support for A/V calls
2 points · Open discussionsiacs
conversations
HISTORICAL RECORD2014–2020
siacs / conversations · Not publicly available
conversations
Discover this repository through its Hacker News conversations.
19Distinct people
21Mentions
1Explicit recommenders
What to know before exploring
What it is
A public description has not been verified.
Where it is used
No documented product use has been verified yet.
What people are saying
> battery life / fast reconnection (aka, the mobile problem) Don't see what to reply here > push notifications Solved…
andrey_utkin used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year21 dated mentions
Observed mentions: 2014-03-25 02:22:30 UTC to 2020-04-27 07:51:37 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 1 | 2 |
What Hacker News says
21 sources> How do you handle push notifications with XMPP?
XEP 0357, implemented in servers ( https://modules.prosody.im/mod_cloud_notify.html for prosody, for example), and implemented by clients ( https://github.com/siacs/Conversations/issues/1171, for conversations for example).
Conversations also uses XEP 0198 and XEP 0352 for battery optimization: https://conversations.im/#optimizations
In Decentralize MessagingFor mobile, there's already 'Conversations': https://github.com/siacs/Conversations
In Dino: An open-source application for XMPP messagingTo give some context on why JMAP is relevant today, you might want to read this answer in the conversations FAQ [1]. It basically states that XMPP powered Apps are having trouble fighting against the battery saving software because XMPP is stateful. JMAP, on the other hand, is stateless.
As protocols are meant to connect different implementations and bringing more protocols for the same task quickly hurts the interoperability (before bringing some improvements in the long-term), I am skeptical to the effects those new protocols bring to the ecosystem. I am aware that JMAP was born more out of the RESTful requirements of an HTTP based App, but in general, I am wondering where this road will lead us.
[1]: https://github.com/siacs/Conversations#but-why-do-i-need-a-p...
In JMAP: Like IMAP but Not ReallyNot really no. It's more problematic, a good amount of vendors doesn't allow applications to run in the background and it's not a matter of notifications.
It's a big issue with IM apps like Conversations or calendars and contacts synchronisation apps like DAVx5
Some example:
https://github.com/siacs/Conversations/issues/2771
In Android vendors, don’t kill my appI've looking into this issue for the last 2 days:
The APK we all looked into is IronChat-3.40-release.apk [1], after decompiling I think it is a copy/fork of Conversations version 1.14.6 with a few more commits until October 13th 2016 [2] with Secret Space Encryptor version 1.7.2c [3].
About unencrypted support: "supportUnencrypted() { return false; }" is in the config, so probably not [4].
There is a theory (I kind of started [5]) that it might be MitM because of bad UX. This is because they used OTR without TOFU which was only added in Conversations 1.15, after the fork [6].
[1] https://ironphonestore.com/IronChat-3.40-release.apk
[2] https://github.com/siacs/Conversations/tree/6371d2b7a9a2b5d7...
[3] https://paranoiaworks.mobi/sse/
[4] https://twitter.com/BWBroersma/status/1060136620383453195
[5] https://twitter.com/BWBroersma/status/1
Read the rest
059851925234036739 / https://twitter.com/Schellevis/status/1059852605801852929 (= the author of the article quoted by ars: https://nos.nl/l/2258309 )
[6] https://twitter.com/BWBroersma/status/1060278116315262976
People migrating from GCM to FCM need to be aware that in FCM analytics are turned on by default: https://github.com/siacs/Conversations/issues/3041
In How Tutanota replaced Google’s FCM with their own notification systemOr XMPP+OMEMO which adds things like multi-client support and encrypted group chat:
https://news.ycombinator.com/item?id=13396083
I'm running this on my own server (using ejabberd [1] as Prosody - which I used previously - still has problems with some of the required XEPs[2]) using several different clients (Conversations [3] on Android, Pidgin on Linux, etc).
The one weak link in OMEMO is the difficulty of verifying the authenticity of the device key signatures used by communication counterparts. These signatures are 64-character hexadecimal strings which the user is supposed to verify being authentic before initiating encrypted communications. Humans as not very good at this task, computer can help but they can also be tampered with. There are ways around this problem - e.g. meeting up in person before initiating communications (viz. PG
Read the rest
P key signing parties), sending Q-codes off-line, using algorithms to turn those numbers into things which humans are better at recognising (e.g. the coloured emoji used by Telegram etc.). Encrypted group chat only works if all participants have all other participants in their address lists. Then again, it does work and it is fully standardised with several compatible implementations.
[1] https://github.com/processone/ejabberd
[2] https://xmpp.org/extensions/
[3] https://github.com/siacs/Conversations
If you're referring to the table at the bottom I believe they just want to sway people into buying Business Edition with that.
When you compare actual XEPs needed [0] for good mobile and desktop multi device service then Community supports them too! (except one: roster versioning but that matters if you have hundreds of contacts).
[0]: https://github.com/siacs/Conversations#xmpp-features
In Ask HN: Why does P2P encrypted messaging still suck?[1] Seems to do the trick but I don't do Android dev so I don't know any details about this.
[1] https://github.com/siacs/Conversations/blob/2b9cdde558ed96c2...
In Android OreoCo-author of the OMEMO standard and lead developer of Conversations here. To answer your question one after the other.
> What do we think about this protocol?
It's the first encryption protocol that allowed me to actually use it on a daily basis. I regularly use my desktop client and my mobile client in parallel and switch between them constantly. OMEMO allows me to do that.
> Is it a good idea?
Yes. Compared to OTR the entire stack (that includes the XMPP layer) is properly standardized. This also kinda answers your questions regarding the OTR implementations. OTR had the problem that it couldn't do multiple devices and the behavior regarding multiple devices and when to start and end sessions wasn't defined at all.
All OMEMO developers are also in regular contact to coordinate behavior between the apps.
> Why are there three encryption
Read the rest
choices
I would really like to get rid of OTR (and we will eventually) but we currently still need it for backwards compatibility with older clients (primarily Pidgin)
PGP servers a bit of a different use case. It doesn't provide forward secrecy and authentication but it turn allows for a server-side re-retrievable archive. If you get a new client it can automatically retrieve old messages. (In OMEMO the receiving must exist at the time of writing. It doesn't have to be online but it has to exist and announced the device specific key material)
In reality the choice isn't too much of a problem. You select it once per contact and that's it. It's not like you are getting new contacts every day.
> How is the server support.
The server requirements for OMEMO aren't too bad. However it is recommended that you do pick a modern XMPP server for other reasons (battery-friendliness, reliability). Have a look at this comparison list to see if your server supports all modern extensions: https://gultsch.de/compliance_ranked.html
> How is the support of group chat
Support for group chat exists and works fine once it is setup. However it has some limitations that make setup harder. Everyone has to be in everyone elses contact list. And the group needs to be setup with special parameters. (Conversations automatically sets it up this way, but you couldn't for example create the group with Pidgin and then expect OMEMO to work.)
The readme on the Conversations github page explains this in a little more detail: https://github.com/siacs/Conversations/blob/master/README.md...
It works quite well for me with the Conversations Jabber client with no discernible battery usage impact.
Did something change in recent Android versions?
Edit: Apparently Nougat's Doze is the issue. Conversations bug report, you can apparently put it on a whitelist:
https://github.com/siacs/Conversations/issues/1624
In Why I won't recommend Signal anymoreYep. In addition to that, it’s also FOSS¹ and you aren’t limited to only getting it from the Google Play Store; it’s also distributed² on F-Droid³ too. One thing to note though is that the version of Conversations on F-Droid doesn’t support push notifications, since that functionality uses Google Cloud Notifications.
――――――
¹ — https://github.com/siacs/Conversations
² — https://f-droid.org/repository/browse/?fdid=eu.siacs.convers...
³ — https://en.wikipedia.org/wiki/F-Droid
In “How do I choose not to share my account information with Facebook?”I think this is taking it to the next level, even for Google.
They now make hangouts be on parity with Allo, except for no opt-in end-to-end encryption? Or is the difference that Allo allows encryption, and Hangouts allow group video chat?
BTW, I know I've used videochat via hangouts on Android some time in the past two years - but I guess maybe that was through chrome?
The good news is that there's some work on the open XMPP side, with conversations[1] (along with the OMEMO protocol [2]) and zom.im [3] -- so it looks like we're set for another xmpp revolution. And if that fails, there's always Matrix[4] (And the best part of that is that it's not either/or - we can have both. And everyone else can rot in their crummy message silos. Good riddance).
[1] https://github.com/siacs/Conversations
[2] https://conversations.im/omemo/
[3] https://
Read the rest
Showing the 15 most recent of 21 sources. Enable JavaScript to search and browse every indexed mention.