did: Allow Ed25519

[lorenzleutgeb]

This is a follow-up on #181, see #181 (comment)

Add parsing, decoding, encoding, signing, verification for Ed25519 via @noble/curves/ed25519. Analogous to the already existing curves. packages/crypto/src/ed25519/operation.ts is a straightforward modification of a copy of packages/crypto/src/secp256k1/operation.ts. Note that there's no compression, i.e. {de,}compressPubkey are trivial.

Should be released only after did-method-plc/did-method-plc#93

[lorenzleutgeb]

@foysalit, kindly asking you to approve workflows for me. Thanks!

[bnewbold]

This is something we are open to considering over time, but it should start as a protocol conversation before implementation work.

Ed25519 is a popular system, and we considered it when selecting the original 2x cryptographic systems. If we are going to add the complexity of a third system, which every implementation of atproto would be expected to adopt, we would want to make sure there are clear and unique/novel advantages to that additional system, however.

[lorenzleutgeb]

What is a protocol conversation?

Please also note my other, linked PR which restricts rotation keys and verification methods for "atproto" to P-256 or secp256k1, even if @atproto/crypto would support more did:key algorithms.

The reason for allowing Ed25519 is because I would like to link my did:plc with a verification method that simply does not support either P-256 nor secp256k1, but does support Ed25519.

Just adding an Ed25519 verification method with ID "radicle" would enable interoperability with Radicle. That is, it would allow did:plc to be used not only in an ATProtocol context but also in a Radicle context.

From what I understand, such openness is a goal of did:plc.