Mazin on Nostr: Websocket connection overhead is an obvious problem with the gossip model that few ...
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?
Published at
2024-03-20 19:35:28Event JSON
{
"id": "e6feda853b8f55abfb00202de88cbf21bbf44a57d3c64ea3da1ed2f9b7b6671c",
"pubkey": "3d842afecd5e293f28b6627933704a3fb8ce153aa91d790ab11f6a752d44a42d",
"created_at": 1710963328,
"kind": 30023,
"tags": [
[
"client",
"31990:20986fb83e775d96d188ca5c9df10ce6d613e0eb7e5768a0f0b12b37cdac21b3:1700732875747"
],
[
"published_at",
"1710961577"
],
[
"d",
"1710959004510"
],
[
"image",
"/static/media/random_cover_1.dfa37f6a5d82c049464a.png"
],
[
"title",
"The Gossip Model Doesn't Scale"
],
[
"summary",
"Websocket connection overhead is an obvious problem with the gossip model that few are willing to acknowledge. The more decentralized relay selection becomes the worse it scales."
]
],
"content": "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.\n\nBelow 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. \n\nEDIT: 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.\n\nAvailable relays: 600 (~what nostr.watch currently shows for online relays)\nFollows: 200\nRelays per person: 2 (randomly selected)\nUnique Connections Required: 291\n\nAvailable Relays: 600\nFollows: 500\nRelays per person: 2\nUnique Connections Required: 486\n\nAvailable Relays: 600\nFollows: 1000\nRelays per person: 2\nUnique Connections Required: 577\n\nEven 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?\n\nAvailable Relays: 3000\nFollows: 200\nRelays per person: 2\nUnique Connections Required: 376\n\nAvailable Relays: 3000\nFollows: 500\nRelays per person: 2\nUnique Connections Required: 847\n\nAvailable Relays: 3000\nFollows: 1000\nRelays per person: 2\nUnique Connections Required: 1461\n\nI’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). \n\nWhat am I missing?",
"sig": "051202dcc3a29100294a8b4e9fcf93724231cffe670064d1cc997657af9a4f936f300810bf0b8cd704934e81fe602d5b602b6c5b99179ae0d0e206220cd3f99f"
}
