Allow dapps to include "proposed names" along with any address-involving methods

[danfinlay]

Breaking out from #7.
Based on pet names

Naming things is hard. Especially in a decentralized web where anyone can generate a new 32 byte identifier freely. Relying on central registries, or even name markets, can struggle to keep up with some realities of normal usage:

• People may refer to the same thing by many names.
• People may have private names that are only known by some.
• Public name registries are chronically prone to mimicry attacks, where lookalike names appear as legitimate as "real" names.

It seems natural and intuitive that perhaps the most decentralized and safe name a person can ever have for an address is one they assign themselves (like in an address book), but of course this hits the limits of what names a person ever knows themselves.

In most cases, when a user adds a name to their address book, that name is proposed by a third party, often the address holder themselves. In most wallet-dapp interactions, the user has some trust in the underlying website, at least for basic information like its own name, and its names for its own internal components, and we can leverage that initial small trust to at least help establish names for things. If the wallet UI then later makes it easy to view those names when those addresses appear in other contexts, then the user has become safer as they browse the web.

I propose a new transaction parameter that could be added to any method that invokes user interaction that includes an address as a parameter, like eth_sendTransaction, or eth_signTypedData. In that way, this proposal is similar to EIP-747: wallet_watchAsset, but allows general purpose naming, and is not confined to any particular type of asset (and lacks specifics related to any particular asset type).

The parameter would be proposedNames, it would be an array of objects that represent names to propose to the user.

{
  proposedNames: [
    {
      "address": "0x55e2780588aa5000f464f700d2676fd0a22ee160",
      "name": "Dan Finlay",
      
       // optional, chain identifier
      "chainId": "eip155:any",

       // optional, logo image
       avatar: AVATAR_URI,
    }
  ]
}

The chainId parameter could be defined in the format of CAIP-2

If an Avatar URI is included, it should be cached as to not leak the user's IP address every time it is loaded. First load is arguably excusable from the confirmation since the user is already on a site that can load images, but could be hidden behind a "load remote content" waiver.