Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Why does P2P encrypted messaging still suck?
161 points by xstartup on April 3, 2018 | hide | past | favorite | 193 comments
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?




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?


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.


It's not really trolling in this case since they actually use and develop on the technology


The Ars Technica article on their lawsuit against Apple [1] said they advertised a product on their website but received zero revenue from that product and seemingly didn't have any engineers working on it.

[1] https://arstechnica.com/tech-policy/2017/10/full-scale-of-ap...

Edit: Added the link.


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.


sad


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.


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.


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.


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.


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.


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.


When it targeted a narrow band of uni students Facebook was free, and didn't have ads


> 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.


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.


should have adopt the IRC mode. Allow people to self-host servers.


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.


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!


And what about non-free?


Threema is pretty good. Unfortunately it also sucks.

(Sucks as defined by OP)


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.


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.


  > 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).


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.


FYI there have been efforts to rewrite an equivalent in Golang: https://github.com/matrix-org/bullettime


Dendrite seems to be a much more active Matrix server written in Go.

https://github.com/matrix-org/dendrite


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.


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.


> 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.


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.


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).


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.


There are builds for ubuntu now. They even run an APT repo. https://support.signal.org/hc/en-us/articles/214507138-How-d...


There's been one a couple in the AUR for a long while, too. Signal Desktop is not too bad. The aesthetics are clunky, and it didn't seem to scale well last time I used it, but decent overall.


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.


There's even a cli client that someone has written: https://github.com/AsamK/signal-cli


I'm using the Flatpak on Fedora: https://beta.flathub.org/apps/details/org.signal.Signal


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've heard a lot of great things about matrix.


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.


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 :(


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?


It will just work. Your PGP key isn't a "base" key, the device keys are. Your PGP key is only used for PGP operations.

https://keybase.io/blog/keybase-new-key-model


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.


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.


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?


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.


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.


No love for SpiderOak's Semaphor. It's a secure end-to-end encrypted system. Free for 5 users or less. https://spideroak.com/semaphor/


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.


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.


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.


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.


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".


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.


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.


sounds unnecessarily complicated when you can just use public ip + TLS client certificates or SASL


Well, iMessage is end-to-end encrypted and works smoothly on both mobile and desktop. Caveats apply, of course: supports OS X and iOS only, is not open source and its protocol is not publicly available for audit.

OP’s post indicates they need support for Android mobile and Linux desktop, so it won’t fit their bill, but it’s a viable option for some.


> 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.


I use Wire, which is a neat p2p encrypted messenger: - with an open source app / server - you don't need a mobile phone and you can use a desktop app - Voice call works perfect (really good alternative to skype) - no random crashes at all - (a colleague of mine diskussed some 'minor' issues on twitter - and they fixed in within few days)


Did you try Ring? (https://ring.cx).

Ring is comparable to Tox, but it has much less bugs.

Full disclosure: Ring dev here. I can answer questions.

Keep in mind that some of the platforms you have listed here are not decentralized. When using a fully decentralized system like ring, you must be willing to compromise on some functionality.


Never heard of ring, looks very interesting!

Questions:

1. Who is developing Ring? Is there a company behind the software? Who are the people?

2. Is it really truly P2P? Does it require servers or known supernodes? If so, what guarantees that those are up? (E.g.: Skype used to be somewhat P2P until MS changed that, and banned old clients from logging in - is that scenario possible?)

3. What is the UI framework based on? (i.e. is it another Electron app?)

4. Bittorent Bleep looked promising, until it was suddenly no more. How are you going to keep Ring afloat? What's going to ensure it's there in 5, 10 years? (As much as I don't like Skype, everyone I need to (video)chat with has been there for 15 years)

Thank you!


1. Ring is a GNU project (see https://www.gnu.org/manual/blurbs.html#ring).

It is mainly developed by Savoir-faire Linux. A free software consulting company based in Montreal: https://savoirfairelinux.com

2. It is fully decentralized. OpenDHT is the backbone of the network. Calls are made using the sip protocol and are initialized with ICE (https://en.wikipedia.org/wiki/Interactive_Connectivity_Estab...).

Some situations require extra nodes: - If ICE can't open a connection with: ip-to-ip, UPNP, udp hole punching, it will revert to using a TUN/STUN server hosted by Savoir-faire Linux. Note that you can configure your own TURN/STUN server in the Ring settings.

- The first time that Ring connects to the network, it needs a "bootstrap server". A bootstrap server isn't really a super node, it is just a "know active node". Every DHT-supporting bittorrent client supports this. Note that you can point ring to another bootstrap server in the settings.

- Ring uses an optional blockchain (ethereum) based service to register usernames. This isn't part of all ring nodes by default. It has to be installed separately and then you must point your ring client to it. You can chose not to use usernames if you want and call people with their full RingID instead.

3. We have several clients, all of them use native frameworks. - GNU/Linux: GTK - Android: native android libraries - Mac: native mac libraries - Windows UWP: native UWP libraries - Windows win32: native win32 libraries - IOS: native ios libraries

4. Ring (sflphone) was released in 2004. At first, it was a SIP softphone app. It only became decentralized a few years ago. However, the app still supports SIP.

The development has been generously funded by Savoir-faire Linux since 2004 and there is no plan to stop. Savoir-faire Linux has taken every step to ensure that Ring remains free. Joining the GNU project, (2016) was one of these steps: - https://lists.gnu.org/archive/html/info-gnu/2016-11/msg00001...


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.


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...


Signal on Android(app)/Debian(desktop) always syncs for me within a few seconds, and both my connection and DNS suck.


Some general notes (I don't have recommendation). Many people see those options as not something to build on, but rather use. I.e. there aren't many p2p encrypted communication frameworks, and they especially don't solve anonymity + discovery well. Also, I think not enough developers care about making it really easy to self-host (i.e. bust NAT and serve from home) with read mirroring. Myself and I'm sure a gazillion others have side projects trying to tackle these things. You just have to wait until one catches on :-)


Here's your solution, 181 pages worth of it:

https://grothoff.org/christian/habil.pdf

Bonus: Briar could run on GNUnet, which would speed up interest in secushare development, which currently occurs at a... well, unexciting rate.

Also, I wish Briar would implement double ratcheting WITH metadata encryption. At the moment, it has no double ratcheting, but because the transport layer works differently this seems less concerning as they use good crypto algorithms, but it poses an issue to secure interdevice message sync. I only point the 'WITH metadata encryption' part out because SignalProtocol[!] lacks it.

A point against both Briar and Signal: I can't specify my preferred encryption method and parameters.


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?


The issue becomes very difficult when you need to preserve message history reliably and allow account usage across devices. Because key management becomes tricky and clunky and there's no easy UX ways around it.

For ephemeral messaging like a SnapChat type use case, you can EASILY provide p2p encrypted. For services like Telegram and FacebookMessenger, their feature list requires cross device syncing, historical archiving, and those features don't play well with rotating keys, perfect forward secrecy, and other e2e encrypted messaging techniques.


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.


> The situation is still pathetic. What do you recommend?

XMPP/Jabber + OTR


Yea I second that, and have been doing this combination for years. For the client programs:

  Pidgin with OTR - Linux/Windows
  Adium with OTR - Mac
  ChatSecure/ZOM - iOS/Android
Used on top of some XMPP service underneath such as Cisco Jabber.


On that matter: Can anybody recommend XMPP clients that support GSSAPI/SASL/Kerberos user authentication?

I'd really love to implement thorough self hosted SSO infrastructure that authenticates against a crypto token (Yubikey, Nitrokey, GPG smartcard). Doing this for e-mail and SSH logins is straightforward (BT;DT). And the Prosody documentation is promising with that respect, so the server side should be doable as well. But on the XMPP client side all I can find are some maillist posts where people supposedly got it working with Pidgin, but no howtos or similar to be found.

One thing that I also want to implement is kerberized OAuth and OpenID; however there are only very few services where you can actually log in with something other than Google, Twitter or Facebook – StackExchange used to offer login via custom OpenID, but they removed that a few years ago.


XMPP + OMEMO. Cross-platform, multiple client, works fine.


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)


I wouldn't call three of those p2p and one of them doesn't even deserve the description "encrypted".

The probably is that the proper p2p encrypted messaging tools have a UI that either absolutely sucks or they have other, similar problems. Problems you have when you can't afford a UI/UX designer.


I think part of your question is, why does every p2p app not work on all platforms equally well. This is true of pretty much 90% of apps and software - they don't work on all platforms equally well. This is because of conscious design and business decisions taken by the builders.


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.


https://liberapay.com/matrixdotorg/

https://www.patreon.com/matrixdotorg


>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.


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 apologize I misspelled it, I mean "around" not "Android".


…then I retract my comment. Thanks for clarifying.


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


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.


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)


Today I learned - thanks!


Two words: Key Management

And of course nobody wants to pay for it. Also we need to aim higher than just p2p messaging. Shameless plug. http://firestr.com


I use Wire (wire.com). It's good with a few downsides:

- Cannot send things to yourself.

- Sometimes buggy with video calls

- I would love a bit more customization client side, like being able to have a more compact interface on the desktop


Briar seems to be an interesting p2p encrypted chat and forum system.


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!


Lack of efficient fully homomorphic encryption -- as soon as we crack that, we can start injecting ads into encrypted messages and it will be profitable enough to make not suck.


I use Signal every day as my primary IM client. I haven't had any real problems except the occasional having to reset my keys.


How about running the Telegram or WhatsApp mobile apps on your desktop using an Android virtualization layer (e.g. BlueStacks)?


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.


Startups like PreVeil are trying to address this with servers that don't have access to your data.


Try https://forsta.io


I use JMP.chat which is basically XMPP + OMEMO + a phone number.


We are building a p2p decentralized application that uses WebRTC for real time chat, video, etc

You can try it at www.stealthy.im. Would love your feedback!

Also, we have a super secure version called "Snowden Mode" for the privacy enthusiasts!


Looks neat - like it checks a lot of boxes I am looking for. Does not seem to tell me of I can host all the code on my own servers or if this is a kind of closed source saas thing you are trying to make happen. It may answer "does it have perfect forward privacy" with some of the terms I am not familiar with, or not, not sure.


Thanks Steve, the underlying auth/storage technology is open source: https://github.com/blockstack.

We are planning to open source our code in due time.

One of the cool aspects of our tool is there are no servers involved. Everything runs client side and the lookups are done with de-centralized zonefiles on the blockchain.


Cool app!

had some bugs logging in, will try again in a bit.

Would like to chat with you about collaborations :)


Thanks SpaceLab, please reach out to us at support@stealthy.im

Also, let us know about the login bugs, we are looking to constantly improve the tool :)


mainframe is attacking this issue https://mainframe.com/


What about RetroShare? I realize the software can feel a bit janky at times, but I've heard many good things about its p2p privacy features.


Wire is pretty lit, e2e on all devices.


For noobs like the OP Http://crypto.cat is something to look at. (XMMP/OMEMO for idiots.)


Because networking is difficult with a lot of unknowns, P2P is a resource hog with many security issues, and encryption in itself is a beast.

A lot of the video game studios would love to use P2P instead of having to invest in infrastructure that cost money. Destiny is a example why they shouldn't. Destiny P2P system shows on average that anything over 5 users causes major lag in data transfer. Users home networks are equip for handling data coming to them, but not for data being pushed out. Same thing for cell phones they are design for small burst of data going out not constant data being uploaded. P2P is to much a resource hog when it becomes a time sensitive data transfer.

The other problem Destiny prove to be a issue with P2P is a small security issue with ddosing. You beating someone in a video game well a instant ddos and bam lag spikes. Lag spike in a P2P system are murder because they are instantly felt by all.

Another unknown issue with networking is routing you never know how or where your packets are being sent. If one user packets are for some reason being routed through Uganda then every user might have to send the same package 3 or 4 times each time till it reaches them. You would be surprise how many packet drops happen between isp and networks. This is even a bigger issue with P2P because a packet drop is multiple by the amount of users.

And finally we get to the fun world of encryption. It is fun because it is simple to say all the terms that make it sound encrypted and secure but it is a iceberg of hell and dog poop. Creating secure channels while creating encrypted message while insuring that the end party are a trusted end users while ensuring all the algorithms used are up to date and solid is horribly boring and tedious. Did you know that if you compress something then encrypted then you just broke your encryption? That is because compression algorithm has a repeating pattern that makes it easier to break encryption. It is little things like that and more why you need a whole security team of red and blue team when you ever use the word encrypted.

Also to the other problem you eluded to cross platform. Making anything cross platform is it's own major heart break issue. When you toss in phones as well (I run in corner screaming and crying thinking about it). You might say something like java can handle it all, but it doesn't. You still need to test everything over and over again. Every computer can be running a different version of the Java virtual machine each having its own different bugs. Then you get to the realm of cell phones on top of creating a desktop app, and I would just walk away. I would charge someone billions to handle that kind of dev work.

The situation isn't pathetic it is a iceberg problem. The amount of complex problems that come with creating a stable P2P cross platform encrypted solution that is easy for end user to use, and doesn't compromise in certain areas would cost millions of dollars upfront to build.


Y'all not using Digital Note? (XDN) Been incredible for me.


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 tried arch linux one.


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.


AFAIK Telegram for OSX does support secret chats: https://macos.telegram.org/ I don't know about the other platforms


Which platform? I only use Mac for a GUI OS and that has secret chats for Telegram.


Try Peerio.


Isn't there a client by John McAfee?


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: