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.
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.
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).
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.
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.
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.
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?
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.
...but any help is always welcome!
