Ya I mean basically, you need a way to ditch a nip05 provider if you were using some crap one or lost control of the domain etc..

Reply to this note

Please Login to reply.

Discussion

But assume that in that case, you still got your npubs. So having multiple nip05s, you could have them time expire because you wouldn't post to them and they'd expire.

yeah, so it should also be signed by an authority key

the current primary key should become an authority key and only get used to sign metadata and things like nip-05 messages and kind 0 user metadata - and that itself is another example of a place that could have multiple subkeys specified

also, they could maintain actual HD path coordinates in them as well so you only need the primary key and the world also has the necessary pubkeys that derive out of them

You could also smol brain it.. each npub has its own time expiry, the 'hot keys' are short, then the ones you want to cold store, don't even touch the internet till they're up for bat, with like a year expiry or something.. and when those go hot, you add a few more cold ones.

But if any of the keys fails to make it's scheduled check in, that nip -05 is burned

that's hard with weak consistency, where are you looking for the events?

The events are in the nostr.json, you sign em and stick em in there. Along with setting the next checkin.

They're not really events perse.. they're not on the relays only in the nip -05 nostr json

how do you handle that server going dark or being DoSed?

That's why you need multiple, so you can rollover to the next

oof, need to go more smol i think

Heheh, ya maybe.. maybe not? A ddos would be a problem for relays too..

But also your idea with the key derivation, maybe that's something .. I just don't understand what you were saying about an authority key, would this key be able to be offline, and then you don't need the time expiry?

yes, the authority key probably should be kept offline, i can see hardware signers being quite valuable for this, they would want to have a key rollover protocol built into them that spits out keys from requested HD coordinates

and yes, maybe have two key paths, the authority and the identity key paths, then you can roll the authority key over as needed as well

This sounds a lot better than my idea 😂

You can't add cold ones. How are they authenticated? Will a new cold key be signed by a previous older one? If the previous older one expires so do all the keys signed by it, transitively.