Replies (101)
Well, that's exactly why we still having this issue over and over
Correct. That's how easy we have it today.
Here's the draft NIP that explains the reference implementation:
View article →Hard to get everyone to adopt key rotation yeah.. PGP is the only thing that sort-of has built-in rotation, but does it really? It's just a new key, and an expiry to force people to go find the new key.. Bitcoin doesn't have it at all.. Etc.
Cool that you tried tho, the complainers really have no grounds to stand on, other than "muh UX should be ez for muh normies like muh centralized platform" Even keybase.io, hardly got any traction. Showed how much people say they want something, and then they don't use it.
Not solved at all... But anyway, we can agree to disagree, no problem
I didn't say it was solved. It's just what people do and solve their rotation needs right now. You can't build anything that is harder than that for the user. Otherwise, they will just go back to that simple thing.
Yeah, I agree. That’s why my last attempt at key rotation wasn’t about key rotation at all, but about identity continuation. And I think not everyone, but some people might use it, specially entities or "high value" accounts. As I see it they would work more like a kind of change.org campaign. "Hey, this is my new key, there you have some proofs (wot voting, secret revelation, any other proof) that this is me and not an impersonator"
See below for something that works. 👇
If you want to take a look at some actual cold storage identities, just go to the Inkan website and click "Explore".
Yes, in the case they don't care, but if the case is complex like a valuable account, social engineering, impersonation etc users would go and collect proofs to make the transition more legit. Right now there is no way to make this more than outband communications
If I send a DM to the master key do all usable keys decrypt it?
I did this, but I also have an OTS proof on the note to include, for when this day comes.. Pre-dated, pre-generated set od vanity keys, to any future compromise. That way I don't need a 3rd party. Thought it was a cool way to do it. Ofc, if those keys also got compromised I'm shit outta luck 🍀
Make the transition more legit can also be used by attackers to make their attack more legit. That's where all crypto-first ideas die.
I think it will always be out of band communications. At least I have not seen a single idea that doesn't require active web of trust verifying things around it... Which is the same as the kind 1 post.
going that route its more straightforward to have a private relay accept employee submissions that are then resigned and published by the ''main'' keypair (which is done by another employee that has a bunker link to do this). Where the "main" key is controlled by a FROST setup among a group which constitute the owners of the organization.
See how all these things can just be stacked in order to fit the usecase and level of delegation/trust?
My proposal also uses OTS. Proofs are complementary, is just an standardization of the checkpoint event, basically the event that say I'm in possession of this key at this point, linage and proofs semantics. All is in the nip draft
that's why my proposal baked the attestation into events:
- embedded attestation signature validates? use attesting id instead of pubkey
- ask for revocation events
- if you get one, lazy mark events with that attestation as deleted
That's why my proposal is not crypto-first, wot social proofs, ots, and so on. Not a single way an attacker can impersonate you by "knowing your password". And from my pov is not the same as a kind 1 post, kind 1s are already overloaded
"... this impossible requirement ..."
You can literally go ahead and use it today. It's not even especially difficult.
For example, here is a cold storage identity if you'd like to see one in action:
The privkey for that one has never come close to a networked device.
Why would you revoke if you can just delete the event?
Its just formalizing the wot verification that already happens on a single kind 1.
I don't disagree with you that it works in the same way, but you have to see that it is way more complicated to implement for the exact same result.
OTS alone is not even coded by 99% of nostr apps.
So how can the organization use this right now without having to create all that software themselves?
Because revokation is a signal. It completes a chain. If information exists or are found, they can simply be marked as revoked without losing their information. Yes previously valid, but revoked information can still be useful.
My proposal has a flaw that prevents this from working completely, but the ability for clients to maintain continuity after revocation allows identities to continue transparently.
I haven't implemented DMs but actually started thinking about this recently. You'll want to treat delegatee keys like different phone numbers that belong to the master key and which the master key advertises as capable of receiving DMs. The caller decides to which delegatee they want to deliver the DM, and Inkan permits them to verify the association of the delegatee with the master.
One interesting use of Inkan is to associate delegatee keys with specific devices that belong to the master identity. I think you may be able to use this for a double ratchet for Nostr. 👇
But then it is the same issue that Marmot has. If a user has 5 clients, why is the sender choosing which app the receiver has to reply on? Marmot solves it by creating a group chat of all sender and all receiver devices. Every new device needs to be added to all other device conversations. It is a lot of work.
Unless clients don't implement revocations... then nothing works. They don't even implement deletions right now. That's my point. The system breaks because it requires clients to implement it. It's optional. And identify management shouldnt be optional. It either exists and is implemented by literally every one, every little nostr app, or it doesn't exist (which is what we have today).
that's silly. i can want people to know that random app nsec is me without caring whether they do consistently, across clients. it's strictly better than what we have now, which is nsec pasting and "trust me this is my new identity"
Then implement a solution and let's see how far it gets without getting called "it doesn't work" because Primal still displays the old account I rotated of that Amethyst users were automatically migrated to a new account because the attacker got my nsec but I don't even use key rotation apps.
Well, I guess for my double ratchet I was simply envisioning that the receiver just advertises their device-bound delegatee keys like they would advertise their personal and work cell phone numbers. I guess they'd have to answer on the device on which they get the call. That doesn't seem like too much of an imposition for my taste, but opinions may differ on this.
Apart from DMs, notice that Inkan allows you to post under keys that are kept in permanent cold storage. For example, here is the profile page of a key that has never signed a single Nostr event:
You can't make the client chicken-egg problem. Jumble is still one of the most popular clients I see in my referrer logs and it implements deletions.
Everything on Nostr is the client chicken and egg problem. It's quite literally where most of my time as a dev goes. Trying to make shit work with other clients.
no, i'm not going to boil the ocean to prove it's a good idea. that goodwill is spent
You now understand why Nostr will never have key rotation.
Yeah this almost makes more sense to have something like a chatroom or forum that is "followed" rather than an npub. So that posts to the forum can be done based on an authorized and revokable scope...
I just don't know if it's worth breaking the basic "signed json" simplicity of Kind 1 just for some business use case.
i already did: the people stewarding clients don't care about it
you basically said "it's not going to work because not everybody will implement it at the same time". but that's how every feature was built on nostr.
Your acquaintance may want to take a look at Inkan. It allows the organization to hold a master key and distribute delegatee keys to its employees. The employees can then use the delegatee keys to post on behalf of the organization until the organization decides to revoke that authority.👇
It's not just that. It's a model for identity continuation. Using Kind 1s for this is the wrong approach by far. They are overloaded and can easily get lost in the feed. A specific kind for identity checkpoints would have cleaner semantics and could be rendered in a feed. There's also no hard requirement for OTS, and if it is used, clients can always rely on a client that renders it with a rich UI/UX, like NIP-89 does. In any case, I'm not here to convince anyone. I've never liked politics.
👇
This is different. All apps have the same profile picture. We can't have some apps with some profiles and other apps with other ones. You fuck with identity, you destroy the only thing that works all the time on Nostr.
If people start questioning if the npub I am talking to is still the same npub I was talking to yesterday, we will have major problems.
Nostr somewhat works because the identity is immutable. Once that mutates, a whole slew of issues arise. And we don't have the consensus layer to follow just one path, together.
If identity breaks like DMs are broken, nostr dies.
People are using all kinds for this, not just kind one. It's not about kind 1 at all. They use whatever kind is available in the app they use.
It's about ease of use and integrity of identity across all apps and all relays.
You can just start using it. Just go to the Inkan website and click on "Explore" to see some cold storage identities. 👇
Which is a massive interoperability failure. That's why I was proposing that
I don't think it's that different. also there are many different ways to design this, not all suffer from the same issues that you've described. you seem to have given up on this. that's ok but I hope others didn't.
Inkan displays exactly the same profile picture for my signer key as all other Nostr apps do. Here it is:
At the same time, the posts I am making are also getting attributed to my master identity, which you can see here:
There is nothing nefarious or destructive about it. You can literally delegate down from a master key to your regular Nostr key and keep using your regular Nostr key as usual across the Nostr ecosystem. That's what I'm doing right now.
You'll just have gained the benefit of a master identity which can, in case your current Nostr key gets compromised, revoke it and replace it with a new one.
an embedded, revokable attestation *is* immutable. it can be disavowed, but that's not mutation
I read about 15 or so proposals on this. All of them suffer from the same issues. So, it's not that I have given up. We just run out of ideas.
Even the ideas that delegate identity to a separate protocol fail to address the same issues.
That's why I am investing so much in WoT. I don't think identity can be solved by anything else at this point.
How do you place said attestation in replaceable events that are mutable by design? Do we now have to deal with revocation of revocations through replaceable events by attackers?
same way as nip-09
your expectation is maybe incompatible with the solution that people want
It's actually functional without having been implemented across the network, and it doesn't break anything in the rest of the protocol.
You can create a delegation from a master key to a signer key now, and then simply use the signer as a regular Nostr key across current Nostr clients. It works exactly like any other normal key with any of the familiar apps.
Now if other people actually want to see or interact with the *master identity* itself and not just the signer, they will need to visit a delegation-enabled client. For example, you can view or interact with my identity here:
In the meantime, the signer is perfectly servicable as a regular Nostr key. And if other delegation-enabled clients come online in the future, there will be other places where people can view and interact with the master identities.
I have never seen anyone asking for less than what I expect here. On the contrary, users want much more from an identity solution. They want magic. We are not even reaching the most basic layer, the feasible part, in my mind.
they are better off building it themself and actually use it, and keep it alive and then other organizations can start using it as well etc.
Otherwise some dev makes this stuff, and its all nice and fancy, but nobody gives a shit and it goes straight into the dust bin, and then 5 minutes later some organization will complain the software is not there, eventhough we have an entire graveyard full of stuff they could be using.
For the record my proposal would be completely backward compatible with the current impl of nostr. Clients would simply choose to honor and build trust trees if they chose. Otherwise keys present as individuals as they always did. The published delegation events produce the trust tree. Follow them, get the trust.
yes, most want the impossible. that doesn't mean you ignore the possible
I am not ignoring it... Just nobody has suggested anything that works in my mind. And even fewer implemented their own ideas to prove to us that their designs actually work.
It should be a paid service.
"They want magic."
I've been using this system every single day for months now. It's functional and non-magical. And it doesn't disrupt the regular Nostr protocol. The post I am making right now is fully compatible with both regular Nostr clients and with Inkan.
Inkan uses exactly the same kind-0 profile for the pubkey that signed this post as all other Nostr clients do.
Inkan merely recognizes that the signing key is making the post on behalf of a master identity, and attributes the post to that master identity.
If I follow this key and you rotate it on your side, will I see your new posts on Amethyst?
FROST bunkers are the only solution. They are a thousand times better than any solution implemented by any of Nostr's competitors, in any aspect. They fix everything and anything while also being compatible with all the other solutions and ways of signing. They are implemented and functional as of today.
View article →
If you follow my current signer key A and I replace with a different signer key B, you will need to separately start following my signer key B to see its posts on Amethyst in your following timeline.
But if you follow my delegator key X which delegated to signer A and later replaced it with signer key B, then the *Inkan* client will show you all of X's events, both those signed by A and those signed by B, under X's profile.
In the meantime, nothing in the regular Nostr protocol gets broken. From the regular protocol's point of view, A and B are just completely normal Nostr keys. And X is also a normal Nostr key, which will show up in Amethyst as having no events whatsoever. Inkan does not displace or interfere with the current protocol.
To see some key rotations, you can look at the profile of this pubkey:
You can for example pick events from each of May 22, May 28 and June 20. If you click on "View raw event" for each of these, you'll see the different delegatee pubkeys that signed these.
So, you need to add something to the about of your child keys to tell users to follow the master key, not the child key. But tell them to DM only the children keys since the master key is not replying to DMs, or is it?
You're right - I should include a link to my master profile in my signer profile. Actually,
@meta has done precisely that. You can click on the link in their signer profile to go to the master profile.
And you're also right about DMs. The master key is buried in my basement and doesn't sign or decrypt anything. So DMs need to be directed to the phone number keys that the master has declared (of course a delegatee can make these declarations on behalf of the master). And the master can, for example, declare different phone number keys for different devices if it wants to. And more importantly, anyone who wants to call these numbers can always check, right before making the call, that the master key has not *revoked* the number.
Frostr does the trick, but the UX could use some polish.
thats not how that works.
First you need an organization to build this stuff themselves;
Then you need other organizations that start using that stuff because it is good enough;
Then at some point you get to an amount of organizations that someone figures it starts to make sense to offer things as a service which amps up the quality and allows for a large number of organization to start adopting things.
You can't just go:
Someone go build stuff and offer it as a service, and then suffer crickets for eternity
It's not rocket science. And it's already an established business model. See Buffer etc.
you know what definitely is pointless? Being concerned with the woes of low agency people in relation to a new open protocol that is rebuilding the entire web from the ground up.
Ad hominems also don't solve anything. And we all have limited time.
If you're not interested in people using Nostr for the social media use case, then why did you reply in the first place.
What ad hominem? Low agency?
I am afraid you misunderstand.
You said ''some who's merely looking for a simple solution to posting content'', people who ''merely'' are looking do anything with Nostr are here too early...there is no ''merely''; for now, there is only put in a bunch of effort, time, trial, error and AI tokens or whatever and be content with a minimal viable result.
Not sure if you even understood anything i said, because the ''merely'' only comes after other did all the work for them before hand, including bootstrapping a potential market in the first place.
No, definitely not that. I just linked above.
Here again:
Why not have this instead of a key rotation:
Have 2 keys in a service: Master and Slave
Service listens for slave's events. Deletes them, and signs the same event with the Master key.
If the delegated key is compromised, simply swap it with a new one in the service.
There was Keycast that was made for this specific use case, but you had to run it on a web-accessible server. Is that asking too much? I think it was repurposed now into a custodial key service for Divine users (because no one was interested in the original product).
But if you want to delegate simply running `nak bunker` should work, no?
If you don't want to run it yourself but also don't want to handle your key to a third party then the best solution is a FROST bunker. We have that infrastructure running and you can plug your own parts of the stack or reuse the public services as you wish (would be nice to get more public operators though). The only limitation is that profiles are tied to Google accounts for now, but that can change if there is demand, as I just wrote somewhere else.
I care. I will work on a simple demo for your NIP
In the realm of possibiliies, no.
MONEY WAS FLOWING AND LEAKING FROM GRANTS OFC WE DID NOT CARE
Here is a decentralized PKI for Nostr:
I've never understood key rotation. What's the threat model and how can a protocol even address it?
I just want to point out again that we have a fully functioning key revocation and replacement system in Nostr. I've been using it every day for months now.
You can literally just head over to
and create an identity that can delegate signing authority to delegatee keys and revoke it when these keys are compromised.
This enables cold storage identities for Nostr. If you want to see one of these identities in action, here is an example:
And here is the draft NIP that goes along with the reference implementation:
View article →The "shooting down" of proposals on key rotation is just a cultural issue with Nostr. It's not a technical limitation.
This thread is an example of this. Lots of comments about how key rotation is impossible. And when I post links to a website where a functioning key rotation has actually been implemented and is in use, it's mostly just ignored. And then there are more comments on how nobody has figured our how to do key rotation. There's a lot of cognitive dissonance here.
I guess I'll just keep posting links. Here is a functioning key revocation and replacement system for Nostr, which you can start using today. 👇
I tried to look at it but get
"Site not available - Site was paused as it reached its usage limits."
Any other place I can read about this?
Right, so your solution requires OTS and ethereum? The latter is the issue there. Most of us are never going to touch eth, let alone pay gas fees.
LFG! I think I'll also get a little demo client I did at that time up to speed and release it, so we can have 2 apps implementing it.
GitHub
GitHub - gzuuus/oc
Contribute to gzuuus/oc development by creating an account on GitHub.
Yes, it requires OTS and ethereum.
OTS is free. Gas fees for delegations and revocations are tiny. A recent series of transactions creating a 3-key delegation chain came to about 518k gas. I think at current prices that may be less than $0.15. On-chain transactions are required only at the time of identity creation and key replacement, which is very rare.
For people who don't hold ETH or don't know what it is, they can ask a sponsor to pay on their behalf. If you'd like to try it out, I'm happy to cover the tiny amount of ETH. You can go to
and click "Get a toy identity" to get a throwaway trial identity. On the last screen of the wizard, there's a link through which you can ask me to sponsor the transaction.
For general concerns about using Ethereum, my initial response would be this👇
You can read about it on the README of that repository.
and
are other instances of that website, but there is nothing there to read.
I also love frost
Thanks, I think I may have found the pomegranate repo here:
gitworkshop - Decentralized Git
Decentralized GitHub alternative over Nostr for browsing repositories, managing issues, and collaborating on pull requests.
I'm trying to understand the security posture.
It seems that the user, for each generation of key shards G that they produce, sets a threshold number T(G) such that anyone who at any time holds at least T(G) distinct shards from generation G will be able to reconstruct the user's privkey.
If that's correct, it seems that
1. Google itself can get your privkey at any time if they decide to fake OAuth;
2. anyone who has your Google login credentials will be able to get your privkey;
3. if at least T(G) operators holding shards of generation G collude, they will be able to get your privkey;
4. if anyone is able to steal at least T(G) shards of generation G from operators, they will be able to get your privkey;
5. any combination of dishonest operators and thieves that together at any future time come to hold at least T(G) shards of generation G will be able to get your privkey.
Does that seem right?
what's the rotation mechanism? regenerate new shares when one of them is leaked?
what's the rotation rules? you lose a share and regenerate the 2 of 3?
It would be similar to one of this remote signers that the signer itself grants other keys signing rights. They keys are then just random instead inside Frost's polynomial
it requires a second signer like a bunker though to make sense amirite
It can be anything, the client decides the threshold at the time it is generating the key. To rotate for now for you have to go there on the admin and reset it manually.
At some point I'll finish the DKG implementation so not even the first client the person uses has to see any keys.
That would also be good in case someone wants to do something like an X bridge with a key that the rightful owner can later claim, for example (as long as the operators involved in creating the key attest that the key was generated fairly), but this is a different topic.
What do you mean "you may have found"? I had linked to this same repository in my note earlier in this thread.
Yes, it is correct that your keys can be stolen by compromised operators. This is all written in the README.
I could try vibecoding a Nostr client with key rotation. Do you have a specification for this? Or should I let the AI do its thing? Kimi K3 is pretty good.
If NIP-06 wouldn't have been unrecommended...
I had trouble opening the 30617 event that you had quoted. On imwald, I saw this, but clicking on that link just sent me to a broken page:
I was trying to understand what your frost scheme means in practice.
So the first observation was that, in your particular setup, your privkey is only as secure as your Google credentials, and Google needs to be trusted.
Otherwise, this scheme seems like an enhancement to NIP-46 if I'm understanding it correctly. If you yourself run one operator and require all shards for signing, it seems like it would be at least as good as current NIP-46. The operator you are running would be analogous to your NIP-46 signer app in that you have direct control over these, so that would presumably never be worse than current NIP-46 even if all the other operators are compromised.
If that's correct, your scheme composes with a key delegation system in the same way as NIP-46 does.
is this using ethereum like yakihonne?
Frost is old hat.
It's using ethereum for recording delegation and revocation declarations, and Bitcoin for OTS-timestamping Nostr events.
Absolutely, for recording key delegation, revocation and invalidation declarations.
I wasn't able to figure out an easy way to record these declarations on Bitcoin, but admittedly I didn't try all that hard.
The Nostr events themselves are timestamped with OTS on Bitcoin.
why can't these declarations just be Nostr events?
These declarations need to be discoverable with 100% certainty.
For example, the client needs to be absolutely sure that it has not overlooked a revocation declaration.
Use it then if irs better
