> sovereign identity needs a sovereign identity server just as sovereign payments need a sovereign payments server.

It is, yes. I still would love to subscribe to a superkey instead of a signing key; that would make things a little less dangerous on the signing key exposure. But yes, NIP-26 feels incomplete for that to me too (and relies on relay-side routing, not just relay-side signature validation.) Running one serverside vault is easier to secure than running it on your Samsung that never gets patched too - but then, people have no clue anyway.

> transport. Nostr is paradoxically not a good fit for this

I am feeling that way about the entire protocol, haha. It's not transport-optimal in any way. Nesting layers of base64 encoded json.. oof.

> not loving the liveness requirement

Yea that's the trade-off with all this sovereign internet stuff. Same as Lightning, sovereign identity needs a sovereign identity server just as sovereign payments need a sovereign payments server.

Biggest decision I have yet to make on it is the transport. Nostr is paradoxically not a good fit for this because of the size increase of the response event nesting the signed event. Need to investigate what compression or returning the signed event as binary might achieve. Having the signer do the actual emit could have security implications since it couldn't be in a militarized network, and the client UX/DX could suffer.

justin_shocknet

A policy engine on the remote signer also allows for much more granular controls than delegation ever could. I think of it like firewall rules, can this client sign? what kindds can it sign? to which p tags? How many sigs per day?

How we used to solve this in the field is with SAMs / secure applets (that implement counters, limit capabilties through x509 scope, short duration certs that are reissued frequently) but x509 is terrible to implement, especially bespoke-ish on nostr as you'd need to do it on the client (because giftwrapping) and since it's 99% quality poverty on the client implementation side, results will be even more variable as they are today.

So I think that despite not loving the liveness requirement and profile of a centralized nostr key, I do not see the alternative being feasible in that space - you may very well be right.

It's still proof of concept to inform the initial open protocol but we're getting back to it after the next Pub/Wallet release.

Looking forward. It'd be awesome if I don't have to waste time writing a signer from scratch.

nostr

Why Nostr Identity Is Not a Negotiable Feature - alp

Scoresby

> A policy engine on the remote signer also allows for much more granular controls than delegation ever could. I think of it like firewall rules, can this client sign? what kindds can it sign? to which p tags? How many sigs per day?

How we used to solve this in the field is with SAMs / secure applets (that implement counters, limit capabilties through x509 scope, short duration certs that are reissued frequently) but x509 is terrible to implement, especially bespoke-ish on nostr as you'd need to do it on the client (because giftwrapping) and since it's 99% quality poverty on the client implementation side, results will be even more variable as they are today.

So I think that despite not loving the liveness requirement and profile of a centralized nostr key, I do not see the alternative being feasible in that space - you may very well be right.

> It's still proof of concept to inform the initial open protocol but we're getting back to it after the next Pub/Wallet release.

Looking forward. It'd be awesome if I don't have to waste time writing a signer from scratch.