Tony D’Addeo pfp
Tony D’Addeo
@deodad
rundown of the different Ethereum accounts that are part of your Farcaster experience note that most of this isn't directly applicable to end users (just like an end user doesn't think about OAuth credentials) why so many? in short, they serve different functions and have different permissions. combined they yield a self custodial, user friendly account that is safely portable across clients and captures your full onchain public persona - custody address: holds your FID, root key for your FC account - recovery address: can recovery your FID if you loose access to the custody account, by default a Farcaster (the app) controlled wallet so we can do social recoveries for users - auth address(es): additional address that can sign in as you, used so you can sign in multiple clients w/o needing to import your custody address, your Farcaster Wallet is automatically added as an Auth Address and used to do SIWF on web
3 replies
4 recasts
20 reactions
Tony D’Addeo pfp
Tony D’Addeo
@deodad
- verified address(es) - addresses you've publicly associated with your FID, they don't have any permissions related to your Farcaster account, especially useful in a world of embedded wallets where the # of wallets users have is high, your Farcaster Wallet is automatically verified for you (you can revoke if you don't want this) - primary address: the verified address you've publicly marked as primary to indicate people should send you assets there, your Farcaster Wallet is automatically designated as your primary if you haven't designated one already, easy to change - connected address: when you're using a Farcaster Client and go to do an transaction this is the account that does the tx, for most of your this is your Farcaster Wallet but we support Coinbase Wallet and Rainbow as well, this wallet is not necessarily related to your Farcaster account, for instance you might be connected to a burner wallet
2 replies
0 recast
5 reactions
will pfp
will
@w
re primary address default, it's probably too late to do this but people who using ENSes should've had their primary resolutions respected, I think (unforunate, imo, that a user with an ENS handle can have a different ENS resolution than fc primary, tho i get *why* it's possible/happens)
1 reply
0 recast
1 reaction
Tony D’Addeo pfp
Tony D’Addeo
@deodad
that would be nice, would be a fair amount of complexity though right now snapchain has the primary designation in memory, it's a simple flag on a verified address, and can trivially return it when requested, to do this snapchain would need to see the username is ens, ignore the primary designation boolean, and make a network call to get it snapchain also emits change events so that farcaster clients can index this data, so would also need to listen for changes and propagate those through, since this is a boolean on verified addresses it reuses the same event type, but in the ens model you're primary might not be a verified so you'd need a new event type for the case it's a non-verified primary address change farcaster clients would need to hande as well, rather than a list of verified addresses with a button to set primary, it'd need to communicate you have an ENS name so this overrides any primary designation set on your verified addresses and you need to go update there
1 reply
0 recast
1 reaction
will pfp
will
@w
the horrors of shipping real shit
1 reply
0 recast
1 reaction
will pfp
will
@w
(and wonders, too, tbf)
1 reply
0 recast
1 reaction
Tony D’Addeo pfp
Tony D’Addeo
@deodad
a nice alternative would be to have your farcaster set username resolve via ENS to your primary I think we have a prototype of this working but not sure where it's at
1 reply
0 recast
1 reaction