Hello!
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.
cc @silverpill
Known issues:
authentication or assertionMethod.expires property should be added.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.
Nostr vocab: Nostr Vocabulary
Nostr context: https://w3id.org/nostr/context
I can add terms as needed to comply with the FEP
Could work. Or possibly this is better done as an individual FEP, together with the proxy object.
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.
Proposal has been updated: #132 - FEP-521a: Update proposal - fep - Codeberg.org
It now states that keys with assertionMethod purpose are suitable for signing activities and objects.