got a few details to work out with the claims format for the token and the process of building the key pairs, will be getting that sorted out this afternoon

it will be possible to use the same secret as your nsec (we will prefer this as a default as it's simpler) and then just need to have the procedure for deriving the pem and crt files, the pubkey registration, containing the crt will be the content of the 30050 event, the claims file will contain the pubkey so to perform the auth the relay will search for the pubkey registration event (certificate) and then get the JWT pubkey and verify that the message hash matches the signature and the signature matches the crt

it's all familiar stuff to me, except for the encoding... it will be using p256 ECDSA signature algorithm, most similar and compact to match up with the cryptosystem used in nostr

and yes it will be possible to also use a separate key file for this auth, it may actually be better to do it this way, so i'm going to make it so the process flow is the same either way

the purpose of this is it enables us to use standard common web dev tooling to implement authenticated access to nostr relays for publication, yes, that will basically mean seamless webhooks that push nostr events, and the core purpose though is enabling the use of nostr relays on low power devices like ebook readers, which often cannot support websockets