05nelsonm / Matt Nelson is on Nostr

Navy -> NASA -> Sphinx Chat -> Strike -> FLOSS
PGP: 0x61471B8AB3890961
Kotlin Multiplatform and C are the way

Last Notes

2025-11-03 10:54:41 UTC

- reply

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

2025-11-03 01:28:57 UTC

- reply

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.

2025-10-06 21:42:02 UTC

- reply

Mynymbox, Namecheap, Porkbun

2025-09-06 16:55:04 UTC

- reply

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.

2025-09-05 16:53:34 UTC

- reply

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.

2025-09-05 15:41:58 UTC

- reply

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

2025-09-05 13:19:52 UTC

- reply

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.

2025-06-23 23:29:18 UTC

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)

2025-06-10 19:33:34 UTC

- reply

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.