I don't understand the nostr context, but why can't you use a deterministic nonce generation algorithm? (Unless you're doing musig in which case, yes, you basically can't). Either the bip340 suggestion, without injecting fresh randomness, or rfc6979 even?
Not being rfc6979 shouldn't be a problem, the algorithm is never a matter of consensus with other parties.
Doubtless I missed at least one thing here ...
I know you can, but basically every implementation today just generates a random nonce so you can't rely on them being able to do sigs with specific nonces.
OK, that makes sense. Doesn't the libsecp API let you specify the additional randomness yourself though? I vaguely remember it does but i wouldn't be surprised if that's a bit fiddly.
A recollection from years ago, I remember gmax telling me he talked to Pornin quite a bit about the RFC6979 spec and that he thought it was unnecessarily complicated (difficult to disagree if you read it!) - the main concept is of course f(privkey, msg) where f acts as a PRNG. Vitalik implemented it wrong in pybitcointools (less of a 'burn' than it might sound, since the error didn't break anything except with negl. prob ... so it's more just an example of how complicated it was).