Show HN: Beeper – All Your Chats in One App
beeperhq.com
beeperhq.com
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.
Would love to use this on Linux, I find all the desktop apps really rubbish (and very happy to pay for it).
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.
Without an open source client, how can I be assured that you aren't harvesting user data through it?
Awesome work Eric, Tulir, and the whole Matrix team too!
For some, $10/month is a nice way to have all that worry-free.
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.
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.
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!
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'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.
Ideally I would not want to run the whole stack if I understand how the E2E encryption is managed.
It makes zero sense that you don't have access to the messages.
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.
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’d appreciate a blog post explaining the architectural choices here.
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.
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.
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.
> 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
Only if the desktop client is legally a derivative work of the bridges.
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/
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.
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.
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.")
the website says the second self-hosting option is free
https://www.statista.com/statistics/668966/mobile-average-re...
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.
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.
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.
Or a mess of nonstandard addons/plugins that you had 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.
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.
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]
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.
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 :)
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.
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.
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?
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 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."
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.
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.
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.
XMPP with MAM and push doesn't have similar requirements.
* 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.
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.
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".
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.
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.
If it is competing with OMEMO or not might be a separate discussion, but both can be used to utilize E2E encryption of messages.
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.
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 :|
> We can't control what randoms on the internet say though :|
You could acknowledge Matrix's shortcomings instead of denying or minimizing almost every criticism. And not say things like "It's fine to dislike Matrix and pine for XMPP, but please don't spread FUD."
> 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.
...which is by far the biggest shortcoming of Matrix I'm aware of. I reserve the right to refute the inaccurate criticisms though (and to call them FUD, if that's what they are :)
Yeah, that's awfully close to what the xmpp people used to say. There are rtc calls and there are conferences, and otp is something else than omemo entirely.
For the end user however, when they click that telephone icon in their client, they may or may not get an embedded widget of some type or other, or an rtc stream, or something else. Should the remote client support the same thingamajig, they get a voice call. Look at the dozen or so most popular Matrix clients and for a non-technical user, it's still a gamble.
It's pretty much comparable to email in the 90s. Send a file, and it may end up as a uuencoded Mail Attachment, or perhaps a base64 encoded MIME. In the latter case it may be a multipart MIME or a non-multipart. Non-technical users sometimes couldn't open the file and then you had to send it some other way. Over time some clients got important enough for a de facto standard to emerge. It's still not perfect in 2021, one well known software company insists on their own .eml attachment that doesn't always work.
Matrix is quite similar to xmpp in this regard. Take the dozen most popular clients for each protocol, and check off how many popular features (voice calls, e2e, profiles, conferences, screen sharing etc.) interoperate fully. There's certainly room for improvement.
Don't take this the wrong way however! This is the price we pay for open protocols. If the alternative is low protocol innovation, then bring on the interop testing and annoyed users! It's worth it.
> aren't actually merged into the spec yet, but are specified at MSC1236
You even have standards proposals! They have numbers. Great! Let me guess, you bunch them up, spread some holy standardization water on them, recite an incantation and then they are part of an Offical Standard. Guess how many other protocols developers do that?
> that's not me or the Matrix core team doing that
Again, the tone could certainly be improved. One needs to look no further than this thread, to see other software developers being told in exactly how many ways their standard suck.
Take pride instead in what you did, and if someone asks you again why you didn't use the existing standard to build your chat product, just tell them you had more fun that way. Don't say inefficiency, don't say battery management, don't say interop when all of those metrics aren't looking any better in Matrix. Tell them about the nice team web chat you did, which is plenty reason to use it.
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.
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.
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.
Never understood what was wrong with the name vector by the way. That was even nicer IMO.
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.
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-...
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!
I'll check out your site and you may have some very happy paid users soon :)
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!
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.
It was just funny when I read it first, I thought someone else had the same idea :)
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.
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".
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 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.
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.
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.
Every time I see something like this I check again, but it’s so far never been supported.
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.
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.
and the name is dope, don't count that for 0.
I'd rather be prepared to use different protocols in a sensible way.
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... :)
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...
Also, why no WeChat? The stickers are the best there !
>(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.
Forwarding all my messages to some 3rd party service doesn’t break E2E anymore then forwarding them to my friends.
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.
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?
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_...
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.
So I imagine there might be the possibility of it being allowed for Beeper as well.
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.
Discord's generally fine with anything using it's API/gateways as long as it's NOT logging in as a "real" user.
It never used to be like this. MSN messenger,AIM even YIM; they all had FOSS applications.
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.
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.
Granted I'm very familiar with ansible but for someone not technical it should be doable, too.
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!
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.
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.
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.
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.
> 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.
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.
Under what legal framework could this be possible?
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)
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.
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.
So it is obvious when texting with someone that the content is flowing unencrypted over sms, and easily read by the phone company, let alone a request from LE.
The problem with this service is it makes the conversation look like it is over iMessage. And while your comments about the factual trust level of the user or their choices around iCloud backups and password protection is always the base consideration—-beeper is being additionally introduced, possibly using a wholly unprotected iOS device along with their own cloud storage of the content.
So the attack surface now includes not only the recipient and their trustworthiness and opsec in using the apple product but the entire opsec of this third party service.
Dialing it up to, “well prism” or “trust of the other person” deliberately ignores my point which is beeper is being added as a listener in an opaque way to the iMessage user.
When I say practical expectation, I am not worried about my contacts copying and pasting a conversation. They might but there would be a reason and I’m not worried about some kind of betrayal.
Nor am I overtly concerned about a contact having their iCloud backup stolen and read. There are fairly robust measures Apple takes to prevent this including mandatory 2FA. It would take true determination.
However this is marketed as an innocuous gateway for iMessage and it isn’t. As I mentioned above Beeper takes no responsibility for the loss of data and does not bear much reprisal if they leaked data. They can’t because it’s a startup.
I'm ignoring that point because I disagree it's a valid point that's worth making or acknowledging.
iCloud backups are added in an opaque way to the iMessage user. Screenshots happen in an opaque way to the iMessage user. And while you'll get a blue bubble in iMessage when sending over SMS, you won't see that until after you start the conversation. The point is, if you don't trust someone to have a secure phone, that's a talk you need to have with that person, it's not a problem with the Matrix protocol.
If you think that Matrix presents a novel, undetectable way to exfiltrate data, then you trust iMessage too much and you should rethink your approach to secure communication. Thinking in terms of, "the bubble is green so my contact can't be doing anything weird" is the wrong way to think about security. Don't do that.
Especially since, again, you should not be using iMessage for seriously private conversations in the first place, you should be using Signal, or in a pinch (ironically) Matrix/Element itself, since both platforms actually have full E2E encryption that forces users to validate sessions and doesn't break itself by default.
It's fine for you to be skeptical about the security of this company, but if you think it breaks some taboo or compromises your phone in some unique way just because it's a bridge, then you're putting too much faith in Apple and approaching message security from the wrong perspective.
> possibly using a wholly unprotected iOS device
Just as a sidenote, this in particular is weird to me. Your argument is based on the idea that you trust Apple. But Apple is the one that makes messages from those old devices show up green. If your argument is that they might be unpatched, shouldn't you bring that up with Apple and ask them to start requiring updates to be installed before green bubbles appear in chat?
Why is it Matrix's fault that Apple considers old iPhones to be secure?
I also know that people so tin foil hat about security can never be satisfied and that this hamstrings UX and resulting in lesser use and less used secure tools.
So there is a happy medium and there’s reasonable protection to cover 96 or more % of consumer comms.
Is iMessage secure? Maybe enough to send an SSN, but maybe not to send bank info. Would I send either over sms? Nope. That’s a call anyone can make on their own.
I don’t like this service hooking into iMessage. I don’t like the always connected jailbroken phone bridge idea.
I do think apple, of all consumer products companies, has made privacy and security core values and, at least for now, I trust the company.
I don't care how matrix is involved in the beeper’s bridge functionality nor am I evaluative of the technology.
I don’t know beeper, and don’t want the product hooking into my contacts’ end of our iMessage comms.
At the end of the day though, that's a conversation you have to have with your contacts. The fact is that your contacts may jailbreak their phones already, and they'll still show up as green bubbles, and at some point you'll either trust your contacts to be secure with the tools that are provided to them or you won't.
It is not Beeper's job to sort all of this out for you. It's not their problem that you dislike people jailbreaking their phones, that's a personal choice you can make about who you communicate with.
To jump from, "I would prefer not to communicate with jailbroken iPhones or bridged services" to "this program is comparable to malware" is a massive leap in logic and a dismissal of personal responsibly. People have the right to jailbreak their phones and to use services that securely bridge their communication platforms, and if your security model requires you to avoid communicating over those channels, that's a personal choice you can make by checking with the people you communicate with and talking to them about security.
As to why these messages show up as green, it's because Apple doesn't have a visual indicator of jailbroken phones in iMessage, and because Apple allows old phones running old firmware/software to show up as green, and if you have a problem with that then you should take it up with Apple. Beeper didn't write iMessage, they're not the reason why the messages are green.
> So there is a happy medium and there’s reasonable protection to cover 96 or more % of consumer comms.
And if that happy medium for most users ends up including bridged services? What then?
What line are you drawing that says it's OK for Apple to avoid notifying you in iMessage about contacts with outdated firmware, but critically important that they let you know a contact is bridging? You're comparing this app to malware based on a completely subjective, personal security criteria -- one that it doesn't look like most other people share with you.
It's fine for you to be uncomfortable with bridges, but it's not fine for you to claim they're some kind of unique/novel threat that compromises iMessage when iMessage is already willingly making similarly large security compromises in other areas -- compromises that are also just as opaque to end users as Beeper is.
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.
https://airmessage.org/ (dev on subreddit indicates it will be open sourced once some code cleanup happens)
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.
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).
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.
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?
I assume they're now aware of 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.
> 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.
For a good quality one? Same. Signed up.
> 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.
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!
> 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.
So they made a desktop client.
I liked breaking my chats out into different tiny windows I could see everything happening at once.
That's been fixed now :)
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 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.
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 why it is so good
TLDR: It didn't work then, won't work now.
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 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>'".
Someone forked Rambox and kept it FOSS, and it's called Hamsket.
This looks like an interesting alternative and I am looking forward to trying both of them out once I get in
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...
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.
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... :-/
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.
is this not a joke?
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've sent you an email. It's great to see the problem being addressed the right way.
Also please add support for Google Chat.
That is, once weechat-matrix works together with wee-slack… (https://github.com/poljar/weechat-matrix/issues/248) :-)
> A Matrix-WhatsApp puppeting bridge. Written in Go using the Rhymen/go-whatsapp implementation of the sigalor/whatsapp-web-reveng project.
Whatsapp
Facebook Messenger
iMessage
Android Messages (SMS)
Telegram
Twitter
Slack
Hangouts
Instagram
Skype
IRC
Matrix
Discord
Signal
Beeper networkStill though, I'd like some alt text. It wouldn't even disrupt the layout.
>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 answers my question! One iPhone for each Beeper user, no wonder the $10 monthly fee!
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.
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.
> Oh, the matrix logo among others, good thing at least
> YES !
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).
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?
Perhaps this is implicit from Matrix protocol but I didn't see a clear call out on the site.
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 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 now just check Beeper in batches (there's a great shortcut for cycling through unreads), rather than having endless apps to check.
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.
Thanks!
The UI appears to be top notch, too.
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?
2) This seems like a security nightmare. Is it?
Maybe the free tier has google ads -- these folks are already seeing these most likely and wont mind?
Hopefully Beeper will survive.
Even if it didn't the data is still passing through WhatsApps's servers.
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.
Adium is dead, all hail Beeper.
Is that it?
I used mailspring for a while but it just was too buggy for me unfortunately.
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.
AOL, MSN, ICQ, Yahoo messenger all in one client!
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?
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.
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.
I thought it was closed!
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 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!
A great example is Signal. They invested quite a lot into UX in the last year and it paid off.
This approach is preferred, but regularly impossible for people with average contacts.
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.
Probably just a lot of upvotes in a short period of time.
It's a pretty cool idea.
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.
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.
No user will ever use this in the way you are advertising here.
The only solution to IM fragmentation is decent interoperable clients. But looking at the past, that is the way to kill the ecosystem too.
Maybe start building an "All your All your Chats in One App-Apps in one App"-App?