[HN Gopher] Show HN: Beeper - All Your Chats in One App
___________________________________________________________________
Show HN: Beeper - All Your Chats in One App
Author : erohead
Score : 845 points
Date : 2021-01-20 16:24 UTC (1 days ago)
(HTM) web link (www.beeperhq.com)
(TXT) w3m dump (www.beeperhq.com)
| erohead wrote:
| While working on Pebble, we ran into a lot of issues as we tried
| to enable messaging from the watch. For example, we never figured
| out how to send an iMessage or WhatsApp reply. While digging
| around for a solution to that problem, I thought it was odd that
| no one had built a Adrium/Trillian/Meebo chat app for modern chat
| networks. I buried that thought for a while, until I learned
| about Matrix two years ago.
|
| 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.
| pinusc wrote:
| 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!
| Abishek_Muthian wrote:
| 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...
| sarthakjshetty wrote:
| 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!
| erohead wrote:
| Simplest way to learn about the API is to look at several bot
| implementations https://github.com/maubot/maubot
| sarthakjshetty wrote:
| Awesome! Thanks a ton!
| NikolaNovak wrote:
| 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 :)
| wsinks wrote:
| 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!
| jimbob45 wrote:
| I thought Apple barred iMessages from being sent/retrieved
| outside of the specific iMessage app? How did you dodge that?
| el_dev_hell wrote:
| 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.
| jimbob45 wrote:
| 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.
| aquaticsunset wrote:
| 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
| nextaccountic wrote:
| Hey, does it support Telegram stickers?
| kitkat_new wrote:
| 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
| have_faith wrote:
| 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.
| jeroenhd wrote:
| 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.
| erohead wrote:
| 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.
| m0hit wrote:
| 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.
| TheCraiggers wrote:
| 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.
| rkangel wrote:
| 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.
| TheCraiggers wrote:
| 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.
| bertman wrote:
| Yes, I was wondering about exactly this! A dev response
| would be much appreciated.
| [deleted]
| pbronez wrote:
| 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.
| _-___________-_ wrote:
| This simply cannot be true, since you have to decrypt the
| messages to send them to, for example, WhatsApp.
| rkangel wrote:
| 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?
| TheCraiggers wrote:
| 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.
| dehrmann wrote:
| 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.
| SulfurHexaFluri wrote:
| 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.
| Marsymars wrote:
| 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.
| toast0 wrote:
| 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.
| erohead wrote:
| I've been using it for the last year straight and I think we
| only experienced one unforeseen breaking API change.
| have_faith wrote:
| 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!
| spamalot159 wrote:
| 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.
| pseudalopex wrote:
| Beeper requires a Mac like AirMessage. Or they'll send you a
| jailbroken iPhone.
| SulfurHexaFluri wrote:
| 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.
| kevincox wrote:
| 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.
| giancarlostoro wrote:
| How old are these iPhones cause that's the oddest part of
| that setup I've heard.
| pseudalopex wrote:
| iPhone 4.[1]
|
| [1]
| https://twitter.com/ericmigi/status/1351934418961661959
| giancarlostoro wrote:
| 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.
| pseudalopex wrote:
| I think the idea is you leave it plugged in at home.
| Aeolun wrote:
| 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.
| nimbleal wrote:
| I was about to comment the same, but with Wechat. I can't not
| use wechat, much as I'd like to. I wouldn't be surprised if
| it wasn't significantly more difficult/impossible to
| integrate though.
| mrkramer wrote:
| 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.
| kitkat_new wrote:
| 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).
| kevincox wrote:
| 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.
| luplex wrote:
| Yes they can! But it's unlikely they would all do it at the
| same time.
| wiggler00m wrote:
| 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.
| modeless wrote:
| 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.
| p00f wrote:
| What are the system requirements for self-hosting?
| bluesmoon wrote:
| 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-...
| est31 wrote:
| 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).
| Arathorn wrote:
| 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. http
| s://ec.europa.eu/info/strategy/priorities-2019-2024/euro...
| kpgiskpg wrote:
| This looks awesome! I wonder why I haven't heard about it
| before.
| LockAndLol wrote:
| 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.
| GekkePrutser wrote:
| 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.
| erohead wrote:
| Yes, Beeper is the new name for NovaChat.
| GekkePrutser wrote:
| 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 :)
| gtf21 wrote:
| 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).
| feanaro wrote:
| 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.
| foolinaround wrote:
| is the N configurable by the user? ( different paid tier)
| feanaro wrote:
| 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).
| kevincox wrote:
| 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).
| feanaro wrote:
| Yes, I was talking about native Matrix specifically.
| km3r wrote:
| you can self host the bridge between matrix and signal,
| allowing e2e to a host you control, and e2e from that
| host to your device. Perhaps not ideal, but likely
| unavoidable if you want an all in one app like this.
| gtf21 wrote:
| 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)?
| erohead wrote:
| yes, it's a secure tunnel to your self-hosted bridge from
| client
| rStar wrote:
| 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.
| alex_duf wrote:
| 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.
| LordOfWolves wrote:
| I'm also curious about Beeper's plan re: potential
| response/pushback from Apple and the status of (likely
| broken?) E2E in iMessage.
| ignoramous wrote:
| 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
| rkangel wrote:
| 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/
| [deleted]
| erohead wrote:
| The bridges do not run inside the client, they either run on
| your own self-hosted server or our cloud.
| KitDuncan wrote:
| I already have a Matrix server with the bridges I need
| running. Can I still use your desktop client? It looks
| sick!
| nextaccountic wrote:
| > Then aren't you required to AGPLv3 the desktop client, too?
|
| Only if the desktop client is legally a derivative work of
| the bridges.
| StavrosK wrote:
| 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.
| acct776 wrote:
| Is it possible to build a zero-trust version of this?
| acct776 wrote:
| Also, didn't they say something about being able to run the
| full stack self-hosted?
| crooked-v wrote:
| > 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.
| foolinaround wrote:
| $10 monthly for a chat service is a bit steep for users from
| Asia and other places..
| viewer5 wrote:
| 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")?
| pinusc wrote:
| 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.
| troydavis wrote:
| > 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.")
| p00f wrote:
| > 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
| smarx007 wrote:
| 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...
| robtherobber wrote:
| 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.
| donclark wrote:
| Good point. Maybe their pricing could be location based?
| flurdy wrote:
| 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
| robinhood wrote:
| 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.
| recursivedoubts wrote:
| 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?
| erohead wrote:
| 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!
| filmor wrote:
| 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.
| acct776 wrote:
| We could always start building on webOS again, it's open now,
| right?
| kevincox wrote:
| 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.
| acct776 wrote:
| Some big NGOs and world governments are getting on the
| Matrix train,
|
| and the name is dope, don't count that for 0.
| raunakdag wrote:
| 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?
| necrotic_comp wrote:
| This is fantastic stuff. Thank you for building it. Matrix
| truly is a wonderful piece of software.
| arendtio wrote:
| 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.
| Arathorn wrote:
| 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.
| selfhoster11 wrote:
| I can only thank you for your work. Open messaging
| ecosystems are much better off for it.
| arendtio wrote:
| 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.
| acct776 wrote:
| 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?
| pseudalopex wrote:
| 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
| acct776 wrote:
| 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.
| Semaphor wrote:
| 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.
| dijit wrote:
| 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.
| MattJ100 wrote:
| This is what happens. Compliance suites are published
| annually: https://xmpp.org/about/compliance-suites.html
| Semaphor wrote:
| 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.
| jiofih wrote:
| 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.
| pseudalopex wrote:
| 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?
| upofadown wrote:
| XMPP is pretty successful right now. Last I heard there
| were something like 80k federated servers. Matrix can
| only dream of that level of sucess...
| Arathorn wrote:
| we can see ~60k federated servers on Matrix right now,
| and presumably there are loads more we can't see.
| SulfurHexaFluri wrote:
| 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
| xorcist wrote:
| 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."
| mszcz wrote:
| That and they probably threw hoards of cash and
| engineering at the problem.
| thiht wrote:
| > 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.
| kuschku wrote:
| The ridiculous part is that nowadays IRC has more stable
| and reliable (and beautiful) clients for web and mobile
| than XMPP.
| Tepix wrote:
| 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.
| kuschku wrote:
| UTF-8 has been in the standard since the mid 2000s.
| You're just as much out of date with the other
| assertions.
| selfhoster11 wrote:
| 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.
| pseudalopex wrote:
| 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.
| arendtio wrote:
| > 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.
| derefr wrote:
| 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.
| pseudalopex wrote:
| 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.
| Arathorn wrote:
| 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.
| remram wrote:
| It's late beta but no push notifications (!!), no
| presence, no search, no cross-signing of E2E keys, no
| clustered deployments.
| pseudalopex wrote:
| 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.
| selfhoster11 wrote:
| 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.
| pseudalopex wrote:
| 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/
| selfhoster11 wrote:
| Dendrite is meant to be good too.
| Arathorn wrote:
| 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".
| arendtio wrote:
| > 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.
| pseudalopex wrote:
| 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.
| arendtio wrote:
| XEP-0374 is very fresh compared to other PGP-related
| extensions. Just to give an example, 'XEP-0027: Current
| Jabber OpenPGP Usage' became active in 2002.
|
| If it is competing with OMEMO or not might be a separate
| discussion, but both can be used to utilize E2E
| encryption of messages.
| pseudalopex wrote:
| XEP-0027 became officially obsolete in 2014. I'm giving
| them the benefit of the doubt they didn't mean anyone has
| to think about XEP-0027 in 2021. They implied they could
| break compatibility some day. So I think they're talking
| about not having 2 current standards. How they see a
| transition working is still a good question though.
| petre wrote:
| > 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.
| xorcist wrote:
| > 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.
| Arathorn wrote:
| > 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 :|
| xorcist wrote:
| > There is precisely one way to do a 1:1 VoIP/Video call
| in Matrix
|
| 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.
| pseudalopex wrote:
| Most of the fragmentation in the XMPP ecosystem is just
| incomplete implementations.
|
| > 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."
| Arathorn wrote:
| If you look a few messages up, you'll see...
|
| > 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 :)
| pseudalopex wrote:
| 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/
| kitkat_new wrote:
| > 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 :)
| upofadown wrote:
| >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.
| kitkat_new wrote:
| Yes, there is: https://github.com/matrix-org/matrix-
| bifrost/wiki/Address-sy...
| pseudalopex wrote:
| The XMPP bridge means the user communities don't have to be
| split. The developer communities are.
| michaeljelly wrote:
| 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!
| pimeys wrote:
| 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.
| pimeys wrote:
| 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.
| aloisdg wrote:
| If you achieve it, it could be nice to improve the
| existing documentation.
| rattray wrote:
| 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?
| spiffytech wrote:
| $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.
| petre wrote:
| For $10/mo one could host their own VPS and server infra.
| robinhood wrote:
| 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.
| petre wrote:
| 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?
| rattray wrote:
| The first sentence in your otherwise useful post doesn't
| feel helpful to the conversation.
| 411111111111111 wrote:
| The messages still go through the "free" networks, so they're
| still being used exactly like that.
| pimeys wrote:
| 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!
| erohead wrote:
| So good to hear that! Have you considered buying one off
| ebay? Still some good deals there :)
| spondyl wrote:
| 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".
| erohead wrote:
| Tulir is on the Beeper team, he's the one writing all the
| bridges! They are quite reliable now.
| spondyl wrote:
| 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.
| Wowfunhappy wrote:
| 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.
| Wowfunhappy wrote:
| ...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.
| littlehugie wrote:
| Will you Support Threema in the future?
| hans_castorp wrote:
| Came here to ask the same. It would only make sense to me if
| Threema is also added to the list (Signal already is)
| liminalsunset wrote:
| 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?
| acct776 wrote:
| Why would you want that additional attack surface?
| GekkePrutser wrote:
| 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.
| mail2merge wrote:
| This is good. What competitors do you fear?
|
| Also, why no WeChat? The stickers are the best there !
| azinman2 wrote:
| Where is the open source code for the iMessage bridge?
| pseudalopex wrote:
| It doesn't exist yet.[1]
|
| [1] https://news.ycombinator.com/item?id=25849040
| ibeckermayer wrote:
| 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.
| hartem_ wrote:
| 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_...
| kitkat_new wrote:
| Kudos to Tulir!!!
| yters wrote:
| 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..
| selfishgene wrote:
| ... because divided you are conquered.
| mrleinad wrote:
| Because a long time ago, Microsoft bought Skype and created its
| own communication protocol. It was all downhill from there
| on...
| yters wrote:
| 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.
| Nextgrid wrote:
| 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.
| ivanche wrote:
| An app definitely _can 't_ reverse engineer the frontends
| for all these communication services. A skilled developer
| (or, more realistically, developers) probably can. They're
| not cheap though.
| yters wrote:
| Doh of course! Hah I meant devs ;)
| codebutler wrote:
| 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!
| erohead wrote:
| Desktop app is Electron. We will open source the iMessage
| bridge in a few weeks.
| dawnerd wrote:
| Dang, was hoping it wasn't electron.
| Hamuko wrote:
| So much for that "Native Chat Is Better".
| jnsie wrote:
| 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!
| dmcc7897 wrote:
| 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.
| ggrelet wrote:
| I submitted my infos to Nova.chat (same form) a while ago. Do I
| need to do it again?
| erohead wrote:
| Nope!
| ggrelet wrote:
| Waiting for the beta, then.
| miguelrochefort wrote:
| 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).
| peteretep wrote:
| 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?
| nickbeukema wrote:
| I'm experiencing the same thing, I'm unable to sign up.
| rkul wrote:
| https://twitter.com/imrichvalach/status/1351935706097135617?.
| ..
| habosa wrote:
| This looks super cool! Obligatory WUPHF link:
| https://youtu.be/8wfG8ngFvPk?t=9
| gcblkjaidfj wrote:
| you are only enabling marketers and spammers.
|
| No user will ever use this in the way you are advertising here.
| acct776 wrote:
| You won't.
| NikolaNovak wrote:
| 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
| gcblkjaidfj wrote:
| 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.
| acct776 wrote:
| chomping at the bit**
| jmarinez wrote:
| Beeper bridges with WhatsApp. Does it mean that one can bypass
| the upcoming Facebook data sharing requirement by just using the
| Beeper client?
| jcul wrote:
| No, it just uses WhatsApp web.
|
| Even if it didn't the data is still passing through WhatsApps's
| servers.
| philsnow wrote:
| 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.
| donio wrote:
| 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.
| Liskni_si wrote:
| 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.
| GekkePrutser wrote:
| You can add an app like quassel / quasseldroid on top for some
| mod cons like unlimited scrollback.
| farukuzun wrote:
| 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.
| fileyfood500 wrote:
| Will this support Amazon Chime and Microsoft teams?
| gkfasdfasdf wrote:
| I thought WhatsApp banned thirdparty apps some time ago? How does
| this work exactly?
| episteme wrote:
| Could be a wrapper around WhatsApp Web.
| jcul wrote:
| 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
| gkfasdfasdf wrote:
| 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.
| amelius wrote:
| YouTube-DL is successful despite it violating the ToS.
| hansdieter1337 wrote:
| 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.
| GekkePrutser wrote:
| That's exactly what it does!
| noxer wrote:
| 10$/month is absurd
| scrollaway wrote:
| Absurdly low.
| sarthakjshetty wrote:
| 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?
| vini808 wrote:
| 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
| acct776 wrote:
| Write them, tell them to fuck off with that.
| vini808 wrote:
| Yea you are right! It suck to not be able to make custom
| discord client.
| carterschonwald wrote:
| 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.
| Groxx wrote:
| Nope: https://news.ycombinator.com/item?id=25852034
| [deleted]
| rhacker wrote:
| 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.
| deallocator wrote:
| 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)
| tulir wrote:
| 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)
| bambax wrote:
| This looks awesome but $10/month/user is too high. Can one
| register somewhere and be notified if the price changes?
| zufallsheld wrote:
| 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.
| itsovermyhead wrote:
| 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.
| zufallsheld wrote:
| 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.
| itsovermyhead wrote:
| Thanks for the reply! I'm going to give it a shot!
| [deleted]
| MattyRad wrote:
| 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.
| briffle wrote:
| I am interested, but not sure of system requirements. What kind
| of resources does it use on your cheap VPS?
| mrweasel wrote:
| How does it work? Most of those protocols are't exactly open.
|
| Also please add support for Google Chat.
| 2Gkashmiri wrote:
| >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?
| dyeje wrote:
| Yea, I'm really confused by that FAQ item.
| erohead wrote:
| Not a joke
| https://twitter.com/ericmigi/status/1351934418961661959
| heroHACK17 wrote:
| WUPHF.com 2.0
| olah_1 wrote:
| 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.
| louis-lau wrote:
| 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!
| olah_1 wrote:
| 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.
| acct776 wrote:
| You have excellent friends.
|
| This approach is preferred, but regularly impossible for
| people with average contacts.
| olah_1 wrote:
| 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.
| acct776 wrote:
| 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.
| dbancajas wrote:
| no viber support?
| TheKarateKid wrote:
| What's old is new again. Anyone remember Trillian?
|
| AOL, MSN, ICQ, Yahoo messenger all in one client!
| pryelluw wrote:
| wuphf.com ?
| scottcorgan wrote:
| this
| jonplackett wrote:
| 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?
| underlines wrote:
| 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.
| asiando wrote:
| 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.
| vessenes wrote:
| 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. :)
| GekkePrutser wrote:
| 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.
| WorldPeas wrote:
| For those that don't use a macintosh(or don't care about
| imessage), ferdi is a great free alternative
| louis-lau wrote:
| Ferdi is a web browser that's oriented on messaging. This is
| something completely different.
| Kaze404 wrote:
| 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
| :)
| recursive wrote:
| 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.
| bhandziuk wrote:
| Scroll down to the FAQ Whatsapp
| Facebook Messenger iMessage Android Messages
| (SMS) Telegram Twitter Slack
| Hangouts Instagram Skype IRC
| Matrix Discord Signal Beeper network
| recursive wrote:
| I see it. Thanks.
|
| Still though, I'd like some alt text. It wouldn't even
| disrupt the layout.
| e-clinton wrote:
| 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.
| aabbccsmith wrote:
| 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.
| uoflcards22 wrote:
| How do I get started? I put in my email like 10 minutes ago and
| have received nothing...
| mouldysammich wrote:
| 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.
| uoflcards22 wrote:
| Yup, just got it. Thanks.
| thatgerhard wrote:
| I like the idea, but the signup is awful, just give me a download
| link..
| soheil wrote:
| 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.
| acct776 wrote:
| Maybe it works differently than that
| soheil wrote:
| Looks like they actually send you a jailbroken iPhone
| physically in the mail to enable iMessage. Not sure how
| scalable that is.
| acct776 wrote:
| I think the news they'll generate from it alone will be
| worth it.
| trinix912 wrote:
| 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?
| soheil wrote:
| 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.
| andoriyu wrote:
| 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.
| morpheuskafka wrote:
| 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.
| dilly_li wrote:
| "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!
| GekkePrutser wrote:
| Not necessarily. In Europe we don't really use iMessage much. I
| would have no need for it personally.
| sor1nmarkov wrote:
| Massive generalisation about Europe I and most people I know
| use it.
| Liquid_Fire wrote:
| 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.
| GekkePrutser wrote:
| 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.
| electriclove wrote:
| Reconsider your pricing strategy. $19 for the year will get you
| TONS of signups (if scaling is not an issue).
| Andrew_nenakhov wrote:
| 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.
| kitkat_new wrote:
| This is a single protocol client, which can be replaced by any
| Matrix client.
|
| This is why it is so good
| Dirlewanger wrote:
| 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.
| Andrew_nenakhov wrote:
| 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.
| pseudalopex wrote:
| Bridges make the server a multi protocol client.
| kitkat_new wrote:
| not really, they are all individual pieces put together -
| independent of the server
| pseudalopex wrote:
| 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.
| Andrew_nenakhov wrote:
| 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.
| kitkat_new wrote:
| it works already - and only the bridge needs to be
| updated. Everything else can stay the same.
| Andrew_nenakhov wrote:
| Unlike you, I have actually experienced running the
| bridge that 'only needs to be updated'. Good luck with
| that.
| philsnow wrote:
| 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>'".
| GekkePrutser wrote:
| 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 :)
| kitkat_new wrote:
| 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.
| pseudalopex wrote:
| Most multi protocol clients used the same libraries. The
| hard part was reverse engineering the protocol changes.
| wiggler00m wrote:
| Where can I read more about Beeper's privacy and encryption?
| bkovacev wrote:
| Is there a plan for supporting Viber?
| 2Gkashmiri wrote:
| 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
| erohead wrote:
| 2-3gb RAM + 50GB disk. Small CPU is ok.
| 2Gkashmiri wrote:
| How many users can this server serve
| tylermenezes wrote:
| 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!
| acct776 wrote:
| What's the worst glitch you've had, if you don't mind me
| asking?
| tylermenezes wrote:
| 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 :)
| kevincox wrote:
| 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.
| IggleSniggle wrote:
| 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).
| danShumway wrote:
| 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.
| kevincox wrote:
| 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.
| da_big_ghey wrote:
| 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?
| Liskni_si wrote:
| 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) :-)
| acct776 wrote:
| Not for you, apparently.
| anticensor wrote:
| Weechat is a TUI application. This is a GUI one.
| hypfer wrote:
| 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?
| monkeynotes wrote:
| Does this support RCS flavours of SMS?
| yingbo wrote:
| Are there already many similar apps? I used two: Rambox
| https://rambox.pro/ and Franz https://meetfranz.com
| 50 wrote:
| https://texts.com - it's not released yet but you can sign up
| for early access.
| GekkePrutser wrote:
| 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 :)
| navanchauhan wrote:
| 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
| KishanBagaria wrote:
| Yep, check out some tweets by our users here:
| https://twitter.com/TextsHQ
| navanchauhan wrote:
| 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/129475427399
| 8172160...
| KishanBagaria wrote:
| > 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.
| ajimix wrote:
| why login with Google and not regular email?
| folkrav wrote:
| 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.
| smt88 wrote:
| 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.
| folkrav wrote:
| 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.
| halfjew22 wrote:
| >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.
| polishdude20 wrote:
| 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?
| whycombagator wrote:
| 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
| erohead wrote:
| It's 6 months better now! We haven't open sourced the iMessage
| bridge yet, will do that in a few weeks.
| meibo wrote:
| > 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!
| renewiltord wrote:
| This is great!
| gpmcadam wrote:
| Expect Apple to come down on this like a tonne of bricks and
| render the whole thing impossible very quickly.
| jhatemyjob wrote:
| Never gonna happen as long as checkra1n can pwn the latest
| iOS. Cat and mouse game. MobileSubstrate/Substitute/libhooker
| is too powerful a platform.
| bredren wrote:
| 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.
| morpheuskafka wrote:
| > 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.
| bredren wrote:
| 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.
| jiofih wrote:
| > 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.
| pseudalopex wrote:
| Syncing messages through iCloud uses end to end
| encryption. Backups don't.[1]
|
| [1] https://support.apple.com/en-us/HT202303
| jiofih wrote:
| 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.
| pseudalopex wrote:
| Messages in iCloud and iCloud Backup are different
| features. That says Apple has the key as long as iCloud
| Backup is on.
| sneak wrote:
| 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.
| bredren wrote:
| > the FBI can read every message in every backup without
| a warrant.
|
| Under what legal framework could this be possible?
| sneak wrote:
| 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_Surv
| eil...
|
| https://en.m.wikipedia.org/wiki/PRISM_(surveillance_progr
| am)
| bredren wrote:
| 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.
| danShumway wrote:
| > 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.
| bredren wrote:
| Sms conversations are green to iMessage users. So the
| practical expectation of a blue message is at least the
| content is not going one or more carriers.
|
| 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.
| danShumway wrote:
| > deliberately ignores my point which is beeper is being
| added as a listener in an opaque way to the iMessage
| user.
|
| 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.
| [deleted]
| [deleted]
| mattmcknight wrote:
| >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.
| pseudalopex wrote:
| They're using unsupported iPhones.[1]
|
| [1] https://twitter.com/ericmigi/status/1351934418961661959
| bredren wrote:
| Worth considering that these always-connected devices
| exfiltrating data are not only jail broken, but unable to
| receive iOS security updates.
| lxe wrote:
| I was wondering how this is solved... and here's the answer!
| Wish there was a free/foss DIY solution to this.
| pp00hh wrote:
| https://bluebubbles.app/
|
| https://airmessage.org/ (dev on subreddit indicates it will
| be open sourced once some code cleanup happens)
| technick wrote:
| 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.
| neycoda wrote:
| All your chat are belong to us
| el_dev_hell wrote:
| 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.
| monkeypilot wrote:
| 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?
| pragmatick wrote:
| $10 a month. It has to go somewhere...
| webo wrote:
| https://twitter.com/ericmigi/status/1351934418961661959
| khimaros wrote:
| 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.
| erohead wrote:
| The upstream bridges are written and open sourced by our lead
| developer Tulir https://github.com/tulir/
| yur3i__ wrote:
| 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
| johnisgood wrote:
| How does encryption work across the bridges? Is this written down
| anywhere? Signal, Telegram's Secret Chat, etc.
| acct776 wrote:
| tl;dr Worse, in most if not all cases.
| poisonborz wrote:
| 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.
| [deleted]
| DeerSpotter wrote:
| ALL YOUR CHATS BELONG TO US
| IggleSniggle wrote:
| ...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.
| scrollaway wrote:
| 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.
| saltybytes wrote:
| Isn't Beeper similar to Franz [0]?
|
| [0] https://meetfranz.com/
| louis-lau wrote:
| No, not at all.
| The_Amp_Walrus wrote:
| Beeper people: I filled out your Airtable form... how do I give
| you money?
| dundercoder wrote:
| I was just looking yesterday for a unified chat client,
| specifically for slack and discord. Looks interesting.
| AnonHP wrote:
| 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?
| anoa_ wrote:
| 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 :)
| chickenpotpie wrote:
| 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.
| smt88 wrote:
| 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.
| trinix912 wrote:
| > 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.
| jackson1442 wrote:
| Agreed. I would kill to not have to use Snapchat's app to
| talk to some of my friend groups. Same goes for Instagram.
| scrollaway wrote:
| > _I would pay $100 /mo for it._
|
| For a good quality one? Same. Signed up.
| soheil wrote:
| 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?
| BFatts wrote:
| Trillian!
| bfors wrote:
| If I had a social life I'd be really excited about this
| vladojsem wrote:
| i can imagine this can work well for different way how to contact
| tech support. are people using it for that use case?
| bichiliad wrote:
| 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.
| michaeljelly wrote:
| 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.
| bichiliad wrote:
| I can't tell you how great this is to hear! I'm really
| excited to give it a try.
| kuter wrote:
| 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.
| css wrote:
| 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
| NikolaNovak wrote:
| 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... :-/
| shepherdjerred wrote:
| I'm also confused. I filled out the form and was then
| redirected with no other info?
| rkul wrote:
| https://twitter.com/imrichvalach/status/1351935706097135617?.
| ..
| soheil wrote:
| 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?
| flyGuyOnTheSly wrote:
| I doubt it.
|
| Probably just a lot of upvotes in a short period of time.
|
| It's a pretty cool idea.
| soheil wrote:
| 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?
| saagarjha wrote:
| This is not always the case. New comments get upweighted,
| but they do not get "pinned", if that makes any sense.
| maikhoepfel wrote:
| 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.
| worldmerge wrote:
| Because you're using APIs, if I stop paying I won't lose my
| messages right? They'll still be in my other apps?
| 3np wrote:
| 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.
| Arathorn wrote:
| 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 :)
| maneesh wrote:
| I just signed up and filled the form. It redirects to the home
| page. How do I find the link to download?
| CosmicShadow wrote:
| I keep thinking that's the PayPal logo
| usbfingers wrote:
| 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!
| adkadskhj wrote:
| 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/ ?
| louis-lau wrote:
| You read that wrong.
|
| Available on MacOS, Windows, Linux.
|
| iOS and Android via Element.
|
| So they made a desktop client.
| adkadskhj wrote:
| Ah hah, thank you!
| KitDuncan wrote:
| Wow Syphon looks sweet. Gonna try it (knowing that it's not a
| finished product)
| erohead wrote:
| I've been following Syphon, it looks great!
| properdine wrote:
| 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.
| npmisdown wrote:
| 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.
| anticensor wrote:
| Discord allows relay bridges (using bot accounts), but not
| puppeting.
| jakelazaroff wrote:
| 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
| kitkat_new wrote:
| 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.
| Half-Shot wrote:
| 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.
| stryan wrote:
| 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.
| timdorr wrote:
| Well, that would be what they're doing here, no?
| Macha wrote:
| 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
| saagarjha wrote:
| I have yet to see any verbiage in the Discord ToS that mentions
| this...do they really not read their own legalese?
| acct776 wrote:
| After a disclaimer, that sounds like a problem between the user
| and the Discord people.
| jakelazaroff wrote:
| Yes -- I would be the user, and I would like to avoid that
| problem.
| doublerabbit wrote:
| 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.
| aquaticsunset wrote:
| They didn't start that way though. It wasn't until they were
| forced to play nice under regulatory action.
| maelito wrote:
| > Interesting, please tell me this is based on matrix
|
| > Oh, the matrix logo among others, good thing at least
|
| > YES !
| alaenix wrote:
| 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$).
| chenster wrote:
| 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.
| KitDuncan wrote:
| 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.
| EGreg wrote:
| Wait wait -- how is Beeper able to use WhatsApp API?
|
| I thought it was closed!
| hemmert wrote:
| Awesome, Eric! Keep it up!
| xx4xx4 wrote:
| i hope the company supports parity purchasing power for the 3rd
| world countries... idk maybe $5 a month.. it would be very
| helpful..
| arsome wrote:
| 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.
| jaimex2 wrote:
| If the price comes down I'd be very keen.
| dkman94 wrote:
| Is this the wuphf rebrand?
| xlance wrote:
| Just watched this episode earlier today, my exact thought ^^
| ronyfadel wrote:
| 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.
| recursivedoubts wrote:
| Please, someone do this for email.
| tracyhenry wrote:
| Doesn't your phone's email app support multiple email accounts?
| Gmail and Outlook both support mail forwarding too?
| recursivedoubts wrote:
| 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.
| louis-lau wrote:
| 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.
| erohead wrote:
| Already in the works :)
| https://github.com/JojiiOfficial/Matrix-EmailBridge
| fangyrn wrote:
| what do you mean?
| jcul wrote:
| 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?
| erohead wrote:
| we use synapse right now. Hopefully moving to dendrite when
| appservice support is added
| krisgenre wrote:
| 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.
| lc3sim wrote:
| Congrats on the launch! My understanding of the space is that
| there is a great desire for "super powered" messaging -
| especially over text. Any chance "send later" is a part of your
| roadmap? Or possible to implement using your API?
| erohead wrote:
| definitely on roadmap
| ggm wrote:
| PSI is dead, all hail Adium.
|
| Adium is dead, all hail Beeper.
|
| Is that it?
| GekkePrutser wrote:
| 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.
| ggm wrote:
| 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.
| wnscooke wrote:
| 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?
| hansdieter1337 wrote:
| 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.
___________________________________________________________________
(page generated 2021-01-21 23:02 UTC)