#[6] would explain better, as those are their graphs from nostr.band , but I suppose he's counting unique zaps signers, as zap events are signed and published by the Lightning Address providers after the payment has been processed properly.
Discussion
Exactly, zap notes are published by the LN node that received the payment.
The zapper service needs to listen to the LN node to confirm payment, indeed. Doesn't have to be the LN node itself.
Ok, I think #[3] was simplifying the architecture, yes.
The LN node receiving the payment doesn't have to implement the zapper function by itself. It could ask another zapper to publish and sign the zap event, I guess.
I suppose nostr.band is using the zapper pubkey to identify a zapper, whatever the LN node receiving the Lightning transaction was.
Is it like that, #[3] ?
That's all provider's implementation detail, I think. Yes I use the pubkey, not LN node id from the invoice
Maybe it's nice to differentiate between custodial and non-custodial zappers.
#[5] is my personal zapper.