SeekerErebus on Nostr: We've needed a master/slave system for npubs for a while now. This just further ...
We've needed a master/slave system for npubs for a while now. This just further reinforces it.
In case you don't know what I mean, you have your daily use npub(s) the nsec(s) of which will often be on hot devices, and then you have an npub the nsec of which is a cold key treated with the same security as cold storage. The hot keys post a metadata note that identifies the cold npub as a master. Then should the cold npub post a note that declares one of the hot npubs burned, the participating relays reject all notes from that npub. The relays/clients could also assist in redirecting follows to a replacement npub identified by a note from the master.
Such a system could drastically increase redundancy as well as allow hierarchical structures , but might have holes I haven't thought of.
In case you don't know what I mean, you have your daily use npub(s) the nsec(s) of which will often be on hot devices, and then you have an npub the nsec of which is a cold key treated with the same security as cold storage. The hot keys post a metadata note that identifies the cold npub as a master. Then should the cold npub post a note that declares one of the hot npubs burned, the participating relays reject all notes from that npub. The relays/clients could also assist in redirecting follows to a replacement npub identified by a note from the master.
Such a system could drastically increase redundancy as well as allow hierarchical structures , but might have holes I haven't thought of.