@Arachnid, yes, I knew the first part - I saw the Clef presentation in an Ethereum Berlin meetup > half a year ago.
User specific data like an address book definitely belongs on the Clef side of things, not the node side of things.
I agree with this.
@karalabe, @holiman, there is no mention of a proposal for retrieving address book items in the Clef repo. I am beginning, not starting over. Plus, any such proposal should be an EIP draft - easily findable by interested parties (e.g. wallets), so they can plan & contribute.
I see that Clef uses the same JSON-RPC standard, so my proposal remains valid. Let’s discuss it:
The data type specced out in Clef, for returning a user’s account is:
So, I can add
type to the data type that I proposed.
WalletAddressBookItem will therefore have this format:
"name": "My Friend"
Is the above acceptable?
@karalabe, on my PR, you said:
The field filter seems weird on RPC. That’s essentially what GraphQL is for and how it works. I’m not sure it’s a good idea to start introducing GraphQL concepts into the RPC.
The issue: dApps may want all the information from an address book item (better UX). But exposing names or other info might pose a privacy risk, so the user can choose not to expose them. I think it is the user’s decision.
So, what do you propose for solving this problem, if you do not like the