Migration path:

1. Add Ed25519_inline key type to protobuf
   • All new keys will have this type

enum KeyType {
  RSA = 0;
  Ed25519 = 1;
  Secp256k1 = 2;
  Ed25519_inline = 3;
}

2. Ed25519_inline will always use the peer_id calculation above
   - 'implicit' hash function - solves Specify peer ID hash function in public key #111
   - no conflict with previous implementation Peer ID Calculation History And Resolution #138

In what way does this solve the design constraints in #138?

It obviates (no hashing of keys)

• We need to provide a way to for users to select a hash function other than sha256 when computing their peer ID.

It meets

• Given a public key, peer ID calculation must be deterministic.
• There must be a case-insensitive way to express peer IDs appearing in IPNS paths (for browsers). Currently, peer IDs are always base58 encoded which is not case-insensitive.

It also has

• We'd like a way to "inline" public keys into peer IDs (if the public key is small enough to fit comfortably). This will allow encrypting a message to a peer without needing to look up their key first.
• (potentially) Peer ID Calculation History And Resolution #138 (comment)

  querying the DHT for PeerID -> metadata without disclosing PeerID or metadata

@Zolmeister I think this would be a good candidate to go through the new process defined in #169.

If you want to write up a draft spec PR, we can form up an interest group and pull it into the repo as an initial draft to get some discussion around it.

Closing here as discussion has continued on #172.