It can be done in a decentralized manner; that is exactly what I'm building now... Device to device. No centralized server. Can ping any app on my phone (as long as it's registered with my app) from my laptop using terminal, curl and tor.

Server is embedded in the application that other apps on the device can register with. Http calls hit the server and get routed to the registered app.

It's a one click install for users. All overhead is pushed to developers to setup the client library for IPC, and then me to maintain the app & client library. UX is dead simple consumer wise, unlike other products that may require users to run a server at home or something.

Reply to this note

Please Login to reply.

Discussion

It seems like you’re headed in a good direction but then it’s no longer a drop in replacement, right?

I was referring to projects that aim to provide a Google Play Services reimplementation that can be just dropped in place, which doesn’t require any changes to make existing apps work. And that’s the approach that I think would lead to centralization.

Still, I think it’s important for OS developers to ensure that, to be able to let the device sleep as long as possible, they should provide app developers with APIs that would allow the OS to effectively “sync” background tasks so they’re executed simultaneously, resulting in a shorter timeframe where the device is woken up.

Then it shouldn’t matter all that much if you have multiple apps delegating this work to one or few other push provider apps, like it was proposed by another guy in this thread, or if you have many apps fetching individually.

What I found out is that our devices are damn fine at sleeping but once you do need to wake up, you better ensure you’re making use of every milliwatt “while you’re at it”, and synchronized timers work for both reducing the wakeup count and overall time spent at this higher energy state.

Oh. Like microG?

https://github.com/microg