Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
berty
Berty is a secure peer-to-peer messaging app that works with or without internet access, cellular data or trust in the network
-
-
-
Signal-Server
Server supporting the Signal Private Messenger applications on Android, Desktop, and iOS
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Widely used? No. I've found Session to be a decent alternative however it's still early development which entails some scuff and details as to how they intend for it to be financially supported long term aren't clear.
https://getsession.org/
TLDR on Session is that it's a fork of Signal (effectively same front end, key scheme, encryption scheme, etc) with a modified transport/delivery and notification system and without the phone-number-as-an-identifier caveat that signal has.
Note: Sorry for the wall of text below.
As for what that modified transport layer is, it's routing all the messaging and data hosting over Oxen (https://oxen.io/) which is a cryptocurrency that serves as a decentralised short term / small size addressable data store and an onion router for those messages/data. As much as cryptocurrency=bad in a lot of cases, here it kinda makes sense as it's just an automated digital marketplace for data hosting and bandwidth with tooling wrapped around it to support privacy and anonymity preserving tools without relying on some hopefully benevolent dictator to run it.
As for who's backing it, same group that develops the Oxen, an Australian non-profit focused on privacy tech and bearing the same name (Oxen Privacy Tech Foundation). While Oxen is pay for use (messaging and all that has an on chain cost), it looks like the foundation is covering the costs of running Session for the foreseeable future. Given the nature of the project, it should eventually be possible for users to pay their own infra costs however that doesn't seem to be implemented yet.
It's pretty easy to use.
1. Install via F-droid or download from the web.
2. Basic cryptocurrency wallet style setup where your account is based on a randomly generated "recovery seed" phrase (string of words with equal bits of randomness as the private key which can be used to rebuild the private key on a new device).
3. Then you can share your "Session ID" which is basically just your public key or you can pay for a custom username which is addressed to your public key (you can set names for contacts after adding them so the username is mostly for ease of discoverability).
4. After that it's basically just Signal but where you can make and throw away accounts at the drop of a hat.
My main complaints are
1. that it's a bit slow on delivery
2. The onion routing half of decentralised storage + routing is still being implemented for Session as the project is very much WIP at this stage.
----
My takeaway is that provided it can stick around, Session has potential to shore up where Signal falls short. Give it a year or two in the oven and I might recommend it as a daily driver for messaging.
Likewise for the OPTF and their goals in general. It looks like once Session is "fully implemented" they are looking at trying to expand the approach to a discord/slack/matrix competitor as well which could be interesting. As far as I can tell they are just a bunch of privacy nerds with a little bit of a cryptocurrency lean to them but they are doing good work.
Widely used? No. I've found Session to be a decent alternative however it's still early development which entails some scuff and details as to how they intend for it to be financially supported long term aren't clear.
https://getsession.org/
TLDR on Session is that it's a fork of Signal (effectively same front end, key scheme, encryption scheme, etc) with a modified transport/delivery and notification system and without the phone-number-as-an-identifier caveat that signal has.
Note: Sorry for the wall of text below.
As for what that modified transport layer is, it's routing all the messaging and data hosting over Oxen (https://oxen.io/) which is a cryptocurrency that serves as a decentralised short term / small size addressable data store and an onion router for those messages/data. As much as cryptocurrency=bad in a lot of cases, here it kinda makes sense as it's just an automated digital marketplace for data hosting and bandwidth with tooling wrapped around it to support privacy and anonymity preserving tools without relying on some hopefully benevolent dictator to run it.
As for who's backing it, same group that develops the Oxen, an Australian non-profit focused on privacy tech and bearing the same name (Oxen Privacy Tech Foundation). While Oxen is pay for use (messaging and all that has an on chain cost), it looks like the foundation is covering the costs of running Session for the foreseeable future. Given the nature of the project, it should eventually be possible for users to pay their own infra costs however that doesn't seem to be implemented yet.
It's pretty easy to use.
1. Install via F-droid or download from the web.
2. Basic cryptocurrency wallet style setup where your account is based on a randomly generated "recovery seed" phrase (string of words with equal bits of randomness as the private key which can be used to rebuild the private key on a new device).
3. Then you can share your "Session ID" which is basically just your public key or you can pay for a custom username which is addressed to your public key (you can set names for contacts after adding them so the username is mostly for ease of discoverability).
4. After that it's basically just Signal but where you can make and throw away accounts at the drop of a hat.
My main complaints are
1. that it's a bit slow on delivery
2. The onion routing half of decentralised storage + routing is still being implemented for Session as the project is very much WIP at this stage.
----
My takeaway is that provided it can stick around, Session has potential to shore up where Signal falls short. Give it a year or two in the oven and I might recommend it as a daily driver for messaging.
Likewise for the OPTF and their goals in general. It looks like once Session is "fully implemented" they are looking at trying to expand the approach to a discord/slack/matrix competitor as well which could be interesting. As far as I can tell they are just a bunch of privacy nerds with a little bit of a cryptocurrency lean to them but they are doing good work.
Yep, it's definitely been frustrating in the past. The number of iOS Element bugs was overwhelming at times too. It's a lot more stable now, but the bubble layout still isn't the default - I think that's what most people expect from a personal messenger. I'm looking forward to seeing what the Rust rewrite [1] brings for performance/stability.
FluffyChat also has quite nice UX and a bubble layout by default, but threads are still a while off [2]. On iOS it worked flawlessly through the iOS 16 betas while Element had some show stopping bugs, a couple of my friends moved over if they were on the beta.
I haven't had any friends ask me about the verify session buttons. I don't see any prompts on latest iOS Element but it's still too prominent on Element desktop for my liking.
SchildiChat [3] is my daily driver and feels more friendly than Element on desktop (unified DMs & group chats, no verify UX, chat bubbles), but it doesn't have any update mechanism built in, so I'm wary to recommend it to non-technical friends. It was also my goto recommendation on Android before the Element redesign.
I'm confident the ecosystem is moving in the right direction though, and so thankful for the amount of choice.
[1]: https://github.com/vector-im/element-x-ios
Your "major problems" are fair, but nothing's perfect, so unless you have a better solution with the same design constraints (e.g. https://github.com/signalapp/Signal-Android/blob/main/CONTRI...), they are rather moot, because they're not actionable. That being said:
> - it is not that private after all since it requires a phone number. Yes, you can override this by using some virtual throwaway number if you are geeky enough but your account will be associated with this phone number anyways.
You still leak very little because of their sealed sender feature. If you allow arbitrary usernames, in practice you start from an even less trustworthy environment (if I receive a message from @barack_obama for the first time, I have no clue if it's actually someone I know, while a message from @+1235312 indicates that the sender at least had access to this number at some point to register). All solutions have tradeoffs.
> - as a consequence you _will_ receive spam from bots fanning out messages to phone numbers.
There's very little spam now on Signal (I think I've had 2 spam messages in about 4 years). At one point there was a bit, but server-side measures are now preventing that.
You can't really have no spam at all as long as you have a common id that's shared among your contacts, which is the case most of the time for usability, as any of these contacts can leak this id somehow.
> - Signal protocol is probably great from the e2ee perspective but it is not federated and unlike XMPP you cannot spin up your own server and have full control over it.
Signal's approach is that you shouldn't care about the server. Why do you?
> And I am sure you cannot run an end-to-end audit of the whole Signal platform to verify that what they actually run has been built from the source code you have audited.
You can do that on the client code, which is reproducible, and again mostly what you should care about.
> - Since it is centralized, Signal is prone to censorship in those countries that decide to fight it.
I'd say that their reliance on phone numbers is the main issue with censorship: if new users can't receive their registration text message, they cannot register.
AFAICT people in censored countries still rely on WhatsApp, Signal and similar messengers instead of more niche but more decentralized alternatives like Tox. Again, however bad their current approach might be, it's a moot point until there's something that works better in practice.
They might not compromise on encryption, but they have no intentions of open sourcing their censorship module either: https://github.com/signalapp/Signal-Server/blob/90490c9c8485...
I suppose people should decide for themselves if they take the word of a centralized service. Convenience is a factor after all.
For those that have small circles of friends they wish to chat with and minimize the number of ISP's their traffic traverses, I would suggest tinkering around with uMurmur [1] There are pre-built packages in several operating systems package managers. The configuration is dirt simple [2] and the daemon is very light weight, designed to run on home routers. Use certbot to generate LE certs or just use self-signed. One TCP and one UDP port must be forwarded to the daemon, default port being 64738. One can set a server-wide password to keep strangers off of it, or set passwords per-channel.
uMurmur is not E2EE but if it is running on your own router and you are talking with your friends that you know and trust then maybe that is less of an issue. The mobile client is Mumla. Just put in the IP or hostname of the uMurmur instance.
[1] - https://github.com/umurmur/umurmur
[2] - https://github.com/umurmur/umurmur/wiki/Configuration