I'm the author of gossip, a desktop client not a mobile app, but I have someting to say on this. Gossip downloads only about 4MB when I start it in the morning and run it for an hour. Since that is several orders of magnitude less than some other clients, I thought I'd make a list as to why:

1. Duplicate Events - many clients subscribe to the same filters on all of the "read" relays. So if a person has 10 read relays, they get each event 10 times. They could subscribe in a way that only gets N copies, where N is set in some setting somewhere (gossip defaults to 2 or 3).

2. Not Dynamically Connecting to Relays - when clients don't dynamically connect to the 'write' relays of whoever you follow, users are incentivized to add lots and lots of relays as a hack to try to get that content, aggrevating issue 1. If clients smartly went to the write relays (based on relay lists), all of the content a user has subscribed to would arrive (in best case scenario) and users would no longer feel the need to add massive numbers of read relays.

3. Counting how many followers you have is expensive. Kind-3 contact lists are long, and you need to pull one for each follower to make such a count. Especially if done across many relays (where the same ones are pulled multiple times, once per relay), this could be 10-20 MB on it's own. Then how often is the client triggered to recount?

4. Downloading of avatars: gossip caches these so it doesn't have to re-download them. Any client that uses an IMG tag and doesn't have a browser caching is probably downloading these over and over, at worst case every time a post scrolls into view.

5. Content images and content web page pre-rendering: This can be very expensive, but is probably unavoidable on rich UI clients. Gossip is a "poor" UI client, without any images or prerendered links (it just shows links that you can click on to open your browser). But with caching, repeated downloading of the same thing can be avoided.

6. Re-checking of NIP-05 could be done periodically, perhaps daily if it failed or every 2 weeks if it passed, probably the worst strategy is every time a post scrolls into view.

There are probably others.

#[4]

Reply to this note

Please Login to reply.

Discussion

NIPS needed:

1) "select: ['id']" filter so you only get matching event ids and not the full event 10 times. You can then ask only 1 node for the full event, or skip if you already have it.

2) Bloom filter for "I already have these events, don't send them". Can be resource intensive on the relay side and not usable in all queries.

3) Follow distance filter for authors, so you don't get irrelevant spam. Iris discards stuff from unknown authors on the client side, but would be better if they weren't sent and processed in the first place. Shouldn't be difficult to implement with some SQL wizardry.

Thanks for answering question. Answer me this one:

Why does the zaps button keep appearing and disappearing on iris.to?

On profiles or posts? Haven't seen before.

posts. Lightning addys are on profiles. but I am missing the zaps button on posts quite often.

On my cell, Nostr runs off of Firefox. I reload the app by refreshing the browser button. When I reload it, the lightning bolts appear.

Which client r u running?

Iris

I'm running the iris.to client on firefox and once in a while I see the zaps button but usually not.

On my desktop.

I like these ideas.

1. I think the 'select' filter isn't really a filter (selecting which events) it is requesting a different kind of result so it should probably be a new REQID message (IMHO).

2. Bloom filters are interesting. strfry is using merkle trees, presumably to see which branches need refreshing... but I'm not sure how applicable that is to a much smaller set of IDs or how it compares to bloom filters.

3. I'm not sure we can presume a relay has everybody's contact lists and can compute a follow distance. Maybe some relays could specialize in doing that though. Clients probably need to have a concept of which relays are "aggregators". All kinds of aggregations like this, reaction counts, how many followers someone has, it all depends on a relay having all that data which I suspect over time will be a less and less accurate assumption for general relays as people move off the central crowded relays.

One option is a bloom filter of authors. It's not good for history queries, but for new events it would be useful. 10k authors from your social graph with 1% false positive rate would be around 12 KB. Would limit incoming spam nicely.

👍

Hi Martti, maybe unrelated to this post, iris.to desktop client is great missing below zapping implementation on snort.social, any plan to add?

Is this video capture from your browser app on iris.to? I do not see this when clicking on sats icon. The HREF link starts with "lightning:" and there is no app register for it.

It's the browser version

All browser, it just doesn't work on any browser on Windows OS. It works fine on phone. Same works fine on snort.social .

#[5]

#[6]

#[7]