shuffle new relays #41
Conversation
There was a problem hiding this comment.
Thanks for the contribution!!
However, I can't entirely agree with parts of these changes. Here are the reasons
- This requires a level of interaction from the user. This means it's going to be harder to auto-provision the server
- There should be a strong preference for a set of nostr nodes that work well.
I think the best course of action here is for the user to be able to provide the node they want to connect to. And in the read me we can have a example start command that uses the nostr.watch API.
Lmk what you think
|
I made this available via argument parsing:
I don't know if exiting right after running the --show command is good, maybe I should just let the --add option and the user has to find new relays by himself. |
src/utils/nostr_utils.py
Outdated
| def add_relays(): | ||
| def show_relays(): | ||
| r = (requests.get(NOSTR_WATCH, {})).json() | ||
| new_relays = [x for x in r[:20] if 'damus' not in x and 'nostr-pub.wellorder' not in x] |
There was a problem hiding this comment.
Why not show damus and the nostr-pub.wellorder
There was a problem hiding this comment.
Is that just to skip protocol portion of the url?
There was a problem hiding this comment.
- First question: that’s because I’ve let the original relays in the NOSTR_RELAY global list, so I’m excluding them here to avoid potential duplicates
- Second question: sorry for the magic number, should be corrected, that’s an arbitrary number bc the list of active relays is quite long, originally I was asking the user if he wanted to reshuffle so that it shows 20 other relays and so on
The relay selection could be improved based on relay location or other informations
There was a problem hiding this comment.
Would this make the service dependent on Nostr Watch? If that service goes down would that be a single point of failure? We may be able to achieve the same thing with an async websocket relay pool unless there are other advantages to using Nostr Watch.
There was a problem hiding this comment.
Yeah the show option relies on the nostr_watch API , the advantage to me is that it's dynamically updated which could be desirable given how relays are prone to instability.
Moreover it seems pretty canonical.
If by websocket relay pool you mean a statically maintained pool, it could lead to extra continuous work to maintain if but if you know how to get relays that are online and dynamically update the pool, it would indeed be a better idea. I could peep the nostr_watch repo to see how they get the relays under the hood.
Lmk what you think
Added a function to use more active relays via the nostr watch API