clients should have basic support for it when connecting to a relay that supports delegation. Queries to pubkey X should return pubkeys Y if Y is signing on behalf of X and has a valid delegation.
Discussion
see #[4] for an example
i think minds and npmrepo.com/nostr are the only clients/libs that create these at the moment though
so for example, when I alphaama sees posts from jb55-anigma, it should show as jb55@minds.com?
should look like this unless you're explicitly filtering them out
you can just query directly to confirm this:
echo ["REQ", "nostril-query", {"authors": ["eb300dd2386a3b8efe0447be59bac4603d8b2f558a77b5ea7cb41823b56e21e6"]}] | nostcat wss://relay.damus.io
you'll see fa11cadbb65d6e81ae4e18a09ab7d784ea87d8b5c18bc81ece76b088fa0d1f5b pubkeys
so it's all token based? we know the pubkey by decoding the signature? I'm not sure I fully understand it yet. where is that token by the minds pubkey? I only see it on the posts by the anigma account
We know the root pubkey because it's included in the delegate tag with the signature and event creation conditions.
The unsigned token is `nostr:delegation:
So basically you just sign a token that gives the permission to
and this process is handled internally right now by the issuer? so you need to input that token you received via other means? how is the token verification done?
anyone can verify the token by just checking the signature of sha256(nostr:delegation:publisher-key:conditions) against the pubkey in the delegation tag (which is the root key). also make sure the publisher-key is the pubkey of the nostr note.
huh I was gonna display them as the same user (so whichever key you use, delegated or not it looks the same).
are we limiting what kinds can use the delegated feature? not sure how I feel about kind 0 and kind 3 being posted by delegated account.
yes I am going to do that too, I'm showing damus with 0 delegation code changes here.
the conditions limit what a publisher can publishing. if you set kind=1 then it can't publish kind0. well it can but it will only be valid for the publishing key.
this is why you see a @minds profile here, minds tried to overwrite the anigma profile but couldn't because it didn't have kind0 permission. so the @minds profile is only for that publisher key.
I guess what I am getting at is what kinds will clients be expected to support? not sure I want to support/encourage posting kind 0/3 from delegated keys as it would become super confusing for avg user.
ah ok I didn't look closely enough
#[5]
why would it be confusing? The point of delegate keys is to not give an app access to your private keys. Your client should request kinds that it needs to function, that includes kind0/3 and anything else. Your client will still show your root key everywhere, you never need to show the delegate key anywhere.
Why would this be confusing for the average user? They shouldn't even notice. Delegation enables key rotation and cold-storage root keys.
One issue would be DMs, I haven't tested delegation with them and that would be potentially confusing if it's not handled well by the client.
I don't think handling dms would be much different than handling kind 1
you don't have root privkey to generate shared secret, it would have to be based on the delegate key. which means logging in with your root key you wouldn't be able to see any of the dms.
so if you send a new kind 0 event from the delegate pubkey, that should be effectively considered the most recent kind 0 from the original pubkey?
might be useful to have relay filter to search author and tags for delegated pubkey? otherwise you will always need 2 filters right?