tate on Farcaster

Content pfp

0 reply

0 recast

0 reaction

welter pfp

hmm... there should be a Farcaster social field option, don't you agree?

3 replies

0 recast

9 reactions

Greg pfp

will be added soon. we keep going back and forth on which key to use (text records are key/value pair) eg twitter uses the key `com.twitter`, but it feels weird for a protocol to use `xyz.farcaster` so either `eth.farcaster` (easiest) or somebody has to make the argument for `farcaster` which we don't typically do

2 replies

0 recast

5 reactions

welter pfp

would the user put in their fid or fname? or use the eth address to find all farcaster user with said connected address?

1 reply

0 recast

0 reaction

Greg pfp

for the sake of simplicity, probably just username (fname or ens) same as twitter which could technically also use an id

1 reply

0 recast

0 reaction

boscolo.eth pfp

The ENS record should point at the FID, not fname/ENS. This way users can update their fname and the ENS record will continue to function. Otherwise any time a user changes fname in Farcaster they will also need to update their ENS profile.

2 replies

0 recast

0 reaction

Greg pfp

Same can be said about Twitter, no? I agree with the premise but comes with tradeoffs: - People don't change usernames often - Most users don't know their FID or where to find it - Devs would have to do extra work just to show basic profile info

1 reply

0 recast

0 reaction

boscolo.eth pfp

Not sure if my next statement is still true, but last I checked, Farcaster users don't own or control their fname with their own keys, seems odd to have ENS point at it. IMO, the UX for setting this should hide the details of the FID. Twitter is not composable like web3, not sure it's a good proxy for what we should do

1 reply

0 recast

0 reaction

Greg pfp

you're right regarding fnames - I see both sides tbh @taytems.eth also had thoughts on this I think

1 reply

0 recast

0 reaction

tate pfp

i dont think using fids in the profile makes sense for now for the same reasons as greg. the fact that users don't control their fnames with keys doesn't justify the amount of effort required to make fid => fname resolution supported across the board imo

1 reply

0 recast

0 reaction

boscolo.eth pfp

If by profile you mean the UX people see when they visit app.end.domains, then I agree. But for apps that query ENS via APIs like ether.js, it will be much more useful to have the FID to call additional services like https://docs.neynar.com/reference/user-bulk.

1 reply

0 recast

0 reaction

tate pfp

it would be useful for apps that explicitly intend on resolving FIDs, yes. but there is no ENS spec for resolving something like an FID, so it couldn't be builtin to libraries like ethers unless there was an exemption for it.

0 reply

0 recast

0 reaction