pull down to refresh
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.
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.
Yes, clients particularly on mobile can't reasonably do the work for delegation, they're pretty unusable as is. This has already failed with NIP-26 I think it was and other iterations of delegation.
Centralizing signers is still decentralized of course, it just becomes part of the self-hosted stack.
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 kinds can it sign? to which p tags? How many sigs per day?
Those rules can then be defined into categories, perhaps your social client has a social scope while your wallet client has a wallet scope... each only with specific kinds/p-tags or perhaps even relays.
We're using in production only as an email-auth bridge so there's no self-hosted code yet, just the SDK that points to our instance and the granularity stuff is not in the policy dashboard yet. 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.