Show HN: Beeper – All Your Chats in One App(beeperhq.com)
beeperhq.com
Show HN: Beeper – All Your Chats in One App
https://www.beeperhq.com/?hn
484 comments
As an answer to your first question:
Between 2000-2003, I worked on components of the cross protocol IM backend used by many of the multi-protocol messengers back in the early to mid 2000s (eg: Adium, Trillian, Fire, Ayttm, and more). Each of the frontends had different ways to integrate. Trillian used 2 processes with TCP communication between them to get around the GPL licensed backend), Fire, Adium, Ayttm released everything under the GPL.
Eventually most clients moved to using libpurple as the backend (developed by the team behind Gaim), but the devs also started getting older, busier, and having other responsibilities outside of work. The only apps to survive were those that had a business model that allowed them to reuse open source code without having to release any of the code they developed themselves.
I personally stopped working on instant messaging in April 2004, the night before I became a Yahoo employee, though I continued blogging and doing conference talks about the experience:
- https://tech.bluesmoon.info/2004/09/fallback-messaging.html
- https://tech.bluesmoon.info/2011/05/story-of-george-ayttms-m...
- https://tech.bluesmoon.info/2010/11/stream-of-collaboration-...
Between 2000-2003, I worked on components of the cross protocol IM backend used by many of the multi-protocol messengers back in the early to mid 2000s (eg: Adium, Trillian, Fire, Ayttm, and more). Each of the frontends had different ways to integrate. Trillian used 2 processes with TCP communication between them to get around the GPL licensed backend), Fire, Adium, Ayttm released everything under the GPL.
Eventually most clients moved to using libpurple as the backend (developed by the team behind Gaim), but the devs also started getting older, busier, and having other responsibilities outside of work. The only apps to survive were those that had a business model that allowed them to reuse open source code without having to release any of the code they developed themselves.
I personally stopped working on instant messaging in April 2004, the night before I became a Yahoo employee, though I continued blogging and doing conference talks about the experience:
- https://tech.bluesmoon.info/2004/09/fallback-messaging.html
- https://tech.bluesmoon.info/2011/05/story-of-george-ayttms-m...
- https://tech.bluesmoon.info/2010/11/stream-of-collaboration-...
It's not just about devs getting older and busier, but also about networks becoming openly hostile towards third party client implementations. There used to be a healthy ecosystem of Whatsapp client libraries, but they have gotten takedowns, and their users bans. Eventually people give up. Some few individuals build third party implementations but keep them secret so that there is no retribution (I remember reading about a guy blogging about a self made iMessage client).
Thankfully the EU is moving rapidly towards making that sort of behaviour illegal, which as a knock-on effect should improve the situation for the world in general. https://ec.europa.eu/info/strategy/priorities-2019-2024/euro...
This looks awesome! I wonder why I haven't heard about it before.
I think we all know which gatekeepers are going to land on the list and how happy they'll be to be on it. If this does more than just create a list and actually punishes gatekeepers for bad practices, I'll be impressed.
It's like net neutrality but for gatekeepers. They can't abuse their position.
This is a great start
Yeah, same thing with discord. The "cordless" client dev got some of his accounts suspended recently and decided to stop developing the project :/
I'm glad to see a paid for service, by I don't think I'd take the jump for $10 a month!
>(from the website) we send each user a Jailbroken iPhone with the Beeper app installed which bridges to iMessage
Aren't you worried about Apple's reprisal ?
Also it might be worth adding a word about the privacy of the messages. Am I correct that the end to end encryption goes out the window and each Matrix connector can see the messages in plain text? I think it's not so much an issue as long as it's clear to the user, and that they pay for you to keep their private messages private.
>(from the website) we send each user a Jailbroken iPhone with the Beeper app installed which bridges to iMessage
Aren't you worried about Apple's reprisal ?
Also it might be worth adding a word about the privacy of the messages. Am I correct that the end to end encryption goes out the window and each Matrix connector can see the messages in plain text? I think it's not so much an issue as long as it's clear to the user, and that they pay for you to keep their private messages private.
I'm also curious about Beeper's plan re: potential response/pushback from Apple and the status of (likely broken?) E2E in iMessage.
If I backup my WhatsApp messages in plaintext or screenshot my iMessage it’s still E2E. Once the message is delivered all bets are off.
Forwarding all my messages to some 3rd party service doesn’t break E2E anymore then forwarding them to my friends.
Forwarding all my messages to some 3rd party service doesn’t break E2E anymore then forwarding them to my friends.
>>(from the website) we send each user a Jailbroken iPhone with the Beeper app installed which bridges to iMessage
Is there really something that makes iMessage so difficult to reverse engineer that this is considered economical? People were able to write AIM clients 20 years ago, what special trick has Apple used?
Is there really something that makes iMessage so difficult to reverse engineer that this is considered economical? People were able to write AIM clients 20 years ago, what special trick has Apple used?
I’m homeless and pay $10/mo for a terminal app.
The value is in the eye of the beholder... FWIW I used to be a pretty well paid software engineer, and I run as much of my personal IT as possible... so for me, the $10/mo is worth it to save seconds 100s of times per month and make hours of experience per month pleasant.
The value is in the eye of the beholder... FWIW I used to be a pretty well paid software engineer, and I run as much of my personal IT as possible... so for me, the $10/mo is worth it to save seconds 100s of times per month and make hours of experience per month pleasant.
Honestly so glad it's a paid service. I'm happy to pay for something I can trust to handle my messages, rather than using them against me to sell ads/send to shady data brokers!
Awesome work Eric, Tulir, and the whole Matrix team too!
Awesome work Eric, Tulir, and the whole Matrix team too!
I've been in the past few nights trying to build my own Matrix server with integrations to Signal, WhatsApp, Telegram, IRC, Slack et.al. It is quite a lot of work, even with the Ansible script. First was the DNS SRV record, that is needed to federate with matrix.org. And the Signal integration happily sent messages to my friends, but I never got any messages back.
I have quite a lot of experience with Linux and server maintenance. And I know if I put enough time to this, I'll get everything to work eventually. I'm still saying that paying money for somebody else to do this feels like a nice investment at this point. The task of doing everything by yourself is quite tricky.
I have quite a lot of experience with Linux and server maintenance. And I know if I put enough time to this, I'll get everything to work eventually. I'm still saying that paying money for somebody else to do this feels like a nice investment at this point. The task of doing everything by yourself is quite tricky.
Need to add now I got everything working. Element running in my own domain, connecting Signal, Telegram, Matrix federation and IRC in a beautiful way.
It is a lot of work, some of the documentation can be a bit tough if you don't know how things work together and especially the DNS setup can take a bit of time to get the federation working.
It is a lot of work, some of the documentation can be a bit tough if you don't know how things work together and especially the DNS setup can take a bit of time to get the federation working.
If you achieve it, it could be nice to improve the existing documentation.
Sorry, just to clarify - are you saying that self-hosting Beeper is a lot of work, or that self-hosting Matrix with bridges without Beeper is a lot of work?
$10/mo is steeper than I like for a chat app, but this is so huge to just roll everything into one place, and I like that it's OSS, so I'm happy to pitch in and support the devs even if I'm capable of self-hosting the backend.
For $10/mo one could host their own VPS and server infra.
Classic HN comment.
Yeah, $10/mo, + the time needed to setup everything + the time to maintain it + the security holes to patch yourself + the downtime because the instance rebooted for some reasons + the monitoring of the service + all the time wasted because you could have simply lived your life and paid the reasonable fees for the service in the first place.
Not at all, prosody and ejabberd both work flawlessly without all of that nonsense. If it's a shitty piece of software maybe, but then why even bother using it in the first place?
“All that nonsense”
Are the realities of running any software.
If you don't care about the uptime of your chat service you may as well not have one. Eventually those things will be the same.
The first sentence in your otherwise useful post doesn't feel helpful to the conversation.
I already have a VPS for other reasons, so I'm glad if I could get a self-hosted solution.
But that includes setting up and maintaining it, as well as troubleshooting when there's an issue.
For some, $10/month is a nice way to have all that worry-free.
For some, $10/month is a nice way to have all that worry-free.
The messages still go through the "free" networks, so they're still being used exactly like that.
How “brittle” are the integrations? I guess I mean is this a supported feature of all the 3rd party services or do you have to rely on hooking into undocumented apis that could change at any time etc.
I'm running several of the mentioned integrations on my own server (without the Ansible script) and every now and then there's a weird bug, or some slowdown, or some messages not getting through, but I've mostly switched.
I'm not sure if I'd ever pay $10/mo for a service whose main selling point is running what are essentially reverse-engineered hacks. Some of the integrations use the official available API (like the Telegram one) but others (like the Whatsapp and Signal ones) run on altered web client code. Furthermore, in most commercial chat systems, alternative clients are usually not allowed and can lead to a ban of your account if the server considers you a bot.
The product is a worthy attempt at fixing the mess that is modern chat solutions, but from my experience I just don't trust the system enough to switch.
Also keep in mind that any e2e encryption platforms like Signal and Whatsapp provide is made worthless if you use a bridge; I haven't seen any bridge use Matrix's e2e encryption yet and your messages are all being decrypted on the server regardless.
I'm not sure if I'd ever pay $10/mo for a service whose main selling point is running what are essentially reverse-engineered hacks. Some of the integrations use the official available API (like the Telegram one) but others (like the Whatsapp and Signal ones) run on altered web client code. Furthermore, in most commercial chat systems, alternative clients are usually not allowed and can lead to a ban of your account if the server considers you a bot.
The product is a worthy attempt at fixing the mess that is modern chat solutions, but from my experience I just don't trust the system enough to switch.
Also keep in mind that any e2e encryption platforms like Signal and Whatsapp provide is made worthless if you use a bridge; I haven't seen any bridge use Matrix's e2e encryption yet and your messages are all being decrypted on the server regardless.
All of our bridges (except Slack and Discord, but will soon) use Matrix's e2e encryption scheme and all messages are stored encrypted on Beeper servers with a key that you control. We can't decrypt your messages.
Wait, how is this possible? There's an obvious integration point between your bridge server and the other service. They don't talk the same encrypted protocol, obviously, so you have to send plain text at some point in that process.
It makes zero sense that you don't have access to the messages.
It makes zero sense that you don't have access to the messages.
They don't talk the same protocol but that doesn't prevent them using compatible forms of message encryption.
If the basic concepts of "E2E key exchange" and "pass this encrypted message" exist at all points, I see no fundamental problems with having E2E encryption across different networks. I can see potential for lots of the normal practical small problems but it could fundamentally work.
If the basic concepts of "E2E key exchange" and "pass this encrypted message" exist at all points, I see no fundamental problems with having E2E encryption across different networks. I can see potential for lots of the normal practical small problems but it could fundamentally work.
I agree that it's technically feasible but that's not going to help me right now. It would require all services use the same encryption (or at least understand a common, compatible one) and I don't see that happening, ever.
Yes, I was wondering about exactly this! A dev response would be much appreciated.
[deleted]
Seems like you have to unwrap the message from the upstream scheme and re-wrap it in Matrix’s scheme at some point, right?
I’d appreciate a blog post explaining the architectural choices here.
I’d appreciate a blog post explaining the architectural choices here.
Thanks! This is the only piece of information I needed before giving Beeper a chance. I could not find it on the Beeper home page as a callout or in the FAQs, and it would probably be good to add.
Ideally I would not want to run the whole stack if I understand how the E2E encryption is managed.
Ideally I would not want to run the whole stack if I understand how the E2E encryption is managed.
This simply cannot be true, since you have to decrypt the messages to send them to, for example, WhatsApp.
Nope - you have to encrypt them to send them to WhatsApp. Why could you not encrypt them in the client and then send that encrypted message over the bridge, preserving E2E?
Because that's not how this works. The bridge has to have the unencrypted text, because it's the bridge that is communicating with WhatsApp/Signal/IRC/whatever. The client isn't the bridge, it's not communicating directly with WhatsApp, it's just communicating with a Matrix Bridge (over an encrypted channel) to a Synapse server you don't control.
You'd need WhatsApp's collaboration for this, which I'm going to go out on a limb and suggest that the bridge operator doesn't have.
There are two encrypted channels: client<->bridge, and bridge<->WhatsApp. The bridge can read the decrypted text, and the comment I replied to is a lie.
There are two encrypted channels: client<->bridge, and bridge<->WhatsApp. The bridge can read the decrypted text, and the comment I replied to is a lie.
I've been using it for the last year straight and I think we only experienced one unforeseen breaking API change.
Just chiming in, I probably wouldn't pay for $10 a month for this service (maybe I'm not the target market). I do use various messaging apps and it is annoying though.
This jumped out at me:
>we send each user a Jailbroken iPhone with the Beeper app installed which bridges to iMessage
I couldn't tell if that was some sort of joke or if it meant something different to how I was reading it?
Being open source is great, but to be honest I lack the time (and expertise) to see how all the integrations work. A page that describes a high level overview of how this works exactly might build more trust.
Good luck!
This jumped out at me:
>we send each user a Jailbroken iPhone with the Beeper app installed which bridges to iMessage
I couldn't tell if that was some sort of joke or if it meant something different to how I was reading it?
Being open source is great, but to be honest I lack the time (and expertise) to see how all the integrations work. A page that describes a high level overview of how this works exactly might build more trust.
Good luck!
I get the concern, but they're probably not super brittle because chat apps still need to support old clients. I'd worry more about getting blocked entirely.
I remember chatting with the Meebo founders about some of this. They didn't really have an answer to why AIM, YIM, and MSN Messenger wouldn't block them beyond it being bad for their networks. On how they'd make money, I don't remember hearing any interesting answers. They never really figured out the money thing and ended up getting acquihired by Google.
The did have a crazy-impressive web UI for the mid-2000s; for a while, that know-how was probably their most valuable asset. The need and the market still (and have always) kinda exited, but the players changed a lot in the last 15 years. One of their business ideas was to pivot into a commercial support chat app. People use them today, so maybe they were before their time, or maybe B2B was never in their DNA.
I remember chatting with the Meebo founders about some of this. They didn't really have an answer to why AIM, YIM, and MSN Messenger wouldn't block them beyond it being bad for their networks. On how they'd make money, I don't remember hearing any interesting answers. They never really figured out the money thing and ended up getting acquihired by Google.
The did have a crazy-impressive web UI for the mid-2000s; for a while, that know-how was probably their most valuable asset. The need and the market still (and have always) kinda exited, but the players changed a lot in the last 15 years. One of their business ideas was to pivot into a commercial support chat app. People use them today, so maybe they were before their time, or maybe B2B was never in their DNA.
We had a bunch of IPs for each of our servers to get around some of their auto-blocking stuff. Eventually we got approval from AIM but that was fairly late. You're right in that we had crazy-impressive web UI but the backend was also unique in that we had a process running for every logged in user (and eventually we had a process running for every user who was running the iOS app)
Why would chat apps need to support old clients? If facebook pushes out an update almost every user will have it on day one and every user will 1 month on. They can just show an error banner to users who have automatic updates turned on.
My life as a developer would be much easier if every user actually upgraded their apps within a month of updates. In my experience, a substantial proportion of users either have automatic updates disabled and only manually update individual apps when they break, or don’t habitually connect their phones to Wi-Fi, and thus don’t get automatic updates.
It’s why apps like desktop Chrome have extremely aggressive automatic-update schemes which are near-impossible to disable if you’re ever connected to the internet.
It’s why apps like desktop Chrome have extremely aggressive automatic-update schemes which are near-impossible to disable if you’re ever connected to the internet.
You must have different users than I had.
iOS users upgrade pretty quick, but Android users don't. There are lots of phones with not very much storage, so upgrading is painful for users and they turn off auto-updates and don't update frequently.
And when you add on end of life platforms that have enough users you don't want to cut off, but not enough users that you want to do active development, or the platform owner won't sign packages anymore, you have to support some clients for a long time.
iOS users upgrade pretty quick, but Android users don't. There are lots of phones with not very much storage, so upgrading is painful for users and they turn off auto-updates and don't update frequently.
And when you add on end of life platforms that have enough users you don't want to cut off, but not enough users that you want to do active development, or the platform owner won't sign packages anymore, you have to support some clients for a long time.
> Beeper is a paid service
It took me multiple times searching that page to find the "$10 monthly fee" hidden in the FAQ section. You desperately need an obvious pricing section.
It took me multiple times searching that page to find the "$10 monthly fee" hidden in the FAQ section. You desperately need an obvious pricing section.
$10 monthly for a chat service is a bit steep for users from Asia and other places..
Is it a just plain high price (e.g. if this was $50/month that would be expensive for me, here in the US) or is it high comparable to other things (e.g. "other messaging apps would be closer to $3/month")?
I think generally paying for a messaging app subscription more than you pay for your phone subscription (ARPU) is going to be hard to sell to a wide audience.
https://www.statista.com/statistics/668966/mobile-average-re...
https://www.statista.com/statistics/668966/mobile-average-re...
I tend to agree with this. I understand the convenience it offers, but as long as the services it connects to are "free", I'm not going to pay more than one or two dollars / euros for it. This is not being stingy, simply a subjective evaluation of the worth of such a service.
It's comparably high-other messaging apps are _free_. Don't get me wrong, this is awesome-I've been doing it myself manually by hosting bridges myself for a while, and it seems like a very nice solution for non-tech-savy users.
But $10/month is steep, given that in practice you're paying that much just for the convenience of having your (pre existing chats) in the same app.
What I don't get is that hosting your own bridges requires the same $10/month subscription. If there was a $2/month fee for "power users" instead, letting you host your own... I would most likely get a subscription for the convenience of using their better integrated software.
But $10/month is steep, given that in practice you're paying that much just for the convenience of having your (pre existing chats) in the same app.
What I don't get is that hosting your own bridges requires the same $10/month subscription. If there was a $2/month fee for "power users" instead, letting you host your own... I would most likely get a subscription for the convenience of using their better integrated software.
> What I don't get is that hosting your own bridges requires the same $10/month subscription. If there was a $2/month fee for "power users" instead, letting you host your own... I would most likely get a subscription for the convenience of using their better integrated software.
Those features may require extra engineering and support effort, not less.
(Even if these changes actually reduced the cost of service delivery, it's usually a small part of the price. In consumer SaaS, you're not paying for the cost of goods sold, you're paying for everything else - particularly software engineering, support, and marketing AKA customer acquisition. A reasonable analogy is a restaurant, where 20-30% of the meal price goes to food costs. In consumer SaaS, the "food cost" is often 10%-20% of the "meal price.")
Those features may require extra engineering and support effort, not less.
(Even if these changes actually reduced the cost of service delivery, it's usually a small part of the price. In consumer SaaS, you're not paying for the cost of goods sold, you're paying for everything else - particularly software engineering, support, and marketing AKA customer acquisition. A reasonable analogy is a restaurant, where 20-30% of the meal price goes to food costs. In consumer SaaS, the "food cost" is often 10%-20% of the "meal price.")
> What I don't get is that hosting your own bridges requires the same $10/month subscription.
the website says the second self-hosting option is free
the website says the second self-hosting option is free
Good point. Maybe their pricing could be location based?
That would just be worked around with VPNs etc, so then they have to spend a huge amount of their dev time not on features but instead on working out how to detect where the users are geolocated. IP, language, credit card address etc. Just not worth it and always going to be many edge cases. One price for all is fairer even if it is very expensive for some locations/people
Because I’m pretty sure that if they put that forward or in a more explicit manner, the first reflex would be to close the tab and move on.
They hide because it makes sense to try the product, realize how awesome it is to have all the conversations in one central place, and make you pay for it afterwards - which makes sense.
They hide because it makes sense to try the product, realize how awesome it is to have all the conversations in one central place, and make you pay for it afterwards - which makes sense.
How about XMPP support? I mean, you are talking about Matrix being the holy grail of chat and at the same time you do not support the IETF standard for instant messaging (which is also federated, supports E2E encryption, can use bridges to other networks and has several open source implementations)...
In general, my biggest issue with the Matrix community is that they chose to build something new, instead of fixing something existing. Granted, at the time when Matrix started, XMPP wasn't fit for the mobile revolution. But instead of improving the XMPP standard (which other people did afterward), the Matrix people decided to build something new from the ground up. They took a few different design decisions, but in my opinion, nothing that would justify building a competing solution and splitting the already thin developer community.
Now we have too solutions, both failing to find significant adoption. I understand that the matrix people probably built their eco system as a hobby, so who am I to criticize them. I just feel so depressed, seeing so much work being done on a very important subject, not fulfilling its potential due to missing focus.
In general, my biggest issue with the Matrix community is that they chose to build something new, instead of fixing something existing. Granted, at the time when Matrix started, XMPP wasn't fit for the mobile revolution. But instead of improving the XMPP standard (which other people did afterward), the Matrix people decided to build something new from the ground up. They took a few different design decisions, but in my opinion, nothing that would justify building a competing solution and splitting the already thin developer community.
Now we have too solutions, both failing to find significant adoption. I understand that the matrix people probably built their eco system as a hobby, so who am I to criticize them. I just feel so depressed, seeing so much work being done on a very important subject, not fulfilling its potential due to missing focus.
Because XMPP sucks. It had 20 years to succeed, and failed. Maybe it’s time for you to move on?
Last company I worked at that used it internally had thousands of employees in IT and still considered maintaining the jabber server not worth it - a million XEP extensions cannot bring it to the same level as a modern chat client. On every matrix post the xmpp crowd comes out of the woods, but what have you got to show? What’s the best cross-platform or web client for it right now? They all look like half-baked ports of long abandoned QT apps made for Linux and still don’t support syncing/multi-presence well.
Last company I worked at that used it internally had thousands of employees in IT and still considered maintaining the jabber server not worth it - a million XEP extensions cannot bring it to the same level as a modern chat client. On every matrix post the xmpp crowd comes out of the woods, but what have you got to show? What’s the best cross-platform or web client for it right now? They all look like half-baked ports of long abandoned QT apps made for Linux and still don’t support syncing/multi-presence well.
Messaging underwent an earth-shattering paradigm shift in the past 20 years, so numerous features considered optional back in 2000 are now mandatory when you want any mass market appeal (which is the whole point when messaging is dominated by network effects).
A rework of the FOSS messaging ecosystem was much needed, and Matrix was the one to deliver it and not XMPP. I say the winner takes the crown, especially when the end result is more coherent for users.
The fact is that sometimes the kind of tool you need is a solid monolith built from the ground up with specific objectives in mind, and not a loose accretion of small utilities and extensions.
A rework of the FOSS messaging ecosystem was much needed, and Matrix was the one to deliver it and not XMPP. I say the winner takes the crown, especially when the end result is more coherent for users.
The fact is that sometimes the kind of tool you need is a solid monolith built from the ground up with specific objectives in mind, and not a loose accretion of small utilities and extensions.
I wish Matrix delivered what it promised. But it hasn't yet.
Matrix is coherent if you use the reference server and clients. But so is XMPP if you get them from the same source. And the Matrix reference server needs pretty powerful hardware.
Matrix is coherent if you use the reference server and clients. But so is XMPP if you get them from the same source. And the Matrix reference server needs pretty powerful hardware.
> And the Matrix reference server needs pretty powerful hardware.
That is not a bug, its a feature (or so the Matrix people say).
In fact, part of the Matrix design is a fat server which has a lot more responsibilities by default than an XMPP server. However, I guess a full-featured XMPP server (with MAM, Push, etc.) probably has similar requirements.
That is not a bug, its a feature (or so the Matrix people say).
In fact, part of the Matrix design is a fat server which has a lot more responsibilities by default than an XMPP server. However, I guess a full-featured XMPP server (with MAM, Push, etc.) probably has similar requirements.
The Matrix people don't say it's a feature. They say the rewrite will fix it.
XMPP with MAM and push doesn't have similar requirements.
XMPP with MAM and push doesn't have similar requirements.
There's some confusion here.
* Dendrite ("the rewrite") uses about 5-10x less RAM than Synapse; it's in relatively late beta and you can see for yourself today. For instance, dendrite.matrix.org is currently sitting at 480MB of RAM, despite being in ~5000 rooms spanning ~150K users.
* Matrix is coherent no matter what clients you use, given there is only one version of the spec (and as it happens, we haven't broken backwards compatibility yet). Sure, some implementations might not have implemented all the features, but the features they do implement (assuming they're not buggy) will work reliably with any other client or server out there.
It's fine to dislike Matrix and pine for XMPP, but please don't spread FUD.
* Dendrite ("the rewrite") uses about 5-10x less RAM than Synapse; it's in relatively late beta and you can see for yourself today. For instance, dendrite.matrix.org is currently sitting at 480MB of RAM, despite being in ~5000 rooms spanning ~150K users.
* Matrix is coherent no matter what clients you use, given there is only one version of the spec (and as it happens, we haven't broken backwards compatibility yet). Sure, some implementations might not have implemented all the features, but the features they do implement (assuming they're not buggy) will work reliably with any other client or server out there.
It's fine to dislike Matrix and pine for XMPP, but please don't spread FUD.
The third party Matrix ecosystem is exactly as coherent as the XMPP ecosystem. Sure, some implementations might not have implemented all the XEPs, but the XEPs they do implement (assuming they're not buggy) will work reliably with any other client or server out there.
I'll like Matrix when it can replace XMPP. Dendrite sounds like a step in that direction when it's mature.
Please stop spreading FUD about XMPP.
I'll like Matrix when it can replace XMPP. Dendrite sounds like a step in that direction when it's mature.
Please stop spreading FUD about XMPP.
The difference is that there are multiple different XEPs performing similar operations, and even with the compliance suite XEPs, it can be confusing to synchronise on whether different bug-free clients are speaking the same dialect.
Whereas Matrix ensures that there is only ever one way of doing a given operation at any point, and those operations are backwards compatible, because there's only one spec. Obviously the client and server you're talking to needs to have actually correctly implemented the bits of the spec that you're trying to use - but there's no openpgp v. OMEMO or rival file transfer mechanisms etc. It's only a difference in governance, but it's an important one.
Obviously, a single monolithic spec controlled by a committee like the matrix spec core team has its own problems (most importantly, the committee can become a bottleneck); and we still provide mechanisms to let people experiment via the equivalent of vendor prefixing, which can go horribly wrong (c.f. aggregations in Matrix) if not managed with discipline.
But, I'm not trying to spread FUD about XMPP - just try to explain that the approaches taken are different, and have different tradeoffs, and are not "exactly the same".
Whereas Matrix ensures that there is only ever one way of doing a given operation at any point, and those operations are backwards compatible, because there's only one spec. Obviously the client and server you're talking to needs to have actually correctly implemented the bits of the spec that you're trying to use - but there's no openpgp v. OMEMO or rival file transfer mechanisms etc. It's only a difference in governance, but it's an important one.
Obviously, a single monolithic spec controlled by a committee like the matrix spec core team has its own problems (most importantly, the committee can become a bottleneck); and we still provide mechanisms to let people experiment via the equivalent of vendor prefixing, which can go horribly wrong (c.f. aggregations in Matrix) if not managed with discipline.
But, I'm not trying to spread FUD about XMPP - just try to explain that the approaches taken are different, and have different tradeoffs, and are not "exactly the same".
> Matrix ensures that there is only ever one way of doing a given operation
That's not entirely true though. Press voice call in a client and you may end up with an embedded jitsi, some WebRTC thing, or nothing at all. That's exactly how xmpp clients started to diversify.
> I'm not trying to spread FUD about XMPP
Yeah, the tone could certainly be improved. Every time Matrix comes up, someone mentions xmpp and immediately the flinging starts about how broken it is and how those developers let it slide into obscurity.
Which there may be some truth to, but it really leaves a bitter taste. Especially since much of xmpp lives on in Matrix in bridges to other networks. Matrix really got a flying start there, and that's a good thing! Software should be shared and built on.
What worries me a little is that the same problems xmpp had, with protocol verbosity and problematic integration with smartphone platforms, is bascially the same in Matrix. The protocol is at least as verbose, and battery management is at least as hard. As a successor to xmpp, one might have expected to learn more from its problems. I'm certainly not complaining however, the more software the better, and the web client is very nice.
That's not entirely true though. Press voice call in a client and you may end up with an embedded jitsi, some WebRTC thing, or nothing at all. That's exactly how xmpp clients started to diversify.
> I'm not trying to spread FUD about XMPP
Yeah, the tone could certainly be improved. Every time Matrix comes up, someone mentions xmpp and immediately the flinging starts about how broken it is and how those developers let it slide into obscurity.
Which there may be some truth to, but it really leaves a bitter taste. Especially since much of xmpp lives on in Matrix in bridges to other networks. Matrix really got a flying start there, and that's a good thing! Software should be shared and built on.
What worries me a little is that the same problems xmpp had, with protocol verbosity and problematic integration with smartphone platforms, is bascially the same in Matrix. The protocol is at least as verbose, and battery management is at least as hard. As a successor to xmpp, one might have expected to learn more from its problems. I'm certainly not complaining however, the more software the better, and the web client is very nice.
> That's not entirely true though. Press voice call in a client and you may end up with an embedded jitsi, some WebRTC thing, or nothing at all. That's exactly how xmpp clients started to diversify.
This really isn't an example of protocol fragmentation - it's behaving precisely as expected.
There is precisely one way to do a 1:1 VoIP/Video call in Matrix: https://matrix.org/docs/spec/client_server/r0.6.1#voice-over.... It hasn't actually changed since 2015 when we first added it to the spec, until recently when there's a proposal to improve it called MSC2746: https://github.com/matrix-org/matrix-doc/blob/dbkr/msc2746/p.... Now, this is a proposal to patch the spec - it's a Matrix Spec Change. It retains backwards compatibility with the current behaviour, and once the MSC is approved it'll be merged into the spec and the MSC will be discarded.
There is precisely one way currently to do VoIP/Video conferences in Matrix: you instantiate a 'widget', to embed whatever web conferencing service you like into your chat room (e.g. Jitsi). You use the widget API to control it. Widgets aren't actually merged into the spec yet, but are specified at MSC1236 (https://github.com/matrix-org/matrix-doc/issues/1236), which should get reviewed and merged in real soon now. So, as long as your client implements widgets, you can do conferences. In future, we have plans for native Matrix conferences (MSC2359), but this is vapourware.
Finally, if your client doesn't implement 1:1 and doesn't implement widgets (or if your don't have permission to perform them in that room) then obviously hitting the call button won't work. But that's hardly fragmentation; it's just incomplete implementations.
Now, if there were multiple competing ways of doing 1:1 calls, or of doing conferences flying around, I'd totally agree we were seeing XMPP-style fragmentation. But we're not, and if we did, we'd see that as a massive bug and jump on it to resolve the fork in the Matrix Spec Core Team, and ensure that matrix.org/docs/spec resolved the collision asap.
> Every time Matrix comes up, someone mentions xmpp and immediately the flinging starts about how broken it is and how those developers let it slide into obscurity.
Perhaps, but that's not me or the Matrix core team doing that (well, other than back in the very early days when I was still feeling a bit salty about XMPP). We can't control what randoms on the internet say though :|
This really isn't an example of protocol fragmentation - it's behaving precisely as expected.
There is precisely one way to do a 1:1 VoIP/Video call in Matrix: https://matrix.org/docs/spec/client_server/r0.6.1#voice-over.... It hasn't actually changed since 2015 when we first added it to the spec, until recently when there's a proposal to improve it called MSC2746: https://github.com/matrix-org/matrix-doc/blob/dbkr/msc2746/p.... Now, this is a proposal to patch the spec - it's a Matrix Spec Change. It retains backwards compatibility with the current behaviour, and once the MSC is approved it'll be merged into the spec and the MSC will be discarded.
There is precisely one way currently to do VoIP/Video conferences in Matrix: you instantiate a 'widget', to embed whatever web conferencing service you like into your chat room (e.g. Jitsi). You use the widget API to control it. Widgets aren't actually merged into the spec yet, but are specified at MSC1236 (https://github.com/matrix-org/matrix-doc/issues/1236), which should get reviewed and merged in real soon now. So, as long as your client implements widgets, you can do conferences. In future, we have plans for native Matrix conferences (MSC2359), but this is vapourware.
Finally, if your client doesn't implement 1:1 and doesn't implement widgets (or if your don't have permission to perform them in that room) then obviously hitting the call button won't work. But that's hardly fragmentation; it's just incomplete implementations.
Now, if there were multiple competing ways of doing 1:1 calls, or of doing conferences flying around, I'd totally agree we were seeing XMPP-style fragmentation. But we're not, and if we did, we'd see that as a massive bug and jump on it to resolve the fork in the Matrix Spec Core Team, and ensure that matrix.org/docs/spec resolved the collision asap.
> Every time Matrix comes up, someone mentions xmpp and immediately the flinging starts about how broken it is and how those developers let it slide into obscurity.
Perhaps, but that's not me or the Matrix core team doing that (well, other than back in the very early days when I was still feeling a bit salty about XMPP). We can't control what randoms on the internet say though :|
The approaches are more similar than you think. At least the parts you mention Experimental XEPs let people experiment. The compliance suites provide a single spec controlled by a committee. And the differences don't matter when the user experience is the same.
XEP-0027 OpenPGP has been officially obsolete for Matrix's entire life. XEP-0374 OpenPGP never went past experimental. It was officially deferred 3 years ago. OMEMO is the only proposal active.
The compliance suites tell you what you need for file transfer. Core requires XEP-0363 for file upload. Advanced requires XEP-0234 and XEP-0261 for direct transfer. You can ignore the experiments.
Figuring out what features 2 clients share can be confusing with either protocol. Looking at Matrix's clients matrix[1] is easier than finding a list of XEPs for each client. But you still have to figure out what the server supports and what it doesn't have to.
The real difference is how 1 company dominates the Matrix ecosystem.
[1] https://matrix.org/clients-matrix/
XEP-0027 OpenPGP has been officially obsolete for Matrix's entire life. XEP-0374 OpenPGP never went past experimental. It was officially deferred 3 years ago. OMEMO is the only proposal active.
The compliance suites tell you what you need for file transfer. Core requires XEP-0363 for file upload. Advanced requires XEP-0234 and XEP-0261 for direct transfer. You can ignore the experiments.
Figuring out what features 2 clients share can be confusing with either protocol. Looking at Matrix's clients matrix[1] is easier than finding a list of XEPs for each client. But you still have to figure out what the server supports and what it doesn't have to.
The real difference is how 1 company dominates the Matrix ecosystem.
[1] https://matrix.org/clients-matrix/
> Whereas Matrix ensures that there is only ever one way of doing a given operation at any point
I trust you that you mean what you say, but I wonder what an implementation would look like (from a user-perspective), that supports something like OpenPGP -> OTR -> Ratchet. I mean, upgrading security over time is mandatory and when I remember how it evolved for XMPP I clearly do not want an implementation that still has all the draw-backs that OTR had.
So I agree that XMPP is lacking some good governance, but I don't see the rivaling XEPs necessarily as the core problem, as many of them had quite some time between the drafts. The bigger issue is that many clients don't have enough developer momentum, so that XEPs that were drafted like 5 years ago are not implemented yet.
Regarding implementation bugs: I know XMPP has the compliance suite, but I feel like it doesn't catch bugs and is more of a basic testing for feature compatibility. Does Matrix have some kind of test suite, that simulates physical disconnects, package loss and the likes for testing real client and server implementations? I know that would not be an easy feat, but I wonder what the best way would be to build something like that, to improve the quality of the existing implementations.
I trust you that you mean what you say, but I wonder what an implementation would look like (from a user-perspective), that supports something like OpenPGP -> OTR -> Ratchet. I mean, upgrading security over time is mandatory and when I remember how it evolved for XMPP I clearly do not want an implementation that still has all the draw-backs that OTR had.
So I agree that XMPP is lacking some good governance, but I don't see the rivaling XEPs necessarily as the core problem, as many of them had quite some time between the drafts. The bigger issue is that many clients don't have enough developer momentum, so that XEPs that were drafted like 5 years ago are not implemented yet.
Regarding implementation bugs: I know XMPP has the compliance suite, but I feel like it doesn't catch bugs and is more of a basic testing for feature compatibility. Does Matrix have some kind of test suite, that simulates physical disconnects, package loss and the likes for testing real client and server implementations? I know that would not be an easy feat, but I wonder what the best way would be to build something like that, to improve the quality of the existing implementations.
OpenPGP could mean XEP-0374 which is newer than OTR. But XEP-0374 went from experimental to deferred 3 years ago. It isn't really competing with OMEMO.
> Whereas Matrix ensures that there is only ever one way of doing a given operation at any point
Python used to claim the same thing when it was a fresh new language, as a reaction to Perl where the opposite was encouraged. Becoming mature and anchored in reality changed some of that.
Python used to claim the same thing when it was a fresh new language, as a reaction to Perl where the opposite was encouraged. Becoming mature and anchored in reality changed some of that.
Some implementations not implementing all the XEPs is exactly my point. "A Matrix server" / "a Matrix client" conveys an expectation that certain functionality will be included. Low-feature implementations will exist, but I assume it will be clear they serve a niche.
Synapse is the only fully featured server. Element Web/Desktop is the only fully featured client. Most of the other servers and clients are aiming for general use. They're just incomplete. Some of the niche implementations like weechat-matrix are in better shape actually.[1]
[1] https://matrix.org/clients-matrix/
[1] https://matrix.org/clients-matrix/
Dendrite is meant to be good too.
It's late beta but no push notifications (!!), no presence, no search, no cross-signing of E2E keys, no clustered deployments.
I've been wondering for a while how hard it would be to adapt Ejabberd into being a Matrix server implementation. Only a small part of Ejabberd is actually all that XMPP-specific.
> Because XMPP sucks
YES! I never understand why people are so eager to defend XMPP for its so called perfection, when it's so bad in reality. The "eXtensible" part only is a huge and unfixable mistake. Make it feature complete, not eXtensible, or you end up with dozens of clients not working the same way and subtly failing in multiple scenarios.
YES! I never understand why people are so eager to defend XMPP for its so called perfection, when it's so bad in reality. The "eXtensible" part only is a huge and unfixable mistake. Make it feature complete, not eXtensible, or you end up with dozens of clients not working the same way and subtly failing in multiple scenarios.
The ridiculous part is that nowadays IRC has more stable and reliable (and beautiful) clients for web and mobile than XMPP.
IRC is lacking a ton of features. It doesn't even have a standardized charset! Nowadays people want E2E encryption, using multiple devices, multimedia, real-time audio + video, contact management, push notifications etc.
I use IRC. I use it with multiple devices, including desktop and phone. I have "contact management" and notifications (whatever push is) on both desktop and my phone. I use OTR for private messages. The only thing it may be missing is audio/video, but I think even that may be doable, I have not researched it due to lack of need.
Interesting. Are these bolted on features standardized anywhere? In RFCs perhaps?
I do not think so. I SSH into my Linux server where I run irssi (IRC client) inside screen (screen manager). Some people use IRCCloud. That is how I can use it on both my phone and desktop. On phone I use JuiceSSH, but I have used ConnectBot before, too.
I have notifications because my status bar and window manager know how to handle urgency hints and "bellIsUrgent" is set to true.
OTR is natively supported by irssi. Weechat supports it via a plugin. I do not know about other clients.
As for contact management... I am not entirely sure what it entails. Some IRC servers (such as UnrealIRCd, for example) support "WATCH" which is a notify-type system. The server will send you a message when any nickname in your watch list logs on or off. You can read about it more here, along with alternatives: https://ircv3.net/specs/core/monitor-3.2. There are a couple of different ways to achieve the same thing.
I have notifications because my status bar and window manager know how to handle urgency hints and "bellIsUrgent" is set to true.
OTR is natively supported by irssi. Weechat supports it via a plugin. I do not know about other clients.
As for contact management... I am not entirely sure what it entails. Some IRC servers (such as UnrealIRCd, for example) support "WATCH" which is a notify-type system. The server will send you a message when any nickname in your watch list logs on or off. You can read about it more here, along with alternatives: https://ircv3.net/specs/core/monitor-3.2. There are a couple of different ways to achieve the same thing.
UTF-8 has been in the standard since the mid 2000s. You're just as much out of date with the other assertions.
Did the company switch to Matrix?
XMPP was pretty successful in the 2000s. More than Matrix so far. There were missed opportunities but the main reason it declined was Facebook and Google decided closed was more profitable than open.
Why exclude native clients?
XMPP was pretty successful in the 2000s. More than Matrix so far. There were missed opportunities but the main reason it declined was Facebook and Google decided closed was more profitable than open.
Why exclude native clients?
I'm not even convinced they decided it was more profitable. The decision probably went something like this:
Manager: Our users want this feature
Developer: We can't add that because it will cause incompatibility with XMPP clients
Manager: This is the 50th feature that has been blocked by XMPP and hardly any of our users use it. Time to cut off support for it
Manager: Our users want this feature
Developer: We can't add that because it will cause incompatibility with XMPP clients
Manager: This is the 50th feature that has been blocked by XMPP and hardly any of our users use it. Time to cut off support for it
It's probably much simpler than that:
"It has come to my attention that clients which we do not control connect to our service. This severely limits the monetization opportunities available to us. Please fix before it is caught in a due diligence."
"It has come to my attention that clients which we do not control connect to our service. This severely limits the monetization opportunities available to us. Please fix before it is caught in a due diligence."
That and they probably threw hoards of cash and engineering at the problem.
Speaking as a Matrix person: we're quite happy with our adoption, which is accelerating exponentially, and we didn't build Matrix as a hobby: it's been the team's fulltime day job since 2014. Before that we used XMPP (ejabberd + spark + XMPP.framework etc) and eventually decided to build a totally different architecture: one focused on syncing conversation history, rather than sending instant messages. I don't think it dilutes or splits the thin developer community: instead it's increased interest in open comms enormously (as well as helping spur the XMPP community into improving their stuff). Just as Linux didn't somehow destroy BSD.
Well, even if I prefer XMPP over Matrix and still disagree over the developer ressources, I wish you the best of luck, because both solutions, being federated, are inherently better than the competition by design.
I can only thank you for your work. Open messaging ecosystems are much better off for it.
> They took a few different design decisions, but in my opinion, nothing that would justify building a competing solution and splitting the already thin developer community.
I'd argue that the design decisions are key to the success of Matrix. However I do not think that there must be any splitting. Checkout the XMPP Bridge that matrix.org hosts.
> I just feel so depressed, seeing so much work being done on a very important subject, not fulfilling its potential due to missing focus.
As long as there are people like Eric, there is hope :) I think we have more focus than ever before, even within the XMPP community :)
I'd argue that the design decisions are key to the success of Matrix. However I do not think that there must be any splitting. Checkout the XMPP Bridge that matrix.org hosts.
> I just feel so depressed, seeing so much work being done on a very important subject, not fulfilling its potential due to missing focus.
As long as there are people like Eric, there is hope :) I think we have more focus than ever before, even within the XMPP community :)
The XMPP bridge means the user communities don't have to be split. The developer communities are.
>Checkout the XMPP Bridge that matrix.org hosts.
Is there a description of how to generate an address on the other network? This sounds awesome. A working bridge gets a Matrix user access to the tens of thousands of federated XMPP servers.
Is there a description of how to generate an address on the other network? This sounds awesome. A working bridge gets a Matrix user access to the tens of thousands of federated XMPP servers.
Was XMPP improved at that time?
Or a mess of nonstandard addons/plugins that you had to match up, like mods in a multiplayer videogame?
Or a mess of nonstandard addons/plugins that you had to match up, like mods in a multiplayer videogame?
They said XMPP improved afterward. The point is a combined effort would be in better shape than XMPP or Matrix now.
The problem with XMPP was every client implemented different parts of the standard. The problem with Matrix is every client implements different parts of the standard.[1]
[1] https://matrix.org/clients-matrix
The problem with XMPP was every client implemented different parts of the standard. The problem with Matrix is every client implements different parts of the standard.[1]
[1] https://matrix.org/clients-matrix
Not being able to share Rick and Morty stickers or have a group call is fine to miss out on.
Having to choose from multiple encryption addons to get started even chatting, that's not a comparable experience.
I miss XMPP, but it's time to let go.
Having to choose from multiple encryption addons to get started even chatting, that's not a comparable experience.
I miss XMPP, but it's time to let go.
Close. It’s a mess of standard addons/plugins that you have to match up, like mods in a multiplayer videogame.
Sadly for me, it’s also the only modern messenger that has decent desktop clients that don’t look like discord. But I guess that this will never change as I seem to be pretty lonely with my want of those.
Sadly for me, it’s also the only modern messenger that has decent desktop clients that don’t look like discord. But I guess that this will never change as I seem to be pretty lonely with my want of those.
The solution was nearly always to create golden packages which could be summarised.
XMPP v1 server could be just XMPP itself.
A v2 client/server includes packages for OMEMO, Websocket, Resumeable connections
A v3 client/server has packages for whatever else becomes the de jour.
The idea that you can just mix and match without ever standardising on a set of capabilities was a large part of what killed XMPP and was entirely solvable.
XMPP v1 server could be just XMPP itself.
A v2 client/server includes packages for OMEMO, Websocket, Resumeable connections
A v3 client/server has packages for whatever else becomes the de jour.
The idea that you can just mix and match without ever standardising on a set of capabilities was a large part of what killed XMPP and was entirely solvable.
This is what happens. Compliance suites are published annually: https://xmpp.org/about/compliance-suites.html
This is either barely getting used or not used enough (or maybe too hidden). Because I had only seen single XEP lists for both clients and servers I looked at.
Thanks! Beeper looks amazing.
> Our desktop client is closed source, but you can use Element (or any open source Matrix client) if you prefer.
I see most bridges are licensed AGPLv3 [0]: Aren't you required to AGPLv3 the desktop client, too?
[0] For ex: https://gitlab.com/nova/whatsapp/-/blob/master/LICENSE
> Our desktop client is closed source, but you can use Element (or any open source Matrix client) if you prefer.
I see most bridges are licensed AGPLv3 [0]: Aren't you required to AGPLv3 the desktop client, too?
[0] For ex: https://gitlab.com/nova/whatsapp/-/blob/master/LICENSE
> Then aren't you required to AGPLv3 the desktop client, too?
Only if the desktop client is legally a derivative work of the bridges.
Only if the desktop client is legally a derivative work of the bridges.
The "network connection" provision of AGPL doesn't require you to open source anything you use to talk to it, just modifications of it. To make it clearer:
Client <--> Server. The server is AGPL licenced.
I can write a client to talk to the server and I don't have any licence restrictions. For example - if I write a web client to talk to an AGPL web server, I don't have to open source the client.
If I modify the AGPL server, and then put that modified server on the internet then the AGPL terms require me to make available the modified source code.
I am not a lawyer, but this is my understanding of this: https://choosealicense.com/licenses/agpl-3.0/
Client <--> Server. The server is AGPL licenced.
I can write a client to talk to the server and I don't have any licence restrictions. For example - if I write a web client to talk to an AGPL web server, I don't have to open source the client.
If I modify the AGPL server, and then put that modified server on the internet then the AGPL terms require me to make available the modified source code.
I am not a lawyer, but this is my understanding of this: https://choosealicense.com/licenses/agpl-3.0/
[deleted]
Couldn't all of these chat apps change their TOS and forbid Matrix bridges like Discord forbid running through 3rd party client? You depend on all of those chat providers to allow you to hook everything in one app.
This has happened multiple times in the past with similar aggregators. I will be surprised if it does not happen again. But good luck. I want products like this to exist.
Yes they can!
But it's unlikely they would all do it at the same time.
t2bot.io hosts a Discord bridge and to my knowledge it is officially allowed by Discord (else they could not have more than 100+ bridge users).
The Discord bridge you are talking about here is a Bot which is officially allowed by Discord, however the Bot APIs have serious limitations that make it unsuitable for full bridging (which is basically making a Discord client). For example it can only be used in "channels" and needs to be added to each "server" by an admin. This means that it is hard to use in servers where you are a guest and you can't use it in DMs and non-channel group chats.
I assume they are offering a "puppeting bridge" which means it acts as you, however this means that it is using unsupported APIs and Discord has been known to ban accounts for this.
I think it is pretty disingenuous to put the Discord logo on the homepage without pointing out those caveats.
I assume they are offering a "puppeting bridge" which means it acts as you, however this means that it is using unsupported APIs and Discord has been known to ban accounts for this.
I think it is pretty disingenuous to put the Discord logo on the homepage without pointing out those caveats.
Having actually run through spantaleev's matrix-docker-ansible-deploy twice in the past, and run the Matrix bridge stack for a few months each time, this is interesting.
Eventually I would have some bridges get out of sync (ie I responded on mobile but the bridge doesn't show my message or messages would get lost) but overall, it worked really well.
The downside of having one error in relative isolation is not the bug itself but that it makes you distrust the stack entirely and you end up double checking the source messenger "just to make sure"
Having said that, it looks like you've done quite a bit of development on the bridges from a quick glimpse of the Gitlab repos.
How are those forks related to Tulir's bridges? Does he integrate any of your changes and vice versa or are they two unique development streams? In your comment, it sounds like Tulir is working with you?
Anyway, I'm looking forward to this very much because the multi-messenger thing has been the bane of my existence, I swear. I would gladly pay $10/month to fix this as I have online (and offline) friends all over the place.
Oh, for the unified inbox, is there any way to "group" by a person? For example, if I primarily chat with someone on Line but then occasionally talk through iMessage. I would expect them to render as two different "conversations" but logically, they're one person of course.
Lastly, I thought the line about shipping an iPhone was satire. You might want to put a note in there like "No really".
Eventually I would have some bridges get out of sync (ie I responded on mobile but the bridge doesn't show my message or messages would get lost) but overall, it worked really well.
The downside of having one error in relative isolation is not the bug itself but that it makes you distrust the stack entirely and you end up double checking the source messenger "just to make sure"
Having said that, it looks like you've done quite a bit of development on the bridges from a quick glimpse of the Gitlab repos.
How are those forks related to Tulir's bridges? Does he integrate any of your changes and vice versa or are they two unique development streams? In your comment, it sounds like Tulir is working with you?
Anyway, I'm looking forward to this very much because the multi-messenger thing has been the bane of my existence, I swear. I would gladly pay $10/month to fix this as I have online (and offline) friends all over the place.
Oh, for the unified inbox, is there any way to "group" by a person? For example, if I primarily chat with someone on Line but then occasionally talk through iMessage. I would expect them to render as two different "conversations" but logically, they're one person of course.
Lastly, I thought the line about shipping an iPhone was satire. You might want to put a note in there like "No really".
Tulir is on the Beeper team, he's the one writing all the bridges! They are quite reliable now.
Ahh, I think I was a little confused. I had noted that there were "forks" on Gitlab but they're actually just mirrors it looks like so fork is perhaps a misnomer in this case on the part of Gitlab?
Also curious to know what the schedule is like for people to sign up? I seemingly never received anything that states I'm on a waitlist or just that my sign up didn't generally go into a blackhole.
Also curious to know what the schedule is like for people to sign up? I seemingly never received anything that states I'm on a waitlist or just that my sign up didn't generally go into a blackhole.
How does this play with the security of e.g. Signal? Security and privacy is the main reason many of us will use it so I wouldn't want to compromise it.
Would love to use this on Linux, I find all the desktop apps really rubbish (and very happy to pay for it).
Would love to use this on Linux, I find all the desktop apps really rubbish (and very happy to pay for it).
Matrix's encryption is based on the same cryptographic ratchet technology used by Signal. The protocols involved are called Olm and Megolm.
Olm is used for establishing 1-on-1 sessions between pairs of users (or rather, their devices). This is then used as a secure channel to share Megolm keys. A Megolm key is ratcheted with each room message sent and is used to derive a symmetric AES key with which the message is actually encrypted. Periodically (every N messages) a new Megolm key is created and re-shared with room participants.
So the end result is that it has roughly the same security as Signal, except that a single compromised Megolm key will reveal N messages to the attacker instead of just a single message. In return, the protocol is much more scalable, enabling relatively efficient large end-to-end encrypted groups. Otherwise, all the session self-healing, forward secrecy properties of Signal are retained.
TL;DR: Approximately the same as Signal, trading a tiny bit of security in the event of a key leak for more scalable encryption in the setting of large groups.
Olm is used for establishing 1-on-1 sessions between pairs of users (or rather, their devices). This is then used as a secure channel to share Megolm keys. A Megolm key is ratcheted with each room message sent and is used to derive a symmetric AES key with which the message is actually encrypted. Periodically (every N messages) a new Megolm key is created and re-shared with room participants.
So the end result is that it has roughly the same security as Signal, except that a single compromised Megolm key will reveal N messages to the attacker instead of just a single message. In return, the protocol is much more scalable, enabling relatively efficient large end-to-end encrypted groups. Otherwise, all the session self-healing, forward secrecy properties of Signal are retained.
TL;DR: Approximately the same as Signal, trading a tiny bit of security in the event of a key leak for more scalable encryption in the setting of large groups.
I believe this is true for Matrix-to-Matrix communication. However if I understand correctly the bridges terminate the e2e encryption and then connect to the third party service (possibly with a different e2e session).
So, essentially, if I self-host the bridges then there's no security issue (otherwise it looks like a third party has access to the keys to decrypt messages, unless the negotiation just creates a tunnel through which the signal connection occurs)?
yes, it's a secure tunnel to your self-hosted bridge from client
so the answer is: yes this reduces security over signal for both myself and whomever i’m chatting with. due to this, seems like a questionable choice to include signal.
is the N configurable by the user? ( different paid tier)
I don't know much about Beeper, but I do know more about Matrix in general. And yes, the N is configurable there (as in, you can change it in a client implementation, even if it isn't particularly common to have it exposed as a setting).
I would love to pay you for this (though I think $10 is a bit steep), but I don't want you to be able to read my messages, which you are since you run the bridges.
Also, didn't they say something about being able to run the full stack self-hosted?
Is it possible to build a zero-trust version of this?
No. Bridges need plaintext messages, because that's what they feed into WhatsApp and other clients.
Can't you put the bridges on a pi, like described at the website?
see the self hosting options
In the FAQ, I'd suggest adding the words price & pricing. That way I can ctrl-f to either "price", or "pricing".
To my weird brain, and after studying accounting, the word "cost" is more of a business/accounting perspective of "expense".
Whereas the word "price" seems to be more of a consumer perspective of "expense".
Yes, it's a little pedantic ;)
Cost: "(of an object or action) require the payment of (a specified sum of money) before it can be acquired or done."
Price: "the amount of money expected, required, or given in payment for something."
I think it's because:
Costing = Accounting. It's the "science" of determining the expense of producing a product or service.
Pricing = Marketing. Marketing is what consumers experience.
To my weird brain, and after studying accounting, the word "cost" is more of a business/accounting perspective of "expense".
Whereas the word "price" seems to be more of a consumer perspective of "expense".
Yes, it's a little pedantic ;)
Cost: "(of an object or action) require the payment of (a specified sum of money) before it can be acquired or done."
Price: "the amount of money expected, required, or given in payment for something."
I think it's because:
Costing = Accounting. It's the "science" of determining the expense of producing a product or service.
Pricing = Marketing. Marketing is what consumers experience.
Holy! I don't remember the last time I was this excited for a chat app. I just saw your tweet and came to HN to post it but this was already on the front page haha.
Just a quick question (completely noob question, I apologize in advance), do bridges work like APIs? Where can I read more about this protocol?
Really looking forward to this Eric!
Just a quick question (completely noob question, I apologize in advance), do bridges work like APIs? Where can I read more about this protocol?
Really looking forward to this Eric!
Simplest way to learn about the API is to look at several bot implementations https://github.com/maubot/maubot
Awesome! Thanks a ton!
I would really like one of these apps to integrate with LINE, which is really big in Japan.
Every time I see something like this I check again, but it’s so far never been supported.
Every time I see something like this I check again, but it’s so far never been supported.
Question: If you already have bridges in place to send and receive messages in other clients, is there any reason I can't chat from those clients?
In other words, I want to be able to use the Messages app on my iPhone to communicate with other people using Discord, WhatsApp, Slack, etc. I would absolutely pay $10 a month for that, and I almost never subscribe to anything!
Is that something you could turn on, or is it more complicated than I'm imagining?
P.S. I'm wearing a Pebble 2 right now. Thanks for all your work on that, it's a great device.
Edit: Actually, even just some sort of XMPP gateway, so I could use any client that supports XMPP, would basically be enough for me.
In other words, I want to be able to use the Messages app on my iPhone to communicate with other people using Discord, WhatsApp, Slack, etc. I would absolutely pay $10 a month for that, and I almost never subscribe to anything!
Is that something you could turn on, or is it more complicated than I'm imagining?
P.S. I'm wearing a Pebble 2 right now. Thanks for all your work on that, it's a great device.
Edit: Actually, even just some sort of XMPP gateway, so I could use any client that supports XMPP, would basically be enough for me.
...as I think about this more, could I, uh, just in general get more detail on what clients can be used? Asking as someone who has never used Matrix before.
Wasn't this NovaChat before? I signed up for the beta and was thinking of planning a session with you for enrolment as you mentioned in your last email, hasn't had time yet, sorry. Saw it here at the last HN post.
If it's available now I'll gladly use it. Since the Whatsapp thing a couple weeks ago even more of my contacts have spread out to different apps and it drives me nuts.
Pricing sounds good too, I know these bridges need work to maintain. I've tried to run them myself using the docker script but it's not ideal. And supporting the maintenance is great.
If it's available now I'll gladly use it. Since the Whatsapp thing a couple weeks ago even more of my contacts have spread out to different apps and it drives me nuts.
Pricing sounds good too, I know these bridges need work to maintain. I've tried to run them myself using the docker script but it's not ideal. And supporting the maintenance is great.
Yes, Beeper is the new name for NovaChat.
Ok, great, I like the new name a lot better!
It was just funny when I read it first, I thought someone else had the same idea :)
It was just funny when I read it first, I thought someone else had the same idea :)
As someone who self-hosts a bunch of bridges–great work! Really appreciate seeing a simple solution for people who don't know or don't want to self host.
Also, seeing that Tulir is not working entirely pro-bono but that his efforts are backed by a company makes me more hopeful that the bridge development will continue!
Also, seeing that Tulir is not working entirely pro-bono but that his efforts are backed by a company makes me more hopeful that the bridge development will continue!
Do you guys plan on continuing with the jailbreakable iPhone method for iMessage bridging for the foreseeable future, or is there an alternative one can expect that is being worked on?
Congrats on the launch! Subscribed and can't wait to get access :).
Do you know what is WhatsApp's stance on a Matrix bridge and using it to provide a service? They've known to have a pretty harsh stance on other services that attempted to integrate ([0], [1]) and even banned users from the platform for attempting to scrape their own data.
Would be very curious to know more details about your WhatsApp integration setup. Thanks in advance!
[0] - https://www.xda-developers.com/whatsapp-sends-cease-desist-a...
[1] - https://www.reddit.com/r/Windows10/comments/89g926/whatsapp_...
Do you know what is WhatsApp's stance on a Matrix bridge and using it to provide a service? They've known to have a pretty harsh stance on other services that attempted to integrate ([0], [1]) and even banned users from the platform for attempting to scrape their own data.
Would be very curious to know more details about your WhatsApp integration setup. Thanks in advance!
[0] - https://www.xda-developers.com/whatsapp-sends-cease-desist-a...
[1] - https://www.reddit.com/r/Windows10/comments/89g926/whatsapp_...
How does your iMessage integration compare to AirMessage?
I've been using AirMessage for a couple months now on my new Android phone and it is about 80% reliable. Images and videos also take significantly longer to processes than if I were to use an iPhone.
I wonder if Beeper would be an upgrade over AirMessage or if it is essentially the same.
I've been using AirMessage for a couple months now on my new Android phone and it is about 80% reliable. Images and videos also take significantly longer to processes than if I were to use an iPhone.
I wonder if Beeper would be an upgrade over AirMessage or if it is essentially the same.
Beeper requires a Mac like AirMessage. Or they'll send you a jailbroken iPhone.
How is imessage so hard to reverse engineer that its easier to send someone a jailbroken iphone to use? Surely the protocol can't even change much since many users are stuck on old versions as its part of the OS.
I seem to recall that registering for iMessage requires sending the ID (or a signature maybe?) of real Apple hardware. So you could reverse the API but unless someone has hardware that they don't plan on using iMessage on it won't help much.
How old are these iPhones cause that's the oddest part of that setup I've heard.
iPhone 4.[1]
[1] https://twitter.com/ericmigi/status/1351934418961661959
[1] https://twitter.com/ericmigi/status/1351934418961661959
Thanks for that! It's kind of funny to me, but also kind of cool. I guess you just have to be sure to charge the iPhone every now and then.
I think the idea is you leave it plugged in at home.
Ha, when all those apps started breaking out, I knew that there would be a day when someone would finally connect them. Thank you for the story about how Matrix enabled you here, we're all standing on the backs of turtles!
I think part of the problem is that there is no infrastructure for something like this on iOS and Android.
With webOS, there was a single messaging app that integrated SMS, Skype, Facebook and Google. The latter part was implemented using libpurple, so it was relatively easy to extend this to all messaging that libpurple supports.
I really liked that approach (marketing name was "Synergy", unified messaging was only a small part of this), but it's quite obvious that neither Apple nor Google have any interest in adopting this unified approach for anything but their respective own messaging of the day.
With webOS, there was a single messaging app that integrated SMS, Skype, Facebook and Google. The latter part was implemented using libpurple, so it was relatively easy to extend this to all messaging that libpurple supports.
I really liked that approach (marketing name was "Synergy", unified messaging was only a small part of this), but it's quite obvious that neither Apple nor Google have any interest in adopting this unified approach for anything but their respective own messaging of the day.
I think if we could get the world unified on a single chat protocol we can expect things like this to emerge. Of course it will be unlikely to happen soon, if at all.
Plus we all know that Google really wants to own a chat app so maybe they will decide not to make it first-class in Android i fit seems like a threat.
Plus we all know that Google really wants to own a chat app so maybe they will decide not to make it first-class in Android i fit seems like a threat.
We could always start building on webOS again, it's open now, right?
There are people working on this: https://webos-ports.org
A few years ago I was in contact with someone from the project to integrate the changes that I did, so their messaging client should now support pretty much everything that Pidgin supports (which, as I learned today, nowadays includes Matrix, Signal, Telegram and Steam as well through plugins).
Maybe I should install that on my old Nexus 4 and see how far they got... :)
A few years ago I was in contact with someone from the project to integrate the changes that I did, so their messaging client should now support pretty much everything that Pidgin supports (which, as I learned today, nowadays includes Matrix, Signal, Telegram and Steam as well through plugins).
Maybe I should install that on my old Nexus 4 and see how far they got... :)
I would love for this to keep expanding to more inboxes, and beyond to news feeds and other kinda inbox-shaped things. Why not aggregate Facebook news feed, Instagram, Twitter, Reddit, HN, your local newspaper, etc. It's what Google Reader woulda/coulda/shoulda become.
Please, break down the walled gardens. Free us from the whims of the product managers pumping out redesign after redesign for all the services we use.
Please, break down the walled gardens. Free us from the whims of the product managers pumping out redesign after redesign for all the services we use.
Thank you, I am very glad to pay you money to solve this problem!
Without an open source client, how can I be assured that you aren't harvesting user data through it?
Without an open source client, how can I be assured that you aren't harvesting user data through it?
At first, you have to trust us though we will perform auditing eventually. If you would like to use an open source Matrix client, that works as well!
Thank you for Pebble! It was my main Diabetes app for seeing the current blood glucose directly from my wrist until my Pebble 2 finally died a year ago. It was almost like magic and had a week of battery life.
The commercial matrix bridge is an excellent idea. I was able to get my homeserver running, but it is a hell of a job to get everything working. When it does work, oh boy, it again feels like magic!
The commercial matrix bridge is an excellent idea. I was able to get my homeserver running, but it is a hell of a job to get everything working. When it does work, oh boy, it again feels like magic!
So good to hear that! Have you considered buying one off ebay? Still some good deals there :)
Nicely done, congratulations on the launch!
This brings back memories. In 2017 I had launched a similar 'chat-app network' platform[1] for privacy focused dating using Bot API of the respective platforms allowing communication between,
Messenger <-> Telegram <-> Viber <-> LINE
It was quickly selected for acceleration by one of those platforms. The features included half-duplex messaging(user had to wait for reply to send a message to prevent harassment), optional location, near-far dates switch etc.
Adoption was quick, the first major issue I ran into was that in SE Asian countries many used their children photographs for profile picture in chat apps, which obviously was a no go for dating, so I had to implement Amazon Rekognition to detect age and make those users change their profile picture and their profiles weren't displayed until it was changed. At peak it processed 200,000 images/month.
Obviously bridge approach as in Beeper(Matrix) is a more reliable approach than using Bot API, especially due to UI/UX limitations and even platform stability issues(Some bot API were nascent).
In about a year it even crossed the Trough of Sorrow with ~2,40,000 users on Messenger alone.[2] But had to let go of it as I fell sick(was told I could become quadriplegic[3]) and as single founder bus factor hit my startup.
I received several offers to buy the platform, but I didn't sell it as I was not sure whether the buyers would stick to the privacy promises. So I just nuked the platform.
Even if I had continued, I'm not sure whether I could have monetized successfully as selling digital content was explicitly prohibited by these platforms because of Apple Tax/Google Tax(it would mean that the chat apps function as app store).
[1]https://www.youtube.com/watch?v=aeuL8_Qinhs
[2]https://web.archive.org/web/20181203031208/https://finddate....
[3]https://abishekmuthian.com/i-was-told-i-would-become-quadrip...
This brings back memories. In 2017 I had launched a similar 'chat-app network' platform[1] for privacy focused dating using Bot API of the respective platforms allowing communication between,
Messenger <-> Telegram <-> Viber <-> LINE
It was quickly selected for acceleration by one of those platforms. The features included half-duplex messaging(user had to wait for reply to send a message to prevent harassment), optional location, near-far dates switch etc.
Adoption was quick, the first major issue I ran into was that in SE Asian countries many used their children photographs for profile picture in chat apps, which obviously was a no go for dating, so I had to implement Amazon Rekognition to detect age and make those users change their profile picture and their profiles weren't displayed until it was changed. At peak it processed 200,000 images/month.
Obviously bridge approach as in Beeper(Matrix) is a more reliable approach than using Bot API, especially due to UI/UX limitations and even platform stability issues(Some bot API were nascent).
In about a year it even crossed the Trough of Sorrow with ~2,40,000 users on Messenger alone.[2] But had to let go of it as I fell sick(was told I could become quadriplegic[3]) and as single founder bus factor hit my startup.
I received several offers to buy the platform, but I didn't sell it as I was not sure whether the buyers would stick to the privacy promises. So I just nuked the platform.
Even if I had continued, I'm not sure whether I could have monetized successfully as selling digital content was explicitly prohibited by these platforms because of Apple Tax/Google Tax(it would mean that the chat apps function as app store).
[1]https://www.youtube.com/watch?v=aeuL8_Qinhs
[2]https://web.archive.org/web/20181203031208/https://finddate....
[3]https://abishekmuthian.com/i-was-told-i-would-become-quadrip...
This feels too good to be true. It feels a "Shut up and take my money". I thought with effective demise of XMPP and myriad differing standards and proprietary apps & protocols, this could not happen anymore.
I'll check out your site and you may have some very happy paid users soon :)
I'll check out your site and you may have some very happy paid users soon :)
This is amazing. I had precisely this idea ~6mo ago (but never actually built anything). Excited to see you’ve done all the heavy lifting for me. I also love the paid model to align interests and the ability to self host. I will definitely be giving this a test run.
On the website it looks like it says Android and iOS via Element [appears to be the renamed Riot.im matrix client]. Is there no custom iOS or Android application for Beeper that this will ship with?
Yeah riot was renamed, as they finally admitted that it was a weird name with negative connotations.
Never understood what was wrong with the name vector by the way. That was even nicer IMO.
Never understood what was wrong with the name vector by the way. That was even nicer IMO.
Why would you want that additional attack surface?
Will you Support Threema in the future?
Came here to ask the same. It would only make sense to me if Threema is also added to the list (Signal already is)
This is fantastic stuff. Thank you for building it. Matrix truly is a wonderful piece of software.
Where is the open source code for the iMessage bridge?
It doesn't exist yet.[1]
[1] https://news.ycombinator.com/item?id=25849040
[1] https://news.ycombinator.com/item?id=25849040
What are the system requirements for self-hosting?
I thought Apple barred iMessages from being sent/retrieved outside of the specific iMessage app? How did you dodge that?
Apparently:
How in the world did you get iMessage to work on Android and Windows? This was a tough one to figure out! Beeper has two ways of enabling Android, Windows and Linux users to use iMessage: we send each user a Jailbroken iPhone with the Beeper app installed which bridges to iMessage, or if they have a Mac that is always connected to the internet, they can install the Beeper Mac app which acts as a bridge.
How in the world did you get iMessage to work on Android and Windows? This was a tough one to figure out! Beeper has two ways of enabling Android, Windows and Linux users to use iMessage: we send each user a Jailbroken iPhone with the Beeper app installed which bridges to iMessage, or if they have a Mac that is always connected to the internet, they can install the Beeper Mac app which acts as a bridge.
Hmmm, you could pretty easily spin up a Mac container with the Beeper app and then remote into that from your phone. Seems like a lot of work.
Still, it seems like they didn't really dodge anything at all. It's the same gripe I had with Signal: if I have to switch between iMessage and Signal, then I'll never be able to sell Signal to my family.
Still, it seems like they didn't really dodge anything at all. It's the same gripe I had with Signal: if I have to switch between iMessage and Signal, then I'll never be able to sell Signal to my family.
I'm not sure if this project will go any further, nor if iMessage works inside here, but this is an easier way forward:
https://github.com/popey/sosumi-snap
https://github.com/popey/sosumi-snap
libpurple (the thing behind Adium/Pidgin) has plugins for a lot of the major messaging networks today.
Hey, does it support Telegram stickers?
I don't know about the app, but you can use Telegram stickers in Matrix - somewhat.
However, it requires a few minutes of work:
https://github.com/maunium/stickerpicker
For video watchers: https://www.youtube.com/watch?v=Yz3H6KJTEI0
Kudos to Tulir!!!
This is good. What competitors do you fear?
Also, why no WeChat? The stickers are the best there !
Also, why no WeChat? The stickers are the best there !
Doesn't using this with Discord run a risk of your account getting banned for using a third-party client? That's why the Cordless developer shut down the project: https://github.com/Bios-Marcel/cordless
If I can login to your service with the API given, there should be no reason for a ban. And this is what annoys me with today's communication protocols; your forced to enjoy their service only with their provided application.
It never used to be like this. MSN messenger,AIM even YIM; they all had FOSS applications.
It never used to be like this. MSN messenger,AIM even YIM; they all had FOSS applications.
They didn't start that way though. It wasn't until they were forced to play nice under regulatory action.
They're using HalfShot's appservice bridge I think, which works entirely through the standard Discord API with bot users. IIRC Discord is very much aware of the project.
Discord's generally fine with anything using it's API/gateways as long as it's NOT logging in as a "real" user.
Discord's generally fine with anything using it's API/gateways as long as it's NOT logging in as a "real" user.
Well, that would be what they're doing here, no?
There's two ways to connect discord. One is a appservice. You got a bot user that relays everything and you get messages that are basically "BotUser: <Alice> Hello world" using the official API. This is currently allowed, but doesn't allow access to 1:1 chats. The other is "puppeting", the bot logs in as Alice by Alice providing her credentials and hitting endpoints the actual Web app uses. This results in a less obvious, nicer experience for people on he discord side but is the one that is banned
After a disclaimer, that sounds like a problem between the user and the Discord people.
Yes — I would be the user, and I would like to avoid that problem.
t2bot.io hosts a Discord bridge and to my knowledge it is officially allowed by Discord (else they could not have more than 100+ bridge users).
So I imagine there might be the possibility of it being allowed for Beeper as well.
So I imagine there might be the possibility of it being allowed for Beeper as well.
t2bot.io uses webhook/bot based bridging which at least doesn't trigger the "no custom clients" clause (as you aren't using any real user account tokens)
The broader question of whether bridges are allowed seems to be broadly yes as there are many other bridges out there for Discord (IRC/slack ones) and those haven't been shut down either.
I think so long as you aren't abusive, Discord don't care.
The broader question of whether bridges are allowed seems to be broadly yes as there are many other bridges out there for Discord (IRC/slack ones) and those haven't been shut down either.
I think so long as you aren't abusive, Discord don't care.
Could someone shed a light on economics of working on such kind of a project?
Aren't developing third-party client for the entity which you do not control and somehow compete with is typically a futile experience?
Doesn't it go against most of ToS-es directly (e.g. Discord/WhatsApp happily ban accounts using third-party clients) or indirectly (I guess no proprietary chat platform will be exactly happy having third-party clients that compete with their official and controlled app).
I mean how people justify building a business on it given that it essentially means that they have to play on the other's people playground by the rules which can be changed at any time. Like tomorrow Slack would decide to disallow any third-party apps and you're done.
Aren't developing third-party client for the entity which you do not control and somehow compete with is typically a futile experience?
Doesn't it go against most of ToS-es directly (e.g. Discord/WhatsApp happily ban accounts using third-party clients) or indirectly (I guess no proprietary chat platform will be exactly happy having third-party clients that compete with their official and controlled app).
I mean how people justify building a business on it given that it essentially means that they have to play on the other's people playground by the rules which can be changed at any time. Like tomorrow Slack would decide to disallow any third-party apps and you're done.
It’s very risky to build a service that relays directly on the API layer of other commercial services. If any of there chat apps change their APIs to stop Beeper traffic then they will lose users. Some services will cause a larger loss than others.
I think the economics are simple. The company is two devs and they charge $10/month. If the costs are $4/month/user then they need 83k users to clear a quarter million a year in profit per dev. This isn’t a unicorn, but it has the potential to bring in good money while it lasts.
I think the economics are simple. The company is two devs and they charge $10/month. If the costs are $4/month/user then they need 83k users to clear a quarter million a year in profit per dev. This isn’t a unicorn, but it has the potential to bring in good money while it lasts.
Discord allows relay bridges (using bot accounts), but not puppeting.
I just installed matrix and bridges for telegram, slack and whatsapp using the linked ansible playbook. I used my own domain and a new cheap vps.
this took me about an hour.
I connected Element on my android phone to my new matrix server and now I have all chats in one app and on desktop. That is totally great and worked far better and easier than I imagined. Well done.
Thanks for leaving this comment saying that you were successful and it only took about an hour, otherwise I wouldn't have had much confidence in the scripts. It took me ~2 hours but I'm not as well versed in ansible. I'm finally off of Slack's awful electron app.
Any chance you can write down a little more tactical instructions on how you did this? I'd love to try this out, but am not super technical.
I really just followed the very good docs here: https://github.com/spantaleev/matrix-docker-ansible-deploy/b...
Granted I'm very familiar with ansible but for someone not technical it should be doable, too.
Granted I'm very familiar with ansible but for someone not technical it should be doable, too.
Thanks for the reply! I'm going to give it a shot!
[deleted]
I am interested, but not sure of system requirements. What kind of resources does it use on your cheap VPS?
I use a hetzner cx21 with two CPUs and two GB RAM. So far it is performant enough.
> we send each user a Jailbroken iPhone with the Beeper app installed which bridges to iMessage
Huh, I wonder how this is sustainable. I assume there is a greater cost than 10 bucks a month for this option? I wouldn't want to be the one managing the logistical effort of that!
Huh, I wonder how this is sustainable. I assume there is a greater cost than 10 bucks a month for this option? I wouldn't want to be the one managing the logistical effort of that!
It says you can run a Mac app but presumably this is to bridge in users outside the Apple ecosystem.
So probably it is the cheapest iPhone that has a year or two worth of iOS support left and just sits plugged in.
While a novel hack, I would never want my iMessage conversations being bridged to a service outside the Apple ecosystem.
While I have no doubt this service will do their best with security, it relies on leaking data from Apple.
Imagine if someone built an insecure bridge for FaceTime Audio, and the caller did not know the recipient was using a bridge service.
Any reliance on Apple’s massive investment in the privacy and security of a FaceTime transmission goes out the window and into the hands of an unknown 3rd party.
It also tricks the sender into thinking that their secure iMessage conversations are what they look like.
I know when i see a green chat bubble, that low level people at Verizon can access the content of the messages.
I see this as a big problem, where the goal of letting more people in for UX reasons undermines expectations of privacy from those uninvolved in the use of the product.
People are mention Discord being unhappy with this, but I imagine Apple would see this as an abomination.
So probably it is the cheapest iPhone that has a year or two worth of iOS support left and just sits plugged in.
While a novel hack, I would never want my iMessage conversations being bridged to a service outside the Apple ecosystem.
While I have no doubt this service will do their best with security, it relies on leaking data from Apple.
Imagine if someone built an insecure bridge for FaceTime Audio, and the caller did not know the recipient was using a bridge service.
Any reliance on Apple’s massive investment in the privacy and security of a FaceTime transmission goes out the window and into the hands of an unknown 3rd party.
It also tricks the sender into thinking that their secure iMessage conversations are what they look like.
I know when i see a green chat bubble, that low level people at Verizon can access the content of the messages.
I see this as a big problem, where the goal of letting more people in for UX reasons undermines expectations of privacy from those uninvolved in the use of the product.
People are mention Discord being unhappy with this, but I imagine Apple would see this as an abomination.
> It also tricks the sender into thinking that their secure iMessage conversations are what they look like.
If you send a message to someone, you are assuming that anything can happen to it unless you have a legal agreement to the contrary. They could have a keylogger (malware or device-management), someone looking over their shoulder, take a screenshot, forget to sign out of the library computer, etc.
The end-to-end-encryption on iMessage gets defeated for most people anyway if they have iCloud Backup on.
If you send a message to someone, you are assuming that anything can happen to it unless you have a legal agreement to the contrary. They could have a keylogger (malware or device-management), someone looking over their shoulder, take a screenshot, forget to sign out of the library computer, etc.
The end-to-end-encryption on iMessage gets defeated for most people anyway if they have iCloud Backup on.
You are right, this has always been true with taking a photo of a screen and printing it out on your printer.
This defeats any truly end-to-end encrypted conversation.
I think you are also right to compare this service to malware.
It takes content intended for a secured environment maintained by one party and exfiltrates it into another.
This other environment is protected by an entity that is neither bound by the reputation damage of failing to keep the information secure, nor on the receiving end of funds that can be directed to keep it secure.
Since 100% of the iMessage content, text and photos flows through this environment, it is not like occasionally taking photos of conversations. It is the wholesale duplication of the data.
iCloud Backups are also encrypted, and are the security of that system is maintained by the first party the conversations were originally sent by.
This defeats any truly end-to-end encrypted conversation.
I think you are also right to compare this service to malware.
It takes content intended for a secured environment maintained by one party and exfiltrates it into another.
This other environment is protected by an entity that is neither bound by the reputation damage of failing to keep the information secure, nor on the receiving end of funds that can be directed to keep it secure.
Since 100% of the iMessage content, text and photos flows through this environment, it is not like occasionally taking photos of conversations. It is the wholesale duplication of the data.
iCloud Backups are also encrypted, and are the security of that system is maintained by the first party the conversations were originally sent by.
> The end-to-end-encryption on iMessage gets defeated for most people anyway if they have iCloud Backup on.
iCloud backups are encrypted using a unique key which is only unlockable with the user password, which is itself protected in hardware. So no, it doesn’t defeat the purpose.
iCloud backups are encrypted using a unique key which is only unlockable with the user password, which is itself protected in hardware. So no, it doesn’t defeat the purpose.
Syncing messages through iCloud uses end to end encryption. Backups don't.[1]
[1] https://support.apple.com/en-us/HT202303
[1] https://support.apple.com/en-us/HT202303
Keep reading:
> Messages in iCloud also uses end-to-end encryption. If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages. This ensures you can recover your Messages if you lose access to iCloud Keychain and your trusted devices. When you turn off iCloud Backup, a new key is generated on your device to protect future messages and isn't stored by Apple.
> Messages in iCloud also uses end-to-end encryption. If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages. This ensures you can recover your Messages if you lose access to iCloud Keychain and your trusted devices. When you turn off iCloud Backup, a new key is generated on your device to protect future messages and isn't stored by Apple.
Messages in iCloud and iCloud Backup are different features. That says Apple has the key as long as iCloud Backup is on.
This is exactly correct. Apple engineered that page to read to people who are scanning quickly that "it's encrypted, it's fine" when in fact iCloud Backup, which includes complete plaintext message history (and SMS history too, which Apple normally would not see, plus all iMessage/SMS attachments like photos and videos) is NOT end to end encrypted but encrypted with Apple keys, and can be decrypted by Apple at any time without the user's device or password.
It's perhaps the most shady thing they do. Nothing on that page is a lie, yet if you read it without an intimate knowledge of Apple's services ("iCloud", vs "Messages in iCloud", vs "iCloud Backup") you will get an impression of the opposite of what is true.
Additionally, they were going to e2e encrypt backups, but the FBI asked them not to, and so they didn't, and Apple and the FBI can read every message in every backup without a warrant.
It's perhaps the most shady thing they do. Nothing on that page is a lie, yet if you read it without an intimate knowledge of Apple's services ("iCloud", vs "Messages in iCloud", vs "iCloud Backup") you will get an impression of the opposite of what is true.
Additionally, they were going to e2e encrypt backups, but the FBI asked them not to, and so they didn't, and Apple and the FBI can read every message in every backup without a warrant.
[deleted]
> the FBI can read every message in every backup without a warrant.
Under what legal framework could this be possible?
Under what legal framework could this be possible?
It's Section 702 of the FISA Amendments Act, aka FAA702, cited in Apple's transparency report as FISA (they turned over 30,000+ users' data without a warrant in 2019), and better known to the general public by its internal NSA codename of PRISM, thanks to Ed Snowden telling us that this is the primary, #1 source of information used by NSA spies.
Apple wasn't lying when they said they "had never heard of PRISM"—until Snowden, it was not known by that name outside of the NSA/IC.
It is regularly used against US users, in the US, as well as people in other countries. Snowden cited this use (resulting from a classified, private interpretation of FAA702 made by the classified FISA court) against US citizens as one of his main reasons for going public in the summer of 2013 with the fact that this is happening.
https://www.eff.org/702-spying
https://en.m.wikipedia.org/wiki/Foreign_Intelligence_Surveil...
https://en.m.wikipedia.org/wiki/PRISM_(surveillance_program)
Apple wasn't lying when they said they "had never heard of PRISM"—until Snowden, it was not known by that name outside of the NSA/IC.
It is regularly used against US users, in the US, as well as people in other countries. Snowden cited this use (resulting from a classified, private interpretation of FAA702 made by the classified FISA court) against US citizens as one of his main reasons for going public in the summer of 2013 with the fact that this is happening.
https://www.eff.org/702-spying
https://en.m.wikipedia.org/wiki/Foreign_Intelligence_Surveil...
https://en.m.wikipedia.org/wiki/PRISM_(surveillance_program)
Okay, I am familiar with prism.
However, the context of this thread is to compare the relative security of Apple iMessage and iCloud backups with what happens to those messages when they are exfiltrated by Beeper.
I do not see the existence of Prism belying the practical expectation of security Apple users get from iCloud and iMessage.
It doesn’t make the point that beeper’s service has a similar level of security.
But to your point, some apple iMessage users will unknowingly have their data shared with a third party if the recipient is using beeper and doesn’t tell them.
Which makes having a friend quietly using beeper a bit like having a prism inquiry.
However, the context of this thread is to compare the relative security of Apple iMessage and iCloud backups with what happens to those messages when they are exfiltrated by Beeper.
I do not see the existence of Prism belying the practical expectation of security Apple users get from iCloud and iMessage.
It doesn’t make the point that beeper’s service has a similar level of security.
But to your point, some apple iMessage users will unknowingly have their data shared with a third party if the recipient is using beeper and doesn’t tell them.
Which makes having a friend quietly using beeper a bit like having a prism inquiry.
> belying the practical expectation of security Apple users get from iCloud and iMessage.
What practical expectation of security? iCloud backups are not E2E encrypted.
If you're expecting that it should be impossible for anyone else to read your messages, then don't use iCloud. If you don't trust the people you're messaging, then don't message them. Trying to build a platform that guarantees security regardless of who you message is a fallacy, that system doesn't exist and people shouldn't think about security in those terms. If you send someone information, you can not guarantee with any messaging system that they won't copy that information and send it to someone else. Recipient trust is part of the equation.
Any one of your friends can just copy and paste text out of iMessage, you have no technical guarantee that your messages are going to stay in Apple's ecosystem. If you send a message to someone with an Android phone, it gets sent in plaintext over SMS. If they're in a group chat, boom, no more encryption. Apple themselves can't keep your data in the iMessage environment, they exfiltrate it for you whenever you text someone who's not on iOS.
And even if you don't have any friends on Android, all of the data that you're worried about leaking gets stored non-E2E encrypted to Apple's servers whenever anyone in your messaging pool turns on backups -- and I guarantee most of your contacts on iOS have backups turned on.
But you're worried about security flaws in the Matrix protocol? Based on what?
If you actually need E2E encryption, you shouldn't be using iMessage in the first place, you should be using something like Signal, a program where the default settings for you and your contacts aren't going to leak your messages and break their encryption. And at least Signal warns you in advance if a contact isn't on the same platform. At least it works on multiple operating systems so you aren't virtually guaranteed that it'll be impossible to do E2E chat with some of your friends.
What practical expectation of security? iCloud backups are not E2E encrypted.
If you're expecting that it should be impossible for anyone else to read your messages, then don't use iCloud. If you don't trust the people you're messaging, then don't message them. Trying to build a platform that guarantees security regardless of who you message is a fallacy, that system doesn't exist and people shouldn't think about security in those terms. If you send someone information, you can not guarantee with any messaging system that they won't copy that information and send it to someone else. Recipient trust is part of the equation.
Any one of your friends can just copy and paste text out of iMessage, you have no technical guarantee that your messages are going to stay in Apple's ecosystem. If you send a message to someone with an Android phone, it gets sent in plaintext over SMS. If they're in a group chat, boom, no more encryption. Apple themselves can't keep your data in the iMessage environment, they exfiltrate it for you whenever you text someone who's not on iOS.
And even if you don't have any friends on Android, all of the data that you're worried about leaking gets stored non-E2E encrypted to Apple's servers whenever anyone in your messaging pool turns on backups -- and I guarantee most of your contacts on iOS have backups turned on.
But you're worried about security flaws in the Matrix protocol? Based on what?
If you actually need E2E encryption, you shouldn't be using iMessage in the first place, you should be using something like Signal, a program where the default settings for you and your contacts aren't going to leak your messages and break their encryption. And at least Signal warns you in advance if a contact isn't on the same platform. At least it works on multiple operating systems so you aren't virtually guaranteed that it'll be impossible to do E2E chat with some of your friends.
[deleted]
>I would never want my iMessage conversations being bridged to a service outside the Apple ecosystem
I think setting up an API outside the Apple ecosystem would be fine. It's crazy that we not only don't have a standard protocol for messaging anymore, the primary services don't even allow for integration.
I think setting up an API outside the Apple ecosystem would be fine. It's crazy that we not only don't have a standard protocol for messaging anymore, the primary services don't even allow for integration.
They're using unsupported iPhones.[1]
[1] https://twitter.com/ericmigi/status/1351934418961661959
[1] https://twitter.com/ericmigi/status/1351934418961661959
Worth considering that these always-connected devices exfiltrating data are not only jail broken, but unable to receive iOS security updates.
I was wondering how this is solved... and here's the answer! Wish there was a free/foss DIY solution to this.
https://bluebubbles.app/
https://airmessage.org/ (dev on subreddit indicates it will be open sourced once some code cleanup happens)
https://airmessage.org/ (dev on subreddit indicates it will be open sourced once some code cleanup happens)
Expect Apple to come down on this like a tonne of bricks and render the whole thing impossible very quickly.
Never gonna happen as long as checkra1n can pwn the latest iOS. Cat and mouse game. MobileSubstrate/Substitute/libhooker is too powerful a platform.
This is great!
I love the idea of hosted bridges (in fact I was thinking about starting my own service like this) and I'm glad that the bridges themselves are open source. However I would much rather that the client was open source as well (It would make it way easier to get all my friends to Matrix with a well polished client).
Basically $10 a month for access to bridges that funds bridge development is great however I don't want some of that to fund the development of a closed-source client. If the client was opened, or had work upstreamed to an open source client I would be all on board.
Basically $10 a month for access to bridges that funds bridge development is great however I don't want some of that to fund the development of a closed-source client. If the client was opened, or had work upstreamed to an open source client I would be all on board.
I get what you're saying. However, I think this is nice a compromise. The closed-source client is pushes out continued development of the bridges for a little longer than it otherwise would. The client only matters insomuch as it has good bridges, so the bridges must naturally come first.
In the longer term, if a project like this succeeds, then all messaging clients become defined by their feature set rather than their vendor lock-in. If Facebook Messenger wants to compete with Beeper, then it better be able to connect to Hangouts, etc.
I welcome a player that pushes chat clients as a whole towards interoperability and commoditization, and am happy to (as a side effect) support a proprietary client that helps drive additional platform support over time (eg, I don't see Airbnb on the list of Beeper messaging bridges yet, etc).
In the longer term, if a project like this succeeds, then all messaging clients become defined by their feature set rather than their vendor lock-in. If Facebook Messenger wants to compete with Beeper, then it better be able to connect to Hangouts, etc.
I welcome a player that pushes chat clients as a whole towards interoperability and commoditization, and am happy to (as a side effect) support a proprietary client that helps drive additional platform support over time (eg, I don't see Airbnb on the list of Beeper messaging bridges yet, etc).
I'm also skeptical about the proprietary client, I would have kind of thought that having a good Matrix client was more important than the bridges; I almost would have preferred to see the client Open and the bridges properietary.
But that is a very convincing comment that kind of sells me on the idea, and it matches what I've seen in other places. Cross platform play on consoles, region locking, etc... once you get enough momentum that something becomes a selling point, it becomes a lot harder for the overall ecosystem to ignore it.
So yeah, the argument you raise makes me feel a lot more positive about the service.
But that is a very convincing comment that kind of sells me on the idea, and it matches what I've seen in other places. Cross platform play on consoles, region locking, etc... once you get enough momentum that something becomes a selling point, it becomes a lot harder for the overall ecosystem to ignore it.
So yeah, the argument you raise makes me feel a lot more positive about the service.
I agree, I think it is a "good enough" compromise that I would pay for it. However I think that clients are more important than bridges right now, I would love to get people natively on Matrix. I want both but it is a shame not to be funding an open client. I think I would just continue using Element as a client if they let me in to show what I prioritize.
This looks nice, but $10 a month is a tough sell for me (I use only two of the supported platforms everyday, with about 20 messages total in a day, on average).
Also, why does the site ask for an email address to get started? An explanation of why along with the on boarding process would be useful.
That aside, the Meet Our Team section on the homepage shows “This is some text inside of a div block.” on the right. Is this an oversight or is it some inside joke?
Also, why does the site ask for an email address to get started? An explanation of why along with the on boarding process would be useful.
That aside, the Meet Our Team section on the homepage shows “This is some text inside of a div block.” on the right. Is this an oversight or is it some inside joke?
Charging per network makes sense to me. I would only use this for iMessage and signal, so it’s only worth a buck or two a month for me. If I was using everything offered I would gladly pay $10 a month.
I would pay $100/mo for it.
I think it's just not a pain point for everyone. In a lot of countries, "everyone" uses a single platform and it's not a big deal.
As a US user of 5 apps, some for business, it's just a mess and a constant source of friction.
I think it's just not a pain point for everyone. In a lot of countries, "everyone" uses a single platform and it's not a big deal.
As a US user of 5 apps, some for business, it's just a mess and a constant source of friction.
> I would pay $100/mo for it.
For a good quality one? Same. Signed up.
For a good quality one? Same. Signed up.
> In a lot of countries, "everyone" uses a single platform and it's not a big deal.
> As a US user of 5 apps, some for business, it's just a mess and a constant source of friction.
Depends on what countries you have in mind, but it's pretty much the same elsewhere. Messenger, Instagram DMs, WhatsApp, Snapchat, Viber, Discord, Telegram, Signal... You just need to have all of them and this seems like a very elegant solution for having all your messages in one place.
> As a US user of 5 apps, some for business, it's just a mess and a constant source of friction.
Depends on what countries you have in mind, but it's pretty much the same elsewhere. Messenger, Instagram DMs, WhatsApp, Snapchat, Viber, Discord, Telegram, Signal... You just need to have all of them and this seems like a very elegant solution for having all your messages in one place.
Agreed. I would kill to not have to use Snapchat's app to talk to some of my friend groups. Same goes for Instagram.
Looks like that's a bug that occurs when javascript is disabled. It should have another two entries.
I assume they're now aware of it :)
I assume they're now aware of it :)
I assume some part of the iMessage faq is a joke ?
> This was a tough one to figure out! Beeper has two ways of enabling Android, Windows and Linux users to use iMessage: we send each user a Jailbroken iPhone with the Beeper app installed which bridges to iMessage, or if they have a Mac that is always connected to the internet, they can install the Beeper Mac app which acts as a bridge.
> This was a tough one to figure out! Beeper has two ways of enabling Android, Windows and Linux users to use iMessage: we send each user a Jailbroken iPhone with the Beeper app installed which bridges to iMessage, or if they have a Mac that is always connected to the internet, they can install the Beeper Mac app which acts as a bridge.
[deleted]
While I think the core focus of Beeper as a cross platform messenger is great, the bigger positive here in my opinion is a matrix client with good UX and design.
The user experience portrayed here is much more in line with what is required to get people less technical on one decentralized/federated network, such as matrix.
I’m currently working towards the same effort, in a very different stage of development, in that regard with https://github.com/syphon-org/syphon.
Props to Eric, Tulir, and the team for making such a good looking client!
The user experience portrayed here is much more in line with what is required to get people less technical on one decentralized/federated network, such as matrix.
I’m currently working towards the same effort, in a very different stage of development, in that regard with https://github.com/syphon-org/syphon.
Props to Eric, Tulir, and the team for making such a good looking client!
Wait, did they do anything for the Matrix client? Their "Get Beeper" section makes it seem like they just use the normal Matrix client.
> Available on MacOS, Windows, Linux iOS and Android via Element
Which i assume is https://element.io/ ?
> Available on MacOS, Windows, Linux iOS and Android via Element
Which i assume is https://element.io/ ?
Wow Syphon looks sweet. Gonna try it (knowing that it's not a finished product)
I've been following Syphon, it looks great!
It really sucks that we can't go back in time to the days chat apps looked like AIM, ICQ, etc... The current model of making giant React based Electron apps for a chat app is idiotic IMO. Maybe that's the price we pay for corporatizing chat?
I liked breaking my chats out into different tiny windows I could see everything happening at once.
I liked breaking my chats out into different tiny windows I could see everything happening at once.
I've been using this for several months now, and it's one of the biggest digital quality-of-life improvements I made in 2020. Getting modern chat networks to interact is never something I thought I would see. Congrats to Eric and co!
What's the worst glitch you've had, if you don't mind me asking?
In the very early days the bridges were less reliable, and there was no warning if a bridge disconnected, so there were a few times when I didn't realize a message didn't go through for a few hours.
That's been fixed now :)
That's been fixed now :)
This looks awesome, only I tried to "get started" and it looks like it's just mined a bunch of my contact details into Airtable, which seems suboptimal?
I'm experiencing the same thing, I'm unable to sign up.
I mentioned bitlbee elsewhere in this thread, but in case people haven't heard of it, it's a similar beast to Beeper but it bridges chat systems to an IRC client of your choice (you can use an IRC bouncer or whatever else you want to connect to bitlbee). It supports several chat systems https://wiki.bitlbee.org/ including apparently Matrix.
I mostly mention it as a historical note because bitlbee's use of IRC as the bridged protocol means that it's of limited usefulness on mobile. It was fantastic for me in the days before smartphones became a thing, but I do at least 50% of my "chat" on my phone these days.
I mostly mention it as a historical note because bitlbee's use of IRC as the bridged protocol means that it's of limited usefulness on mobile. It was fantastic for me in the days before smartphones became a thing, but I do at least 50% of my "chat" on my phone these days.
The use of IRC as the bridge protocol is actually the best feature for me because of the multitude of client options of available including several for Emacs.
I love the text focus and at least for the protocols I care about images and videos are presented as URLs so they are easily accessible.
I love the text focus and at least for the protocols I care about images and videos are presented as URLs so they are easily accessible.
I'm a long time user of IRC and bitlbee (I wrote my own IRC bridge for a popular webchat back in 2004) and the last few years I've been using weechat-android as a mobile client and it's not too bad. It's still IRC, so image/video/gif attachments are out of the question, but for someone who's been using text-mode IRC clients for the last 20 years it's a godsend.
You can add an app like quassel / quasseldroid on top for some mod cons like unlimited scrollback.
Multiprotocol clients and transports are a dead end.
Most walled garden messaging service developers are openly hostile to third-party clients - this goes back to early 00s and ICQ war against QIP and other much better clients. Modern technology and app distribution model has made it far easier for service owners to enforce their rules of using their service.
Most walled garden messaging service developers are openly hostile to third-party clients - this goes back to early 00s and ICQ war against QIP and other much better clients. Modern technology and app distribution model has made it far easier for service owners to enforce their rules of using their service.
This is a single protocol client, which can be replaced by any Matrix client.
This is why it is so good
This is why it is so good
The problem is not the client at all. Look at the history of libpurple/gaim. My chat setup used to be an irc client connected to bitlbee (which uses libpurple), and (way back when) the various chat system owners would either intentionally or unintentionally break the integrations fairly regularly.
They have no incentive to keep their API stable since they control their official client.
On top of this, when you try to bridge disparate comms platforms together, you end up with the client having only the common subset of functionality, or with the client emulating functionality clumsily.
The example I'm thinking of is in iMessage, if you're on a group text thread with people who are on SMS instead of iMessage, "tapback" reactions (the thumbs-up, exclamation, haha, etc ones) show up as "<name> emphasized '<the full text of the message they !!ed>'".
They have no incentive to keep their API stable since they control their official client.
On top of this, when you try to bridge disparate comms platforms together, you end up with the client having only the common subset of functionality, or with the client emulating functionality clumsily.
The example I'm thinking of is in iMessage, if you're on a group text thread with people who are on SMS instead of iMessage, "tapback" reactions (the thumbs-up, exclamation, haha, etc ones) show up as "<name> emphasized '<the full text of the message they !!ed>'".
For me partial support is a key feature. Not having to send read notifications, not having to look at bs like stickers and the ability to ignore chat deletions is really great about bridging :)
it's way harder to make all Matrix clients support all protocols and somehow sync them properly than to write a App Service that can be plugged to a server.
Most multi protocol clients used the same libraries. The hard part was reverse engineering the protocol changes.
What you refer to is called 'transport',such transports for xmpp exist for more than 20 years.
They didn't fly because service owners don't really want them to. Sometimes services resist actively, sometimes passively. The protocol you use is irrelevant, xmpp, matrix, email, whatever - this is never-ending game of catch up which the service owner will win, because he needs users to use their stock app and all their metadata.
They didn't fly because service owners don't really want them to. Sometimes services resist actively, sometimes passively. The protocol you use is irrelevant, xmpp, matrix, email, whatever - this is never-ending game of catch up which the service owner will win, because he needs users to use their stock app and all their metadata.
Bridges make the server a multi protocol client.
not really, they are all individual pieces put together - independent of the server
They're called bridges because they connect the Matrix server to the other servers. They aren't independent. And reverse engineering protocol changes wouldn't be easier if they were.
What is discussed here is nothing new. I ran a jabber ICQ transport for myself and colleagues as far back as in 2005. It was a constant source of pain. Whenever the ICQ protocol changed, you had to wait till developers of transport updated the lib, so you could resume the service. If anything, now it is far easier for service maintainers to update the protocol because the app distribution model got much more efficient - just one tap on the smartphone, so you can just suspend the functionality until the users updates, whereas ICQ devs had to rely on users manually downloading and installing the update to their official apps, slowing the update cycle by many months/years.
TLDR: It didn't work then, won't work now.
TLDR: It didn't work then, won't work now.
it works already - and only the bridge needs to be updated.
Everything else can stay the same.
Unlike you, I have actually experienced running the bridge that 'only needs to be updated'. Good luck with that.
Any one of those services can instantly plug up the hole (especially the Apple one) and it's over. Building a business reliant on other company's platforms rarely ends well.
This is really cool however I’m worried about getting banned from discord using for using your service as I believe it’s not authorized on discord to use third party client
Are there already many similar apps? I used two: Rambox https://rambox.pro/ and Franz https://meetfranz.com
No, those are totally different. They're just Electron shells around web versions of chat apps. They're also extremely resource-intensive and buggy.
Someone forked Rambox and kept it FOSS, and it's called Hamsket.
Someone forked Rambox and kept it FOSS, and it's called Hamsket.
There is also an OSS hard-fork of Franz called Ferdi, for anyone interested. Been using it for some time, I don't love nor hate it.
Those are glorified browsers wrapping the web based clients in dedicated "tabs". AFAIK it looks like Beeper hosts a matrix<->service bridge between those platforms, and their client actually unifies messages in a single inbox. Seems to be different.
https://texts.com - it's not released yet but you can sign up for early access.
Interesting! It would be great though if you could sign up without a Google account. One of the reasons I want something like this is the data collection of all these separate apps. I'm trying to get away from Google :)
Anyone who is already in the early-access?
This looks like an interesting alternative and I am looking forward to trying both of them out once I get in
This looks like an interesting alternative and I am looking forward to trying both of them out once I get in
Yep, check out some tweets by our users here: https://twitter.com/TextsHQ
Ah you are the creator! I had a couple of questions:
1. Are you using unofficial APIs or do you have custom bridges much like Beeper?
2. How would you deal with messaging apps like Snapchat?
Also, you were right in saying "app invites are the new currency of SV"[0]. Keep up the good work!
[0] https://twitter.com/KishanBagaria/status/1294754273998172160...
1. Are you using unofficial APIs or do you have custom bridges much like Beeper?
2. How would you deal with messaging apps like Snapchat?
Also, you were right in saying "app invites are the new currency of SV"[0]. Keep up the good work!
[0] https://twitter.com/KishanBagaria/status/1294754273998172160...
> Are you using unofficial APIs or do you have custom bridges much like Beeper?
All platform integrations were developed in-house from the ground up. We don't use the Matrix protocol but support it.
> How would you deal with messaging apps like Snapchat?
We don't plan on supporting Snapchat since it's single session only.
All platform integrations were developed in-house from the ground up. We don't use the Matrix protocol but support it.
> How would you deal with messaging apps like Snapchat?
We don't plan on supporting Snapchat since it's single session only.
why login with Google and not regular email?
If I'm not mistaken, if you're using this with Signal you'd better be running the bridge yourself or your messages are unencrypted on someone else's server.
Is this actually active now?
The FAQ implies it's an available product. Going through the form indicates I may be invited to use at some unspecified point in the future... :-/
The FAQ implies it's an available product. Going through the form indicates I may be invited to use at some unspecified point in the future... :-/
I'm also confused. I filled out the form and was then redirected with no other info?
I guess it’s only a matter of time until Facebook et al fight the bridges in form of lawsuits and API changes. Some years ago Facebook’s chat was accessible via the Jabber protocol. I think they won’t like users switching away from their apps and miss the control and ad revenue.
Serious question: Is the below a joke or legitimate?
How in the world did you get iMessage to work on Android and Windows? This was a tough one to figure out! Beeper has two ways of enabling Android, Windows and Linux users to use iMessage: we send each user a Jailbroken iPhone with the Beeper app installed which bridges to iMessage, or if they have a Mac that is always connected to the internet, they can install the Beeper Mac app which acts as a bridge.
How in the world did you get iMessage to work on Android and Windows? This was a tough one to figure out! Beeper has two ways of enabling Android, Windows and Linux users to use iMessage: we send each user a Jailbroken iPhone with the Beeper app installed which bridges to iMessage, or if they have a Mac that is always connected to the internet, they can install the Beeper Mac app which acts as a bridge.
It’s so sincere that it doesn’t sound like a joke. Maybe the fact that they are a paid subscription they can do this? What’s the pricing of Beepr?
$10 a month. It has to go somewhere...
>This was a tough one to figure out! Beeper has two ways of enabling Android, Windows and Linux users to use iMessage: we send each user a Jailbroken iPhone with the Beeper app installed which bridges to iMessage,
is this not a joke?
is this not a joke?
Yea, I'm really confused by that FAQ item.
Oooh, this is so exciting.
I went down the bridged chat rabbit hole earlier this year when I realized I had to be checking signal, telegram, WhatsApp, WeChat, iMessage and multiple emails to be on top of communication. I stopped when I realized how difficult WhatsApp and WeChat were going to be, though.
I want to pay for this, right now. Ideally double if it will help you launch. :)
I went down the bridged chat rabbit hole earlier this year when I realized I had to be checking signal, telegram, WhatsApp, WeChat, iMessage and multiple emails to be on top of communication. I stopped when I realized how difficult WhatsApp and WeChat were going to be, though.
I want to pay for this, right now. Ideally double if it will help you launch. :)
WhatsApp is not that hard anymore. Only issue is that you have to run the Android client somewhere. But you can do that on your phone.
Holy crap, this is inspiring. The blog post (https://medium.com/@ericmigi/the-universal-communication-bus...) really says it all.
I've sent you an email. It's great to see the problem being addressed the right way.
I've sent you an email. It's great to see the problem being addressed the right way.
Some of the supported messaging apps doesn't allow automation or provide APIs. I appreciate the work that went into supporting those.
But I don't think it would be possible to have consistent support for some of those chat apps. Things like API changes or just getting you server ips banned would disrupt service.
How does it work? Most of those protocols are’t exactly open.
Also please add support for Google Chat.
Also please add support for Google Chat.
I use weechat for this and it works fine. Slack, Discord, Signal, etc. all bridge fine (though Signal is a bit messy). And of course, IRC. The one thing I haven't figured out how to connect is MS Teams, and it doesn't look like this service offers it anyway; is there a reason to use it?
I run a similar setup although with a different set of services: IRC, Slack through wee-slack, Hangouts through bitlbee with purple-hangouts, Facebook Messenger through bitlbee with bitlbee-facebook. Slack and Hangouts mostly work, but FB Messenger is a pain, attachments rarely work and it disconnects fairly often. So if the Beeper bridges end up being more reliable (possibly due to people being paid to work on them), I might just give it a try.
That is, once weechat-matrix works together with wee-slack… (https://github.com/poljar/weechat-matrix/issues/248) :-)
That is, once weechat-matrix works together with wee-slack… (https://github.com/poljar/weechat-matrix/issues/248) :-)
How do I get started? I put in my email like 10 minutes ago and have received nothing...
I was also a little confused, you'll get an email in a bit explaining that there is a queue for signing up and they'll inform you when you're in and that kinda thing.
Yup, just got it. Thanks.
I thought WhatsApp banned thirdparty apps some time ago? How does this work exactly?
Could be a wrapper around WhatsApp Web.
It is, the matrix WhatsApp bridge uses a reverse engineered WhatsApp web library.
> A Matrix-WhatsApp puppeting bridge. Written in Go using the Rhymen/go-whatsapp implementation of the sigalor/whatsapp-web-reveng project.
https://matrix.org/docs/projects/bridge/mautrix-whatsapp
> A Matrix-WhatsApp puppeting bridge. Written in Go using the Rhymen/go-whatsapp implementation of the sigalor/whatsapp-web-reveng project.
https://matrix.org/docs/projects/bridge/mautrix-whatsapp
I'm sure it could be done that way, but if it violates TOS then I would be wary that the bridge will be unreliable.
I had that thought, too. That’s the reason that stopped me from implementing sth like that.
I think a definitive solution to a cat-and-mice game would be an automated reverse-engineering of the chat apps.
YouTube-DL is successful despite it violating the ToS.
That's exactly what it does!
If I had a social life I'd be really excited about this
There's a list of logos for supported chat networks. But it doesn't give the names. I recognize about half of them, but it would be nice if they were written in words somewhere.
>How in the world did you get iMessage to work on Android and Windows?
>This was a tough one to figure out! Beeper has two ways of enabling Android, Windows and Linux users to use iMessage: we send each user a Jailbroken iPhone with the Beeper app installed which bridges to iMessage, or if they have a Mac that is always connected to the internet, they can install the Beeper Mac app which acts as a bridge.
Can you elaborate? Surely this is satire or I'm missing something super obvious.
>This was a tough one to figure out! Beeper has two ways of enabling Android, Windows and Linux users to use iMessage: we send each user a Jailbroken iPhone with the Beeper app installed which bridges to iMessage, or if they have a Mac that is always connected to the internet, they can install the Beeper Mac app which acts as a bridge.
Can you elaborate? Surely this is satire or I'm missing something super obvious.
"Beeper has two ways of enabling Android, Windows and Linux users to use iMessage: we send each user a Jailbroken iPhone with the Beeper app installed which bridges to iMessage, or if they have a Mac that is always connected to the internet, they can install the Beeper Mac app which acts as a bridge."
This answers my question! One iPhone for each Beeper user, no wonder the $10 monthly fee!
This answers my question! One iPhone for each Beeper user, no wonder the $10 monthly fee!
Not necessarily. In Europe we don't really use iMessage much. I would have no need for it personally.
Massive generalisation about Europe I and most people I know use it.
It's true, though. iMessage requires an Apple device, and Apple simply doesn't have a lot of market share in Europe (around 30% for iOS, less for macOS). So most people don't have access to iMessage.
Yeah that's what I meant, they don't have the critical mass to really put it on the map here. It falls back to SMS for Android recipients of course, but group chats and pictures/video are out of the question.
So in practice nobody in my circle uses it whereas Whatsapp is huge (still). I don't have iOS but I would notice if I got SMSes. The only ones I still get are insecure 2FA and spam.
So in practice nobody in my circle uses it whereas Whatsapp is huge (still). I don't have iOS but I would notice if I got SMSes. The only ones I still get are insecure 2FA and spam.
Went to their website, filled out the form, assumed I was signing up for a beta. Then...nothing happened. No automated emails, "you're in the beta!" notifications, nothing. Reached out to them on twitter, nothing. So I'm not sure what's going on, but from where I'm standing right now it looks like I gave my email to a service for no reason...
Wonderful promise ! I'm really thinking that I need an app like that one but how to justify the price ? I'm ready to pay for that kind of service but it's seems too expensive to me. How an app like this can cost you 10$ per month and in comparison an app like Procreate (best drawing app on iPad) cost you only 10$ (not per month or year, just 10$).
Great to see the progress! I really hope you can grow sustainable and profitable while facilitating Matrix. Kudos!
Tulir's been doing fantastic work, but it does seem that to ~80%, all the significant bridge maintenance/development for public IM networks is a one-man show... Makes me a bit concerned that such a key piece of the Matrix ecosystem (and IMO a crucial component for eventual success) is underfunded, neglected and relying on a single person. Keeping things working with potentially hostile changes in undocumented or unsupported APIs is not trivial.
Also, how does your roadmap for new protocols look (if you have any)?
I'd love to promote this, but without LINE it's pretty much uninteresting/useless here in Japan, Korea, and Taiwan. I heard it's also one of the top IM apps in other countries, like Thailand.
Tulir's been doing fantastic work, but it does seem that to ~80%, all the significant bridge maintenance/development for public IM networks is a one-man show... Makes me a bit concerned that such a key piece of the Matrix ecosystem (and IMO a crucial component for eventual success) is underfunded, neglected and relying on a single person. Keeping things working with potentially hostile changes in undocumented or unsupported APIs is not trivial.
Also, how does your roadmap for new protocols look (if you have any)?
I'd love to promote this, but without LINE it's pretty much uninteresting/useless here in Japan, Korea, and Taiwan. I heard it's also one of the top IM apps in other countries, like Thailand.
fwiw, separate to Tulir being funded by Beeper for all of his bridges, Element also funds a bunch of bridging work for the Matrix.org Foundation: IRC, Slack, Gitter, XMPP. Meanwhile there are other ones from the community (e.g. Discord). So, it's not entirely true to say it's a one-man show, although Tulir's prolificness is impressive :)
> Interesting, please tell me this is based on matrix
> Oh, the matrix logo among others, good thing at least
> YES !
> Oh, the matrix logo among others, good thing at least
> YES !
iMessage integration is interesting but I can’t imagine it will last. Not sure what type of wizardry you guys pulled but a cease and desist is likely on its way. Either way, congrats. Really hope it works out as this is very much needed.
Are paying users messages visible to Beeper? If so, then it's just another risk.
Any plans for VoIP SMS support?
A few years ago, I moved my phone number to VoIP.ms to save about $50/month on my cellphone bill ($70 /month for calls, texts and data vs $20/month for only data). VoIP.ms costs me roughly $2/month. With the pandemic, I cancelled my cellphone plan and make all phone calls on WiFi.
However, SMS are still a pain to deal with. About 2-3 people in my life still send them, and many apps still use them for authentication/verification.
Adding SMS support would make Beeper a lot more appealing, and might encourage people to move to VoIP (a service you might charge for when you inevitably work on audio/video bridges).
A few years ago, I moved my phone number to VoIP.ms to save about $50/month on my cellphone bill ($70 /month for calls, texts and data vs $20/month for only data). VoIP.ms costs me roughly $2/month. With the pandemic, I cancelled my cellphone plan and make all phone calls on WiFi.
However, SMS are still a pain to deal with. About 2-3 people in my life still send them, and many apps still use them for authentication/verification.
Adding SMS support would make Beeper a lot more appealing, and might encourage people to move to VoIP (a service you might charge for when you inevitably work on audio/video bridges).
I thought I’d seen this before[0]
Also:
> I make no claims to this being production level reliability. It's very much beta software. Very beta
@erohead does this quote from you 6 months ago still hold true?[1]
This is a software I’d definitely use & pay for if it was polished/worked.
I quickly looked at the GitLab source and couldn’t find the code for the iMessage bridge. How does that integration work?
[0] https://news.ycombinator.com/item?id=23693371
[1] https://news.ycombinator.com/item?id=23694933
Also:
> I make no claims to this being production level reliability. It's very much beta software. Very beta
@erohead does this quote from you 6 months ago still hold true?[1]
This is a software I’d definitely use & pay for if it was polished/worked.
I quickly looked at the GitLab source and couldn’t find the code for the iMessage bridge. How does that integration work?
[0] https://news.ycombinator.com/item?id=23693371
[1] https://news.ycombinator.com/item?id=23694933
It's 6 months better now! We haven't open sourced the iMessage bridge yet, will do that in a few weeks.
What's the story on data retention and privacy? Are there servers you store data on and it downloads from? Do you back up messages?
Perhaps this is implicit from Matrix protocol but I didn't see a clear call out on the site.
Perhaps this is implicit from Matrix protocol but I didn't see a clear call out on the site.
It’s cool, the tech behind it all, but I’m in the process of closing my WhatsApp account, so I don’t need a bridge. For some reason my initial reaction was joy that this could be a WhatsApp replacement, somehow. And at the moment, I like keeping my other chat apps in their own app window, for keeping track of what I’m doing In them. I could see myself accidentally responding to the wrong person if everything is in one app. So again, it’s cool what with the tech, and OS, but, as I think about it... am I really going to use it?
I spent a lot of time and effort merging my chat clients in the Meebo era and afterwards with XMPP proxies and I tried to keep friends from messaging me in 3 apps at once.
I gave up and that's fine. I have at least 4 messaging apps on my phone and I still prefer that over debugging a proxy. A missed message causes real-world problems, so it's important not to mess with the delicate balance that IM already carries.
If the benefit is easier archival and search, give me a solution to that that works in the background rather than a real-time proxy.
I gave up and that's fine. I have at least 4 messaging apps on my phone and I still prefer that over debugging a proxy. A missed message causes real-world problems, so it's important not to mess with the delicate balance that IM already carries.
If the benefit is easier archival and search, give me a solution to that that works in the background rather than a real-time proxy.
It looks great, I would definetely subscribe but trusting a third-party with my IM data something I'm not comfortable with. Fundamentally, deploying a Matrix homeserver in the cloud is the same thing. Homeserver requires a public ip address or domain name, it's really hard to set up one at home.
I don't have enough information about Matrix protocol but, a raspberry pi image, or Dockerfile doesn't need IP or Domain, uses hosts file to trick the homeserver maybe, just supports bridges, would be perfect.
I don't have enough information about Matrix protocol but, a raspberry pi image, or Dockerfile doesn't need IP or Domain, uses hosts file to trick the homeserver maybe, just supports bridges, would be perfect.
The main appeal of this to me is the whatsapp part. If I can reliably self host this and get rid of whatsapp on my phone, replacing it with an open source app then that's awesome
This looks super cool! Obligatory WUPHF link:
https://youtu.be/8wfG8ngFvPk?t=9
I've been really excited for something like this, and seeing that it's built on top of Matrix is also exciting. One of my biggest gripes as of late is how hard it is to, for example, limit your time on Instagram without cutting yourself off from Instagram's chat. I can tell my friends to send me texts as much as I want, but there's always a message or two in Instagram that I don't see until a day or two later than I want to.
I have this exact problem too! Having tried Beeper, and now using it every day, I can confirm it achieves this perfectly.
I now just check Beeper in batches (there's a great shortcut for cycling through unreads), rather than having endless apps to check.
I now just check Beeper in batches (there's a great shortcut for cycling through unreads), rather than having endless apps to check.
I can't tell you how great this is to hear! I'm really excited to give it a try.
A significant part of my SO’s business (interior architect) is based on introductory chats with clients on different platforms (namely Instagram, WhatsApp, iMessage).
Did you guys solve custom features such as “replies to a specific message” (all platforms), or “stickers” (WhatsApp/iMessage).
The last thing I want to do is to go check my phone every time I receive a sticker from a client, to get more context; it would beat the purpose of Beeper.
Did you guys solve custom features such as “replies to a specific message” (all platforms), or “stickers” (WhatsApp/iMessage).
The last thing I want to do is to go check my phone every time I receive a sticker from a client, to get more context; it would beat the purpose of Beeper.
Looks awesome, I'm looking forward to trying it out! A couple questions:
1) Is the desktop app electron or native?
2) Is the Mac iMessage bridge open-source?
Thanks!
Thanks!
Not "All Your Chats". Franz is doing this already. It has a free version with limited features. The down side is it is a CPU hog. It doesn't support WeChat, neither is your Beeper. That really sucks. It is probably due to WeChat's closed API that they never really wanted any 3rd party to interface with it. Not sure if anything you can do about it.
Franz and Beeper aren't very comparable. Franz is just the usual webapps combined in one wrapper if I understand correctly. Beeper actually bridges all chat services into a unified experience.
I wrote some code for this project a while ago and was fascinated by how well it works. I'm glad to see it finally being released :)
I have signed up and will happily pay for this the very second I receive an invite. This is exactly what I need.
The UI appears to be top notch, too.
The UI appears to be top notch, too.
How does encryption work across the bridges? Is this written down anywhere? Signal, Telegram's Secret Chat, etc.
tl;dr Worse, in most if not all cases.
This looks great.
I'm just in the middle of trying to set up a home server using dendrite to do exactly this (mainly for fun).
This looks really well done and polished though.
It's great to see services like this using matrix as it can only mean positive feedback for the protocol / server code.
Is it using synapse or dendrite (or something else) for the server?
I'm just in the middle of trying to set up a home server using dendrite to do exactly this (mainly for fun).
This looks really well done and polished though.
It's great to see services like this using matrix as it can only mean positive feedback for the protocol / server code.
Is it using synapse or dendrite (or something else) for the server?
we use synapse right now. Hopefully moving to dendrite when appservice support is added
1) Is this actually live or just a concept. All I get a a survey when signing up
2) This seems like a security nightmare. Is it?
2) This seems like a security nightmare. Is it?
I was just looking yesterday for a unified chat client, specifically for slack and discord. Looks interesting.
Reconsider your pricing strategy. $19 for the year will get you TONS of signups (if scaling is not an issue).
I would like to see this but for notifications. One cannot trust websites to have actual notifications anymore instead of stupid re-engagement pushes, and logging in to the various apps is a chore designed to be addictive. We need a no-nonsense platform for aggregating those.
[deleted]
How does Beeper avoid Instagram deciding that "your account has been compromised" and forcing you to change passwords? Unsurprisingly, Instagram seems to not be a fan of "illegitimate behaviour" (like bots / 3rd party clients).
I see that they allow you to search through your messages across all platforms.
How do they achieve that, unless they're somehow storing all my messages in their backend (which I'm not really a fan of if that'd be the case)
Messages are stored in encrypted form on the Beeper server and the Beeper client has a local search index (the same one used by Element desktop: https://github.com/matrix-org/seshat)
I wouldn't use this for Discord, as it requires you to insert a user token (aka self botting – which is against the terms of service). Bar that, the app looks quite promising, but I would be wary of what they are offering.
A suggestion for the beeper folks -- offer any 2 integrations for free, and then another tier for 2 more integrations, etc.
Maybe the free tier has google ads -- these folks are already seeing these most likely and wont mind?
Maybe the free tier has google ads -- these folks are already seeing these most likely and wont mind?
Beeper people: I filled out your Airtable form... how do I give you money?
I used to use an app for this called IM+ in the early days of iOS, looks like they're still around: https://www.plus.im
This is awesome, but do I see correctly - based on the screenshots- that only basic chat is possible? I wouldn't expect calls or video, but things like sending gifs, location, etc.
can you give us a ballpark figues of how much of a vps is needed to get started? you have given an ansible script and all but minimum specs would be nice along with users it can handle
Not sure how many know/remember Digsby? It worked pretty well on Windows, got acquired by Tagged, open sourced, promise of Linux client and then disappeared.
Hopefully Beeper will survive.
Hopefully Beeper will survive.
They lost me at $10 a month. I would be interested at $5 a month, but $10... I'm just going to go without or even consider setting up my own thing with Matrix.
What happens if I have an iPhone and want to send/receive text (not iMessage)? Is this officially supported or text messaging only works if you have an Android?
This looks really neat. Would love to know more about how iMessage is integrated and get thoughts on the likelihood of Apple blocking it in the future. But kudos!
Does this solve the whole security issues with WhatsApp and such? It seems like just a proxy so it's not any more secure than the apps it accesses right?
this is a really cool project, and a great curation effort. there are ansible scripts which they recommend for self-hosting: https://github.com/spantaleev/matrix-docker-ansible-deploy -- most of the bridges (mirrored to their GitLab org) appear to be unmodified from upstream.
The upstream bridges are written and open sourced by our lead developer Tulir https://github.com/tulir/
How does it compare with pidgin?
https://www.pidgin.im/plugins/
https://www.pidgin.im/plugins/
Beeper uses Matrix infrastructure
Will this support Amazon Chime and Microsoft teams?
I'd love an answer on this one. Most services I use have decent clients already, so the rest of the bridges are interesting but not really that important to me. Teams, on the other hand, is mandated by my employer and working with it is an absolute nightmare!
Another quick question, the webpage looks a lot like Mighty's. Is it designed by the same folks or is it like a design language?
This looks awesome but $10/month/user is too high. Can one register somewhere and be notified if the price changes?
Because you're using APIs, if I stop paying I won't lose my messages right? They'll still be in my other apps?
trillian, Messenger Plus, Franz, WhatsApp Plus.
they all eventually die out. Either they use unofficial hooks or just the web app of the service.
:(
also: i am living in Thailand and here everybody uses LINE Messenger. they removed the webclient and the platform is not famous enough outside of SEA for any western multimessenger dev to reverse engineer and hook.
they all eventually die out. Either they use unofficial hooks or just the web app of the service.
:(
also: i am living in Thailand and here everybody uses LINE Messenger. they removed the webclient and the platform is not famous enough outside of SEA for any western multimessenger dev to reverse engineer and hook.
I just signed up and filled the form. It redirects to the home page. How do I find the link to download?
Does this support RCS flavours of SMS?
Does this provide any additional privacy benefits over using say the native apps for said networks?
PSI is dead, all hail Adium.
Adium is dead, all hail Beeper.
Is that it?
Adium is dead, all hail Beeper.
Is that it?
No. Adium does everything inside the client app. This used a matrix server so you can connect from multiple clients even if the source network doesn't support that.
Thanks! huge learning uplift from one sentence. I should add, that Adium developers are fighting on, but its been a long time since significant investment in the app was made and it crashes on big sur frequently. If Beeper by using the matrix can avoid this, and simplify the GUI back down, I could be taken there.
Please, someone do this for email.
Already in the works :) https://github.com/JojiiOfficial/Matrix-EmailBridge
Doesn't your phone's email app support multiple email accounts? Gmail and Outlook both support mail forwarding too?
The cross-platform client aspect of it (linux in particular) is what I'm interested in.
I used mailspring for a while but it just was too buggy for me unfortunately.
I used mailspring for a while but it just was too buggy for me unfortunately.
A nice looking cross platform email client doesn't have a lot to do with this concept IMO.
I personally also don't see why you couldn't use different clients on different platforms. They can all link to your email account I the same way.
I personally also don't see why you couldn't use different clients on different platforms. They can all link to your email account I the same way.
what do you mean?
What's old is new again. Anyone remember Trillian?
AOL, MSN, ICQ, Yahoo messenger all in one client!
AOL, MSN, ICQ, Yahoo messenger all in one client!
Where can I read more about Beeper's privacy and encryption?
If there is an iMessage bridge that would be considered a zero-day exploit. There is no official or un-office API for iMessage outside the Apple ecosystem and this is part of security measures by Apple to ensure privacy.
Not sure how it would be a zero-day exploit.. you're allowed to run whatever code you want on your Mac, and if you bypass the sandbox by giving Full Disk Access or whatever other permissions this uses, it follows that it will be able to read your iMessage database.
As for the iPhone bridge, that does use a jailbreak which is, of course, an exploit--one that Apple has patched and the patch deliberately not applied to the device in question.
As for the iPhone bridge, that does use a jailbreak which is, of course, an exploit--one that Apple has patched and the patch deliberately not applied to the device in question.
Maybe it works differently than that
Looks like they actually send you a jailbroken iPhone physically in the mail to enable iMessage. Not sure how scalable that is.
How exactly does this work?
I find this interesting as it raises so many questions:
Do they just give away free iPhones, or reset it for each user and have them mail it back? What if it gets lost / damaged during shipping? How do they cover the costs of this?
I find this interesting as it raises so many questions:
Do they just give away free iPhones, or reset it for each user and have them mail it back? What if it gets lost / damaged during shipping? How do they cover the costs of this?
I may be wrong on the physically mailing you the iPhone. It could be that they ask for your Apple login and just log you in to a jailbroken iPhone on their premise.
I think the news they'll generate from it alone will be worth it.
Well, no. iMessage protocol was reverse engineered, but they patched it and make really hard to do crypto part of it. Hard enough that people stopped trying - after all you still required an existing registration from Apple's device and there was no guarantee it stops working again.
What they do is run ichat2json every time there is a new message in a folder and AppleScript to send outgoing messages. It requires a macOS with already authenticated Messages.app.
It's not using any unofficial APIs, it's just a wrapper around iMessage client on a mac.
What they do is run ichat2json every time there is a new message in a folder and AppleScript to send outgoing messages. It requires a macOS with already authenticated Messages.app.
It's not using any unofficial APIs, it's just a wrapper around iMessage client on a mac.
Wait wait -- how is Beeper able to use WhatsApp API?
I thought it was closed!
I thought it was closed!
If Matrix / Element had a better UX, it wouldn’t need “bridges” as the best selling point.
I use other messengers because I find their features to be better. If I preferred Matrix, I would use that without the need for bridges.
I use other messengers because I find their features to be better. If I preferred Matrix, I would use that without the need for bridges.
The best selling point is federation if you ask me.
I prefer matrix, but it doesn't help me if the people I want to talk to don't. Oh, look at this! A project which bridges the clients others use to a client I would like to use!
I prefer matrix, but it doesn't help me if the people I want to talk to don't. Oh, look at this! A project which bridges the clients others use to a client I would like to use!
It’s not difficult to switch friends to a new messenger if the UX is genuinely better.
A great example is Signal. They invested quite a lot into UX in the last year and it paid off.
A great example is Signal. They invested quite a lot into UX in the last year and it paid off.
You have excellent friends.
This approach is preferred, but regularly impossible for people with average contacts.
This approach is preferred, but regularly impossible for people with average contacts.
I can only convince friends that I have influence with. That means that I'm already in regular communication with them and an active member of the conversation.
Casually bring up some shortcomings about the current messenger and see if others agree.
Then don't jump the gun on new messengers. If it's "good enough", it's usually not ready to invite others. When it is "awesome" is when it's the right time. For example, I only got my friends on Signal after they added user mentions, stickers, and fixed link previews.
Casually bring up some shortcomings about the current messenger and see if others agree.
Then don't jump the gun on new messengers. If it's "good enough", it's usually not ready to invite others. When it is "awesome" is when it's the right time. For example, I only got my friends on Signal after they added user mentions, stickers, and fixed link previews.
It doesn't matter if a service will be around forever and hands out oral sex, some people refuse to switch tech stuff until they absolutely out of options.
i hope the company supports parity purchasing power for the 3rd world countries... idk maybe $5 a month.. it would be very helpful..
If the price comes down I'd be very keen.
How does the integration with facebook work?
i can imagine this can work well for different way how to contact tech support. are people using it for that use case?
Interesting that "eroheard" comment seems to be pinned to the top of this thread. Is this a new feature by HN and only available to YC company founders?
I doubt it.
Probably just a lot of upvotes in a short period of time.
It's a pretty cool idea.
Probably just a lot of upvotes in a short period of time.
It's a pretty cool idea.
As far as I remember every time I post a comment it always shows at the top for about a minute saying "0 minute ago", but in this case it was the second comment right after I posted. Anyone else noticed this?
This is not always the case. New comments get upweighted, but they do not get "pinned", if that makes any sense.
I keep thinking that's the PayPal logo
Is there a plan for supporting Viber?
I very much welcome this, it would enable a smooth transition away from centralized, for-profit clients.
But am I missing something? Is this open for public? There's a questionnaire after clicking signup, and then one gets redirected to the homepage again. No emails.
The privacy policy hardly looks encouraging. The hosted version is only tempting if they'll comply with GDPR.
But am I missing something? Is this open for public? There's a questionnaire after clicking signup, and then one gets redirected to the homepage again. No emails.
The privacy policy hardly looks encouraging. The hosted version is only tempting if they'll comply with GDPR.
Awesome, Eric! Keep it up!
do you have plans of making outside calls or sending sms?
I like the idea, but the signup is awful, just give me a download link..
Trillian!
All your chat are belong to us
ALL YOUR CHATS BELONG TO US
...except this is open-source and self-host-able. I mean I am always here for "all your base" memes, but it doesn't apply here.
no viber support?
awesome product!
Why isn't there a single app to aggregate and integrate all social media and messaging and email and voice chat platforms? Then it doesn't matter which ones come and go, and people don't need to worry about the plethora of ways to communicate..
Because a long time ago, Microsoft bought Skype and created its own communication protocol.
It was all downhill from there on...
But couldn't an app reverse engineer the frontends for all these communication services and create an aggregation overlay? E.g. what Dropbox did with the Mac osx filesystem.
Doing this within a mobile app is not practical for several reasons.
First off, the official mobile apps often use the platform's push notification service for asynchronous notifications of new messages. A third-party app can't pretend to be another app for push notification purposes (unless you jailbreak?).
Second, so if you can't access push notifications for async, then you need to poll or keep a websocket open. That'll nuke your battery life.
Third, the mobile platforms are quite hostile to this. There's been plenty of third-party YouTube clients that have been removed, and even more stupid things like controlling smart lights on your local network through their official, deliberately unauthenticated LAN API needs an approval from the manufacturer of said lights.
First off, the official mobile apps often use the platform's push notification service for asynchronous notifications of new messages. A third-party app can't pretend to be another app for push notification purposes (unless you jailbreak?).
Second, so if you can't access push notifications for async, then you need to poll or keep a websocket open. That'll nuke your battery life.
Third, the mobile platforms are quite hostile to this. There's been plenty of third-party YouTube clients that have been removed, and even more stupid things like controlling smart lights on your local network through their official, deliberately unauthenticated LAN API needs an approval from the manufacturer of said lights.
... because divided you are conquered.
WUPHF.com 2.0
you are only enabling marketers and spammers.
No user will ever use this in the way you are advertising here.
No user will ever use this in the way you are advertising here.
I may be missing something; I'm jumping at the bits to use something like this, and I'm quite the opposite of spammer - I'm just a nerd with heterogeneous family and friends who refuse to all magically switch to my recommended and obviously superior chat app :P
that's my point. for every one ultra power user who will have a dedicated root IOS device just to bridge all that, there will be thousands of spammers doing it for a profit.
The only solution to IM fragmentation is decent interoperable clients. But looking at the past, that is the way to kill the ecosystem too.
The only solution to IM fragmentation is decent interoperable clients. But looking at the past, that is the way to kill the ecosystem too.
You won't.
It's mind-boggling, how many of these "All your Chats in one App"-Apps exist.
Maybe start building an "All your All your Chats in One App-Apps in one App"-App?
Maybe start building an "All your All your Chats in One App-Apps in one App"-App?
Matrix is the holy grail of chat. It's end-to-end encrypted by default, federated and open source. The only problem is that not a single one of my friends or family was on it! Luckily the Matrix folks had already envisioned a solution to this problem - they built an API enabling 'bridges' between Matrix and other chat networks. This struck a chord with me, maybe we could finally build a single app that I could use to chat with all my friends, regardless of which chat app they used. Through the Matrix community I met Tulir, the most prolific bridge developer and we started working together on what would become Beeper. I've been using it as my primary chat client for almost 2 years now. I could not imagine going back to the hot mess of 12 different chat apps I had before!
Beeper is a paid service because I think it aligns interests between us and our users. We make a featureful and secure app, in exchange you pay us money. For those who prefer to self-host, you can run the entire Beeper backend stack on your own server. The vast majority of the code we've written for Beeper is open source on gitlab.com/nova. Our desktop client is closed source, but you can use Element (or any open source Matrix client) if you prefer. See our FAQ for more info or I'd be happy to explain more.