Cold Root Identity milestone Python and Go now produce identical deterministic vectors for derivation and lineage. The model is stable. Canonical test vectors are frozen in: tests/vectors/cold_root_identity.v1.json CRI requires no protocol changes. Clients just follow standard kind 30001 lineage events signed by an offline root. Repo and spec: https://github.com/GHOST-UntraceableDigitalDissident/cold-root-identity If you maintain a client or SDK, you can now test against the vectors and confirm compatibility.

If it’s not Fiona Apple I’m not interested

Happy to join. Appreciate the invite. feel free to add me.

Rotation and survivable identity feel overdue and I’m glad more people are exploring the trust layer. I’ll check out the wotathon schedule and see where this fits. Thanks for the invite.

It’s definitely overdue. The more people surface the shortcomings around static keys, the faster clients can move toward safer defaults. Rotation shouldn’t be an edge case.

The epoch key is generated from the root key offline. The client never sees the root and has no visibility into the derivation process. All the client needs is the lineage event you publish that proves “this new pubkey descends from my root.” Once the client sees that lineage event, it just switches over automatically. Users shouldn’t need to understand HKDF or manage subkeys manually. Clients can handle rotation entirely. Right now the reference code is just a simple Python prototype that generates and rotates keys offline. (see below) It’s proof of concept. The end state is a small app or built in client feature that handles all of this behind the scenes with one click while your root stays cold.

Most people bleed data every day without feeling a thing. The exposure feels normal so they stop noticing. You’re the frog sitting in boiling water. https://untraceabledigitaldissident.com/digital-footprint-for-beginners-whats-exposing-you/

To clarify, you aren’t abandoning your audience because this isn’t a second identity. The root npub is still the identity everyone follows. Rotation just changes the operational key underneath that root and only clients that support lineage switch to using it. Clients that don’t support it simply keep using the existing key. Correct, a client ignoring the lineage event won’t associate the new key with the root. But the assumption that rotation is only useful when “most clients” support it isn’t accurate. Rotation is optional, contextual, and tied to the clients your audience uses, not the entire network. You rotate when your actual follower base is on clients that support lineage. If they aren’t, you don’t. Or you never rotate at all if you choose. This isn’t meant to be a universal switch. It’s a safer operational mode for the users and clients who opt in and it doesn’t break anything for anyone else. Is the critique about implementation speed or something about the model itself?

Exactly right. Spec first, adoption after.

Rotation doesn’t require abandoning an audience because it doesn’t change the identity people follow. The root npub remains the stable anchor and clients simply map that identity to an epoch key once they support lineage. A derived key is just an operational key under the same identity. Rotation only happens after the ecosystem you care about supports it, so existing followers aren’t affected. Adoption follows the same pattern as NIP-05, DMs, zap receipts, and badges. Features spread gradually, early adopters benefit first, and broader support comes as value is demonstrated. Most users can use their current nsec as the root. A root key doesn’t need to be pristine, it simply goes cold after the first epoch key is generated. PGP and minisign have relied on this exact model for years. Interoperability stays intact because rotation only occurs once the clients used by your audience implement lineage. Until then nothing changes. And if someone prefers not to rotate at all, the model stays entirely optional. The goal is to provide a backward compatible alternative to the hot key identity model without forcing anything on any user or client.

Cold Root Identity v0.1.0 Cold Root Identity is a simple model for survivable Nostr identities. No protocol changes, no new relay behavior, and no delegation logic. The idea is straightforward: - A root key stays offline as the authority - Epoch keys are derived deterministically for actual daily use - A signed lineage event proves each new epoch key is legitimate - Clients treat the newest valid epoch as the user’s active identity - Old posts stay under old keys; new posts use the fresh one This gives users safe key rotation without burning their entire account. A compromise only affects a single window instead of the whole identity. The Python reference implementation, test vectors, and spec are here: https://github.com/GHOST-UntraceableDigitalDissident/cold-root-identity If you’re a client dev, this is everything needed to implement rotation cleanly today.

Clients follow the current key for an identity, not the historical ones. A1 was Alice’s active key and followers followed A1. When a valid lineage event shows A -> A2, the client simply updates the active pubkey for “Alice” to A2 going forward. No different from how clients already update profile metadata, relays, mutes, pins, etc. Users are following the identity, so the client treats A2 as the live key and uses it for new posts, profile info, and interactions. A1 remains only as the signer of old events. That’s the entire model.

You can chain sign yearly keys, but it isn’t required. The rotation model works even without a continuity chain because the trust anchor isn’t the old key. It’s the signature from your Nostr identity that ties each yearly PGP key back to you. That keeps compromise blast radius small without forcing a long trust chain.

I didn't wake up until noon. For me that is Rip Van Winkle territory. It's signal that I am burning the candle at three ends.

Perfect. Optional password fits the model without altering the recovery guarantees.

I'm honestly curious how many people I am going to piss off with this piece https://untraceabledigitaldissident.com/pgp-nostr-digital-ownership-identity/

Give back to your community. Tell your local meth head how much copper is in a CCTV Camera.

The cat is not impressed

Fingerprint: 35F5 B91C 0185 C612 7043 B8E9 2C2F B9EE E285 B33B Expires: December 31, 2026 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Nostr npub: -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQ19bkcAYXGEnBDuOksL7nu4oWzOwUCaTPEKgAKCRAsL7nu4oWz OxZIAQCMR7OUttVGhlxrQpGtFC8PdTNzjt0yOALQ+kIWK4IrRgD/WcpHu9E2Vpsb hksEcdPnMq/ONrq5eYCtDPN9Vhozhg4= =BsBm -----END PGP SIGNATURE-----

Then how do you explain Elf on a Shelf 🤣

Tomorrow I’m starting the build guide for something I’m calling ZeroSentinel. What ZeroSentinel does: - Turns a $15 Raspberry Pi Zero into a fully autonomous privacy node - Builds a locked, authenticated WireGuard tunnel home from anywhere - Runs your DNS through your own Unbound resolver with DNSSEC enforcement - Blocks ISP meddling, hotel rewrites, captive portal tricks, and upstream manipulation - Monitors its own health every few minutes - Sends you an encrypted Nostr DM when anything breaks - Enforces no-fallback DNS and drops all traffic that isn’t in the tunnel - Works behind travel routers, double NAT, carrier-grade NAT, and hostile networks - Makes your phone’s “VPN” actually mean something Your own infrastructure. Quiet. Cheap. No subscriptions. No external services.

So the entire internet is just one AWS Server and Cloudflare. Checks out

I got banned from Redbook the Chinese social media app. 🙄 That didn’t take long

Where's my dodge check?

I am alone: there is no God where I am.