DID:Eth Method Specific Identifier about did-eth

[nickreynolds]

I'm kind of conflicted on this one. It does seem like it would make development slightly easier when it's standardized like this, but from a UX perspective, I think it's nice to be able to omit certain fields and assume some defaults. Can you expand on the potential harm in assuming "eip155" if nothing in that field is present? Or assuming "eip155:1" if neither field is present?

@mirceanis would this also prevent us from using public key hex as identifier? CAIP-10 is only for addresses right?

@Reccetech would something like did:eth:hedera:mainnet:0.0.1234567890-zbhlt be supported? That's CAIP-10, right?

[Reccetech]

As you suggest you would have to also assume an EIP155 chaincode as default - which like did:ethr could be ethereum mainnet. I think it made perfect sense for did:ethr to default to mainnet - because it was built for only Ethereum.

But did:eth is targeting a multichain EVM world. So to enter controversial territory - I think if we look at the history of DIDs - very few of them were actually anchored on Ethereum mainnet as it was and still is expensive. So my suggestion would be that if/when did:eth gains traction we'll see a healthy proportion and maybe even the majority of the DIDs on L2s/EVM chains like polygon, avalanche, cardano, hedera. So in this world it makes little sense to assume a default of Ethereum mainnet - unless it's just to give ethereum a privileged position in the DID method (which might make sense if we get development funding from Ethereum foundation). But if we want to keep things even steven then I think it's better to just instill best practices that the full CAIP10 address be used at all times - no shortcuts allowed.
To your second question - yes did:eth:hedera:mainnet:0.0.1234567890-zbhlt could be used as its CAIP-10 compliant.