Show thread history
fiatjaf
5d ago
Sounds arbitrary. And probably a security concern over a webpage causing your computer to DoS a million sites? I don't see why it would eat the battery to have the same amount of data sent over 400 connections rather than 200, and, well, battery is not a concern for desktop computers, while phone apps don't run on browsers (I imagine even the webview-wrapped apps may not be subject to that limit). Not ideal, but I guess you can add a relay picking algorithm that favors hubs over non-hubs when running in a browser.
Now assuming you have that, is there a reason why you wouldn't open 100 subscriptions on the same relay with one key each instead of a single subscription with 100 pubkeys?
Now assuming you have that, is there a reason why you wouldn't open 100 subscriptions on the same relay with one key each instead of a single subscription with 100 pubkeys?
See translation
2
0
0
0
0
Replies
hodlbod
@ hodlbod
5d ago
I just don't see why you would. Why wpuldn't you just use lisp and program everything using cons cells?
See translation
0
0
0
0
0
Mazin
@Mazin
5d ago
If you can build a performant client that connects to 400+ relays when trying to load your following feed I’ll build a nostr church in your name.
See translation
0
0
0
0
0
fiatjaf
@fiatjaf
5d ago
I don't want a church, I want an explanation on why you think that is so absurd. The amount of data you'll download is the same and will depend on how many people you follow and what you have cached locally. Each new TCP connection is cheap. What am I missing?
See translation
0
0
0
0
0
Mazin
@Mazin
5d ago
It’s not about data. There are browser, OS (open files), and mobile per-app limitations that prevent opening an unlimited amount of websockets. Even in a perfect nostr world with only reliable high performance relays you will start to bump in to these limits in most places as you exceed 200-300.
As we do not live in this perfect world, I suspect the practical challenges of managing hundreds of different connection and response times with varying reliability in a performant way with an acceptable UX will not be trivial either.
As we do not live in this perfect world, I suspect the practical challenges of managing hundreds of different connection and response times with varying reliability in a performant way with an acceptable UX will not be trivial either.
See translation
0
0
0
0
0
k.
@k.
5d ago
in case of cpu intensiveness, tcp connections are not that cheap i believe.
See translation
0
0
0
0
0
Zero
@Zero
5d ago
The point you’re missing is that these are pessimists who spend their energy trying to prove that nothing can be done.
See translation
0
0
0
0
0