Nostr Web Client

Looks like a Signal issue. Pokey does a similar thing and uses less than 1% in my phone

Signal uses the socket-io library to maintain an open socket with their backend; it's incredibly resource intensive.

Tutanota uses the SSE API for their push noticication service and does a pretty good job on their end as it relates to battery consumption.

That said, if every app were to implement their own push notification service, 5+ apps doing on a device that turns a "mobile" phone into something that always needs to be plugged in. It does not scale.

I ran a test on Android using kmp-tor and a ktor server exposed as a hidden service, pinging it every 5 min via cronjob from my server at home. Over 24h, battery consumption was about 5%-7% depending on the test device.

Working on a product right now for drop in replacement to google/apple services, but it's far from ready.

Reply to this note

Please Login to reply.

Discussion

Vitor Pamplona 3mo ago 💬 2

Any chance you can help Pokey instead of building another product? I would love to keep it alive and just get Amethyst users to install Pokey instead of running a Pokey service inside of Amethyst.

Matt Nelson 3mo ago

I'd love too, but am booked for the next couple of months under a sponsorship from nostr:nprofile1qqs8suecw4luyht9ekff89x4uacneapk8r5dyk0gmn6uwwurf6u9ruspzpmhxue69uhkumewwd68ytnrwghszrnhwden5te0dehhxtnvdakz7d8grcu

to work on kmp-tor. After that, I resume work on that project.

Vitor Pamplona 3mo ago 💬 4

Nice! I think Pokey might need a service-like lib, just like the Tor one, that any app can import and start the service by itself. But if many apps do this, only one service runs. nostr:nprofile1qqsxg45ph8gx0vdrvtzta6xal7v86frx6jvstsnvhrlvtehmwwh4epqpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9cc8scmgv96zucm0d5hszxmhwden5te0dehhxarj9eekzarnw3exzmrfvyhxxmmd9uuxk3na

In that way, we can all run Pokey internally and as long as one Nostr app is active, everybody benefits.

Matt Nelson 3mo ago

The coordination needed to do that is tremendous, especially when you get into versioning. A dedicated companion app is better. "Hey user, if you want to use this feature XYZ in my app, install this other app so mine can register with it".

Makes the UX dead simple for both users and developers by moving the overhead to a single application & thin IPC client library for other apps to import and configure (just like registering with Play Services Framework).

KoalaSat 3mo ago

It shouldn't be that hard to do since I already implement it as a Service. Bad news is that I have no idea how to define it as a lib, I need to dig into it.

Vitor Pamplona 3mo ago 💬 2

You might need to do a Content Provider for your DB. Otherwise each service will have their own DB.

Ideally if Primal and Amethyst both import Pokey, we can start a single Pokey service while sharing the same user settings. Starting from Amethyst or from Primal should yield the same service.

Matt Nelson 3mo ago

I would highly advise against such a setup, where every app imports the server. Logistically, that is a nightmare due to how aggressive Android is in killing processes.

Instead, I'd create a dedicated companion application users can install, and a client SDK with a thin API/protocol for developers to hook into and communicate locally via IPC.

The separation is a huge benefit for everybody (especially users) because the less code in that SDK, the more you can huck into the app and manage from 1 place. Security wise, this is beneficial too.

Vitor Pamplona 3mo ago 💬 1

So, is the plan for your Tor lib to also only work on a specific app and people have to install that app to use it?

Matt Nelson 3mo ago

Never. kmp-tor's Android service is configured to export=false. Developers can lock down notification action Intents even further by declaring a signature permission in their manifest, and configuring the service with their custom string. Giving any app on the device access to a Service or BroadcastReceiver requires careful work given the security implications.

Most app's only need access to the tor network while they're running. kmp-tor provides that for them. Archiving kmp-tor and doing something like an Orbot app would be asinine.

The application I am working on uses kmp-tor, but yes, I have baked into the SDK's IPC protocol InetSocketAddress and UnixDomainSocketAddress information for immediate access to a tor socks/http proxy, either by requesting it via Intent, and always being sent along with the forwarded http calls.

KoalaSat 3mo ago

...but any help is always welcome!

Technical Debt 3mo ago 💬 1

Aren’t there some API to align background fetch events from multiple apps so they run at the same time? I think macOS does that even on sleeping intel machines, timer coalescing ensures less “power naps” wake up the machine less frequently”.

Matt Nelson 3mo ago 💬 1

None that would supplement google/apple services like OP desires.

Technical Debt 3mo ago 💬 1

Seems like a good opportunity for de-googled Android forks to work on.

As appealing as a gapps drop in replacement sounds, it would lean towards a not-google but still centralized alternative.

Matt Nelson 3mo ago 💬 1

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.

Technical Debt 3mo ago 💬 1

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.

Matt Nelson 3mo ago

Oh. Like microG?

https://github.com/microg