Plain Text Nostr

<-- back to main feed

thread · root 8769fdef…159d · depth 7 · · selected 5c6833b2…da63

thread

root 8769fdef…159d · depth 7 · · selected 5c6833b2…da63

b90c3cb71d66 -- 199d [parent] 
|    right but nostr, unlike Farcaster, cannot swallow that. Farcaster your FID belongs to the chain and your main
|    key is control over it, so such a thing can work. Nostr the buck stops at your main key, which means you'd be
|    asking clients to do something that clients cannot physically do in terms of stitching old you and new you
|    together.
|    reply [1 reply]
vinney...axkl -- 199d
You're right that the tactics are quite different between the two systems, but you're wrong that the general
solution "impossible" on nostr. It just employs different tactics than Farcaster.
Feel free to prefer the blockchain solution if you like.
I prefer the tradeoffs on the WoT side.
reply [1 reply]
b90c3cb71d66 -- 199d [parent] 
     I mean it's close enough to impossible to do that you'll give up trying. Think through what clients would have
     to *actually do* in the case of someone having their nsec taken by an attacker and creating a new one that
     friends validate. It's like subkeys and Vitor's response here, sounds great in theory but when you think through
     what clients would have to *actually do* to reconcile the subkeys you realise it's a non starter. There's a
     different such list for this main key respawn scenario, but it's equally off-putting.
     
     https://image.nostr.build/b4c3a4342cc3433866c83717fd0023bfa4d8896805d74abe3cb0071db68f615b.png
     reply [1 reply]

Write a post

Sign in with a signing-capable method to publish.