👀

nostr:npub1gzuushllat7pet0ccv9yuhygvc8ldeyhrgxuwg744dn5khnpk3gs3ea5ds , any chance you know :)?

I did proposed something, prnip41 but got faded because "complexity" of key rotation 😅 I would love to revisit it tbh

# 👀🇧🇷

What is this? Thanks

Yes, from nostr:nprofile1qqs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75spz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0dv4ph5, but I don't remember the PR.

Yeah, sort of, I have not continued to work on it more though as it didn't seem like the right time yet and busy with other work in the meanwhile.

I'm now more of the opinion that changes needed can be done when "follows" are not all packed into one replaceable event, but are each an event and can be used to distribute copies with attestations of kind 0 metadata.

Those atteststions can then inform clients if there was a change to someone's pubkey. This can be useful to display a message such as "n number of people you follow used to follow x and now follow y, and x has been marked compromised/transferred/ended/sold/etc".

https://github.com/braydonf/nips/blob/key-migration-and-revocation/xx.md

I have an idea, but not working specifically on this part of it right now.

1: Derive contacts (npub/npriv) from seed (ready in Trezor)

2. Verify offline your trusted contacts (TBD)

3. Derive shamir that leads to the same result as initial seed (already working in Trezor)

4. Encrypt these shares with previously verified contacts

5. Store it securely - there are more options with various trade-offs- it could be shared directly with your verified contacts, it could be recorded on blockchain (that enables automated health-check, but you can’t remove the trusted contact later on), or you can store it on your(or trusted) node/server → that enables later changes and health check - server can’t misuse these data since they are encrypted.