Likes vs. Zaps.
1. If someone wants to put `Only-Zaps` into their client, and if their users want to turn it on, it's a free nostr.
2. I like likes. I'll continue to support them in more-speech, and continue to send them. It's a free nostr.
3. Bandwidth:
a. If every event causes Nl likes, then total bandwidth is E*(Nl+1). That could get high.
b. If every event causes Nz zap receipts, then total bandwidth is E*(Nz+1). Still high.
c. If Nz ~= Nl then there is no savings in throughput.
d. Zap receipts can be more expensive to process than likes. (e.g. more-speech does not signature check kind:7)
3. Bandwidth solutions: If we are really concerned about the bandwidth of kind:7 (likes), then we could invent some kind of piggyback scheme in which likes are held by the client and tacked on to the next outgoing note. e.g. a "likes" tag that takes an array of liked event ids. Clients could even limit these to once per hour or so. -- IF we were worried about bandwidth.
2. I like likes. I'll continue to support them in more-speech, and continue to send them. It's a free nostr.
3. Bandwidth:
a. If every event causes Nl likes, then total bandwidth is E*(Nl+1). That could get high.
b. If every event causes Nz zap receipts, then total bandwidth is E*(Nz+1). Still high.
c. If Nz ~= Nl then there is no savings in throughput.
d. Zap receipts can be more expensive to process than likes. (e.g. more-speech does not signature check kind:7)
3. Bandwidth solutions: If we are really concerned about the bandwidth of kind:7 (likes), then we could invent some kind of piggyback scheme in which likes are held by the client and tacked on to the next outgoing note. e.g. a "likes" tag that takes an array of liked event ids. Clients could even limit these to once per hour or so. -- IF we were worried about bandwidth.