Why not store the delegation token with Alice's profile as a hint to followers. "Bob sharing text notes and likes ... is actually also me". This way,
* relays could be oblivious to this and wouldn't have to carry the burden of extra indexes
* clients that would have to be delegation aware anyway would have to explicitly query Bob **or** relays could themselves get the delegation from Alice's profile to serve Bob's events as per delegation
* revocation would be resolved by event replacement
I like that a lot.
I do think relays still have the burden of indexing; it's either that and returning the Bob's events when asked for { authors: [ 'Alice' ] } or getting n+1 subscriptions (where n is number of delegated tokens by Alice)
It's not n+1 subscriptions. The one subscription for all of my follows would contain all of my follows' delegations, too.
right, but that would be if the relay understands that it should follow that behavior, no?
what I'm saying is that either the relay returns on a query for authors: alice, alice+delegatees' or the client needs to query for alice and each delegatee individually.
A nip aware relay would be equally efficient for reading both way:
* find events with author=Alice or delegator=Alice
The writing is different:
* If event has valid delegation tag, delegator=tag.delegator
* If event.author is delegatee of x, delegator=x
The problem the "bearer token" tag solves is that in my approach both Alice and Carol could delegate to Bob, with Bob's event not resolving on who's behalf the event was authored.
Resolving would still require a delegator-pubkey-tag. It would be more light-weight omitting signature and conditions. These could in turn be updated or revoked. That would turn that line above into a less hand-wavy:
* If event.author is delegatee of tag.delegator, delegator=tag.delegator
