Nostr notes by 05nelsonm

Sorry, the string value to declare in your manifest is actually ...

2025-11-03T10:54:41Z

In reply to nevent1q…ywq3
_________________________

Sorry, the string value to declare in your manifest is actually `PACKAGE_REPLACED` not `ACTION_PACKAGE_REPLACED

Did you also handle the needed restart on new version being ...

2025-11-03T01:28:57Z

In reply to nevent1q…4rhd
_________________________

Did you also handle the needed restart on new version being installed?

When user updates the app, Android will kill the process, then dispatch a system Intent to it after installation completion. It will receive a warm start whereby the Saved Instance State is recoverable.

Mynymbox, Namecheap, Porkbun

2025-10-06T21:42:02Z

In reply to nevent1q…y3y9
_________________________

Mynymbox, Namecheap, Porkbun

I would highly advise against such a setup, where every app ...

2025-09-06T16:55:04Z

In reply to nevent1q…hy67
_________________________

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.

It can be done in a decentralized manner; that is exactly what ...

2025-09-05T16:53:34Z

In reply to nevent1q…v4zk
_________________________

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.

I'd love too, but am booked for the next couple of months ...

2025-09-05T15:41:58Z

In reply to nevent1q…ltxj
_________________________

I'd love too, but am booked for the next couple of months under a sponsorship from OpenSats (nprofile…grcu)
to work on kmp-tor. After that, I resume work on that project.

Signal uses the socket-io library to maintain an open socket with ...

2025-09-05T13:19:52Z

In reply to nevent1q…2znt
_________________________

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.

Love it! Definitely update kmp-tor. That old API was atrocious ...

2025-07-18T23:29:10Z

In reply to nevent1q…zvmz
_________________________

Love it!

Definitely update kmp-tor. That old API was atrocious (sorry 😂).

Spent the day working on a complete overhaul of kmp-file's ...

2025-06-23T23:29:18Z

Spent the day working on a complete overhaul of kmp-file's API.

This new API will be highly focused file/directory permissions and atomic filesystem operations.

Unfortunately, permissions have always taken a back seat when it comes to Kotlin IO libraries, even in Java. The API is cumbersome and you always have to check if you're on Windows (not POSIX) lest you forget and crash. Additionally, Java's nio API is not available for Android API 25 and below which makes it difficult to come up with a simple to use API.

BUT! Android API 21 introduced the Os and OsConstants classes with access to all the native APIs. With some magic (reflection b/c kmp-file is JVM only), one can have the best of both worlds.

I hope to make permissions a key part of the API, forcing the API consumer to always have to express SOMETHING (null for default dir/file permissions).

API for all platforms will look something akin to:

"/some/path/to/file.text".toFile().writeUtf8(text = "Hello World", mode = "644", mustCreate = true)

"/some/path/to/dir".toFile().mkdirs2(mode = " 744").resolve("new.txt").writeBytes(data = "Hello World!".encodeToByteArray(), mode = null)

It's really awesome how far it has come; stellar work. ...

2025-06-10T19:33:34Z

In reply to nevent1q…u02f
_________________________

It's really awesome how far it has come; stellar work.

It's weird though, every chat app I look at has this unfortunate structure with "some server" component hosting all the data (or at least facilitating delivery of it), which necessitates the additional layer of e2ee like MLS or Signal Protocol.

I really want to get rid of that layer and go direct; device to device. No need for those protocols and the complexity they add if there's no middle man touching your sh!t.