It occurred to me that the new key rotation thing makes it possible to implement a credible low friction "Sign up with email, then migrate a self custody nostr id later" sort of flow. So basically the way it would work is that the client allows the person to sign up with email, and you have a backend service that generates an nsec for them, and the backend signs stuff for them. Then if the user wants to move to self custody at any point, they go in their account settings and click like "Enable self custody" or something. This causes the client to generate a local nsec in the usual way, and the backend creates a key rotation event pointing at the self custodied nsec, and as soon as it's timestamped, immediately rotates to that new nsec. So far so good. However, there is still a problem -- there's no way for the backend to prove that it did not also publish an earlier timestamped rotation event with the new pubkey (which would allow the backend to rug the user in the future) But we can solve this by having the user rotate *again* (using their new nsec) to a second locally generated nsec. (which the backend service could not have known, and thus could not have created any prior key rotation events for) So bottom line is, yeah it involves two rotations (ie a 20 minute process on average given block time) but it massively reduces sign up friction while providing a way to migrate to self custody while keeping the social graph you may have accumulated prior to rotating into self custody. @hodlbod @Max