imessage VS Synapse

The nothing website claims:

> Nothing Chats is built on Sunbird's platform and all Chats messages are end-to-end encrypted, meaning neither we nor Sunbird can access the messages you're sending and receiving.

> Nothing is powered by Sunbird, and Sunbird's architecture provides a system to deliver a message from one user to another without ever storing it at any point in its journey. Messages are not stored on Sunbird's servers and are only live on your device – once a message is delivered, it can only be recovered locally from your personal device.

From: https://us.nothing.tech/pages/nothing-chats

The Verge claims:

> Marques Brownlee has also had a preview of Nothing Chats. He confirmed with Nothing that, similar to how other iMessage-to-Android bridge services have worked before, “...it’s literally signing in on some Mac Mini in a server farm somewhere, and that Mac Mini will then do all of the routing for you to make this happen.”

From: https://www.theverge.com/2023/11/14/23960516/nothing-chats-i...

It seems to me like if they are doing the typical thing of using a bridge like https://github.com/mautrix/imessage then that isn't really E2EE, the messages are being stored, and could be accessed by Sunbird. I don't really see how their claims could be true. Does anyone know? Am I missing something?

If you're willing to dive deep into self-hosting, the open source chat protocol Matrix.org has support for an in-development iMessage bridge. Once you get it to work, there's a Matrix.org client on KaiOS devices called Chooj (sideloading guide) made by Farooq that you can use to access the chat.

iMessage bridge

The disadvantage of not offering an API for iMessage is that there is no easy way to block clients. Apps like Bluebubbles have to work by being installed on an actual Mac and scraping messages from iMessage and Beeper uses a similar architecture[0]. Presumably they have a data centre full of actual macs (or VMs).

[0] https://github.com/mautrix/imessage

I have an old Mac Mini rotting on a shelf in my cupboard which is my bridge to the world of Apple shit. It primarily runs two bits of software: OpenHaystack, which I used to run my own object trackers over the Apple Find My network and Mautrix iMessage which I used to access iMessage via Matrix on my Android and Windows devices.

I've switched from iPhone to a de-googled Android device, and am generally trying to extract myself from google and apple ecosystem lock-in. The last piece for me is trying to find a reasonable bridge for iMessages - but the baseline requirement is to have a Mac PC running 24x7 to act as a bridge for matrix or airmessage. Here's my question: the hardware and software requirements for iMessages are pretty minimal. MacOS Big Sur implemented a few messaging bits like inline replies which I'd like to keep, so that's my OS baseline. Has anyone managed to strip down a hackintosh hardware installation to absolutely minimal proxmox hardware demands (e.g. ram/cores)? If so, got a recommendation on an efficient build process?

I know how crazy it is in America, but I think at leat the HN crowd wouldn't be participating in that madness.

If you are disparate enough, you can use a matrix bridge to get blue bubbles from anywhere

https://github.com/mautrix/imessage

Yes, tulir works for beeper. But I think they stopped doing that iPhone thing, and if you use iOS there are less features available: https://github.com/mautrix/imessage/blob/master/ROADMAP.md

I have an Android phone and if you're desperate you can buy an old Mac Mini and set up an iMessage bridge over Matrix (https://github.com/mautrix/imessage) or BlueBubbles to work around this. I do not recommend it though as it locks you into a facet of the Apple ecosystem.

What are you thinking of here? Synapse has supported purging room history since 2016: https://github.com/matrix-org/synapse/pull/911, and configurable data retention since 2019: https://github.com/matrix-org/synapse/pull/5815.

Meanwhile, Matrix has never needed the full room history to be synchronised - when a server joins a room, it typically only grabs the last 20 messages. (It does needs to grab all the key-value state about the room, although these days that happens gradually in the background).

If you're wondering why Matrix implementations are often greedy on disk space, it's because they typically cache the key-value state aggressively (storing a snapshot of it for the room on a regular basis). However, that's just an implementation quirk; folks could absolutely come up with fancier datastructures to store it more efficiently; it's just not got to the top of anyone's todo list yet - things like performance and UX are considered much more important than disk usage right now.

some context re the Matrix isses, long history apparently: https://github.com/matrix-org/synapse/issues/14481#issuecomm...

Why not Matrix? Here's one reason: it has incredibly hard-to-debug edge cases, and plenty of bugs. One of my favourites is the one where people are kicked out of your room at random, which was reported a year ago[0]. It wasn't fixed, however, because the head of the Matrix foundation (Matthew) presumably didn't like the issue being posted on Twitter.

This is honestly really disappointing behaviour from a platform owner.

[0]: https://github.com/matrix-org/synapse/issues/14481

> That doesn't make this situation any less bad to the rest of the community.

How is the community suffering here? Let's say Element adds a bunch of baller stuff to their versions over the next few months and then closes the source. Can't the community just fork the last AGPL version? You might say, "well then no one can take the AGPL fork and make their own closed-source business", but do you want them to? Even if you do, they still can with the existing Apache-licensed version, just like Element is doing right now.

You're arguing that Element will lose a lot of contributions, but TFA points out that despite being super open, the vast majority of contributions are still made by Element employees (which seems to be true [0]). It's not the case that Element is looking to monetize the (small) contributions of others, it is the case that others are looking to monetize the (huge) contributions of Element.

And besides, aren't the MSCs the core of Matrix? It's already super possible to build your own compliant client and server.

The situation is that Element needs money to keep developing the ecosystem. It would be cool if there were a big network of donors and contributions, but there isn't. You're essentially saying, "that's fine, go out of business then, and the community will keep developing the ecosystem", but that's not happening now, and it can still happen anyway with the Apache-licensed versions, which again people can still contribute to.

[0]: https://github.com/matrix-org/synapse/graphs/contributors