If you’ve used NOSTR for a quick second then you’ve noticed that you need to connect with dozens of relays or else you’ll miss some posts, messages and other stuff unless that data has been pushed to the relays you’re connected with.
Jameson Lopp noticed yesterday (on that other bird app) that he can’t tell how many followers he truly has…
Depending on which relays you’re connected to it looks like he has anywhere from 400 to 5000 followers as commenters confirmed.
For me, I was noticing missing posts and messages until I was connected to somewhere over 20 relays. But I’m not sure what the magic number is. And, as Jameson’s post shows, you can’t really be sure you’re not missing some data unless you’re connected to all relays.
This begs a few questions…
  1. Why don’t NOSTR relays compare and share notes with each other? Is there a reason for this – an intentional design choice, technical limitation, or oversight? If a relay wants to be private, just give it that choice. Similar to how Bitcoin nodes download from each other unless the operator opts out.
  2. If option #1 isn’t possible, why don’t NOSTR clients automatically connect with a relay directory and give the user a option to automatically connect with ALL public relays?
To me it seems the lack of these features will lead to a fragmentation of the network and a user-experience that gets worse over time as more and more relays come online – all silo’d from each other and hoarding their own data. Typical users aren’t going to want to spend time manually adding hundreds or thousands of relays to their social apps.
What am I overlooking?
Why don’t NOSTR relays compare and share notes with each other? This isn't done for two reasons:
First, federation is complicated. Go look at the size of the ActivityPub spec to get an idea of the complication that federation requires. Sharing messages between relays is not as simple as just sending the messages to all other known relays. At minimum, every relay would have to keep track of what messages it has sent to which relays, in order to avoid relays spamming each other with 100k copies of the same message.
Second, clients can easily connect to dozens of relays. That's one reason why WebSockets was chosen.
If option #1 isn’t possible, why don’t NOSTR clients automatically connect with a relay directory and give the user a option to automatically connect with ALL public relays?
A relay directory that knows all public relays is unnecessary, because users can trivially tell each other, "I am connected to these relays." Moreover, it is not desireable for every client to connect to all public relays. Because in 10 years there could be 1 billion Nostr users, and no relay will ever be able to handle 1 billion websocket connections.
--
But Lopp concerned about something that is going the way of fax and chatrooms. Lopp is a social media influencer, which is source of income for him. And to do that job, he needs to know how many people are watching him. But Nostr is not a social media protocol, so social media influencers will not thrive via Nostr. A change of perspective is needed for people to properly take advantage of what Nostr provides (which is so much more/better than social media). Social media is a technological dead-end, like chatrooms, forums, email, and fax.
reply
Yes. I see your points. I guess it's going to take time for my brain to wrap itself around this thing. Lopp's concern about # of followers was only intended as an example of information being missed by clients. I couldn't care less about followers, but I don't think it should be dismissed.
reply
What am I overlooking?
The project's ambition to be/stay decentralized.
Expecting relays to co-operate, now begs the question, how? Trying to answer that is non-trivial. Which users would like their what data to flow to other relays? And which one? What if you don't want your data to flow across all relays? My guess is, this will be attempted anyway, and be seen as an attack on Nostr.
Expecting clients to sign up to a director begs the question, who maintains the directory and how? How do you get included in that directory? Can you get booted from that directory? Censorship incoming in 3...2...1... My guess is, this will be attempted anyway, and be seen as an attack on Nostr.
Even dolu's proxy linked in this thread's comments, if used maliciously, could be seen as an attack on Nostr.
reply
Perhaps "relays comparing notes" was not the right inference. But I still worry that without some kind of consensus, entire pieces of information will go unseen. Whether intentional or not, that is a form of censorship. Bitcoin is decentralized but there is still consensus and one complete ledger.
reply
a proxy will help with mass broadcast
reply
The syncing feature of the strfry relay is something I'd like to experiment with 🤔 when I have more time 😔
reply
Someone should use minisketch to compare events between relays
reply
Rabbit hole alert! Looking into minisketch...
reply
If relays are going to share state, there needs to be a way to prevent spam on nostr. Bitcoin’s mempools do this by requiring txs pay a minimum fee to miners. Otherwise they don’t relay them for inclusion to other mempools.
Nostr needs some kind of equivalent.
reply
This makes sense. So fees would need to be built in at the protocol level, not just individual clients?
reply
It just needs something to close the asymmetry between the 0-cost nature of sending an event and the expense of relaying and storing it.
Spam is already a problem at the relay level and we are beginning to see some experiments with defense.
IMHO nostr will solve this kind of problem by figuring out how to get sats from end users to relays and other nostr layers in a way that scales proportional to their consumption of resources on other layers. It's a non-trivial problem, which can go unsolved for a period of time, but the solution is the difference between nostr eating the world and not.
reply
Use nostrproxy
reply
Interesting. Are you referring to Nostr Proxy by Dolu?
How would your average user go about setting this up? Take an idiot like me for example, I'm using Damus on iOS. Is there a single proxy relay I should connect to? Or do I need to install this on my system?
reply
I'm sure people will start setting up paid proxies as well, that connect to other paid relays.
reply
It's planned for me. I just need to finish to fix perf issues before adding custom relays
reply
yes, you can use the public proxy at https://nproxy.zerologin.co if you want, but you wont be able to use the paid relays. Which is fine.
reply
Holy smokes, look at that. Amazing. Can anyone here verify that this works? I'm assuming you get all the same data you'd get as if you were connecting to all relays independently. Does it improve performance?
reply
Yes, your client is naturally way faster because its only trying to pull from 1 relay/proxy. Now if your proxy is running on dual core intel from 2008, then it will not be faster lol.. the client will be but the proxy will be slow to pull.
reply
yes ive tested the public proxy with a new key, not my main.. works pretty flawless so far. I have tested the private relay too but not with paid relays yet.. Have not had time yet.
reply
  1. There's nothing stopping them. That they don't isn't part of the protocol.
  2. There are relay directories, note the plural, and there are relays that aren't part of any of them, note the plural.
Nostr isn't a centralised, solve your problem, profit making enterprise. There are rules, but frankly after NIP-04 it's all "make it like Twitter" bullshit.
It isn't Twitter, it isn't federated, it's going to work out its own way in the world and the apocalyptic predictions of silos, hoarding, may be right and Nostr isn't the solution. Making it like Twitter though is definitely not the solution.
Jameson Lopp doesn't know how many followers he has, he doesn't know now how many people read his profile and don't follow.
The easiest solution might be to make a relay that follows the relays you've added to your client, then others could follow that one.
PS. Note to self, read then respond. That way I'd find the idea has been implemented; #134918
reply
I think fiatjiaf is opposed to this development, but I believe it is inevitable.
reply
I believe it is possible for relays to broadcast events to each other already
reply
reply