Simpler key migration

[vitorpamplona]

I don't believe in cryptographic securities for key migration: they are not only way too complicated to be coded correctly by every small client out there, but require a global state which we don't have.

So, here's a straightforward scheme that simply gets the migration debate going for each key.

[staab]

I think this is fine, although somewhat at odds with the idea that keys are a user's root identity (which is philosophically debatable). Distinct from but complementary to #2137. It might even make sense to let anybody publish one of these for any key, which would handle the case where the key has been lost, but that would introduce further risk.

[vitorpamplona]

I thought about doing a pure only-other-people-can-migrate-your-key scheme, but then when people fight online they can just start key migrations to the person they hate. This can be used and become very annoying even if we filter by WoT

[pablof7z]

I thought about doing a pure only-other-people-can-migrate-your-key scheme, but then when people fight online they can just start key migrations to the person they hate. This can be used and become very annoying even if we filter by WoT

This is a show-stopper imo; allowing any key to claim ownership over another key would be incredibly harmful and would introduce the need to have watchtowers or something like it.

[vitorpamplona]

Agree, there is a way to do it by starting with the user allowing their friends to force migrate everyone. But that leads to another several-crypto-things-to-check scheme by clients. Nobody has the time and attention to do that correctly.

[fiatjaf]

Maybe we define a key migration event that can only be created by the key itself.

Then we define a bunch of optional "attestations" or "counter-attestation" that can be attached to these key migration events, none of which is a definitive proof of the validity of the migration, but as evidences mount users can be more and more sure or vice-versa.

1. a presigned, OTS-timestamped key signaling event (older means more reliable)
2. a presigned, OTS-timestamped key signaling event that points to a different key
3. a presigned, OTS-timestamped "opt-out" event that disallows the migration
4. attestations by other people (should be filtered by the follow lists of the reader, but could also be filtered by an OTS-timestamped follow list of the key that is migrating)
5. etc

At the same time there can be discussion around the key migration in the form of comments. A complete client would display both the attestations and the comments.

---

The existence of this key migration event calls for the attention of users who follow that key, they go there and check the discussion and attestations and make a decision -- or postpone the decision to later.

[staab]

@fiatjaf's suggestion pushes this back towards #2137, with the addition of kind 1111 comments (which can be done anyway they're just not in the proposal).

[vitorpamplona]

Yeah, @fiatjaf's proposal can be a different PR. This one shouldn't have any cryptographic securities.

[vitorpamplona]

Also, I am considering even removing NIP-56 reports from it. It's already too complex.

[fiatjaf]

@fiatjaf's suggestion pushes this back towards #2137, with the addition of kind 1111 comments (which can be done anyway they're just not in the proposal).

I'm combining both. It's just easier to have the discussions happen in the same place. If you don't like cryptography you can do it with just social engineering, but no one can prevent people from providing cryptographic proofs. By standardizing them and putting them all together we get the best of all worlds and simplicity.