I wanted to build an end-to-end encrypted, distributed, bi-directional, binary PUSH protocol for the Librem 5. In fact I wrote my dissertation on that topic. There are several advantages in building something like that.
Firstly, multiple applications polling their corresponding servers for updates would produce significant CPU and network overhead. In the case of a phone it will result in a increased power consumption. Having to poll only a single server for updates would extend the battery life. And for the record even communication that uses event driven architecture and sockets performs polling - just at a lower networking level. Nevertheless it will still result in CPU processing and radio transmissions.
Secondly there is the security aspect. I wanted to design a protocol that is end-to-end encrypted and decentralised by design. If encryption is something you have to add as an extra - lazy developers would just skip doing it. I want to force encryption at the protocol level. Additionally everyone will be able to deploy a small PUSH server of their own and point their phone at it so they control the intermediary as well. You should also be able to use multiple PUSH servers simultaneously to increase deliverability in case one server is unavailable or compromised.
Thirdly, a bi-directional PUSH protocol can be used for providing services for efficiently issuing remote commands for tracking, ringing, locking and erasing your device without compromising it’s security. This will be a service similar to Google’s Find my Device and Apple’s Find My iPhone. Only this time the protocol is open and end-to-end encrypted and the implementations is free software so whenever you are tracking your device because you can’t find it Google (or any intermediary for that matter) wouldn’t know where it is.
Since I wrote my dissertation on this, I have already figured out the details in terms of implementation, encryption and etc. At the moment I’m looking for funding and volunteers to assist me in the effort. If you’re interested, definitely get in touch on matrix: @itay-grudev:m.hacktag.uk and if you’re interested in funding the effort: https://monzo.me/itaygrudev.
This - is pretty much the biggest gap in the whole mobile concept. I like the idea very much as nowadays you can run own service for almost anything but push is always locked. And that degrades push to mere ‘something happened somewhere’ rather than providing efficient transport for idle mode delivery.
Is the concept of the service available for review/comments or you consider it own intellectual property and thus closed from public?
This could be an interesting topic, but I have some reservations regarding whether this actually needs to be done.
Do you have any data showing that letting applications poll is any better for power consumption than having the network interface do the polling? As far as I can tell, the modem, the WiFi card, etc., already need to do that anyway.
Is it more decentralized than each application contacting its own server? It seems to me that a push server only introduces an intermediary, without doing much for decentralization at best.
Is there a reason this has to be done with a push protocol instead of a transport-agnostic application?
I think what is meant is that instead of tuning each application’s socket to work in high-latency environment (low-power network interface mode, low response from app) which may require specific setsockopts and ioctls (eg window, keepalive, selective acks, etc.) just introduce central high-latency bus (alike dbus) to allow app backends to send notifications causing client to reconnect or at least to wake up. That bus may use UDP for simplified flow control and one-off notifications.
You mean modifying glibc defaults?
Ah, got it, well it could well be a library which will open alternative transport for delivery. it just may make it a bit more complicated and eventually introducing multiple sockets… that’s exactly what comes to the area of review/comments of the concept. fully distributed concept is really a library (not bound to specific service)
Sorry, I don’t have any hard facts to support this, but couldn’t there be more reasons for Firebase (Google Cloud messaging) than just harvesting more of peoples’ personal data?
I mean, wake-up is is expensive - especially waking up radios - so a single push service could potentially let the device sleep more than having each and every app poll. (email, XMPP chat, Matrix chat, Mastodon, calendar sync, …)
The rest of your message contains a potential answer:
Application polling is expensive, but also not the solution unless we consider HTTP to be the only acceptable network protocol.
Radio have to be on all the time anyway, listening for incoming packets before they get filtered and dispatched to the OS, so to me this sounds like the layer which should be used for accepting incoming communication.
There might be another reason for Firebase, which has nothing to do with power use, but everything to do with application lifetime. Android applications can be killed by the OS at any time, transparently to the user. A persistent, direct connection to an application doesn’t work under the circumstances. And without a direct connection or a running program, there’s no destination for a server to send data to. So an intermediary becomes required.
It sound like you might be interested in taking a look at the decentralized nature of the Safe Network. There are some links in the above post. The Maidsafe Github repository can be found here:
That could be the case for WiFi, idk, but when it comes to cellular I think there is a lot of effort put into maximizing sleep and minimizing wake-ups. Entire clock domains in the SOCs are shut down, radios are just turned on briefly to stay in touch with base stations, etc.
Okay, what I said is not strictly true. I should have said: for the purpose of handling incoming packets versus polling, there is no difference in radio usage.
The radio, regardless of which tech, will periodically wake up from low power mode, and ask the other end for updates. Say, in 10 seconds intervals. Without polling, that’s when it receives a data packet sent by the remote host, and passes it to the application.
With polling, it wakes up every 10 seconds, but never sees anything. Every 100 seconds or so, the application wakes up the radio in addition to the 10 sec cycle, to send and receive some data to/from the push server.
There’s not much difference between those 2 strategies.
The difference starts when you have various application stacks. Some of them statefull (xmpp) some stateless (POP3) some mixed bag (IMAP4). All having different timeouts, back-off and retry timers, etc…
Then there are HW power states, frequency scaling, etc. so some apps have no time/desire to reconnect during wake period and skip it (eg due to growing backoff). If there’s a some sort of DBus signal which clearly indicates something is waiting - app may cancel backoff and force reconnection (as if user started interacting with it).
The push service on the other hand will be designed to quickly (re)connect on the wake and gather the events. So on one hand it won’t bash the CPU during wake allowing other apps to enjoy their sleep, on the other it won’t consider it needs to backoff - it must connect and poll.
No, not necessarily. See, despite TCP is reliable protocol there’s still SM in XMPP. And original SM was not even to do resumption, merely to guarantee stanza delivery (to protect from partial writes).
So an app may consider connection to be dead and give it up, and start reconnecting. Also if you put TLS on top it happens even more frequently due to the cipher block not always being aligned with MSS.
Some services introduce artificial delays to protect from abuse (eg SMTP hello delay) so f.i. smtp app which found connection closed, reconnected but went sleeping after it sent hello will most probably wake up with connection closed again by the server (bad example for push but just to illustrate that mere tcp flow control is frequently not sufficient).
