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.
Discussion
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?