7560e - 3y
You must have a good point if you keep veering off the subject to make claims about what I think of various other matters. I think you’re wilfully misinterpreting what I am saying, because you have widely misstated my opinion. Firstly there is no central fire hose any more than there is a single vista of the Pacific Ocean. Can you observe the Pacific? Yes. Does all of it exist in one place? No. Is there a single place from which you can observe all of it at once? No. All you can ever do is see the 40km to the horizon and nothing more. Can you observe the Pacific from Syndey? Yes. Can you observe the Pacific from Seattle? Yes. But are you looking at the same thing? No, not really. You pick relays and they give you a number of vista points, but you can never hope to see all of the ocean, you pick more relays to diversify your view. It seems to me that what you are suggesting is akin to taking a big portion of the sharks in the pacific, putting them in one bottle, and have 1 person decide what the price of admission is for seeing sharks.
aff9a - 3y
An early dumb version that could go a long way might look something like this. A relay could publish that it supports a given shard of users. For example, my relay could publish that it supports serving npubs starting with “aa” through “az” and other relays could too. Now clients just have to tell a user if their relay set doesn’t have enough shard coverage. Whenever the next order of magnitude of users arrive, relays would want to reshard and other or underutilized relays would need to redeclare shards. And there would need to be a way to get users on the new shards. Maybe some kind of registries would be in order here. In fact registries could be the key branded thing that clients watch for censorship and change to new ones etc. Historical data would have to get shared around for reshards but there could be people out there that just keep archives or in ipfs or something. You still need clients to keep users able to understand and identify a bad relay share that is censoring or underperforming or even overserving — or a registry that is promoting shards you don’t like. But I wonder how far you could scale nostr globally with a dumb strategy like this? Really important is that niche relays should not do anything like this and should find other ways to scale (monetize etc) but this would be for just the “global” nostr network experience only.
7ef7d - 3y
Just saw this too #[4]
*Just* made a note about this -> #[4]
d7b76 - 3y
I proposed some time ago something similar, although it was sharding by note hash, not by user. I would get a set of relays to agree to signal that the participate in a DHT protocol, then build a client to use rendezvous hashing to distribute posts and queries
0b39c - 3y
Great analogy describing nostr as the pacific ocean. The pacific exists everywhere but you can only see portions of it from your vantage point. This thread also goes into how topical relays don’t quite make sense, which I don’t completely disagree with… #[0] But there is a new quote going around saying “We don’t have many relays in common.” This quote shows the potential scaling issue with the model. If you find a new person to follow, you will need to add one of their relays so that you can see their notes. How many relays become too many to handle? This would be a centralizing incentive for everyone you want to talk to to be on the same relay (ahem google, apple, Microsoft) which may naturally force “topical” relays, but then who would control the flow of information in and out of those topics (tech giants)? Seems very centralized. It does not incentivize you to host your own relay because if everyone did that there’s no way to connect to every relay. What’s the right middle ground 🤔 #[1]
21a8d - 3y
Very well put, this is currently my biggest question about how this all scales too any resources to understand this bit better would be much appreciated 👍
phil @phil - 3y
I think more mirroring of events from relay to relay would somewhat resolve the issue of not having relays in common. Also possibly some more intelligence built into clients to select the optimal set of relays based on followers.
I’ll share as I get other resources. This thread is talking about the topic. I like lurking on this thread 👀👀 #[3]
Following 👀
31295 - 3y
#plebchain relay network
A relay that only accepts notes with #plebchain in them?
Yes a network of #plebchain relays that broadcast to each other
