Nostr Web Client

to do key rotation (and for that matter, name resolution services) on nostr, you need a consensus protocol. the actual consensus would be an independent server that does the chatter sharing the relays trust attestations (this is a non-token based distributed system architecture), they store and broadcast their events to be stored on relays and they use relays to rendezvous with peers instead of dealing with the network ingress difficulty caused by NAT routers.

this is the proposal that i've drafted for this, it uses a web of trust based design for relays to decide whether they will accept a registration or transfer of a name title to a new npub:

Free Internet Name Daemon (FIND): https://github.com/mleku/next.orly.dev/blob/main/docs/names.md

ManiMe 1mo ago 💬 1

nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku is a smart cookie, and has a nice proposal. But (like Rustr’s proposal also) this problem is not going to be solved by only ONE technique for key management / rotation / expiration / ect … there will be many. There MUST be many.

Nostr’s existential challenge is NOT to find consensus around single NIP for any one problem … but to allow for dynamism (having a variety of techniques in use simultaneously) WITHOUT overly burdening users or developers in the process.

This is where WoT comes in. Most solutions (for any problem) will lean on WoT (in some manner) as a proxy for truth. Without assuming any one WoT technique will be “the WoT NIP”, ANY WoT should be able to “truthfully” demonstrate that “this is indeed Alice’s new npub”.

nostr:nevent1qqsfyceek4pmjxz5au35534af43rl8z8at5l8qt0h9n8ktjq4sda6aqzyr0k07d8usgj2azuheavl0wdqd530qxxg00hhtts7hfppredflpqqqcyqqqqqqgpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgqg5waehxw309aex2mrp0yhxgctdw4eju6t0ahhkqf

Reply to this note

Please Login to reply.

Discussion

david 1mo ago 💬 2

🎯

We need to follow Einstein’s Dictum: we should purse the simplest solution to the problem, nothing simpler.

I think Decentralized Lists offers a method to start out with the simplest workable solution, but then to layer complexity on top of it. The idea is that we achieve consensus one tiny bite at a time, building up gradually to a sophisticated solution, rather than try to generate consensus over a cathedral all at once. When a proposed solution tries to do too much all at once, it’s the complexity that prevents consensus from being achieved, the result being that nothing happens.

david 1mo ago 💬 1

Here’s my write-up of what I was just talking about:

nostr:naddr1qpfxkete94ex7arpw35k7m3dv9hxgtthv43z6mmx9468yatnwskhg6r994ekjmtsd3jhxapdwphhxumfvfkx2ttndak82arfdahz6ar094sj6urjv4ehx6twvukhqun0vfkx2mgzyrjjwt0fzj7nq964csum3rnftxjre8fxvjp37zfu285u0xdpdggz7qcyqqq823cq3xcp0

Hope 1mo ago

Just peeped your write-up, and I’m totally vibin’ with it! 🔥 You nailed it! Keep spittin’ that knowledge! 💯 #Nostr #StayLit

Rustr Intern 1mo ago

Agreed. Thanks for your input on this. Simple is good.

For DIDs I was actually thinking Ion, not a native Nostr DID. Its simple in the sense that keys and WoT are Nostr related but it gets complicated because Ion requires their own keys. I'd have think more about the decentralized lists and key rotation.

In my mind, having Ion DIDs allows a user to rotate keys easier than a Nostr native solution. I'm not sure how a Nostr native solution could work if the primary key pair is compromised. Frostr could possibly come into play. Having a 2/2 or 2/3 multisigs on a decentralized list could be one way to do this.