Element One – All of Matrix, WhatsApp, Signal and Telegram in one place
element.io
element.io
As a Signal user, I kind of don't want this to take off. I like knowing that when I message someone on Signal, it's for their eyes only. It feels like this service starts fragmenting some of the privacy guarantees of the bridged providers.
Pidgin is good (I also miss the ancient Trillian, even though it was closed source), but limited to a local device.
There are XMPP Transports as well for these (see https://git.eta.st/eta/whatsxmpp , https://gitlab.com/nicocool84/spectrum2_signald , but sadly https://spectrum.im/ is surprisingly finicky to set up.)
EDIT: for encryption fans, I've been wondering for a long time now: why would you trust ANY 3rd party with your so sensitive data instead of running your own service? Are you not aware of OMEMO for XMPP? (See https://omemo.top/ )
Obviously still a long way off actual secure communication though.
What's the difference between Element offering these bridges, people deploying their own bridges or others having 3rd party clients that you can't trust with your E2E encryption?
yeahh. thats not exactly a meme but i am personally facing these same state sponsored actions read here https://thekashmirwalla.com/not-pegasus-kashmiris-are-worrie...
The sad reality is that things are complex and you probably get suboptimal results trying to do everything yourself, what other spend their lives trying to accomplish the same.
WhatsApp scaled to 1B users with only 50 engineers, but there were 50 people working full time to provide what people think they can provide in their spare time?
Also as the other end of any communication is quite scaring thinking I am communicating securely with someone, but then finding out that their server is compromised because of an out of date library or service.
Server getting compromised - that's largely unimportant with end-to-end encryption through OMEMO. Distros also apply security patches (just keep things up to date).
You do not require 50 engineers to run a chat server for <200 of your friends. In my experience, once you have the software configured and running - it pretty much runs itself.
Here's a guide on how to install everything needed onto a raspberry pi: https://samhobbs.co.uk/2016/09/installing-prosody-instant-me...
As with anything else, it's a fun learning experience and something new to try.
If you use a 3rd party, it can be compromised and you only find out when it is too late.
The disadvantage of having your server at your home is that you don't know if it's compromised from day one. I may never even find out and just fool myself the entire time.
there is a news by arstechnica that updates by cisco who deny the same but these curbs were imposed and i personally suffered so i am not sure if "have their computers taken without it causing a huge problem for everyone from your mom to heads of state is a bit naive"... even a big company like cisco must bow down and bend rules to a dictatorial country like india.
we ran our own XMPP server for over 10 years using the "off the record" plugin for end to end encryption. Development seem to basically stop on open chat clients a few years ago and everything started getting crufty. (I see Pidgin dev has apparently picked back up again to some extent, as has Adium, to a much lesser extent).
"off the record" mostly worked ok, between Pidgin users, but failed with other clients.
A couple of OMEMO plugins came along but making them work (and keeping them working) was a continual drain - and we're only a small team with only 2 operating systems (Linux and OSX)!
My hunch is that enough people just moved to things like Whatsapp and Slack etc that developers were no longer using chat clients they could hack on. People stopped being able to scratch their itches.
Not to mention lack of any/decent XMPP client support for syncing histories between multiple clients, or handling inline images and things. All that modern stuff people expect.
Things like Mattersmost tried to fit in here but we just didn't get along with them.
Eventually Element/Matrix matured enough and while it was far from perfect, it worked and we sadly finally gave up on XMPP.
All of these work fine with OMEMO (the iOS ones gained better OMEMO and push support in the past few months) and message history retrieval between clients. Gajim doesn't do inline images, but the rest do.
I occasionally use profanity as a console client and that recently had message archive support land in Git.
So, yeah, no idea what you mean by developers giving up - if anything, the ecosystem has greatly improved (minus group OMEMO on iOS).
Oh, and Dino got support for doing encrypted calls to Conversations a few months ago: https://fosstodon.org/@dino/106228549009869402
There are a few options yet for XMPP clients, I have some hope for the ecosystem...!
siskin.im has support for OMEMO encrypted group chat
Even just for OMEMO support, we all had to compile a plugin for libpurple/Pidgin, and it didn't even have full UI support so was very difficult to use when things didn't work automatically.
We used a gajim but iirc, to get OMEMO support we had to compile that too.
But I'm truly glad to hear the ecosystem has improved - I would have much preferred to have stuck with XMPP. But in 2019/2020, Matrix offered all this and more and worked very well. It was impossible to make the case for us to stay on XMPP.
https://www.reddit.com/r/privacy/comments/nkyzdw/what_is_the...
Everyone else, if they don't migrate to a secure and preferred method, I just use email (with pgp if possible) and call it good.
> forced onto FB’s WhatsApp
The annoying thing is is that WA became the standard for communications when they were not owned by FB and had a privacy focus. This is why I have no qualms abut trying to cheat out of their horrible system.
Because trust is not a binary value and I don't have the time to do literally everything myself
OMEMO nor XMPP provide trusted transport.
Perhaps the point you are reaching for is that encryption and transport should be different parties. The message should be encrypted before you hand it to the Western Union agent. After that, the decision between Western Union, Union Pacific, or Pony Express hinges on other concerns.
Because end to end encryption means you don't have to trust a third party? The channel goes out of the equation, at least with reference to the content of your messages. Metadata is definitely handled differently by different services but that's a question of threat model.
Then don't. I have none of those things save for IRC. I get all my work done and live a full life.
As someone who used trillian, you should recognize that you're likely to need to follow someone to a new trendy messaging service within a few years, regardless of an aggregator taking off.
> These bridges are actually just an intermediate step. Since Matrix itself is an amazing chat network, eventually as more people start using bridges on Matrix, they’ll notice that their friends are already on Matrix, eliminating the need for bridges gradually over time.
> I really believe that the world will be a better place when everyone is in the Matrix. Matrix is the non-proliferation treaty of chat.
https://medium.com/@ericmigi/the-universal-communication-bus...
What you know is that unless their device is compromised, it is up to them to decide who can read the messages that you send to them.
Thus the situation with the bridge is not in reality different from the situation now.
I.e. the bridge is a vulnerability that enables man in the middle attacks.
Bridges don't install themselves in place of platform's messengers - it's the user that has to make an active choice to use one. If you don't trust your partner making a right choice for both of you, you can't really trust them not to tattle on your conversation, or get their computer compromised by generic system-wide malware.
And if the bridges themselves are shoddy? Well, I kind of blame the platforms like Signal and WhatsApp, for forcibly bundling their messaging service and their chat client. Were they to open up their APIs to alternative frontends, they could make it so that those alternative frontends identify themselves to the other party in the conversation, and it would remove the need to develop fully transparent bridges for legitimate use.
it is literally a step back towards the centralized unencrypted messenger model
say what you will about the centralized e2e model, but you can't argue that the previous situation was better.
worse:
> currently bridged conversations are not stored end-to-end encrypted in Matrix (they will be in the future)
suggests some kind of re-encryption for storage which appears to resolve the issue but does literally nothing to solve the problem. if the bridges have your keys and can decrypt your messages, you're exposing yourself to attacks on the bridges themselves.
Not even close. I can evaluate the likelyhood of my partner being compromised. I can’t evaluate the likelyhood of a gateway I may not even know about being compromised.
The introduction of these gateways makes the entire system less trustworthy.
Honestly I can’t see how Matrix/Element can stand behind this in good conscience. It is strictly a harm to the goal of enabling private communications. I literally found myself thinking it was a joke when I read it, and I no longer think matrix/element are serious.
Why? It is your partner that is deciding to use what is essentially a Signal client installed on a remote server controlled by Element. If it is true that you are able to estimate this likelihood for your partner, this fact should already have been accounted for in the calculation.
So yes, Element have introduced a new fact that downgrades everyone’s estimate.
It's never not been true since Signal is just a protocol which you can use programatically. It's certainly not been true at least since signald became a thing. And Element is not the first one to come out with such an offering (see e.g. Beeper).
It's just better known now.
It was always possible to build nuclear bombs. It was just ‘better known’ after they were dropped on Japan.
And in this case “better known” is what is being criticized. It’s one thing for someone who understands how to do so to build their own proxy and take their own risks.
It’s another thing entirely to make a consumer product that does this and normalize the practice.
That hadn’t been done before by anyone credible.
whataboutism for sure but i uphold the view that the expectation of privacy from smartphone based internet chat should be very low for tech-literate people.
Although, to be fair, all of those things are far more difficult than using Element One, so there's an argument to be made about reasonable expectations and the actual likelihood of your messages being private...
edit:https://www.huaweicentral.com/new-whatsapp-report-feature-wi...
If they were going to look at all your messages, of course, waiting until the end user gets it is somewhat unnecessary, they could just get them straight from the sender since they're both "E's" in the e2e. But that's true of any messaging client. Unless you're inspecting the code and building your own binaries, you either have to choose to trust what they're saying or not (or I guess just don't care if it's not relevant to you). But again, that's not WhatsApp specific.
If you want to avoid your E2EE conversations on Signal or WhatsApp being relayed via a service like Element One (because you’re an activist or whatever), then your options are to not bridge at all, or run a bridge yourself. Clientside bridging may be an option in future, but reliably running a bridge in the background on mobile is somewhere between non-trivial and impossible.
Finally, we are currently crunching on getting E2EE to work nicely between the bridges and the Matrix clients (so bridged conversations are stored E2EE on the Element One server) and it should be coming in the coming weeks. It’s worth noting again that even when that lands the bridge will still necessarily be able to see bridged conversations at the point of bridging.
TL;DR: if you don’t trust Element with your Signal conversations for whatever reason, don’t hook up Signal to your Element One account :)
Can't you just pass the encrypted message further without decrypting it? Of course, there needs to be the same decryption mechanism on both sides, but it doesn't make it impossible.
Then there's the issue of syncing those messages between Element One clients which means the client now has to re-encrypt the messages and send them back to the server. And if the client is responsible for fetching messages then providing push notifications will be very difficult.
So if you can actually decouple polling/listening for messages from decryption then it would probably be possible.
A brute force approach would be to provide an open source, self-hostable server but can be configured from the centralized Element One service. This server would hold the actual service tokens & decryption keys and would just be sending re-encrypted messages back to Element/Matrix.
The server/bridge is not opensource? I see their github account has lots of code.
Sure, I can go around and tell everyone I know that they shouldn't bridge Signal to Element One because <cryptonerd rant>, but there's no way for me to tell that my advice has been followed. Previously, the chances that someone had set up such a bridge were small, but by nature of making these things accessible, Element One also increases the risk of my conversations being (benevolently?) MITM'd.
I think it's a great offering, but I share GP's reticence about a system that puts what used to be zero-knowledge conversations in plaintext on a third-party server...all without me realizing.
This sounds like a made-up concern.
How do you stop me from screenshotting your convo and posting on twitter, or just copying and pasting from one app to the next?
My concern is about giving messages in an automatic fashion to a third party, which I'm completely unaware of and have no way of making an informed decision about. The third party could be breached (they run an online service, which is much, much easier to attack than some dude's iPhone).
An Element bridge is just a Signal client hosted on Element's infrastructure. Them using an Element bridge is no different than them using an extra device you didn't know about. That device could've well been insecure, or shared by many people, or hosted in the cloud. If you care about this, you should ask.
In the end it isn't a huge deal, as most conversations are extremely innocuous, and those I care about I'll take the time to verify. But after all the trouble to proselytize Signal, I get nervous about large public projects that could, in my opinion, strictly reduce the security of my secure messaging system.
Yes, I totally agree that this would be a huge hassle. But what's your proposed alternative? Reaching out to every programmer in the world and convincing them to never write any software that can act as a Signal client? Or pushing for legal prohibition on any non-Signal developers creating software that can act as a Signal client?
Doesn't mean I'm in favor of such ridiculous things as you've suggested here.
Well, you can always switch to Matrix and have democratized and secure native messaging which uses a cryptographic protocol comparable to Signal. ;)
Also, obligatory xkcd: https://imgs.xkcd.com/comics/standards.png
I've been through the pain of convincing people to Signal due to lack of better alternatives at the time. And I've done it yet again for Matrix. In this case, each move brought us closer to a global optimum so I'm not sorry for it.
It is different in a big way. That extra device would most likely only transit this one user's messages. The Element bridge transits a ton of users and as such is an attractive target for mass surveillance.
> That device could've well been [..] hosted in the cloud.
The capability of self-hosting is very niche. Only technical people could pull that off. Element is working hard to make using this bridge so easy that your grandmother could do it.
Look, I'm not up in arms or anything, I just can immediately see a drawback to bridging Signal specifically. There exist many other services (Telegram, Slack, Discord, the list goes on) that can be bridged to Matrix without compromising the security posture in any terrificly meaningful way, IMO. So the idea is great in principle.
Perhaps in some sense, yes, but in precisely the same sense that you reduce the security of your messages each time you send a new message, or each time you start a conversation with a new person, or each time any of your contacts reads a message on the train where someone might be looking over their shoulder. None of these things strike me as a meaningful reduction in security, at least in the threat models that are appropriate for most average people (namely where you don't expect to be personally targeted by an attacker with resources).
How about because I'm a regular person, and I don't want everything I say analyzed by the federal government and stored in perpetuity? I'm increasingly repulsed by this notion that unless I'm doing something illegal or in opposition the the ruling party, encryption is just a luxury. Encryption is for anyone with any desire to express themselves honestly without modifying their behavior because someone is watching.
People flock to Signal for a reason and a lot of them will use this "bridge" without understanding what they're giving up. You're doing more harm that good to try to usher people towards your platform.
Why would you go to a walled garden if you want more freedom/control? You should just go to Matrix and host it yourself (and keep all the metadata to yourself, too!).
If you don't want to self-host, then you must be comfortable extending trust to someone. SaaS Matrix and Signal seem to be two sides of the same coin, in that case.
> I'm increasingly repulsed by this notion that unless I'm doing something illegal or in opposition the the ruling party, encryption is just a luxury.
Making encryption and privacy a common thing is important to maintain the anonymity of those who have something to hide for various reasons. It's the same as law enforcement using dubious methods: We don't object because we're criminal, we object because we're not (i.e. and don't want to risk false charges).
Sure, but this doesn't actually introduce a new party in the middle of two Signal clients. Someone has to just decide to authorize a Signal client running on a server somewhere to receive messages from you and forward them onward outside of Signal.
AFAIU GP’s point was that even if I don’t bridge, the recipient of the message might, thereby diluting the trust all users have in E2E on Signal, since you can’t know who’s bridging and who isn’t.
I fail to see anything that Element is doing "wrong" here, the issues you are describing are issues between you and your conversation partner
Also, AFAIK it wouldn't be trivial to extract all the Signal chat histories from an iPhone device - this new service makes that much, much easier (not least because they'd be remotely accessible).
The bridge itself serves a specific purpose (opening up Signal to the Matrix API, allowing for the use of a single app), and succeeds at that. Of course there's a trade-off, and the team (at least allegedly) appears to be working on encrypted bridges so that even if the bridge decrypts from Signal, it re-encrypts on the homeserver at rest in a way that only the user (not the bridge) can decrypt in the future.
I think the complaint here is "you advertised a service doing a thing that was already possible, people might use this." I may be mis-characterizing that, but I think it's worth stepping back and thinking a bit more on the actual threat model you face, and how the proposed product (Element One) somehow subverts that. Sure it can do so at scale, but that just means this is one incremental improvement that needs more work, not that the idea needs to be thrown out entirely.
Disclaimers and warnings are not universal solutions to questions on ethics since they are not certain to be read or understood and will have some failure %. If the residual negative effects are likely to exceed the kinds of outcomes a company's core values can tolerate, then making those states unrepresentable by abandoning product ideas is sane.
Furthermore, this is not the first time privacy issues with Matrix have been brought up to you and dismissed without understanding.
I am going to begin recommending that people actively avoid adopting Matrix/Element.
The libremonde research is over 2 years old now, and the valid bits of it were addressed at the time (https://matrix.org/blog/2019/09/27/privacy-improvements-in-s...)
Every single one of them has a configuration, despite a selfhosted instance, that phones home to centralized servers run by your for-profit company.
I'm not sure if this systemic problem is in your config files, your documentation, your defaults, your js client, or what. It's a failing of some part (or multiple parts) of the process.
Ahh. Seems like an easier problem to fix then. Doesn't Element Android remove that assumption and let you choose?
Quick question, is the code for the bridge opensource?
I didn't dive into it, but can you also self-host this? Looking forward to some docker-compose snippets in that case :)
Element One uses a modified mautrix-whatsapp, which means that your phone needs to be connected to the internet for the bridge to work - so you can't quite throw it off your phone. I don't have to regularly open the app or anything, though.
But as far as I know, signal wants to be walled garden. So then it is expected that people create work arounds.
That's not how it works at all. E2E encryption only guarantees that your message is securely delivered to the other party, not that the other party can't do as they please with it. Signal messages are still stored in plain text on the end devices. They can still be backed up to the cloud (when I used Signal, all my chats were). Hell, photos/screenshots can still be taken of the app. If you want total security, you have to trust the delivery AND the end user. Bridging doesn't really change any of that.
So you should have an encrypted message that you hand to Signal. Signal encrypts it again and hands it to the bridge. Eventually, whether at the bridge or at the other end or wherever, something decrypts the Signal message. Then the person you are communicating with applies the final decryption outside of Signal, Matrix, or whatever.
If this sounds terribly inconvenient to you, perhaps privacy is not as important as you claim. Security and convenience are almost always in conflict.
One of the founders of WhatsApp donated $50M to Signal [1] out of regret for how WhatsApp shifted away from privacy after being acquired by Facebook.
The entire project is freely visible to anyone on github [2]. They've made it so even if you don't trust their servers, you can set up your own server and clone your own android/ios app, change some settings and have everything hosted yourself.
There's no reason not to expect Signal to maintain the focus on privacy that they've put in thus far.
[0] https://www.signal.org/ [1] https://www.wired.com/story/signal-foundation-whatsapp-brian... [2] https://github.com/signalapp
If your life depended on it, you would be foolish to depend solely on Signal.
How nice it is that encryption has emerged from the dark corners of life and death to become a fashion accessory. But for those that still exist in the world beyond fashion, your criticism seems naive.
> Security and convenience are almost always in conflict
I think this is less true than people tend to think. See e.g. Signal/WhatApp rolling out relatively seamless E2EE to billions of people -- that was hard to imagine just a few decades ago!
It does seem like since both Signal and Matrix are open source, including the servers, that there should be a path to let one a Signal user know if they are sending it to a Matrix bridge and the encryption is no more.
Also worth noting is that you do need to trust the person on the other end for Signal to have a chance at working, e.g. they can take screenshots or real camera pictures of the messages. So establishing trust with the recipient is rule #1, and this should go for if they are using a Matrix bridge with Element One too.
> All integrations were implemented in-house using the Texts Platform SDK. The SDK will be open sourced at a later date.
Seems like a big nope.
> Messages, contacts, auth credentials, account information never touch Texts servers.
> Your messages are sent directly to the messaging platforms.
> All end-to-end encryption is preserved when the platform supports it.
> Texts is a client and works like the official app.
Apparently all the code runs on the user's device.
There is no guarantee of privacy with communication between two consumer smartphones. Encrypted Signal-to-Signal messages have always been susceptible to capture on either end, by something like this bridge or a rogue (or non-rogue) app on either end with access to read device notifications.
I'm not saying that this service doesn't expose your messages to some additional risk, and should be used cautiously. But it is an illusion that just because the messaging protocol is using end-to-end encryption that the messages can't be intercepted.
It was called Pidgin[0], and it never got particularly big.
I see the same thing here. While it's interesting, I'm failing to see what the use case is. What's the niche that needs this solved in a big way?
I'm unclear if it supports relay mode, but if so, you can invite Matrix, Signal, and WhatsApp users into the same group chat! [1] Edit: Relay mode is not currently supported in Element One, I tried it out. I contacted support and they said "we will discuss this internally and possibly enabled it later"
I've been using this on my self-hosted version of the bridge and it does wonders for those friends who are on Signal but don't want to try another app.
Also, a lot of people just don't want to swap between apps for direct messaging people on different services. This means you can use any Matrix compatible app [2] to chat with anyone on Matrix/WhatsApp/Signal/Telegram.
[1]: https://github.com/mautrix/docs/blob/master/bridges/python/s...
The main difference between this and Pidgin seems to be that you pay a monthly fee for someone to man-in-the-middle all your communications.
But no, they want to prevent people from talking with each other via other platforms because "we're best" or whatever.
If you have FB, and I have Twitter, and we can chat, why would I ever make a FB profile or you a Twitter profile?
The mutual exclusivity is the competitive advantage. All these companies are competing with one another for your eyes. It wouldn't make sense for them to give that up for no return value.
I get that they want their "network effect" and keep it to themselves, but this is no good for users and the industry doesn't "regulate itself" as we've heard so many times, so time for law makers to step up finally.
A law like this could regulate businesses out of existence.
Which websites fall under it? Only social? What about forums, etc. What if the companies just rebase to non-US jurisdictions? Even if you make this law, it's unlikely it would actually compel anyone to comply.
Only if they didn't change their business model to something less incredibly antisocial than walling people in and serving them ads.
There are many ways to operate a communications business on-line. That only the bad one is used in practice is a consequence of it being the most profitable of available options. If it weren't available (say, because of being regulated away), companies would pick the next most profitable one.
The key part is having regulations apply the rules evenly so everyone prices it into their decisions. Trying to limit specific companies makes that feedback cycle less effective.
More generally, my view of regulation is that it should only exist if there is some quantifiable harm to an involuntary third party (negative externality). Where is the demonstrative harm here, and who is it impacting? Having one friend on FB and another on MySpace, requiring the user to log into each platform separately isn't harm. The effect is the same as having one friend call you on a phone to communicate and the other only use text.
Every single person using these platforms makes a conscious decision to use them given their limitations. Nobody is forcing anyone to use these platforms. The government still runs a post office. You could use that to communicate with people if you wanted.
Instead of passing legislation to fix your problem, how about you just talk to your friends and get them to agree on using a single platform?
But it isn't. We know it isn't - exchanging text, audio and video messages wasn't invented by adtech giants. Two prime examples:
1) Telephony and mobile telephony operators have strong businesses to this day, despite being made interoperable by law.
2) Non-adtech e-mail providers exist and make money, despite being interoperable and not subsidized by advertising and personal data misuse.
> Where is the demonstrative harm here, and who is it impacting? Having one friend on FB and another on MySpace, requiring the user to log into each platform separately isn't harm.
In my opinion, there is harm - creating unnecessary burden and confusion for everyone, especially non-tech-savvy people. It is tying people down to services via network effects, and then further harming them by exfiltrating their personal data and exposing them to advertising (either directly or indirectly, making the ads more potent thanks to aforementioned personal information).
> The effect is the same as having one friend call you on a phone to communicate and the other only use text.
No, it isn't. It's just having one friend text you, another friend write you a Messenger message, yet another a WhatsApp message, yet another a Telegram message...
> Every single person using these platforms makes a conscious decision to use them given their limitations. Nobody is forcing anyone to use these platforms.
But that's not true at all. People are coerced to use these services, and coerced to stay with them. That's the literal definition of network effect. I have to use WhatsApp/Facebook/whatever because my mom is there and doesn't want yet another chat app, and my local plumber only communicates through it. I have to stay, because neither my mom nor my plumber will move. The more people are trapped in the net, the stronger its hold.
Contrast that with phone and e-mail service: I can communicate with anyone regardless of the provider they use. I don't even need to know what provider they use. And I can switch my providers at any time, and nobody else has to know, or care.
> Instead of passing legislation to fix your problem, how about you just talk to your friends and get them to agree on using a single platform?
These platforms are as successful as they are exactly because your proposed solution is impossible to implement by most people. Again: network effect.
The rest of your comment is true though. Keeping these bridges up 24/7 is quite a bit of work. Most people (even technical ones) probably won’t bother with that.
I know because I've used the bridge.
[1] https://github.com/mautrix/whatsapp [2] https://docs.mau.fi/bridges/go/whatsapp/authentication.html
When you take away the motivation to mitm all of the users' chats, there's nothing left.
I've used all-in-one messengers before. They come and go like the wind. You'll be downloading a shiny new all-in-one messenger periodically anyway.
Just trading one kind of inconvenience for another.
And still, periodically changing an all-in-one messenger is still better than keeping and changing half a dozen messengers.
--
[0] - Whatever is the most appropriate webdev word of the day.
Once again, the problem is not technical, it's political. Until interoperability is enforced by government, I expect companies to keep building their siloes. Network effect and tragic commons and all that.
[1] https://www.miranda-ng.org/en/ [2] https://github.com/miranda-ng/miranda-ng
All Matrix homeservers and bridges are open source. I self host some of them myself. Have been doing that long before Element One was a thing.
My problem with the self-hosted model is that I don't trust myself to get it right and/or keep it updated. My problem with the 3rd-party model is that I don't trust them, either. So, lacking trust in either myself or the third-party, I'm just one of those people you can get only via secure e-mail, clear-text SMS, or whatever well-supported encrypted service happens to be the one with a plurality of users in my friend/family group. Clear-text sucks, but it can be used to negotiate a secure channel.
Unfortunately, the levels of spam in my traditional telephony services have dramatically increased in recent years, and as a tradeoff, I've just gotten harder and harder to get in touch with directly as I increasingly default to ignoring more and more methods of communication. I don't even think I'm someone with anything to hide or anything to fear my communications being in the public, there's just too much information to manage.
Blockchain-based solutions like Status.im appear to do away with these sorts of issues through decentralization -- but you still have to put trust into their network.
Solutions like TLS & OMEMO over Tor for XMPP seem to be a very strong privacy-centered solution outside of blockchain-based applications.
For all you know, someone else on the server is a high-value target for somebody, and if they compromise the server to get their comms, they may not be very picky about what happens to the private communications of everyone else on that server.
It was not a not a service which was always on and synced between units.
It was a client you had to run on your machine and keep connected. And it obviously didn’t roam.
Pretty much an apples to oranges comparison.
Matrix and Element aims to bring all those things you mention to a single protocol, to which you can connect any client you like, on any device you like, and roam as you like with all your clients always in sync.
It’s what Pidgin used to deliver, levelled up and connected to the “modern” (read: closed) IM-silos the majority of people are using.
It’s definitely different and it’s definitely interesting.
See e.g. Slack, which propelled itself to success by offering an IRC transport, which prevented strong opposition for technically inclined people, and then promptly killing it when they became a major player in the office IM space.
The only thing I can think of is people who do not wish to have the app installed for privacy / open source reasons.
- Not tech-savvy and easily confused by keeping 6 different messengers around.
- People for whom multiple clients becomes a cognitive burden.
- Waste of storage space, memory and CPU power that those (hugely bloated, most of the time) clients incur, especially on mobile devices.
- People like me, with diminished executive functioning capacity, who are fucking tired of bad ergonomics of all those clients together and each individually, and who'd prefer a single, consistent, ergonomic and powerful UI to manage the torrent of messages they receive.
Storage space might be an issue on very low end phones but these days phones are starting with 128gb of storage which no IM app is close to filling. Mobile OSs are extremely good at sleeping apps and can receive messages while the app is not running at all using notification services. I would say that resource bloat is actually much more of an issue on desktop where you have 10 instances of chrome running and none can be closed while still receiving notifications.
All my friends have since moved to Discord now which is way nicer than any other user experience.
These days I think that most services try to make money with stuff that was built decades ago already, and they're just keeping the reinventing cycle spinning.
Anyone remember the franz app [1] ...which finally led to the hardfork of ferdi? [2] I feel that element one is franz all over again.
I used Pidgin a lot. I always found it very convenient to have everything in one place and UI. Better one client than MSN + AOL + ICQ + IRC + Yahoo! + XMPP.
In the last few years I haven't used it much, but that's because it just doesn't support the popular messaging apps of the day (or maybe it now does, I haven't checked in a while).
Also, as others have pointed out, Pidgin is not and never has been a "service", it's just a library (libpurple) that implements various protocols, with Pidgin as the GUI (they also make Finch, a TUI).
No need to pretend that what the previous comment was saying is some kind of conspiracy when it's obvious that business gonna business.
Since then encryption made things a lot harder; specifically, E2E encryption. You can't "just" login to a server and send messages, you need to encrypt and decrypt things on the device with the right keys, and how do you handle things like message history WhatsApp and Signal solve this for the desktop/web versions by designating your phone as the only device that can connect to their service, and everything else communicates via that phone. Telegram solves it by having regular chats not be E2E encrypted, and having a special "secret chat" feature for it.
[0] https://latenightlinux.com/late-night-linux-extra-episode-32...
There's no reason for standardization and interoperability not to be forced on these companies.
When you sent a physical letter you have to follow some standards on the envelope addresses, when you make a phone call to the other side of the world people can still hear your voice, same for sms, same for email, but apparently sending a string of text via internet in a standard protocol is an unsolvable problem.
For example, I was able to communicate using OTR on vk.com (russian facebook clone). Probably other niche messaging plugins work with OTR too (it's just plaintext messages, after all).
Real Scotsmen used bitlbee and irssi to enable their IRC addiction, long after everyone else had moved on to harder stuff.
:)
The use case is simple: instead of using plethora of IM apps, have all your conversations in one place.
Brief history: when Hangouts was going away and Google Chat coming in, I pitched Matrix to my friends as a better alternative that didn't require unique phone numbers, awkward desktop limitations, and a better federated future. We stuck with Google Chat because inertia and networks suck that way.
I revisited the instance I had setup and got the mautrix-googlechat bridge working. It's pretty nice but one friend lamented that he did not have the technical skills to self-host such a thing. And here comes this announcement! Sadly, there is a major hurdle: neither Google Chat nor SMS/GVoice are listed here and those are the major protocols that my social group uses.
At the same time, my social group is conservative in adopting new core technologies and wary of cloud lock-in for critical roles (Google being both an unfortunate anchor and precipitator of that). I'm not sure adding those protocols would tip the balance.
I'm just yelling here to take my money, but nobody answers.
I don't think I want to sacrifice the security for having all my chats in one place.
If they can fix that I might reconsider.
They already reverse engineered the Whatsapp protocol. I see little reason why it can't live in the client? I don't really follow why they move the bridge to the homeserver.
Indeed then very weird why I should trust them more with my personal data than anybody else.
All bridges, and the matrix homeserver itself have been open source and self-hostable for years. I host a homeserver + some bridges myself.
This is just the sugar-coated SaaS for people who dont want to do it themselves.
It is! https://matrix.org/bridges/
* Encrypted with a private key which Google have access to.
I wonder if you can get them via one of those data access requests?
Matrix bridges are rather complex. They rely on a combination of private APIs (WhatsApp), Chrome extension scraping (LINE), bots (Telegram), mobile clients (Android SMS), and jailbroken iPhones (iMessage).
Given that puppeteering should be indistinguishable from real application usage and that $5/month/user should be more than enough to diversify IP addresses, I suspect the model can actually be sustainable in the long term.
Because Whatsapp crushes any client other than their official client. Everyone else is confined to scraping Whatsapp Web.
Element, on the other hand, is MITM by design.
And on top of that Google or Apple or whoever you "trust" with your mobile operating system of choice.
Speaking of mobile OS, Element will likely run fine on mobile Linux whereas you can be sure Whatsapp will never release a Linux client
I don't know about others but it's not that much of a pain point for me, and I'm using all of the apps they mention - WhatsApp, Signal, Telegram as well as few others like IRC and Discord.
These bridges can be amazing if you want to have a chatbot, or a support desk that can put all their conversations in one place, etc, but to replace the mainstream apps it is too much of a tall order. At the moment the mobile clients have so many bugs that makes it hard even for me to go when offering support for my "customers", which at this point is just the couple dozen friends and family that I managed to rope into it. They don't even have feature parity with any of the competitors, so for end-users it's just easier to switch apps on their phone depending on who they want to talk and their will have a better experience doing so.
I still use and support Matrix, but their clients still need to improve a lot if they ever hope to reach mainstream. I am focused now on another project [1], but when/if I ever get to work back on communick, I will pivot away from end-users and into SMB.
[1] https://hub20.io
As one data point, I probably would pay $5 a month just for that. Combining that with all the other Matrix goodness is a bonus.
Purely on the content of the article: Given that the messages are not stored encrypted locally and that this service is connected to the US, I do not see how it can be viable for the privacy-conscious.
It's very likely based on https://github.com/spantaleev/matrix-docker-ansible-deploy
Matrix chats (direct and group) are E2E by default. There is no bridge that will let you keep E2E encryption between Signal/WhatsApp and another service - it has to be broken somewhere. I believe Element is a UK company.
The blog post on This Week In Matrix states it uses modified versions of the open source (and self hostable) Mautrix bridges which are primarily built by tulir [2] of Beeper [3]: https://matrix.org/blog/category/this-week-in-matrix#element...
> However, in addition to being a fast, snappy Matrix account, it also comes with unlimited personal bridging to Whatsapp, Signal and Telegram thanks to mautrix-whatsapp/signal/telegram!
So UK, French and US.
Yes, but it doesn't have to be stored plain on a completely untrusted (because again, the company touches the US - that is an ideologically privacy-hostile space) server. This makes data collection much easier, including data collection of data in the past (as opposed to only communication from a certain point in time, as with an ongoing tap of the machine itself).
> The blog post on This Week In Matrix
Thank you :)
I haven't tried the WhatsApp bridge yet because it needs to go through my phone or an Android VM. WhatsApp recently announced support for using WhatsApp Web without the need to have your phone online, but I don't think it's available for everyone yet.
Even if we disregard that, I can honestly say that I don't think using four separate apps is a problem. I don't even think using ten different apps is a problem, because it's mostly transparent to the user anyway. You get (configurable) notifications from all of them when you need to care about something, and the "sharing" feature on both iOS and Android these days is normally smart enough to figure out who, or at least which app, you want to share something to -- so for me this "multi app confusion" is already pretty well solved on an OS level, at least on mobile.
And yes, I can understand that for some people the inability to easily transfer and collect those conversations is a problem, but for many people (imo probably more people) the ephemeral nature of these messages is a feature, not a problem to be solved. At least that’s why I use Signal over Messenger, for example.
I have this problem; most Android apps send background notifications via Google's Firebase Cloud Messaging instead of rolling their own services. (Signal is an exception to this.)
So, if you're unwilling to use Google Play services (or us an OS which doesn't support it), you're fucked and will not receive background notifications. The primary reason I use bridges with Matrix is not to unify my messaging experience into one app, it's to get notifications on my phone.
I don't know about WhatsApp, but at least Telegram and Threema can fallback to polling if push notifications aren't available. With polling there is of course the trade off between battery usage and message delay, but you shouldn't miss any messages.
I think "on average more willing to sacrifice privacy over ease of use" is probably a reasonable description of me. I'm not a fan at all of FB though, I have absolutely no trust in them at all. As such, I tried to get my world moved from WhatsApp to Signal. Inevitably I didn't succeed completely (although more than I expected) but now I'm split between those two. Plus I have some people who only communicate via FB messenger, and a few friends on Discord.
To message someone I first have to remember which platform they prefer and then find it in my folder of chat apps. It's not an insurmountable problem obviously, but it does add friction. If I can have that all in one place, cross-platform with a decent UX then that's definitely worth $5 a month to me, plus all the bonuses:
* I am actually moving in a more privacy focused direction. Yes I understand the caveats with bridges, but being on Matrix means that I can start a (slow) process of moving my interactions onto it * I don't have to worry about backing up my Signal messages (which is a pain to have automatically sync 'offsite' from your phone) * I can use it as my IRC client (with message history hanging around), etc.
Let me put it another way - I've wanted to be on Matrix for a while but haven't quite managed it. I like the decentralised philosophy, both from a technical perspective and a privacy one but every time I've signed up it hasn't been worth it and/or it's too painful. This gets it over the hump for me (if it's as promised).
1. Yes - In this context I prefer convenience over impractical/unrealized encryption. (Not privacy - I find Whatsapp, which hinges on my personal private phone number, far less "private", than other traditional messenger apps which I can sign up for anonymously; and for my use cases it's not a realized encryption, as people I talk to have no concept of security and I should assume anything I send to them has been scrubbed by malware and any other apps they've intentionally installed and agreed to).
2. Dozen apps are annoying impractical and I darn tooting well do Not have their notifications enabled. I'll agree that Android sharing is awesome; my experience with iPhone sharing has been Far more limited.
3. Whatsapp is darn near impossible to effectively use multi-device. If this will let me chat to my in-laws (who are stuck on Whatsapp not for any privacy or encryption reasons but because "everybody uses it") from comfort of my computers and keyboards, reliably, then this is a shut up & take my money proposition.
3a. Anybody about to comment "But whatsapp works on computers", see my other replies:)
> It’s also worth noting that end-to-end encryption is necessarily broken as messages to (and from) WhatsApp, Signal and Telegram pass across the bridge(s).
They store everything encrypted but this may open the door for legal requests to get access.
The benefit to hosting by a company is it should be more reliable.
You can always run bots, but that's not a real bridge like what is being described here.
[1]: https://github.com/mautrix/signal [2]: https://gitlab.com/signald/signald
Their terms of service [1] clearly state:
> You must not (or assist others to) directly, indirectly, through automated or other means, access, use [..] our Services in impermissible or unauthorized manners [...] including that you must not directly or through automated means: [...]
> (g) sell, resell, rent, or charge for our Services or data obtained from us or our Services in an unauthorized manner;
> (h) distribute or make our Services available over a network where they could be used by multiple devices at the same time, except as authorized through tools we have expressly provided via our Services;
> (i) create software or APIs that function substantially the same as our Services and offer them for use by third parties in an unauthorized manner
It's brilliant actually. The more I think about it, the more that Matrix bridges seem like a perfect NSA tool. It's a man-in-the-middle attack of grand proportions, hidden in plain sight.
> To connect your WhatsApp account, scan the QR code below: > Open WhatsApp on your mobile device. > Go to "Linked devices" > Press "Link a device". > Scan the code below.
Would pay money to get rid of Facebook software in my devices.
I use Matrix and it is certainly a good thing and the connections to other stuff like IRC, too. The fix is getting rid of WhatsApp. Signal is fine, the non-native desktop applications (i.e. fat and ugly Electron with Chrome behind) needs a rewrite with Gtk and Qt.
One of these is not like the others:
Telegram both provides a library to bootstrap alternative clients and prior to that they also sponsored a competition to create a second semi official Telegram client for Android, Telegram X.
So I guess Telegram won't be a big problem.
But of course, saying something bad about Telegram, true or not, feels pretty safe here.
Telegram at least seems to have pretty decent libraries available to communicate with their API. I don't know how often it breaks, but I've been using the "tg" CLI Telegram client in the last week, and it seems to work fairly well (better than their own web interface anyway).
I looked a bit at writing my own as I have some issues with the tg UI; I haven't written the code yet but just looked at the options, and overall it seems fairly decent.
I use their client api to build cool stuff for my userbot all the time, i have great respect for telegram and matrix.
Signal and Whatsapp are more apt when considering walled gardens, not telegram.
For me, Whatsapp is used by my non-technical in-laws for the simple reason of "because everybody uses it". I find whatsapp extremely impractical (I communicate better via large ergonomic keyboard on my computer, vs via 1.5"-wide screen; to each their own), so anything that makes Whatsapp and other proliferation of incompatible annoying chat services easier... yes, yes, please yes :)
Current app uses Phone as primary and allows for one other-non-phone-device. If you try to log in on e.g. your tablet and computer, or switch between them often, you'll hit any amount of trouble and will get locked out of account.
The current beta has enhancements for multi-device support which may support several non-phone-devices at the same time, even if your phone is offline for short period of time. But it's buggy and your Phone is still your primary and it still won't allow you to sign up without one (it assumes Phone is Me and my life centers around my phone, which is true for my in-laws but not for me:), and the list of limitations is sky high and likely to remain that way.
Whatsapp fundamentally prioritizes end to end encryption; primacy of phone; and convenience of contacts for privacy-non-conscious, over everything else. It is good for those who highly value end to end encryption, for reasons of need or principles.
For those who need multi-device support, Whatsapp is way way way worse than other chat services of today or 1990s. Right now, I am logged in to Hangouts on three computers, tablet, phone and Galaxy Note (whatever we call that these days:). I am available via Hangouts whatever I do and wherever I am. And frankly I find it more private as it doesn't advertise my existence to all my contacts and siphon them off, doesn't require my phone number which is one of my most private pieces of identifying information, and provides me actual privacy and anonymity if I choose, but that's a whole other discussion.
Whatsapp does not, and will for foreseeable future not support my use case. It may or may not be rare, it may or may not be something anybody else thinks is important, but Phone is not the centre of my existence or my sole & preferred method of communication, and as such whatsapp is completely unusable for me. I may be 1% or 0.00001%, and I'm open about that, but this whole notion of "Whatsapp totally works on multi-device" is just getting tiring to misspell - it's right on their FAQ that it is counter-indicated by design by current production version.
Of course the new 'multi-device' beta might improve the situation but that's not leveraged yet.
Isn’t Hangouts dead?
I would pay/donate just for them to improve the clients, regardless of this "Element One" service. It's an extremely important project.
Element Home pricing might be better for you if you have a few friends who are also interested ($10/month for 5 users), and won't use bridges [2].
[1]: https://matrix.org/blog/category/this-week-in-matrix#element...
Lower the stakes and the expectations. Even if she is starting conversations with you on any other app, you can still start the conversations on Element. There will be bugs and quirks she will find, you just offer help and ask her for patience.
With time, they get used to the app and will be okay with starting the conversation with you there.
That's what I did with my wife, my parents, closer family and friends. Then you get one day like the recent Facebook outage, and they will come to you to ask if you can help their friends to sign up to it.
Slow and steady is the way I found to run this race. I already managed to get rid of WhatsApp and Messenger on my phone, it's only telegram for the odd group chat that is still resisting a full change.
The plan I'm on pre-dates "Element Home" and sits at the same price-point.
Unfortunately a side-effect of the split is that I can't use the new bridging product without moving back to a shared domain, and the billing model for bridges on custom domains really doesn't work for consumers, at $0.50 per month per person who talks to you.
The newer products are good upgrades for someone on the regular matrix.org server, but not so good for people who already upgraded :P.
This is also making a bet that the inconvenience of juggling these 3 particular messengers is worth $5 a month.
IMO the real value in Matrix bridging that's been neglected (and has been mentioned elsewhere in these comments) is connecting different messengers _to each other_. Being able to connect friends/family scattered across different, otherwise-isolated protocols with a single "just works" tool is a much clearer value proposition than what feels like just another multi-protocol client.
Alas, getting that kind of multi-connectivity is tricky...as is VoIP bridging, which this doesn't support either, but should be considered as crucial for any Matrix bridge.
I don't doubt Matrix/Element will get there at some point, but for now this feels a tad premature.
It shouldn't even be a service. It should be a local app that knows how to be a client for all those things. Just a unified inbox.
Not for people who find two messaging apps too much to have on a phone, or for people who’re talking about privacy.
The thing I don’t have centralized is search, and too often some critical piece of information — which in the past would have been sent and later found by email — is buried in an IM from two years ago. If Element One’s search tools are up to scratch that could be killer. Support for Instagram DMs would be a must too.
Dare I say it, support for email too? I’ve often wondered what that would look like, especially with buffering so that I can send a few messages and have them batched into one email. Most emails these days begin with one round of “Dear X, … All the best Y” but quickly become one liners, trying to get something done.
so much for the federation.
And there's no way to get help about it; none of the folk who run it are active in the #libera-matrix channel, and the libera.chat folks themselves don't have any knowledge of it because it's entirely maintained by EMS.
People who use matrix.org as their homeserver reported no problems with it when I asked, but at least one other person using their own homeserver said it was broken in the same way for them too.
"Infinitely better experience" my ass.
i looked into using something like this or setting up my own synapse+bridges and ultimately thought the synapse server had way too much in the way of complexity and attack surface for something that would ultimately end up being a consolidation of all my encrypted messaging. (it was also a bit weird to see public internet protocols using grpc, but i guess that's what people do now)
that's the world we live in i guess. you either dedicate a bunch of time to watching your own infra, let tech giants read your messages or let hackers read your messages.
this is fine.
Yes, for bridged chats. Matrix <-> Matrix direct & group chats are E2E by default.
> but your account identity/login information as well
Yes, however identity/login does not permit access to E2E messages (and cross signing prevents E2E compromise [1]). Matrix supports migrating accounts to other servers [2] while keeping your data/social graph (depending on your history viewability settings I believe, someone please correct me if I'm wrong!).
[1]: https://matrix.org/blog/2020/05/06/cross-signing-and-end-to-...
Yes, there are public Bitlbee servers out there, but these are for an emergency.
Why can't you install the service on your own phone, and have all your stuff talk to it?
All messaging apps have their own native features, some have E2E encryption etc. Not sure if there's a common subset that is enjoyable enough to use that it's worth it.
That being said, I do wonder what will be the "Facebook Events" (invite all your friends to an event) equivalent in the future when everyone is in a closed garden chat platform instead of Facebook.
I'm also on macOS but I've been using Texts[1] for a few months and it has been a great experience.
If you want to give it a try, this is what I used: https://github.com/spantaleev/matrix-docker-ansible-deploy
Hope I could go with Conduit at some point.