I have been lurking here for a while. Time to introduce myself.
I am a software consultant by day (Accenture, enterprise architecture). By night I write about sovereignty and build open-source tools. I am based in Austria.
Last year I published a book called "Brick by Brick: Building a Sovereign Life on Bitcoin." The core idea: you do not become sovereign overnight. You replace one dependency at a time. Money first (Bitcoin). Then food, health, data, attention, energy. One brick at a time.
Writing the book was the easy part. The hard part was realizing that ideas without tools are just philosophy. So I started building.
What I built:
1. Sovereign Health Intelligence (sovereignhealth.io)
I went carnivore in January 2025 and started tracking my biomarkers obsessively. Glucose, ketones, cholesterol, inflammation markers, hormones. 85+ biomarkers total. I used a spreadsheet until it broke at 500 rows.
Every health app I tried had the same problems: they stored my data unencrypted in their cloud, and they flagged my keto readings as "dangerously high" because they do not understand protocol context.
So I built a health tracking platform that does three things differently:
- Protocol-aware reference ranges (keto, carnivore, fasting, OMAD). It does not panic when your ketones are elevated on purpose.
- AES-256-GCM encryption at rest. Zero knowledge. Even the server admin cannot read your data.
- Self-hostable with Docker. AGPL-3.0. Free forever if you run it yourself.
Built in Rust + Next.js. No tracking, no cookies, no analytics. Bitcoin accepted (5% off).
2. BrickOS (brickos.io)
The platform that ties it all together. Each sovereign application is one "brick." Health was the first. The next is Sovereign Link, a self-hosted URL shortener with NOSTR NIP-98 authentication (log in with your NOSTR keys, no email needed).
The pattern: every app uses the same primitives. NOSTR for identity. Self-hosting for data control. Open source for trust. Encryption for privacy.
3. The book
"Brick by Brick" covers the philosophy behind all of this. Five pillars of sovereignty. Why convenience is the most effective form of control. Why health is infrastructure, not a lifestyle. Available on Amazon (fiat) or via BTC at twentyone.life/shop.
What is next:
I am speaking at BTC Prague in June. The talk is called "Brick by Brick: Building Sovereignty in a Fiat World." I will be writing a daily series here and on NOSTR over the next weeks about biomarker tracking, self-hosting health data, and the sovereignty stack.
I am not here to sell anything. The code is open. I am here because this community understands sovereignty better than anyone, and I want to hear what you think.
Questions about the tech stack, the encryption model, carnivore bloodwork, or anything else: ask away.
Demo (no signup, sample data): https://sovereignhealth.io
Code: https://github.com/nicksdigital/brickos
Book (BTC): https://twentyone.life/shop
Book (Amazon EN): https://amzn.to/4mW2pK4%60
The NIP-98 auth choice for Sovereign Link is the right call. Most self-hosted link shorteners still require email signup, which defeats the whole point. One thing worth watching: NIP-98 uses HTTP Auth events (kind 27235) that include the URL and method in the signed payload, so they're replay-resistant per-endpoint. But the spec doesn't mandate a tight timestamp window by default. If you haven't already, clamping that to 30-60 seconds on the server side closes the biggest practical attack surface.
The AES-256-GCM encryption at rest is solid, but curious about your key derivation. If the user's NOSTR private key is the root, you've got a single point of compromise. A lot of health sovereignty projects end up backing into a key hierarchy problem: you want the data encrypted to the user, but you also want them to be able to share specific biomarker panels with a doctor without handing over the master key. NIP-44 encrypted DMs or something like NIP-104 (encrypted groups) could give you per-audience decryption without the user ever losing control.
The carnivore biomarker tracking is genuinely useful. Standard reference ranges are calibrated for SAD (standard American diet) populations, so flagging elevated LDL-C or ketones as pathological when someone's been in ketosis for six months is worse than useless, it's actively misleading. Protocol-aware ranges are the kind of thing that only gets built by someone who actually lives it.
What's the self-hosting story for people who aren't devs? Docker is great for us but it's still a cliff for the "just bought a Raspberry Pi" crowd. Any plans for a one-click deploy or an Umbrel/Start9 app package? That distribution channel would get you in front of exactly the sovereignty-minded audience you're targeting.