📋 Got 5 minutes? Tell us what's actually broken about family tech — take the survey →
PresenceOS
Theme

For Developers

PresenceOS today is two React Native Android apps (the PresenceOS launcher and a Guardian Companion app), with native Kotlin/Java modules where Android requires them, plus a dedicated-device GSI build in development. The long-term engineering goal is to separate the user experience from Android-specific assumptions, so the stack can move when the hardware does.

There are no user accounts in the system — no passwords, no email or phone signup. Identity is a keypair generated on the device, and the relay authenticates by challenging it. Messaging and calls are end-to-end encrypted, and contact pairing is NFC tap-to-pair.

Beyond Android

The move off Android is not a whiteboard exercise anymore. I have a booting Linux userspace on a Motorola Edge 50 Fusion that is completely void of Android and Google: the phone's hardware, the vendor's drivers and hardware-interface layer, and my own systemd userspace running the PresenceOS UI on top. Think postmarketOS, but it's PresenceOS — only PresenceOS. It's early — a first iteration — but it boots on my bench today. The vendor's proprietary driver code is still required at that layer for now; one day it won't be. While that firmware matures, the Android-based apps are the shipping vehicle.

Hardware Vision

Future devices are planned with no exposed charging port, no SD slot and no audio jack — fewer ports, less attack surface. Firmware flashing would require removing a screw under a security sticker, and removal triggers a wipe intended to erase user data before anyone can attempt firmware extraction.

Backend

The relay and WebRTC infrastructure run on my own hardware in New Zealand, and so does the rest of the stack: DNS, this web server, mail, the form handler, the git server the source lives on. No cloud providers, no Cloudflare, no Google services. Push notifications work without FCM — devices hold a long-poll wake channel to the relay. Updates are the same shape: I build the APK, publish it to my own server, and the apps self-update; a relay-enforced minimum-version floor keeps old insecure builds from connecting.

Source Code

PresenceOS is closed source, at least during development. I'll say that plainly rather than dress it up: it protects me, the codebase, and my workstation while this is very much a beta built and defended by one person. How the licence looks later is a decision I'll make together with the people who invest in me and in this pilot. I support open source, GNU and copyleft principles and build on all three — this is about timing and exposure, not ideology.

The supply-chain climate is part of that decision. In May 2026, GitHub confirmed a breach in which an employee installed a poisoned VS Code extension and thousands of GitHub-internal repositories were exfiltrated; the same actor wave poisoned well over a hundred npm and PyPI packages and hijacked a VS Code extension with over two million installs, and a copycat attack then hit thousands of public repos with malware-laden commits. On 9 July 2026 I moved all PresenceOS source off GitHub onto my own git server, on my own hardware. For a privacy product, hosting the code on someone else's platform was — in hindsight — a mistake, open source or not. The blog covers it in depth.

Closed source doesn't mean closed to scrutiny: if you're a security researcher and want to review the code, including the backend, ask — that's a conversation I want to have.

Current Results

On my development hardware, PresenceOS has shown roughly 45% better battery life than the OEM firmware configurations I compared against. My own informal measurement, not a lab result — most of it is the absence of Google services and background chatter.

Long-Term Goal

A PresenceOS ecosystem that can operate without GSM connectivity, using the devices themselves as encrypted radio mesh nodes for messaging and voice.

Get In Touch

PresenceOS is a one-person project and stays that way — single accountability is the design. What I do need is testers, security researchers willing to break things, and honest review from embedded, RF and infrastructure people. Email paul@presenceos.email or call +64 22 629 2483.