This is a discussion thread for the proposed FEP-521a: Representing actor’s public keys.
Please use this thread to discuss the proposed FEP and any potential problems
or improvements that can be addressed.
Summary
This proposal describes how to represent public keys associated with ActivityPub actors.
Would you consider adding nostr key pairs which use modern, compact Schnorr signatures?
Then all activitypub users will be able to use the nostr eco system. Nostr has 600+ apps on github alone built on nostr, and 1-2 new ones every day.
I’m personally highly disillusioned with the DID/VC eco system as it stands currently, not only is it incredibly complex, but the DID method registry is packed full of illegal and unethical scammy block chains trying to sell tokens to an unsuspecting public. Speaking to the VC group about it, they really dont seem to care, and there are enormous conflicts of interest.
On the contrary, adding nostr would be as simple as adding one field for the pubkey.
This FEP recommends implementers to use Multikey type for public keys. That means a binary representation of a public key must be encoded according to the multicodec spec and then converted into base58-btc multibase string. So, in theory, this FEP already supports Nostr keys (and many other kinds of keys) – one just needs to choose a prefix. I’m not sure if a prefix for encoding Nostr public keys has been ever registered, but registring a prefix should be as simple as submitting a pull request to the multicodec repository (there’s secp256k1-pub, but apparently BIP-340 public keys are different?).
Note that this FEP is concerned with server-controlled keys. The mechanism for linking user-controlled keys is described in FEP-c390. Yes, it is based on DID standard, but it’s not really that bad. Implementers are free to choose whatever DID method fits their needs, and nobody is forced to use methods submitted by companies with questionable reputation.
Someone even wrote a draft of the did:nostr specification.