Replying to Avatar Mazin

Websocket connection overhead is an obvious problem with the gossip model that few are willing to acknowledge. The more decentralized relay selection becomes (the goal) the worse it scales. Even at the current scale of nostr if users chose more diverse relay sets the issue would be crippling.

Below are some very simple simulations to illustrate my point. I used 2 relays per person to be conservative and chose 3 different realistic follow counts. The NIP-65 spec suggests clients should guide users to keep the lists small (2-4 relays) though currently the average kind 10002 contains many more. I ran each simulation 10 times and then took the average result.

EDIT: I understand that selecting relays at random is NOT how things currently work or will ever work. My point is that if our goal is to make relay sets more diverse then we should work towards a solution that scales with accomplishing that goal.

Available relays: 600 (~what nostr.watch currently shows for online relays)

Follows: 200

Relays per person: 2 (randomly selected)

Unique Connections Required: 291

Available Relays: 600

Follows: 500

Relays per person: 2

Unique Connections Required: 486

Available Relays: 600

Follows: 1000

Relays per person: 2

Unique Connections Required: 577

Even today if users randomly selected relays the total number of connections required would be staggering and this is with users only selecting 2 relays each. What happens if the available number of relays increases by 5x?

Available Relays: 3000

Follows: 200

Relays per person: 2

Unique Connections Required: 376

Available Relays: 3000

Follows: 500

Relays per person: 2

Unique Connections Required: 847

Available Relays: 3000

Follows: 1000

Relays per person: 2

Unique Connections Required: 1461

I’m not a client developer and I certainly don’t have all the solutions but I’ve spent enough time operating websockets at scale to know that these numbers aren’t going to work even with only 2 relays per person. Aside from the practical performance implications, browsers also enforce websocket limits that put most of these numbers out of reach (I believe Chrome is 255 and Firefox is 200).

What am I missing?

In nostr:npub1gp4xzpmluelsakjtayc4wtzj97fhj5kakqjvsannu00xkdlf4x8s0xdqyq the default behaviour for feed relays is to go find the minimal amount of relays that fill at least an amount per contact (here used 2), and for my ~300 contacts 23 relays is enough:

Reply to this note

Please Login to reply.

Discussion

I like this solution a lot and included it in one of my replies. This still gives the user control.

It also illustrates how centralized relay selection is today. My goal was to show the problems with gossip if we move towards wider relay selection.