Subnostr

If clients were a little smarter about how they treat each relay (i.e. asked different relays for different things depending on what they know about each) I think this would fit well into relays -- not as "part of the protocol", but just as an extra thing you can request. Putting it on relays has the small advantages of

a) reusing the communication channel; and

b) making it interoperable so these tally providers can be easily replaced (not that an HTTP provider couldn't be like this too).

I just don't want clients to start requesting tallies from every relay and then every relay thinking they must implement this because somehow it is "part of the protocol" or "everybody else is doing it".

Reply to this note

Please Login to reply.

Discussion

Blake 3y ago

I think most tallies may matter across different orders of magnitudes.. less so exact counts. And with a snapshot, new events can just +1 for more or less real-time (with possible double counts)

Eg. 10, 100, 1,000, 10,000, 100,000+. However the future trick will be filtering the bad data (duplicate likes/reactions/boosts, spam accounts propping themselves up, etc).

Blake 3y ago

I think this added logic can sit nicely on top of the generic relay pool concept (all relays equal) used today for most apps.

I’ll spend more time on “best relays for a pubkey” based on who they follow recommendation engine (it’s most likely recursive and may be expensive to generate). However, the client app layer on top of relay pools is the next level of maturity/intelligence needed for relay interactions.