This is exactly how we all started.

It’s past time for cold root identity

GitHub

GitHub - GHOST-UntraceableDigitalDissident/cold-root-identity: Reference implementation of cold root keys, deterministic epoch keys, and lineage proofs for Nostr.

Reference implementation of cold root keys, deterministic epoch keys, and lineage proofs for Nostr. - GHOST-UntraceableDigitalDissident/cold-root-i...

No, thanks. I remember Anigma

all my homies are nsexuals

If I don't understand what the interface is doing, and that's most of the time, then I'd rather not lol

where is nip-49? 🤔

🤣🤣🤣🤙

be careful with your nsec. it is your sovereignty on #nostr 💜 🗡️ View quoted note →

This is a bad meme. It's like saying using one password for all apps is wise.

you are not practicing safe nsecs! :) if nostr is going to become eventually 'No Other Social Trust Required' we have to be mindful of where we paste it because WoT algos may depend on us.

Accurate.

Except the app tends to never be random.

Interesting, but why deterministic epoch labels instead of time beacons? Seems like a foot gun in which one could store future keys in an app (maybe a greedy app) and get those stolen, or if an attacker gets ahold of your HSM as oracle they could pre-gen your future identities. And since the protocol always accepts the latest created_at identity, a far future one would also always override the current one. I understand there are tradeoffs, and I am not sure if liveness was a design goal, but seems to me a non-deterministic time beacon could offer benefits here, plus a clear time boundary rule too. Otherwise, I would suggest including these guardrails: 1) Explicitly recommend apps/users never pre-generate/store future epoch private keys; derive only the current epoch on the hot device; keep root strictly offline. 2) Add client-side created_at sanity checks.

Except the nsec has to be the same by design. A password of a different app is not related.

😆😆😆 The best part of this meme is that I never know if I'm on left side or right View quoted note →

At this point I'm afraid to paste it into my own app that I'm making TBH. Seen the follow lists get nuked way too many times lol

Ha ha 😝 I wrote my own bunker and still do this half the time

Great, don’t do it.

could anyone kindly show me the recovery path if a nsec is compromised?

generate new nsec

that doesn't seem good enough for a business that loses it's livelihood. Maybe there should be a NIP where someone can say "this pubkey was mine until X date"?

I think “frostr” is the solution for businesses

Well not really, because that just divides an nsec into multiple secret shares. They still add up to that nsec, so if that nsec were compromised, then it is compromised. Related, I wrote a sketch of a NIP proposal that offers a solution using FROST, but it isn't sufficient without what I named "Chain of Governance"

GitHub

NIP-XX: Quorum for centralizing decentralized organizations by taylorphillips · Pull Request #2179 · nostr-protocol/nips

This NIP proposal sketches out the concept of a quorum for centralizing decentralized organizations in a framework that is maximally flexible &...

I’ve got one for you to try View quoted note →