BeeBEEP has no server: your messages travel directly between your devices. It is what makes it private, and it is what makes phones hard. A phone in a pocket is asleep, and there is nobody to wake it. Here is how the problem looks, what is planned, and what is still only an idea.
The problem
On a computer BeeBEEP is simply running. On a phone the system decides. An iPhone keeps no network connection open for an app that is not on the screen. Android is more generous but not much: after a few minutes it stops the background networking too. Messengers with a central server get around it because the server can ask the system to tap the phone on the shoulder. With no server, a message that nobody can deliver waits, and the user, who sees nothing, concludes that the application is broken.
Android: stay alive, and say so
Android lets an app keep working if it declares it openly. So the Android BeeBEEP will offer a foreground service: a permanent notification that says BeeBEEP is running, the connection kept alive on Wi-Fi, and a notification for every message that arrives, raised by BeeBEEP itself, no server involved. It is the way Syncthing and Briar work. It is on by default, with its cost in battery stated plainly, because without it the phone works only while you look at it.
Some phone makers add their own battery killers on top of Android's. For those, BeeBEEP will tell the user in plain words how to allow it to keep running in the background.
iPhone: only Apple can knock
On iOS there is no such thing: a closed app cannot keep itself alive, and the only doorbell is Apple's own push service, which accepts requests only from a server that belongs to the app's developer. It is the one thing a serverless application cannot do at all. The idea is the smallest possible server, one that knows nothing. This is how it would work:
- The phone tells the service its address at Apple, and nothing else. The service keeps that.
- A colleague who cannot reach your phone asks the service to wake it. It could only do so by proving to be someone your phone knows.
- The service asks Apple to show a generic line: "You have a new message". No message, no chat and no name would ever pass through it, so end-to-end encryption is untouched. All it would learn is that a device was woken.
- You tap the notification, BeeBEEP opens, connects to your network and the real messages arrive, as always, directly from your colleagues.
It would be a choice, not a requirement: the phone opts in, wake-ups are limited in number so nobody can use them to pester you, and the service would be open source, so an organization could run its own for an app it signs itself.
A server, or no server?
This is the part that is not decided, and it is not only a technical matter. BeeBEEP has always been serverless, and that is what its users value: nothing to install, nothing to trust, nothing that can be switched off. Even a server that carries no content is still a piece of infrastructure that somebody has to run, pay for and keep available, and that a feature would depend on. It changes the promise, even if only for one function on one platform.
- Costs. Hosting, the Apple developer key that must be kept safe, monitoring, and the obligation to keep it running for as long as phones rely on it. They are still to be evaluated.
- The principle. A service that everyone would use for the same purpose is a single point of failure, and a target, however little it knows.
- Usability. On the other side stands the plain fact that a messenger that does not notify is, to the person holding the phone, broken. Sooner or later BeeBEEP will have to choose, and the reason will be how usable it is on a phone, not the technology.
Until then the plan does not depend on it: the Bluetooth pager below and an application that receives while open need no server at all.
And without it: Bluetooth
Without such a service, BeeBEEP receives while it is open. There is a second way to wake a phone that needs no internet: Bluetooth. The roles must be the opposite of what one would guess. A sleeping iPhone that advertises is invisible to computers, but a sleeping iPhone that listens for a known signal is woken by the system when it hears it. So the computer is the beacon and the phone finds it: when a BeeBEEP computer in range has something for you, or a colleague is calling, the phone wakes, connects and shows a notification. The range is the office's, not the world's, which is exactly where BeeBEEP lives. It costs a little battery, so it is optional.
For calls the rule is even simpler: if the other person cannot be reached, a line stays in the chat saying that you tried, delivered as soon as they are back. BeeBEEP as a pager.
Where things stand
The notifications already work on the desktop. The Android service and the Bluetooth pager are planned and still to be built. The wake service for iPhone is an idea under evaluation, for the reasons above. What can be said to users today is this: on Android, keep "Run in the background" on and BeeBEEP notifies you like any messenger. On iPhone, Apple lets no app receive in the background without a push service, so BeeBEEP receives while it is open, and a BeeBEEP computer nearby can wake it over Bluetooth.