About initial setup/delegation, my thinking is: a protocol could allow you to delegate authority to do specific things (like sign) by a direct signature on your main key saying "this sub-key is authorised to sign these events" and then that subkey could be generated collaboratively in a normal way. Common way of using digital signatures (delegation to another key), but admittedly it can be a can of worms...
A bunch of proposals for variants of doing that stuff have been (and continnue to be) suggested. I don't know what is the best way (they all look flawed to me given that there is no single source of truth for what is the latest update on the subkeys of each person) -- but even with all that decided and solved I think it's a bad idea because it would add so much complexity to clients and/or relays that Nostr would essentially cease to work or instantly centralize around a single big entity that would become the central source of all truth and the almighty index of all events. That's why I'm considering these other ways.
Understood. I agree it's a can of worms to do it at scale. Maybe for some smaller scale projects it can be a valid choice.
Subkeys will be time boxed like X.509 certificates or GPG subkeys have done for centuries.
Nostr won't stop existing but if this upgrade flushes some of the nincompoop devs out of the community that can't handle something this simple then that's a win-win.
Oddbean new post about login | logout