App-specific records #160
App-specific records #160
Conversation
jefflau
force-pushed
the
app-specific-address-resolution
branch
from
475b076
to
4a3e17e
Compare
jefflau
force-pushed
the
app-specific-address-resolution
branch
from
4a3e17e
to
7ed318d
Compare
|
|
||
| ### Motivation | ||
|
|
||
| Apps such as Farcaster that use Sign in with Ethereum as a primary login require the generation of a new EoA. It is also possible that you may want to split your address usage across different applications for address hygiene, security or privacy reason. Lastly with account abstraction becoming more popular, we may end up with an increasing amount of different addresses for different applications that man need to be connected. |
There was a problem hiding this comment.
A technicality, but Farcaster wallet clients don't use the SIWE standard for account creation / usage. A new account is created when you make a transaction to a contract, and then the address that made the transaction is now the owner of the account.
| /// @param node A nodehash for an ENS name | ||
| /// @param key A key to lookup text data for | ||
| /// @return The binary data | ||
| function binaryRecord(bytes32 node, string key) view returns (bytes data); |
There was a problem hiding this comment.
Is there a standard for what binary data should be returned for a record? Or is that up to each app to decide?
| * You set the farcaster record on example.eth to 0x456... | ||
| * You now have a connection from 0x123... (your main optimism address) to 0x456... your farcaster address | ||
| * You add your ENS name to your account settings in Farcaster (stored in FC's hub servers) | ||
| * Now Farcaster can check your farcaster address in example.eth and show records from example.eth or NFTs you own on example.eth |
There was a problem hiding this comment.
you might want this to be double opt-in. otherwise i could register something like poop.eth and point it at your accounts keys without your permission. you could require that the binary data in the record contain a signature from the target address
| * You add your ENS name to your account settings in Farcaster (stored in FC's hub servers) | ||
| * Now Farcaster can check your farcaster address in example.eth and show records from example.eth or NFTs you own on example.eth | ||
| * You can take the private key and put it onto any device, and login to Farcaster seemlessly by putting the key on the device | ||
| * This key gives access to your Farcaster account, but if a device is compromised, you can rotate the key to a new account rather than having to transfer all your assets out of your main account. |
There was a problem hiding this comment.
how would this part work? if you are concerned your keys are compromised, and you own some eth or nfts there, youd still have to manually transfer them to the new account
|
|
||
| ### Considerations | ||
|
|
||
| Should the spec also deal with chains? E.g. |
There was a problem hiding this comment.
more broadly, apps should be able to specify multiple keys. for example, farcaster may use different keys for onchain actions vs encrypted messaging. so if you have a general format that apps can register subkeys with, they can easily extend them with chain info if needed.
|
Overall this takes the same approach that Farcaster took with the KeyRegistry but with a few differences:
I think 1 & 2 are fine and a general purpose system like ENS probably shouldn't have these specifics that may not apply to all apps. But i think 3 is worth considering as part of the spec |
WIP.
Things that need to be thought about: