this post was submitted on 06 Dec 2023
182 points (82.5% liked)
Technology
59207 readers
2934 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
So if the app will be open source like they say, can't we just build it ourselves and not pay $2/mo?
There shouldn't be any back end beeper servers with this implementation if they really do what they say and interface directly with Apple servers.
It's a bridge for notifications. Since Apple's APN notification servers require a persistent connection to work, meaning that the application must be running continuously to receive notifications, the Beeper servers push those notifications (messages) to your phone.
This means that the application does not need to be running continuously to receive messages.
Exactly. They host the Apple equivalent to GMS, which is called APN (or is it ANP? Apple Notification Protocol? I forget, but the Bubbler Mini devs explain it well)
Here's a simple picture with minimal reading required.
This is very different to the technology used in the free/wait-list Beeper Cloud app and all the other previous attempts at an iMessage for Android app.
To summarize:
All messages are sent directly between your device and Apple's servers. You do not even need an AppleID. There is a cloud server involved but it's only job is to send push notifications to Android so they app knows when to download new messages (securely with iMessage encryption) from Apple's servers.
No message contents are sent through the cloud server, it just notifies your device when there are new messages. This is necessary because Apple servers obviously do not support Android push notifications.
Running BlueBubbles at the moment, eagerly awaiting someone to build a self hosted implementation of this so I can stop relying on my macos VM.
This implementation I think also allows you to use the phone number of your android device, which is a feature that not even the BlueBubbles method has been able to do.
Beeper Mini does not require a Mac VM or any Apple products. There's no cloud proxy to self host. It registers your phone number directly with Apple's servers, you don't even need an AppleID at all, just like on an iPhone.
It's indistinguishable from an iPhone on Apple's end and your iMessage encryption keys never leave your phone
Yeah I know I was referring to the notifications, because my understanding is that you need a separate server to forward notifications to your device from the APN...? Idk maybe the firebase free tier can handle this without the need for a desktop app running somewhere.
Notifications are generated after the message is pulled from Apple's servers to your device.
The push messages just tell your device a message is available to be pulled. It doesn't contain any message contents or metadata.
It's basically just "you have a new message waiting" and then your phone will ping Apple's server to request the message.
Kind of, but it's more complicated. I'm not sure if the app itself will be open source, but currently, the method they use is. Either way, the hardest part is already done, but you still need a client (maybe; they might open-source it) and a notification server. I'm planning to attempt to build a Matrix bridge if I have enough time and it's not beyond my skills, but if you don't want the messages to be decrypted by the server, making the notification server and maybe client would be really difficult.
I'm pretty sure the point of this is that the official iMessage servers are the notification server.
Sort of.
All messages/etc are sent using iMessage encryption directly between your phone and Apple's iMessage servers.
But there is no Android push notifications from Apple's servers.
So in order to be notified about new messages in a timely manner without killing your battery/data plan a cloud server is required to trigger your phone that a message has arrived so your phone can then request the message from Apple's servers.
This is actually a really common implementation, many apps use Firebase or similar to handle push notifications that are only used to trigger a "pull" of a larger chunk of data.
The push notifications being used here don't contain any private data, they just tell your device when to collect that private data securely.
Ah, I see what you mean. That's pretty neat architecture.
Don't see why not. Whats the timline on this?
Its already available for download and use, but I can't find the source anywhere other than a Python proof of concept project that beeper purchased the rights to to make this app.