Ask HN: Why does P2P encrypted messaging still suck?

161 points by xstartup ↗ HN
I chat with my teammates (who are ready to agree on a particular messenger)

So, far we've tried

1. Telegram - The problem here is that E2E encrypted messaging (secret chat) is not available on the desktop.

2. Tox - Works everywhere but qtox crashes randomly on Mac. Antox also doesn't work well on Android either. Utox crashes randomly on Linux. Qtox has no way to disable notification on Linux.

3. Whatsapp - You always need your phone android

4. Signal - Message syncs is very slow if you switch between desktop/phone often.

I've reported these issues to all these projects but it's been a long time and nothing resolved so far.

The situation is still pathetic. What do you recommend?

200 comments

[ 2.7 ms ] story [ 234 ms ] thread
Signal works pretty well for me. I mostly use it on my phone, but occasionally on my desktop, but never had sync issues.

Matrix.org + Riot.im are a pretty solid combination. Plus, you can bridge to IRC.

I've heard a lot of great things about matrix.
> Plus, you can bridge to IRC

I tried this recently. I really wanted it to work. However, it was a complete mess, mainly frequent (and prolonged) disconnects on the bridge. For folks who primarily use Matrix but would like to occasionally pop into IRC channels, it's probably OK. For folks that need a reliable IRC connection, don't bother.

Agreed. Also another issue was that I Tested and trained a number of NGOs on it and the general feedback was that there were too many options on it when it came to rooms, sharing etc. As a techie I love it, but the general response was that it was too complex to use.
The UI could definitely be improved, but the core team has recently hired a UI designer, so hopefully this will improve in the future. If you have any other feedback that you've heard from your trainings, I'm sure the core team would love to hear about it either in their issue tracker (e.g. github.com/vector-im/riot-web/issues for Riot web), or in the Matrix rooms (#riot:matrix.org or #matrix:matrix.org).
You are probably using one of the IRC bridges that is on the matrix.org server. The matrix.org server is having a lot of problems with being DDoSed as well as not being able to keep up with the normal traffic. The next generation homeserver written in Go is supposed to help with this a lot.

There is nothing inherently broken with Matrix <-> IRC bridges, it is just that one server. Other servers are bridging to IRC perfectly fine and you are welcome to host your own.

The matrix.org home server is spectacularly overloaded right now, causing messages to take several seconds to be delivered at a minimum. It isn't terribly surprising considering my own federated home server with under 20 users sits around 4gb of memory utilization with a single core (the server is single process/single threaded by default) pegged.

There's some work that can be done to proxy some of the load off into separate workers, but Synapse is pretty darn awkward to work with.

Have you tried leaving any giant rooms you may be in? Like Riot/Matrix HQ? I use my personal homeserver for my friends/some IRC channels and my load is nonexistent. May not be the answer you're looking for, but those huge (10,000+ users) rooms are a huge strain on homeservers right now. Look for performance updates in the next version of synapse.
Yup -- that's exactly what the end solution was. Unfortunately reaching out to those 20 users and saying "hey, could you be judicious about which federated rooms you join? otherwise you're gonna hose us all" kinda sucks.
I've been considering writing a Synapse-equivalent Matrix server in Elixir, if there was enough interest.
from the bit I learned at a phoenix/elixer meetup - it seemed that it may be the most well suited for multiple chat streams. I am really interested in this.

  > 20 users sits around 4gb
dafuq? Are you serious? What could possibly need 4gb?
The problem isn't the number of connected or registered users on the server - the problem is the complexity of the rooms they are participating in. So if those 20 users join hundreds of rooms with tens of thousands of users participating, spread across thousands of servers, with large numbers of joins/parts or messages sent a second... you shouldn't be surprised that it takes a few GB of RAM.

HOWEVER, we have been working incredibly hard at optimisation over the last few months, and we have order-of-magnitude algorithmic performance improvements on the horizon over the coming weeks. https://twitter.com/matrixdotorg/status/979049079568240641 etc. There's also a port to python3 happening which should improve RAM by 2-3x given python3 stores strings in utf8 rather than python2's utf32.

I certainly don't mean to throw any shade on the project -- if anything, the RAM utilization was less of a surprise for me than being bound to single-core performance by default. Sure, it's possible to split Synapse up into workers, but it definitely feels like there's some voodoo involved (my first attempt at setting just a Synchroton worker failed miserably this week)
Is it really necessary to maintain the state of the entire network on all federated nodes? (Since I'm guessing that's what you've described)
It isn't necessary, and we don't do it. What I've described is what happens if you type '/join #matrix:matrix.org' and your server starts participating in a large room which spans tens of thousands of users and hundreds of servers. Rooms are only replicated over the servers which participate in them. So if you don't join massive rooms, your server can be have fine. (And in the near future massive rooms should be usable too).
I have a single non-federated synapse server with 10 users and 25 client devices, and the python process is using 135MB (RES in top). Load average is 0.00. There's 2 main rooms and probably around 10 chats. The homeserver.db is 26MB.
Last I checked there was no Signal client for most Linux or BSD distros. IIRC they did something silly like a Debian-only package or something.

But as many others have stated, its inability to work without exchanging phone numbers is a show stopper for many uses cases. Especially now that my country requires SIM registration with valid IDs.

I've been using Signal for a couple of months. Even though it works it has some quirks (slow to load up on macos, sometimes message lifetimes don't seem to be working, messages taking time to arrive to a second device although both have the application running). WhatsApp was better in that regard, but I'd prefer to use something a little more independent :)

Ah, and will try Keybase soon, although the downside of these switches are that I need to convince people around me to use them too..

There's a signal electron app, so there's definitely a signal "desktop" app on linux if you want it. I use it every day.
I just recently replaced FB messenger between my GF and myself with Matrix.org + Riot.im.

Hosting the server (synapse) yourself takes about 15 minutes to setup.

I highly recommend it.

Is the encryption for Riot.im out of Beta yet? Last time I've looked, about 4 month ago, it came with a big warning. Besides that it had no real concept of identity tied to account or so but generated a new key each time someone opened it in a browser or installed the app on a new device with out prompting, leading to people having as much as 30(!) keys, which of course nobody ever verifies.
it's less in beta than it was 4 months ago. we're at the stage of putting telemetry in the app to get it to phone home ever time encryption fails so we can see just how broken it is in the wild, as it seems pretty good for us. Cross-signing keys is next up and we're working on it over the next few weeks.
Nice, thanks for the answer and your work!
I am using Arch + Signal but message syncs are pretty slow after long chat session on mobile.

I've forgot to mention, we've also tried Riot Matrix.

UX was simply not there and app felt oriented towards the very technical audience. My teammates had a problem with this.

I find Wire(wire.com) to be well designed and usable, especially their mac client. Only issue I have with Wire is having no anonymous sign up and having to rely on a central server to add contacts but the former can be worked around by using a temporary email.

I take issue with having to provide a cell phone number for Signal. I just hope Tox clients get more polished and more usable as every client I've used except toxic has been terribly buggy.

In addition, their server-side code is open-source and they claimed that federation support is something they are considering to add: https://github.com/wireapp/wire/issues/160

Overall, I'm also not a big fan of Signal's hostility to federated protocols (https://signal.org/blog/the-ecosystem-is-moving/), so I'm more optimistic about Wire in the long run.

Just want to add onto this that pretty much everything Wire makes is open source. The backend (written in Haskell no less, which continues to amaze me), the desktop app and the mobile apps.
I run Telegram on my desktop? Also i use WhatsApp on my iPhone.
Telegram doesn't use end-to-end encryption by default. It's marketed as a secure messenger, but it's comparable to Facebook Messenger or Google Allo.
As I've mentioned in the post above, telegram simply does not have "secret chats" available on Desktop.

So, if you use Secret chat on mobile and go to desktop, you'll not see it!

Switching back and forth between secret and not secret is troublesome especially when the other side doesn't know if you are on desktop or mobile to check availability for secret chat.

Which desktop client did you try? The official Mac client, at least, has secret chat just like the mobile clients (I just used it yesterday)

Note that Telegram secret chats are end to end encrypted (default chats are not) but you're still dealing with the Telegram server (not peer to peer)

I have just installed the Mac client and it allows to create new secret chat but it does not show the secret chats created before on your phone. At least that is what happened to me.
Which platform? I only use Mac for a GUI OS and that has secret chats for Telegram.
At one company where I worked, we ran our own IRC (+SSL) server, and it worked great. Depending on your exact requirements and use cases, that may or may not qualify as "p2p encrypted".
Seconding this. You can lock down an irc server pretty thoroughly if it is for company internal use only. First, put it in private IP space that is only accessible from a VPN connection (properly setup openvpn for instance). Have unique vpn public/private keys per device so you can revoke access to a stolen laptop or phone granularly. The ircd server host OS should have no public facing IP. Also configure the ircd to only listen for sessions from a certain range of IP space. Once people are on the vpn, have them ssh into a shell bastion system and run irssi + screen (or tmux) from there, connect to the ircd.
This doesn't protect users from snooping by the IRCD admin, which is what e2e encryption/p2p chat is about -- removing the ability of the service provider to see the content of the private messages between users. IMO IRCD in no way qualifies as "encrypted p2p chat".
Plenty of OTR-like plugins for your IRC client of choice.

IMO IRC is still the best chat experience.

I was describing more of a multi person chat (not p2p) for company internal use , such as an irc channel with ten or fifteen people. Much harder to do proper forward-secure crypto for one-to-many messages.

If you run and control your own ircd the risks of snooping by the ircd admin are about the same as if you unknowingly have a rootkit/advanced peristent threat installed on your end point client workstation.

That's why I said it may or may not qualify. What's the threat model? What's the usage environment? (It's "encrypted p2p" between two users if one of the users is also the admin.)

For example, if the purpose of this requirement is to keep a business team's communications out of the hands of other businesses, then local IRC+SSL accomplishes that, even though the local administrator can still snoop on it. Being able to say that company secrets never left the company was a big hit with our investors, and it didn't matter that it was technically possible for our sysadmin to snoop on them because he had physical access to all our workstations anyway.

If you don't have a trusted administrator, all is not lost. Each user can run their own ircd on the same VPN. It's less convenient to set up but any IRC client can handle multiple servers. Again, it depends on your requirements. (Are there 5 users, or 5000?)

Like any other technology, IRC can be used as part of a secure system. It has the advantage that it's free and easy to run yourself. Without knowing more context, though, it may or may not be practical.

sounds unnecessarily complicated when you can just use public ip + TLS client certificates or SASL
Try Keybase (keybase.io). It provides usable apps for all platforms, encrypted file sharing, git, group chats. Most important thing: it does not require to trust keybase servers as trusted party. Trust for your partner key is inferred from various proofs.

Disclaimer: I do NOT work for keybase, just a big fan of it.

I've tried, but it still doesn't support yubikeys/smartcards. So people send me messages on keybase chat, but I can't decrypt them :(
I use Yubikey 4 with keybase too and my GPG key is stored on smartcard. As far as I know Keybase uses device keys for encryption which are independent from your PGP key (but they are cross-signed if you have PGP key added to your profile). Everything is working well for me. Probably your issues caused by some immature version of app or server API.
Hi, I work at Keybase. There actually is some Yubikey support. But it's not relevant here, because chats use per-device keys, not your PGP key.
Right, so how can I decrypt the chats you sende email notifications about if my base pgp key is on a smartcard?
The messages are encrypted with your device keys, so you need to be on one of your attached devices. That'll be either a desktop, or mobile device attached to your keybase account.
Also a fan of Keybase. Overall it is easy to use, but their clients could defiantly use some polish though. The mobile client especially can get annoying since the push notifications don't get grouped together.
How does Keybase make money?
I've occasionally seen delays of ~10 minutes between message sent and received with Signal; even upwards of 30 minutes sometimes.

It's a shame; the app has a very good user experience otherwise.

Delays of minutes or hours also occur in WeChat and plain old SMS. They are incredibly annoying, but it's not obvious to me that we can blame Signal here?
For me, the main problem is, it takes forever to sync when you switch devices after really long chat session on verified chats.
Did you consider https://threema.ch/en yet? I have been using it for years and it is great (iOS and Android). The developers keep adding new useful features to stay on par with Whatsapp etc. For instance, their web chat is currently in beta.
> Ask HN: Why does P2P encrypted messaging still suck?

Because no one wants to pay for it.

Also, no one's asking to have it paid for.

I've noticed over the past few years that a lot of things go un-made because there's an assumption that no one will pay for something if it's done really well.

The reality is a lot of people will pay for something if it's done really well.

I'd easily pay $10/month for Facebook, if Facebook really had some way to shut off 100% of its marketing-based data things that we're all so worried about.

Thing is that people became allergic to asking outright for money from consumers a while ago. I used to buy software, and I still will if someone actually makes great software!

(I pay for all sorts of services that actually ask; Dropbox, a password manager, Spotify, Netflix, extra space on Gmail, etc. Provide an actually great service, make it a reasonable price and I'll pay!)

threema.ch exists if you want a paid encrypted chat client

Things that are free get about 10x more adoption than non-free equivalents, and chat clients are software that have network effects.

https://spideroak.com/semaphor/

SpiderOak is a good company.

I've had a free storage account with them for years. I didn't log in for 3 years and when I logged in my data was still sitting there, safe and sound. Pretty nice for a free tier.

Did you consider XMPP with OMEMO? I'm running my own server for family and friends, we use https://conversations.im in mobile and Gajim or https://dino.im on desktop. Everything runs well including encrypted group chats.
How do you deal with lost messages? When clients have unreliable connections, we experience message loss with that setup (ejabberd + conversations).

Actually, I'm dumfounded that that can happen at all. Lost messages are trivial to detect and to correct, how can that happen with that setup?

I never had lost messages and I'm using Prosody for almost 2 years. Check the advanced info in Conversations account settings page. There you will find all features that the server should support for good service. Maybe your ejabberd is old or doesn't have all necessary modules enabled?
It actually highly depends on client support. There's a few XEPs that help to mitigate message loss, some depending on clients and some -- on both clients and server; apparently most clients don't implement those, and the support on servers is poor as well.
Yes, that's why I recommended modern clients in the original message, they work well and are maintained. I wouldn't say the support on servers is poor if you run your own, two most popular servers (Prosody and ejabberd) support modern XEP suite after enabling modules. For third party one can check here: https://conversations.im/compliance/
I just read something that makes me rather angry. For ejabberd, message reliability is a premium feature that is not supported in the free version. The fuck?

https://www.process-one.net/en/ejabberd/protocols/

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

I do experience message loss, and there is that table. So, I don't think there is much room for interpretation.
Does your server pass this test https://github.com/iNPUTmice/ComplianceTester ?

Did you try conversations.im server that is known good for comparison?

I just ran the tester. The default ejabberd configuration in Debian Testing fails:

  Use compliance suite 'Advanced Server Core Compliance Suite' to test server.tld
  
  running XEP-0115: Entity Capabilities…		PASSED
  running XEP-0163: Personal Eventing Protocol…		PASSED
  passed 2/2
  
  Advanced Server Core Compliance Suite: PASSED
  
  
  Use compliance suite 'Advanced Server IM Compliance Suite' to test server.tld
  
  running XEP-0115: Entity Capabilities…		PASSED
  running XEP-0163: Personal Eventing Protocol…		PASSED
  running Roster Versioning…		PASSED
  running XEP-0280: Message Carbons…		PASSED
  running XEP-0191: Blocking Command…		PASSED
  running XEP-0045: Multi-User Chat…		PASSED
  running XEP-0198: Stream Management…		PASSED
  running XEP-0313: Message Archive Management…		FAILED
  passed 7/8
  
  Advanced Server IM Compliance Suite: FAILED
  
  
  Use compliance suite 'Advanced Server Mobile Compliance Suite' to test server.tld
  
  running XEP-0115: Entity Capabilities…		PASSED
  running XEP-0163: Personal Eventing Protocol…		PASSED
  running XEP-0198: Stream Management…		PASSED
  running XEP-0352: Client State Indication…		PASSED
  running XEP-0357: Push Notifications…		PASSED
  passed 5/5
  
  Advanced Server Mobile Compliance Suite: PASSED
  
  
  Use compliance suite 'Conversations Compliance Suite' to test server.tld
  
  Server is ejabberd 18.01
  running XEP-0115: Entity Capabilities…		PASSED
  running XEP-0163: Personal Eventing Protocol…		PASSED
  running Roster Versioning…		PASSED
  running XEP-0280: Message Carbons…		PASSED
  running XEP-0191: Blocking Command…		PASSED
  running XEP-0045: Multi-User Chat…		PASSED
  running XEP-0198: Stream Management…		PASSED
  running XEP-0313: Message Archive Management…		FAILED
  running XEP-0352: Client State Indication…		PASSED
  running XEP-0363: HTTP File Upload…		FAILED
  running XEP-0065: SOCKS5 Bytestreams (Proxy)…		PASSED
  running XEP-0357: Push Notifications…		PASSED
  running XEP-0368: SRV records for XMPP over TLS…		FAILED
  running XEP-0384: OMEMO Encryption…		PASSED
  running XEP-0313: Message Archive Management (MUC)…		FAILED
  passed 11/15
  
  Conversations Compliance Suite: FAILED
My point is not whether ejabberd supports the needed XEP's. What matters is if they are enabled and properly configured by default.
You were arguing before that reliability is a premium feature while the table shows that XEP-0313 is available for free edition, and that's what holds your messages while you are away.

As for the configuration yes, it would be nice if it came pre-configured with modern suite, but it doesn't. It still can be configured and as far as I can see from the tester the effort is not that high.

I tried to configure it, but it failed. I filed a bug report.
Is there a server you recommend?
Ejabberd and prosody are the most widely used ones. For prosody you should also consider using the community prosody-modules repository that adds many modern features. I'm running prosody 0.10 on a server for my app users, with multiple hundred connected clients simultaneously.
Prosody is very simple to set up, ejabberd can scale to infinity.
Maybe I'm missing something but you asked for P2P messengers but listed a bunch of messengers that aren't P2P? The only one you've tried that is P2P is Tox right?
How about running the Telegram or WhatsApp mobile apps on your desktop using an Android virtualization layer (e.g. BlueStacks)?
(comment deleted)
At least in the pass, one couldn't easily (if at all) run whatsapp on multiple devices. Even if one would run it in bluestacks, it be only a desktop solution.
Yea, but that's too much to ask from all teammates.
1. Telegram - Not p2p

2. Tox - p2p

3. Whatsapp - Not p2p

4. Signal - Not p2p

Putting the above aside: If Tox doesn't work for you, your best mobile-friendly options are: 1) Signal and 2) as others have mentioned Matrix - if you want a self hosted and federated solution.

[edited: addendum] i now realize you probably mean p2p-encrypted messaging. Damn semantics of non-formal languages!

My guess is that the intention was "E2E encrypted".
Yes, i guessed the same, but after i posted the original answer.
How do you call P2P that is strictly without any third party?
What does "third party" in your question refer to? Are you referring to servers that route client-side encrypted messages from user to user?
Yes, so that messages can reach a user even if the receiving and sending users are never online at the same time (a server could be another user/peer(s) that isn't part of the communication, so it could possibly still be called p2p?)
p2p strictly implies no third parties.

If there is a third party involved, you are not p2p.

so if other users (not part of the conversation) are used as temporary servers so that messages get delivered even if the sender or receiver are never connected at the same time, what would it be called?
AFAIK there isn't a modern word to describe the common architecture that you describe.

About a decade ago, the phrase "hub-and-spokes network" was thrown around to describe an architecture with a central server that acted as the mediator. The term "p2p" became popular in this context. (

Napster, bittorrent, tox are all "p2p" because they don't connect to single server. Skype is not "p2p" because all packets go through the skype servers.

Skype used to be p2p, except for the original auth/login. But since then microsoft bought the company and push everything through their servers.
That is incorrect. You've just defined P2P such that no commonly accepted P2P application meets it. At a minimum every P2P app you've likely ever heard of or used, baring maybe one exception, has at a minimum used third parties for orchestration.
>3. Whatsapp - You always need your phone android

Really? I have iOS here, WhatsApp works fine here and the web app version (https://web.whatsapp.com/) also works fine.

Does the webapp still not work if your phone is off (perhaps runs out of battery)?
I've just tried – it doesn't appear to work if the phone handset is offline.
you can't use whatsapp web when your phone is not on the same network
It doesn't have to be on the same network, only on the internet and you need to scan the code (see also my response above)
In case anyone is interested, the phone plus web combo was apparently the final solution to the thorny problem of establishing identity with the web client without requiring any more info on the user beyond the phone number.

All bets are off, now that it's FB's beast, but the two device solution was intended as a privacy feature, afaik.

I sat next to Pasha Sadri, the web client lead, for 4 months before the acquisition. He mentiond the problem a few times.

The fact it took another 2 years to get the client out seems to indicate that multiple problems were solved in other ways.

I apologize I misspelled it, I mean "around" not "Android".
…then I retract my comment. Thanks for clarifying.
I think he refers to the fact that WhatsApp sends all data via the phone.

The private keys are only stored on the phone. With WhatsApp you have a session key via the At code you scan. All messages first go to the phone, which decrypts and reencrypts using the session key. Quite sophisticated, but sometimes slow and not working if the phone has no network connectivity or power.

I was working on exactly this many years ago at the OFTN OSWG with an open source project called Hum.

I stopped development after Apple got sued for secure p2p video chat with the original version of FaceTime, seeing as Hum was also going to support secure multiparty p2p video chat. Unfortunately VirnetX (and by extension, the US military) owns a patent that would have made deployment of Hum difficult without an expensive legal team.

It's not too hard to imagine that the real reason you don't see many p2p encrypted communication platforms is US military-sponsored patent trolling. This aligns with their mass surveillance interests.

Wait a minute here -- You're saying that the US military is patent trolling with secure, multiparty chat patents?

Can you link to said patents?

It's not really trolling in this case since they actually use and develop on the technology
The person is wrong. It's a private company that has the patent, the company works with the government. I don't know why he implies the government is involved in the patent suit, they are not.
"It's not too hard to imagine…" isn't exactly the same as saying "It's true that…". I don't have hard evidence, but it's not hard to imagine VirnetX being manipulated behind the scenes by the US government. Similar circumstances have happened in the past.
How has this affected open source efforts?
Because software patents apply to open source software too.
"How has this affected open source efforts?"

can be read as either

Why is it possible for [situation] to affect open source efforts?

or

In what way(s) has [situation] affected open source efforts?

The latter being more charitable because it also answers the first question and can assume the asker at least has a semblance of why it might be possible.
That was the sense I meant. If the US military is using patents like that I would want to know and be surprised that I had not heard about it already.

It seems like the sort of thing that would have been talked about on the internet a lot.

Yeah, I'm working on a system that makes it easy to build P2P E2EE apps[1], and your comment has me a little freaked out.

I am not aware of any lawsuits or patents on this, could you send links / share your story more?

[1] https://hackernoon.com/so-you-want-to-build-a-p2p-twitter-wi...

Never ever search for patents, knowingly infringing on a patent is much worse than doing so unknowingly.
Are you saying the law has no requirement to do any sort of due diligence? I find that surprising.
Such a due diligence requirement would not be compatible with the current patent system, you are unlikely to be doing anything these days without infringing on someones patent.
Is knowingly turning a blind eye just as bad?
Money. It's not profitable to run an encrypted messaging service for free, because you can't extract any data from the chats, and people aren't willing to pay what it costs to maintain a good app.
Maybe a company could allow paying customers to invite 10 of their contacts to use the app/service for free. Or is even the potential association of all of those people too insecure?

I otherwise can't imagine how to bootstrap a network.

Maybe users could pay to receive messages.

> Maybe users could pay _receive_ messages.

Pay to recieve a possibly unsolicited message?!

That's insane.

Yeah, even requiring users to _send_ messages probably isn't enough to prevent spam. But that's assuming something like the example I imagined, someone wanting to received encrypted messages from anonymous others.

If a user's address is private tho, then asking them to pay to receive messages should be as sensible as the degree to which they protect the distribution of their address.

Unlimited texting as the norm is pretty new, carriers have charged for incoming and outgoing MMS since it became a thing. Same with minutes and received calls.
Getting charged to receive a message I didn't ask for was bullshit then and it's bullshit now. The difference is that people are even less likely to tolerate it now.
(comment deleted)
I otherwise can't imagine how to bootstrap a network.

Facebook started with a narrow target: students of some uni. Look for another similar group of persons, that want privacy and don't mind spending a few dollars.

Edit: Whatsapp (everybody here in Spain has it) was a paid app at first. They gave one year away... eventually they made it free, around the time that Facebook bought it.

When it targeted a narrow band of uni students Facebook was free, and didn't have ads
Yeah, wondering how WhatsApp would be doing if Facebook wouldn't have bought them. It might have been much better for the market if they would still be independent.
One problem with bootstrapping a network of users of an encrypted messaging app/service is that info about the network of users itself arguably needs to be secured too.

But you're still probably right overall. Marketing to businesses or teams within businesses is probably the best bet.

And what about non-free?
Threema is pretty good. Unfortunately it also sucks.

(Sucks as defined by OP)

should have adopt the IRC mode. Allow people to self-host servers.
Even if operation costs are shared between interested parties, half of the problem OP reports are usability ones. A development team capable of maintaining ports to all major OSes does not keep itself fed and clothed.

Open source has proven that volunteers can deliver a barebones, fully functional program, but you need corporate sponsorship to grow that into a high quality software product. Again, it's the money.

We have so many decades of improvements in programming methodologies and sophistication, yet independent developers still cannot produce viable software which is alternative to the for-profit model?
I suppose they can. Please do!
Then can we (the people) donate our time to make an end to end encrypted, decentralized, peer to peer, optionally anonymous (through Tor or whatever if necessary), native chat client for all relevant platforms?

It takes a few maintainers per platform and a few people willing to lead the effort, but I think we could get enough people on Hacker News to help out.

(I've actually been debating making an "Ask HN: Would you join this effort?" post but have been putting it off for one reason or another.)

In some ways, the ideal scenario is to have a funded, privacy-aware NGO maintain a messenger service, but:

https://blog.torproject.org/sunsetting-tor-messenger

"We, the people" is such a fragile concept when it comes to resource stability (time, money, dedication). Looking at a project like Linux, there are commercial interests that fund a large part of the pipeline.

Running the actual network and developing the various messenger clients add a layer of organizational complexity that, in my perspective, only private companies have been able to honor, and only to the extent described by the OP.

One could settle for less Service, but then we have XMPP with various encryption schemes. Too complex to set up.

> Running the actual network

The ideal would require no servers, because the chat would be fully peer to peer. People wanting to be anonymous could just connect through Tor. (Each user account is just a private key, etc, etc.)

Of course, in reality everything is behind a NAT and/or firewall. It wouldn't be too difficult to have "dumb" servers that just exist to pass messages hosted by the community though.

Donate to Open Whisper Systems (maintainer of Signal and led by the designer of the encryption protocol therein). It recently became a 501c nonprofit organization following a hefty donation, but one day that will dry up and they will need continued support.
Savoir-faire Linux has been doing it with Ring (https://ring.cx) (initially sflphone) since 2004.

It turns out that the skills that the company has acquired by doing this pays back with consulting contracts.

Signal on Android(app)/Debian(desktop) always syncs for me within a few seconds, and both my connection and DNS suck.
It's difficult, even the richest company in the world hasn't figured out proper sync of their encrypted messaging platform and they only support their own operating systems!
(comment deleted)
If you're an individual or organization in opposition to a state / stage agency then certainly it makes sense to find an app to protect your communication without a third party being involved.

Short of that, consider if you actually need "P2P encrypted messaging" - if you're doing business-type things then you should probably use a business-type messaging solution. Slack is pretty good. IRC is fine if you're slightly more paranoid, it just doesn't have UX on par with a commercial solution.

Find any HIPAA-compliant messaging product and you'll get most of what you actually need (vs think you want), but be prepared to pay much more for it than for a regular chat client.

I have been using Keybase.io for a lot of the chatting I do with friends, and it works great across multiple platforms.
To clarify: Keybase.io, like Signal, Whatsapp and Telegram above, is encrypted but not P2P - all of them rely on centralized servers.
and thats where the vulnerability is, in the centralized servers
The only vulnerability introduced by the servers at keybase is denial of service. I believe the protocol and clients are open source and there is no need to trust their servers for the key distribution part either (keys are cryptographically verified from a variety of sources like DNS, Twitter, Reddit, HN for each recipient)
https://status.im is great, it uses ethereum whisper protocol https://wiki.status.im/Whisper_Messaging
Who would want to store their private messages on a public database?

Not to mention needing to buy ETH some how and than paying for every message?

You don't need ETH to send messages on whisper. And Whisper doesn't store your messages on the blockchain.

https://github.com/ethereum/wiki/wiki/Whisper

Interesting protocol, thank you for sharing and correcting my misunderstanding.

  Uncertain-latency Not designed for RTC.
At first glance, this looks like a client broadcasts the Whisper to another server which than places it in a cache and might forward to more clients if enabled. Eventually the cache is cleared and there's no telling if the message will propagate successfully in any given time frame?
More or less it's how you described it. The current implementations broadcast messages to all connected peers supporting the protocol every a few hundreds of milliseconds.

It's also true that there is no confirmation that the message reached the recipient (in order to provide dark routing). This can be built on top of Whisper in a separate communication protocol.

(comment deleted)
I've recently moved to wire after looking for a chat app capable of exactly this. It's quite good, sync is fast an effective and even group calling is acceptable.

Only problem is that it currently doesn't allow you to send yourself stuff, making it less useful than telegram was...

(comment deleted)