It's not n+1 subscriptions. The one subscription for all of my follows would contain all of my follows' delegations, too.
Discussion
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