Hacker News Reader

Comment by SamWhited | Hacker News Reader

I highly recommend Conversations (disclaimer: I've worked on it in the past, although I'm not a project "member" per say): https://conversations.im/

It's open source, uses a federated, open protocol, and can do multiple types of encryption including OTR and OMEMO (an XMPP wire format that uses the Axolotl ratched devised for signal). It does not do VoIP, so it would just be for chat (although there is a large bounty on Jingle-based voip support open). It has also had a public security audit, and is designed to be white labeled so you can tweak a few variables in the source and build your own hardended version or encrypted-only version, etc.

View on HN

Conversations is great, but there's nothing comparable on iOS except Chatsecure which isn't yet beta quality. Then you need to pair it with a server that actually has all the recent XEP's installed (for push is XEP357, usually missing), see: https://gultsch.de/compliance_ranked.html

My current 'solution' is to use ZNC connected to Bitlbee (supporting OTR). On Bitlbee I use the jabber.fr service. ZNC has a push script for Mutter (great iOS IRC client) that I modified to redact my notification content from Apple's push service. I connect to the ZNC with TLS, so in theory everything should be ok.

NOT USER FRIENDLY but allows me to keep all my chats in one client and not tied to some shitty walled garden. Everyone less savvy I just tell them to use Signal.

That compliance table is the thing really killing XMPP for practical modern usage.

I tried to write an XMPP client about a year ago and found out about that compatibility table the hard way. It's rough -- I had no idea what I was getting into.

Turns out that XMPP, before expansions, has no standard definition of what message IDs are. Which means "good luck, have fun!" is pretty much the best anyone can hope for on synchronizing messages when you have multiple devices or when the network flakes on you. Which in turn means XMPP is basically unusable on multiple devices. If you're lucky, everything supports all the same extensions, and it'll probably work most of the time; but if any piece of software you use is missing one extension, your day is toast. (And even then, frankly, the "carbons" API is wrong-headed and not very capable of recovering from network failures. In no uncertain terms: It's time to move on.)

I wrote about this more previously on HN: https://news.ycombinator.com/item?id=9772968

I think Conversations is probably getting a lot right, but you also mention its biggest flaw:

> do multiple types of encryption including OTR and OMEMO

Oh and it can also do something else: no encryption at all. That's the problem with XMPP: The user is faced with three different encryption modes, none of them is the default.

There shouldn't be multiple types of optional encryption. There should be one that works and is enabled by default.

The practical problem is that a lot of power-users have strong opinions about which e2e scheme to use in which case. That may include "none". [1] If you enforce a single e2e scheme (no matter which), you will lose a lot of potential power-users, who would double as multipliers to spread your app.

I don't say that Conversations (and the XMPP community at large) couldn't do better, though. For example, there could be a standardized, automated, transparent process for determining which e2e schemes are supported by the clients involved in the conversation.

[1] For example, I skip e2e when talking to my several XMPP bots. They run on the same host as the XMPP server, so e2e won't reduce my attack surface when I already have TLS enforced along the way, but make the bot implementation considerably more complex.

> you will lose a lot of potential power-users, who would double as multipliers to spread your app.

Not really. I consider myself poweruser in many areas, but I would never recommend most of my tools to "ordinary" friends. The tools for them should be easy to use and difficult to misuse.

In practice you always get TLS. That's really all you need if you trust the server.

Something fairly significant has happened in the world of XMPP recently. You can get real certificates for XMPP servers under your control from letsencrypt. That means that things now work transparently between clients and servers and between servers. As a result, organizations that do things that some governments might not approve of can do transparent encryption simply by setting up a server or servers in places that such governments can not physically get at.

TLS on the s2s side is unauthenticated. Therefore TLS only protects you in a situation where both users are on the same server and trust it.

Getting a real cert for s2s doesn't really help as long as you have no agreed upon mechanism how they can enforce validation of those certs.

You need to trust both servers when doing s2s anyway. So you can just turn on certificate validation when depending on just TLS for your security. For Prosody that would be "s2s_secure_auth = true".

Of course an organization using TLS as their only security for XMPP would almost for sure just use one secure server, so I might be being a bit fanciful here. My ultimate point is that because of the way XMPP works, it is possible to make the normal default clients work securely in practice by doing the correct things at the server level.

I tried Conversations but I couldn't for the life of me get message history to work. There's just so much stuff you have to do when it comes to XMPP to get things working. Perhaps if I used someone else's server it wouldn't be a problem but I'd prefer not to do that.

See my comment below. You need a server with the XEP support for it. (XEP-313 I believe)

Yep, I have it. Somehow it was turned off for my account in particular at some point and there's no way I can find to get it back.

If you're using conversations go into the drop down menu, choose Accounts, click on the account you're using and then in its drop down / context menu (what do you call the hamburger menu on Android?) choose "Archiving preferences". Although it's deliberately buried so that you don't mess with it, so I'm not sure how it would have been accidentally turned off, so maybe whatever's happening with your server is unrelated.

I agree that it's a bit hard to get setup if you're dead set on running your own server, but that will be the case with anything (although Prosody and Ejabberd et al could have better defaults for the majority of people who probably just want to throw up a server and be done). The nice thing about XMPP is that if you don't want to run your own server, you're spoiled for choice. The network is significantly bigger than any of the other protocols I know of [citation needed].

> but that will be the case with anything

I mentioned this a bit below but this wasn't the case with Matrix. Setting up a homeserver took me about half an hour and gave me everything out of the box. Setting up Prosody took me days and gave me nothing but trouble.

There are a lot of XMPP servers around but I really want my own so that I can store plaintext chat logs on the server.

Curious for next time I evaluate XMPP is there a list of servers recommended by the Conversations team that people could install themselves? My issue with XMPP is that on the same system I have at DigitalOcean where I could run: an IRC server, a Web Server, and a Mumble Server and extra goodies all together in one box, I couldn't effectively run a XMPP server that would stay up (it would crash). I would of kept at XMPP had I found a decent memory efficient server that didn't merely crash.

I'm a big fan of Prosody (prosody.im); even the nightlies (what I run) are remarkably stable, and the memory footprint is tiny (they have some metrics somewhere if you ask in the chat; I can't find them right away).

THE xmpp server I'd recommend is prosody[1]. Lua based, quite active, very friendly community and easy to set up/configure.

1: http://prosody.im

I have a virtual server (1 CPU + 1 GiB RAM) running nginx, murmur and Prosody. free(1) reports 80 MiB used memory, thereof 10 MiB for Prosody. (I just have one active account, though: myself.)

So unless you're planning on hosting hundreds or thousands of users, you should be fine IMO.

I had not even 3 users... I was running a Java one, looks like Prosody is worth it's salt. Does it support E2E and other features that Conversations supports? :)

Edit:

I was running it on a DigitalOcean box with only 512MB of ram at the time, which I found a bit silly that I would come back and the server was down, but it was a different XMPP server than Prosody.

You probably used Openfire, known to be a memory hog and a bit unstable. Simply go for prosody and you should be fine (ejabberd should also be OK). Some newer XEPs which you may want to have with Conversations are not supported OOTB in prosody (yet) but there are plugins distributed separately [1][2].

[1] https://modules.prosody.im/ [2] https://prosody.im/doc/installing_modules

Yes that was the culprit! OpenFire sounds like it... I wanted something simple to setup, without too many terminal incantations. Thanks for the information, it's invaluable.

E2E does not need support from the server. Regarding Conversations, I'm using it with my server and it seems to be working fine, although I have not tested every single XEP supported by Conversations.

This is true, it's kind of easy to forget how E2E works sometimes, thanks!

I use ejabberd for a client. Prosody is also nice.

I never understood properly where Conversations app fit in. Is it a Jabber client to aggregate all the IM clients/accounts or is it also a independent highly secured instant messaging app on its own too?

A very good Jabber/XMPP client for Android. It's GPL and doesn't require Google services.

Reply on news.ycombinator.com