> 1. Yes, we should consider implementing what nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft suggests, but we should give clients time (90 days+) from merging the NIP to implement it before clients offer this tool to their users. (reviewers: nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn, nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z, nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s, nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc)
Requiring every single clients to support this NIP just for this function? Sounds like rewriting an standardized RFC to achieve what you exactly wanted.
Requiring them 90 days to implement this feature is BS. No. We do NOT need this NIP in every nostr client. Let the developer decide.
I even personally think this NIP is stupid. Just let the client tell to the follower that this user has been migrated to new pubkey by reusing the `kind 0`, By putting `moving` as the new pubkey.
So, our metadata should be:
```
{
"name": "Yonle",
"display_name": "Yonle",
"about": "Self taught programmer from Indonesia",
"website": "https://yonle.lecturify.net",
"nip05": "yonle@yonle.lecturify.net",
"lud16": "humidprocess01@walletofsatoshi.com",
"moving": "341xxxxxxxxxxxx" // <- New pubkey in hex
}
```
And remember this.
> This UX wouldn't be very different from the one we have today, in which an attacker can steal someone's key and start publishing notes every day saying: "this key is compromised, switch to my new account npub1..." -- pointing to an account controlled by the attacker.
https://github.com/nostr-protocol/nips/pull/829#issuecomment-1778055274
And that's why i am strongly disagree with this new NIP.
No, I disagree with nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 that the UX would not be much different.
With Pablo's proposal, once a user fires of the kind:1777 to initiate migration, if your client supports it, depending on how the client implements it, you would not be seeing the attackers notes, or they would have a red border and warning signs telling you that these notes were written after the valid kind:1777.
Today the client has no way to know. With kind:1777 your client can now warn you about the situation.
Of course it's not a mandatory feature. But it's very central and I think any client that relies on kind:3 or other lists will want to implement it.
The 90 days was an idea to prevent front-running by a few clients, as we have seen in the past, it's how long the fast implementers wait as a curtesey to the others, not a deadline.
Then if you lose your key the attacker can put his own key in the "moving" field and then all your followers go to him.
