Hacker News new | past | comments | ask | show | jobs | submit login
Element One – All of Matrix, WhatsApp, Signal and Telegram in one place (element.io)
530 points by mcjiggerlog 41 days ago | hide | past | favorite | 403 comments



> 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). The bridge(s) operates in Element’s trusted EMS environment, with no content scanning or datamining, but currently bridged conversations are not stored end-to-end encrypted in Matrix (they will be in the future).

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.


I want this to take off. I'm tired of having to follow trends because people suddenly think there's a new shinyshinytrendy thing around: IRC to ICQ to MSN to Skype to Google Talk to Facebook Messenger to Whatsapp to Signal.

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


> why would you trust ANY 3rd party with your so sensitive data

Because trust is not a binary value and I don't have the time to do literally everything myself


I'd go further -- absent pressure, there is never any reason to trust anyone. The more pressure one faves, the more one has to trust people.


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

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.


For the past two years; I've been using Conversations (Android), Dino (Linux), and friends of mine have been using Gajim (Windows), Monal/Siskin (iOS).

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


Maybe not developers in general, but development of Pidgin certainly stalled, which is why I stopped using it. Too man features not implrmnted in XMPP and no working support for e.g. Skype.


I didn't say developers "gave up", but even as of 2019 it didn't seem like things were moving forward in any meaningful way.

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.


I use Conversations and Dino daily, they're awesome. When I'm stuck on MacOS or iOS I use BeagleIM and ChatSecure, though Monal looks a little more slick...maybe I should try that.

There are a few options yet for XMPP clients, I have some hope for the ecosystem...!


I think Monal can't do encrypted group chat yet.


> minus group OMEMO on iOS

siskin.im has support for OMEMO encrypted group chat


I don’t run my own service for the same reason I don’t build my own car or I don’t do accounting for my company, I don’t have the time to learn how to do it nor doing it.


No, this is not the same. You want the utmost privacy, yet you still decide to trust someone over it.


I don't want "the utmost privacy". I want something better than raw SMS. I'm not an international secret agent. I encrypt things out of principal more than because I really care if some government force reads them. If a nation-state decides I'm of interest to them for malicious reasons, I'm probably screwed either way.


Then these bridges are fine. Virtually everything is better than raw SMS.


But Signal is better than Signal over these bridges, and it's easy too. Just because you don't want to run your own service doesn't mean you have to choose a poor option over a pretty good one.


But not everyone I talk to is on Signal. And I don't want to remember which app to open to message a certain person.

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?


Nothing makes that better, you're right. I prefer to just remember who uses what and act accordingly, but you choose convenience instead — and both are reasonable choices.


That depends a lot. In a civilized country with low risk of 2G downgrade attacks and sensible telecom laws/law enforcement restrictions, SMS is a lot more secure and private than many other options.

Obviously still a long way off actual secure communication though.


remember that xkcd https://xkcd.com/538/

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


Yeah, infosec has its limits. But if you’re gonna challenge the state, it does help keep things quiet until you are numerous and armed.


I recently had my internet snapped last month and I did not want reddit to know "last 90 days IP access log" so I had a dormant account and I wrote a post locally, called a friend living overseas and made him login to that dormant account and I dictated the text.


I also want utmost security for my money, which is why I put it in a bank rather than holding the cash myself.


And you want utmost security for your body, which is why you go to the doctor instead of self threat. And also doctors go to other doctors when they are ill.

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.


If you've ever used Docker or deployed an nginx server - then you can very easily deploy a chat server. Pretty much the same thing but over a different protocol.

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.


You're right, it isn't the same. Instructions on how to build a car don't change every week. As a hobbiest I wouldn't trust my life on getting in a car if that was a requirement. There's more in my life than that single hobby that I need to do and I only have so much time.


The threat model is vastly different, though.


That is the kind of comment that freaks me out on HACKER news.


Not everybody hacks on everything. Many of us pick and choose our hobbies. I don't sysadmin my phone for the same reason.


Why? Specialization is a thing. Not everyone specializes in security. Which let's be real, being an expert in security is really difficult, especially since it's a constantly moving goal post. Unless you're an expert it's probably not a good idea to roll your own.


Also, to run your own service you must specialize in security AND devops. The two thing overlaps a bit, but not 100%. And you must hope that every contact you are talking to has the same knowledge.


so much this - you can make a service 100% secure - by shutting it down. But if you want to stay online and be secure at the same time, there's always some resource tradeoff between the two


If you know a problem is hard and the consequences for doing it wrong are potentially serious, it would be irrational to not consider selecting a well-managed third party solution. Being a hacker doesn't mean being all-knowing and the best hacks are done with the knowledge of human limits (both of the hacker and of the maker of the system being hacked).


Encryption fan here, bridging is one more avenue for failure, is why I won't buy in. Security is about odds, and nothing is 100% safe. I'm pretty sure signal is way better than anything I could come up with, so I choose it.


Maybe it’s not for you but more for those of us forced onto FB’s WhatsApp and their phone book scanning/uploading by social conventions. This presents a way out without giving up the benefits.


Doesn't grapheneos allow some type of sandboxing to wall off your true contacts, etc. for exactly this purpose?

https://www.reddit.com/r/privacy/comments/nkyzdw/what_is_the...


Shelter can be used for this purpose if desired.

https://github.com/PeterCxy/Shelter


I believe Insular can do this as well. I prefer Insular since it allows me to open the app directly and more quicker.


Thanks!


You know people that have the FB app installed. And all their messages and SMS running through the FB app. And you can't get all of them to stop this madness.


Maybe. I probably don't relate well because I talk to maybe 10ish people regularly.

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
Just don't install it. I've never used it. People ask why, I answer that I do not accept the spying in their terms of service. Far more people are sympathetic to that line than you might expect.


If you live in the Netherlands and have young kids in school this really isn't option. It's how kids' parties are arranged, sports schedules are communicated, parents are kept informed about school. And then it is also often the most convenient way to contact any help desk.

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.


> I'm tired of having to follow trends because people suddenly think there's a new shinyshinytrendy thing around: IRC to ICQ to MSN to Skype to Google Talk to Facebook Messenger to Whatsapp to Signal.

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.


> why would you trust ANY 3rd party with your so sensitive data instead of running your own service?

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.


I wrote a bridge between signald and prosody (without spectrum) so I can use xmpp clients with signal. Async python, only non-standard library dependency is slixmpp. It's working well.


I've seen your project! Congrats, it is very nice. I stopped fiddling with transports because signald doesn't compile/run on freebsd (some of the java libs behind it rely on native libs which have problems compiling), and for now I've put it aside.



Huh. I wasn't aware of this. I tried for quite a long time to compile it myself a while ago and failed, I'll give it another go, thank you!


Eric Migicovsky, Pebble founder who now runs https://www.beeper.com/:

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


I dont have a PhD in crypography and am not sure I will do a good enough job in covering even potential mid-level vulnerabilities. I still care about privacy and so use Signal.


The point of encryption in the first place is to allow an untrusted transport. If you trust the transport, you don't need encryption.

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.


Trillian was awesome! It's just a shell of its former self now.


Because your own service is not an alternative if you actually need to secure-message others because of the line of work you're in, or the regime you're under. The idea that "just do it yourself" is more secure than a company that can't just be walked into and have their computers taken without it causing a huge problem for everyone from your mom to heads of state is a bit naive.


The advantage of having your servers at home is that when the police shows up with a search warrent you know you can't trust that server anymore.

If you use a 3rd party, it can be compromised and you only find out when it is too late.


I'm pretty sure my server at home is less secure since I'm not a professional security expert. I can recognize that I'm dumb and going to make a lot of mistakes.

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.


what about when cisco or "someone" helped india government impose censorship on aroun 8 million people so that they cannot use a vpn or access only whitelisted websites? https://theprint.in/india/us-firm-helps-jk-build-firewall-to... https://tech.hindustantimes.com/tech/news/this-us-firm-is-re...

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.


Not sure if it's still around, but bitlbee for a long time provided an IRC gateway for almost every chat protocol around at the time (including following Twitter feeds, and Google/Facebook chat via xmpp when they still supported it)


> I'm tired of having to follow trends

Then don't. I have none of those things save for IRC. I get all my work done and live a full life.


I remember when I first installed Trillian around 2000, it was so cool!


You don't know that when you message someone on Signal it's for their eyes only.

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.


No - the bridge could be compromised without your conversation partner’s involvement.

I.e. the bridge is a vulnerability that enables man in the middle attacks.


From your POV, the threat model is equivalent to your partner being compromised themselves, and reporting your conversation to criminals/terrorists/law enforcement/intelligence agencies/boogeyman du jour.

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.


> From your POV, the threat model is equivalent to your partner being compromised themselves, and reporting your conversation to criminals/terrorists/law enforcement/intelligence agencies/boogeyman du jour.

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.


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

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.


This is only true now that Element have introduced this compromised way to access signal.

So yes, Element have introduced a new fact that downgrades everyone’s estimate.


> This is only true now that Element have introduced this compromised way to access signal.

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.


That makes as much sense as saying nuclear war was as likely before the Manhattan project as afterwards.

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.


this is extremely not true. federal authorities can compel the bridge operators to log messages sent over the bridges and disclose them on receipt of a national security letter or other sealed warrant. this is just not the case right now - messages sent between parties on signal cannot be intercepted. that the communication endpoints are vulnerable is and remains true but this creates a new vulnerability in the interlink.

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.


the threat model is not the same, there is an additional vector. it's not hard to see how a bridging service provides a single point of compromise and is a high value target compared to a million independent endpoints

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.


Your conversation partner's device could also be compromised remotely.


Yes, but that’s in no way comparable to a centralized server where potentially millions of conversations can be compromised at the same time.


like google and apples notification systems? or the state of whatsapp backups encryption?

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.


Well, not entirely true, because sginal has sent random images out to wrong contacts before.


Exactly - someone could be running a (the?) third-party Signal client, or they could be intercepting the Google push notifications that Signal sends using one of those Play Services compatibility layers, or they could do one of the low-tech things of showing their device with your messages on it to someone else in-person.

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


The messages are encrypted end to end so compromising push notifications doesn't get you anything. That's the problem with this bridge, it adds a new server with access to the unencrypted messages.


come on. can we just drop this end to end encrypted bs on whatsapp atleast ? when you report a message, you allow admins to see the last 3-4 messages. if only you and your receipent is supposed to see the messages, "e2e", how can an admin see them?

edit:https://www.huaweicentral.com/new-whatsapp-report-feature-wi...


While I can't vouch for WhatsApp's implementation of course, the capability could easily maintain e2e encryption by just forwarding those 5 messages directly to WhatsApp admins. E2E just means it gets to your recipient without being exposed on the way. It doesn't mean they can't take and then re-distribute it to others.


That is a slippery slope. Are you SURE WhatsApp doesn't auto forward all communications to itself AFTER the users read them? That too silently so you have no way of knowing


As I said, I'm not vouching for WhatsApp's implementation. What I'm saying is that having the ability to report messages does not mean they're not doing e2e exactly like they say. It doesn't provide any information on that point.

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.


In theory, signal could work with matrix people to support bridging with e2e encryption.

But as far as I know, signal wants to be walled garden. So then it is expected that people create work arounds.


(Element CEO here). Honestly, it depends on your threat profile. Any kind of bridge has to inevitably MITM your conversations in order to work, and we’ve tried to spell that out in all the product info about Element One.

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


That's all well and good, but I believe the original complaint was more concerning the second party in the conversation. There's no way for me, a hypothetical person who wants to keep my Signal messages 100% encrypted in the Signal ecosystem, to opt out of my contacts using an Element bridge.

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.


>There's no way for me, a hypothetical person who wants to keep my Signal messages 100% encrypted in the Signal ecosystem, to opt out of my contacts using an Element bridge.

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?


Those are distinct from my concern. In your scenarios, I have trusted you to keep the conversation secret, and you betrayed that trust.

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


How much do you know about your conversation partner's cyber hygiene? They might leave their phone unlocked at the library or even unknowingly install malware.


All of that is true, and remains true if they're using a bridge service as well. The bridge service is strictly reducing the security of messages.

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.


> The bridge service is strictly reducing the security of messages.

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


The Matrix bridge service is compromised (their infra has been successfully attacked before, and other similar platforms have had catastrophic data breaches as well)? That doesn't require a targeted attack, involves complete history disclosure and probably far more metadata than Signal even stores on their servers.


Just ask your conversation partner?

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.


> Them using an Element bridge is no different than them using an extra device you didn't know about.

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.


I thought I addressed that in my original comment: I _could_ go to each of my contacts and explain why I don't want them to do things like use the cool new Element service with Signal. But 1) I (finally) have a lot of contacts using Signal, so that would be a pain to manage; 2) to me, the entire idea of Signal is that I can pretty much set it and forget it on any relatively-modern smartphone for friends, family, etc. and not have to worry about anything but the biennial phone migration for my mother.

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.


> I _could_ go to each of my contacts and explain why I don't want them to do things like use the cool new Element service with Signal. But 1) I (finally) have a lot of contacts using Signal, so that would be a pain to manage; 2) to me, the entire idea of Signal is that I can pretty much set it and forget it on any relatively-modern smartphone for friends, family, etc. and not have to worry about anything but the biennial phone migration for my mother.

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?


Hahaha of course not. I don't really propose an alternative. I'm just lamenting the situation and trying to provide context to the Element CEO about why the original commenter, and people like him, might not be 100% jazzed about the democratization of technology that, in terms of message _security_, is a step backwards.

Doesn't mean I'm in favor of such ridiculous things as you've suggested here.


> jazzed about the democratization of technology that, in terms of message _security_, is a step backwards.

Well, you can always switch to Matrix and have democratized and secure native messaging which uses a cryptographic protocol comparable to Signal. ;)


Many of us have, and painfully if I might add, finally convinced people to abandon insecure messengers and move to something like Signal. Now the solution is to tell them to abandon Signal in favor of Matrix? I'll pass.

Also, obligatory xkcd: https://imgs.xkcd.com/comics/standards.png


The problem is Signal is not a standard unless they open up their ecosystem, so we're not actually increasing the number of standards here.

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.


> (because you’re an activist or whatever)

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.


> People flock to Signal for a reason

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


People available to communicate with is a key metric of a communications platform. All of these services lack a large number of regular people. For better or for worse, Signal is the one with the most.


If you self-host Matrix, you can still bridge to Signal while avoiding the walled garden trap and having complete control of your data?

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.


Except my messages are E2EE and signal can't read them. This bridge breaks that encryption before it's reached the intended recipient, which if that recipient is me, I very much don't appreciate it.



I very much agree with you.

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


All your comments appear dead to me, I think it's because you're a fresh account and have been shadow banned. Just guessing, I'm not sure about that but I saw similar behavior for another user on a different topic. I vouched because it looks like you're making points in good faith.


Sure, but this defeats the entire point of Signal. You don't use it to get the maximum amount of reach to other contacts, you use it because you're confident that what you send ISN'T being MITMed... that's the entire value of the app! So unfortunately if this takes off, you never know if the reason you're even using the application is just being violated. It destroys the entire purpose. That said, I love Matrix more than Signal and enjoy its E2EE capabilities.... but I also wish this doesn't take off.


It's still a chat app and if I can't reach enough people it's useless.


> You don't use it to get the maximum amount of reach to other contacts, you use it because you're confident that what you send ISN'T being MITMed...

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.


Your cavilier tone here about casually introducing a MiTM threat that many people won't understand to the e2e encrypted messaging ecosystem is pretty disgusting. As others have noted, the issue is that I can't opt out of other people using this which breaks the security guarantees of the chat system.


That's not part of the security guarantee; The message was encrypted from user-controlled end to user-controlled end. It's neither Signal nor Element's fault that your conversation partner has decided to move conversations un-encrypted afterward. That was always allowed.


Signal's core value proposition is radically increasing the expectation that one is having an e2e encrypted conversation. I love Element's product and mission, but a product which explicitly is eroding and complexifying privacy around a 3rd party product which is about privacy seems to be a bad tradeoff, and also stands to undermine the public perception of what Element is all about. I would suggest either carving out the e2e platforms (particularly Signal), or introduce functionality that will ensure conversations had through the bridge inform the counter party that the messages are not e2e encrypted. It's the right thing to do.


> Any kind of bridge has to inevitably MITM your conversations in order to work

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.


At that point it’s basically clientside bridging (or multihead messagering), given having decrypted the message (even if you had the right keys available) you’d need to speak the protocol of the remote service.


It's possible but a lot harder. If the keys/tokens for fetching messages are similar/interlinked to those used to decrypt the messages then you can't separate the two. In this case you would have to do the message 'fetching' and decryption on the client side which would be very difficult for any JS based clients.

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.


> A brute force approach would be to provide an open source, self-hostable server

The server/bridge is not opensource? I see their github account has lots of code.


> or run a bridge yourself

Quick question, is the code for the bridge opensource?


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

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.


That has always been the case no? You can't know what the person you are sending the message to is doing with it, the status of their device, or anything else.

I fail to see anything that Element is doing "wrong" here, the issues you are describing are issues between you and your conversation partner


That is true, but there is a difference between some messages being screenshotted, and a service that acts as a bridge storing all communication that passes through an account. It's a matter of how likely it is that the assumption "my communication is not going to leak beyond the two participants" is broken. Every step in the wrong direction counts, IMO.

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


It seems like you're trying to hold Element to some kind of impossible standard here. It's not like the tech they used to build the bridge didn't already exist.

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.


Companies whose mission is centered on user control and privacy can be held to a higher standard than other companies when it comes to these kinds of questions. It's perfectly reasonable to suggest that Element should have tossed out the idea of supporting Signal for this specific software offering, given the potential for collateral damage in the form of person A using it without person B being aware of this, particularly if person A does not grok that they are compromising person B's communications if they are using it.

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.


because "trust us" has such a great track record.


You misunderstood what he said if that is your TLDR.

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.


Could you expand on the "privacy issues", please? Not sealioning or whatever, I am genuinely interested.


Not sure what exactly they were referring to, but here are some of them: https://github.com/libremonde-org/paper-research-privacy-mat...


sneak’s pet issue is https://github.com/vector-im/element-web/issues/11655: that element web assumes that you want to log into the matrix.org homeserver by default unless you change its config to default to a different one.

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


I've user accounts on 3 different servers, run by 3 different groups.

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.


> element web assumes that you want to log into the matrix.org homeserver

Ahh. Seems like an easier problem to fix then. Doesn't Element Android remove that assumption and let you choose?


I won't use it for signal indeed, for whatsapp though... can't wait to throw it of my phone!!

I didn't dive into it, but can you also self-host this? Looking forward to some docker-compose snippets in that case :)


Here you go: https://docs.mau.fi/bridges/go/whatsapp/setup/docker.html

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.


Hmm, ok, but I could keep it on a spare, empty, old phone at home then perhaps. Still, would have been nice to get rid of it entirely, but I see how that is impossible indeed.


Spare phone method should work, I've barely used whatsapp so I'm not sure if it needs a SIM after setup.


All the bridges (and the matrix server itself of course) are self-hostable.


So then advocate for Signal to fully support third party clients, so that such functionality can be widely supported by multi protocol clients (ala pidgin) rather than needing centralized non-E2E bridges to cope with the administrative overhead of maintaining interoperability.


This reminds me how absurd it is that OSS projects are bridging Matrix, Discord, and IRC. These all have vastly different ToS and forms of encryption and user privacy. By doing this you can be taking an encrypted message on Matrix and implicitly agree to the ToS and reposting their message to something closed-source and with sketchy privacy like Discord, which defeats the purpose on why one would choose Matrix.


I concur. I really wouldn't mind anyone using this for whatsapp as I consider any message I send there is also available to 14-eyes, but bridge usage really should be disclosed to Signal users.


For all you know your Signal contacts are using a CLI client and then forwarding the messages through SMS to their feature phones :^)


If you believe that, then I have a bridge to sell you. :^)


I got so excited for this until I read that, too. I wish there wasn't fragmentation like there is now but MITMing all my comms is definitely not a smart choice if I chose any of the comm systems it bridges based on privacy.


> this service starts fragmenting some of the privacy guarantees

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.


Very good point on not wanting this to take off so that you know if you send it to someone, it is for their eyes only.

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.


There's a difference between malice and ignorance, though. My mom in her 70s is using Signal, and I don't think I can blame her for not realizing the vulnerability. I doubt most people will read the Element webside that carefully.


If privacy mattered that much to you, you wouldn't depend on Signal to encrypt your messages. You would encrypt them before handing them to Signal.

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.


This is a very all or nothing mentality. It's also kind of like saying you should put locks on your locks. Signal's core reason for existing is that it puts a focus on privacy. They say this all over their homepage [0].

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


For most people, privacy is a nice-to-have thing. When it's just nice to have, Signal checks that box.

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.


“Regret”. You don’t sell an app that barely makes money for $19B actually believing its most valuable asset won’t be used. Not like he isn’t currently keeping most of the billions he made from such “blood money” too.


If privacy is truly important to you, then you'll manually encrypt messages in your head using a one-time pad. Can't trust any program you didn't write yourself, including the compiler! /s

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


This is like saying "If you don't sweep the bathroom for bugs/cams, you don't really care about privacy. Why do you bother closing the door"


Your method delivers optimal conversation privacy by ensuring no-one would want to jump through the hoops to talk to you.


You can self-host. I suspect they use this: https://github.com/spantaleev/matrix-docker-ansible-deploy


You can indeed self host (although Element One doesn’t use slavi’s ansible playbooks but instead the Element Matrix Services hosted infra we use to host Mozilla, FOSDEM, HOPE, KDE, GNOME etc)


Come on. E2E encryption is about transmitting the content in transit and in the cloud (if there's a cloud). After people receive your text they can do anything with it.


Been using https://texts.com — they preserve E2E for Signal/WhatsApp.


Um, how do they do that?

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


https://texts.com/privacy says:

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


> I like knowing that when I message someone on Signal, it's for their eyes only.

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.


Back in the day before the rise of Facebook, there was an open source service that combined all the popular messaging protocols - MSN, AoL, IRC, etc.

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?

[0] https://www.pidgin.im/


No, it wasn't a "service" - it was a program. Unlike this thing.

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.


Thank you. Let us not forget what general purpose computing was like.


Following up on this... I was Miranda user. With it I was able to run ICQ, MSN Messenger and other instant messengers with an encrypted layer slapped on top (as long as I was able to talk my friends out of using the official client). Today it's called Miranda NG[1] and it seems alive and kicking[2].

[1] https://www.miranda-ng.org/en/ [2] https://github.com/miranda-ng/miranda-ng


uhoh.wav


> you pay a monthly fee for someone to man-in-the-middle all your communications.

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.


How can I verify you're running unmodified, unhooked source in your server if I'm a user?


You don't, you self-host your own server.

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.


I feel the same way, I don't fully trust hosted solutions but don't completely trust myself to host my own -- which is where E2E encryption comes into play, but a malicious host would still have access to loads of metadata (timestamps, IPs, etc.).

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.


I'm excited about NixOS (/GuixSD) because they would seem to provide a straightforward path to running secure services (self-compiled from publicly reviewable source) while keeping them automatically updated (build rules administered by a third party). I'm not saying this is a good approach for you personally right now, but I can definitely see it becoming popular in several years.


How can you verify what the latest update of Google Play Services is doing on your Android that's running a proprietary WhatsApp client just so you feel happy you have "E2E" encryption?


You can't. You can find a provider you trust or set them up yourself.


How can anyone verify that?


Reproducible builds. https://reproducible-builds.org/


Reproducible builds allow verifying that your build is correct by rebuilding it It doesn't help you verify that the server you're connected to is running the binary you've been given.


Why would I want a man in the middle of my communications?


Because the A-Series round of financiers think that's a great idea.


The real answer is because you want all your conversations to happen in the same app/protocol. You never have to download a shiny new messenger again


I'ved heard that pitch before. It's always true only for some length of time. Protocols change, services evolve, companies transform, products are deprecated and people are fickle.

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.


Perhaps if we normalized messenger interoperabiltiy, there would be less churn in "all-in-one" clients. That churn exists mostly because platforms actively fight their users on this.

And still, periodically changing an all-in-one messenger is still better than keeping and changing half a dozen messengers.


Unless those official clients have features not available in the all-in-one client. Like encryption, which this one apparently lacks.


The benefit of an all-in-one client is that they can port/shim/polyfill[0] missing features between the backing platforms.

--

[0] - Whatever is the most appropriate webdev word of the day.


And the downside of an all-in-one client is that they are going to have to port/shim/polyfill features from a hostile, proprietary, changing API.

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.


It's worth remembering again why we don't do this. Even if you fully trust whoever is running the MITM server, being that it's MITMing all of your comms, and it's on a server so it's actually a lot of people's comms, it's a massively tempting target for all sorts of bad actors. Plenty of governments and criminal gangs would just love to compromise that for all sorts of reasons. Odds are one of them will eventually.

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.


Can you run Pidgin on your phone and tablet and laptop and move between them?


Depends on the services you connect to.


Meebo was a service that did roughly the same thing as pidgin (leveraging libpurple to do so iirc). It's a shame it was turned down.


It is a service, because the bridge is a software that need to be keep operational 24/24h and sometimes this is not so trivial (if I don't get wrong WA need an Android emulator running).


Pidgin doesn't use a "bridge"... it is just a generic local client that supports plugins for various protocols that are implemented via adversarial interoperability.


And because of that Pidgin is horribly unreliable. Don’t get me wrong, I used it for years, but over time all the plug-ins broke for one reason or another.


Law makers are required here to solve the situation, as platforms themselves refuse to work with each other. If Facebook and Google had to operate a common protocol (just like IMAP), Pidgin would work much better or wouldn't even be needed.

But no, they want to prevent people from talking with each other via other platforms because "we're best" or whatever.


It's probably because they don't want to lose users.

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.


Exactly! Providing a walled garden just for the sake of keeping users should not be legal, just like abusing any other market position wouldn't be legal.

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.


My point is that the walled garden is the competitive advantage.

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.


> A law like this could regulate businesses out of existence.

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.


Yes — this line of argument sounds exactly like the people who very confidently said that the economy couldn’t survive ditching asbestos or CFCs, emissions laws would destroy California, etc.

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.


Yes, but what if this is the only way to have a profitable business such as these? Are you okay losing them entirely?

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?


> Yes, but what if this is the only way to have a profitable business such as these? Are you okay losing them entirely?

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.


WA works with a pure go-based bridge. No Android required.

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.


You need WhatsApp to be installed on a real device or a VM for mautrix-whatapp [1] (the bridge) to work. You also need to connect to that real device using WhatsApp web [2].

I know because I've used the bridge.

[1] https://github.com/mautrix/whatsapp [2] https://docs.mau.fi/bridges/go/whatsapp/authentication.html


Which bridge is it? Mautrix/whatsapp does require an Android instance of whatsapp.


Nah. You can pair it up to an real WhatsApp-account using your phone and from there on, it’s go-code only.


It is not a service, if it's a link to a download and a bunch of community-developed plugins.

When you take away the motivation to mitm all of the users' chats, there's nothing left.


And FB will probably not like running WA in an emulator, and will kill that option as soon as it reaches ~100k users.


how can they kill it?


They have so much money and influence, I trust them to find a way :)


With enough motivation, competitors can reverse their efforts. Reversing (competitors' job) is finding just only one flaw in a system. Hardening (WhatsApp's job) is thinking about all the possible ways it could be flawed. It can be an endless cat and mouse game though I guess.


Of course the protocols Pidgin bridged were only used for real-time communication, rather than for leaving messages which could be attended to (or delivered) later.


No, it wasn't. Yahoo had offline messages. So did many of its other protocols.


Ah you're right, I think I indeed had that for MSN as well. Must've gotten confused.


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


Pidgin was extremely convenient. But it was commoditizing messaging platforms so of course it had to be shot in the head by them.


I don't think anything got "shot in the end"; the protocols of old were often just reverse-engineered too. Few bothered publishing anything about it, which is why Jabber/XMPP was created.

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.


That's not 100% accurate. Signal handles message history per device. If you link a new device, you can only see messages that were sent/received after that. There is no way to sync messages between devices, they all get the messages from the signal servers directly. This also means that you can use signal on linked devices if your phone is offline; you just need the phone for initial sign-on.


who's them?


> messaging platforms

No need to pretend that what the previous comment was saying is some kind of conspiracy when it's obvious that business gonna business.


oof


Bitlbee can optionally use Libpurple too.


I thought about all that libpurple did back then, including OTR encryption that worked perfectly fine with others.

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.

[1] https://meetfranz.com

[2] https://github.com/getferdi/ferdi


Franz was mainly just web views, no? Ferdi appears to be the same. This is different.


> Back in the day before the rise of Facebook, there was an open source service that combined all the popular messaging protocols

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.


Back in the day and for a little while platforms companies thought to at least have a common language (xmpp). Then they thought it would be a better idea if we all had 10 different apps on our phones for text messages.

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.


Companies must be forced to implement a subset of their features as part of some interoperability standard. The rest they can keep for their competitive advantage. I can't recall any industry who ever volunteered for this. Car makers didn't, telecoms didn't, software makers won't. No one did and they all exploited their users/customers to the fullest until they were forced to do so.


think about this: WA protocol was simply XMPP with shorter labels (one character when possible)


Anyone remember Trillian? I used to use it to combine Facebook Messenger, ICQ, and some other stuff.

All my friends have since moved to Discord now which is way nicer than any other user experience.


Yep, brings be back... + AIM, MSN, they even had a primitive IRC connection if memory serves me right.


> While it's interesting, I'm failing to see what the use case is.

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

[2]: https://matrix.org/clients/


The Glory days, when both Google Talk and Facebook used XMPP, and you can run one client to chat with all of them. We ran Prosidy and Pidgin at my old job, and it worked great for our company chat server.


Facebook group chats were xmpp too? I thought they never were


I think this is more like XMPP transports in that is is centralized at the server. Such things tended to end up centralized as it is a lot of work to keep up with the efforts of the people running the services to remain incompatible with the bridges. These days few XMPP servers bother with transports to commercial IM services. I suspect the same thing will happen in the Matrix case.


Transports work against your platform. Running a WhatsApp transport, you enhance WhatsApp's network effect and dilute your own.


Transports work for you when you're an upstart, because it makes it less risky for users to adopt your platform. They work against you only once you get significant market share.

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.


Two decades ago I used trillian and mirianda for all the popular messaging protocols,

https://trillian.im/ https://www.miranda-ng.org/en/


Now there is another open source alternative: Matterbridge (https://github.com/42wim/matterbridge) connecting: Mattermost, IRC, Gitter, XMPP, Slack, Discord, Telegram, Rocketchat, Twitch, SSH-chat, Zulip, WhatsApp, Keybase, Matrix, Microsoft Teams, NextCloud, Mumble, VK and more.

The use case is simple: instead of using plethora of IM apps, have all your conversations in one place.


Wow, this seems better than ElementOne?


Agreed, not sure what the use case is. It’s super trivial to switch between messaging apps and it’s not often that you are having a conversation with multiple people over multiple apps at once and even then it’s still manageable.

The only thing I can think of is people who do not wish to have the app installed for privacy / open source reasons.


Think of people who are:

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


The first two are not well solved by Matrix as the default client is far less user friendly than the proprietary alternatives.

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.


There was a good recent episode of Late Night Linux Extra[0] where the maintainer talks about Pidgin and how it compares with Matrix.

[0] https://latenightlinux.com/late-night-linux-extra-episode-32...


I really love libpurple plugins for pidgin and how they can be combined.

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



I’d use the f out of this… if this was easy to setup. I’d like that but with one click and some settings things to sign.


Pidgin is an IM client, not a service. A service would be something like XMPP servers (Google Talk used to be one and even federated until it went sideways).


Pidgin? Pffff! That’s some casual stuff right there.

Real Scotsmen used bitlbee and irssi to enable their IRC addiction, long after everyone else had moved on to harder stuff.

:)


Pidgin works with a surprising number of modern services [0]. I used it last year on my 32 bit computer that couldn’t run the official discord client.


Fun fact, pidgin was developed by Mark Spencer, who also wrote Asterisk PBX and currently builds open source flight avionics.


Ah, XMPP + OTR. Brings back fond memories.


I think Trillian was even older, and I think there were some KDE apps that did it even before that...



I still use pidgin regularly for various chat rooms and ircs etc. It is a great piece of kit imo


Pidgin and Gajim.


Everything old is new again.


This is nicely timed.

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.


Beeper implements Google Chat. I've been using it, it works really well.

https://www.beeper.com/


Yup. And looks like element One is a direct competition to beeper


I've been waiting for an invite for almost a year now. Even gave my credit card for them, but still waiting...

I'm just yelling here to take my money, but nobody answers.


Only if you can signup though, been very long time since I registered for invite.


Beeper's waitlist is probably the longest one I've ever had to wait on for a beta service. Still waiting, over a year later.


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

Search: