IPNS pub key size concerns

Recently I was told ed25519 are preferable for IPNS over other keys due to their smaller size. However it is not in the list of [supported algorithms](https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto#supported_algorithms) in web platform requiring bundling crypto libraries etc...

This got me thinking about potential ways to address this problem, especially since is safe to assume that over time longer keys may proof necessary.

### Idea 1.

Right now public keys are endoded `IpnsEntry` protobuf (which is presumably where we small size is desired). In practice chances are node receiving a record already has a public key because:

1. IPFS default is to use `self` key so it was used in handshake.
2. Recipient has some interest in a IPNS record so key was previously obtained.

If thees assumptions holds, we could make next version of `IpnsEntry` encode CID for the public key instead. Furthermore small keys and _rare_ keys could use identity hash CIDs. It is also assumed that Sequence 0 record will use identity hash.

### Idea 2.

What if instead of basing mutable namespace on the public key we based it on mutex block (genesis block) CID instead that use designated muticodec code. Mutex blocks could encode multiple public keys allowed to perform updates, and also be fairly open ended to allow new or domain specific metadata to be added e.g.

1. peer ids of nodes that are likely to have latest record.
2. DNS alias(es)

I think this would also neatly combine IPFS and IPNS namespaces where `/ipfs/$cid` represents content on creation and `/ipns/$cid` represents content now. For `/ipns/$cid` where cid is not for mutex it would be identical to `/ipfs/$cid` because it's not a mutex so it could never change.

Additional benefit of such mutexes would be that they could cleanly integrate into IPLD as they are addresses by CID.