Account linking might be a prerequisite to unlocking social apps on Ethereum. 

We've started implementing some version of this in the FC contracts but maybe it should be a standard.

https://hackmd.io/@farcasterxyz/Bk4g8tHX3 https://i.imgur.com/9YzQ0d8.png

Lead developer of ENS & Ethereum Foundation alum. Certified rat tickler. he/him.

I'm on Mastodon: https://cryptodon.lol/@weka

I'm on bluesky: nick.eth.limo

Technowatermelon. Elder Millenial. Building Farcaster. 

nf.td/varun

@nick.eth ran into this while onboarding today, and its happened dozens of times getting people to sign up on mobile

Software Engineer at C̶o̶i̶n̶b̶a̶s̶e̶ Yahoo. Yes. Building Design Systems and frontend tools at your favorite internet company like it’s 1999. 

its a similar problem space but solves a slightly different problem. 

delegate.cash requires you to configure the delegation with your primary wallet or it doesn't work. this would let you link retroactively. 

its also much more open ended and allows for more composable recovery systems.

Would something like delegate.cash help solve this problem?

@base contributor #001; onchain cities w/ OAK & city3

How would this live in ENS? 

The logic to actually recover assets needs to be in the contract issuing them or the wallet holding them I think.

1000% percent - imo this should live in ENS cc @nick.eth

I may or may not be an AI. Half of what I say is BS, your job is to figure out which half.

Building https://3num.co

yes ive always said its super easy to wrap a DID around the fid and use it everywhere!

One thing that is super interesting about the Farcaster ID (FID) is that it makes for a terrific public decentralized identifier (DID) in the W3C sense of the word. Moderately cheap to register and could be used by many different decentralized apps/protocols.

i enjoyed this video, reminded me of the transfer request + waiting period for domains

https://www.youtube.com/watch?v=DnAG4mXlOFI

co founder of @metamask . Making computers behave for us.

pinging @danfinlay and https://mirror.xyz/0x55e2780588aa5000F464f700D2676fD0a22Ee160/pTIrlopsSUvWAbnq1qJDNKU1pGNLP8VEn1H8DSVcvXM

One related issue I've been thinking of: Having a "lighter weight" version of isValidSignature on multisigs where having just 1 of the NofM parties' signatures is sufficient (in cases where full security isn't necessary, or incremental security is possible).