pull down to refresh

auth.shock.network

So basically what you're saying is signer centralization, but with secondary key auth, is a better solution than subkey delegation in the protocol?

PS: docs goes to a generic page - can I run this today? I need to get rid of this AVM with Amber because it keeps draining my laptop battery 😬

249 sats \ 5 replies \ @justin_shocknet 26 Jul -420 sats

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.

can I run this today?

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.