Doing lots of tests with web connections on Android. It does seem like there is a limit on how many parallel websockets each phone can handle. And it is quite low.

Which is obvious in hindsight, but really interesting too see how one app can affect another app's loading performance when both are used at the same time. Even Google apps on Google phones are affected.

Year another case for local relays.

Reply to this note

Please Login to reply.

Discussion

Also a case for caching

True. But I think as we move more into dozens of apps per phone. It will start to make sense to have one app to sync to local first and provide that data to the other apps. I wonder if Citrine should start to have some syncing capabilities.

I just added a button to fetch your events and next ill start working on this.

I tried a few months ago and just my follow list + their follows has something like 1000 unique relays after removing filter.nostr.wine/npub

A lot of invalid relays and local relays

But i stoped there

This was using outbox and general relays

I think clients should start checking the relays before adding it to the list, something like i did in amber

For exemple theres a lot of typos and things like damus.io instead of relay.damus.io

Even outside of android, browsers enforce limits. This page gives great answers: https://stackoverflow.com/questions/985431/max-parallel-http-connections-in-a-browser

Frankly, I don't think it is enforced. It's just hitting some real limit somewhere. Anything over 20 connections you can already see a significant slow down. And it changes from phone to phone. Higher ends can take more. Lower ends less. It's very cool.

Over WiFi or phone data?

Wifi.

The desktop case:

Modern firefox does >1000, but Chrome (v81) was limited to 256. My current gossip is connected to 28 relays, but sometimes that spikes to 50 or 60. If I followed a lot more people, and those people were very divergent, maybe I would break 100. If it ever came to be that we couldn't open enough connections to simultaneously pull from all relays I wanted something from, then I would have to queue and batch these requests, which is a bit more complicated but doable. I've always known this was going to be fine on desktop.

The mobile phone case:

As much as it pains me to say it 😉 I completely agree with Vitor. I think local relays make sense for low-powered devices as long as you can trust them. I wouldn't call it centralization since you have your choice of many such services to choose from, and I can't think how any one such service could capture the market (except by being bundled with a client! in which case the FTC should break up that monopoly 😱)

Test this. Pick 50 relays and to a filter to download everything to Gossip. Then compare the amount of data/second with the data limits of your connection. On phones I can only get to maybe 30% of the bandwidth available. Maybe on desktops it will be clearer.

I can get ~100% of the bandwidth as a single download, but not if I split in many connections.

I presume you are counting the event bytes, and not counting the per-connection overheads. But still, 70% of the bytes used for connection overheads seems high enough to be worth some investigation. So long as each relay is returning at least 20 events or so, it should be better than this. If each relay is only returning 1 event, then this number makes sense though.