A project to help folks discover relays
1403 sats \ 5 comments \ @gregory 3 Aug 2023 nostr
I wanted to share a project I've been working on in my spare time: relay.guideThe goal is to help people discover relays to join. Right now it can help find relays by:
Paid / free
Name or keyword (weedstr, damus, etc)
By the recommended relays of people you follow or like. (relay.guide/relay-lists)
You can also look at each relay's metadata. I also added a tool that may be useful to devs to be able to query the events on that relay by kind or author pubkey, etc (relay.guide/inspector) I tried to make it easy to copy relay info so you can update your relays if you find an interesting relay through this. It's similar to nostr.watch but I'm hoping to add some novel capabilities soon:
Discovering relays by the relay lists of others
Discover by relay community preferences and/or language tags (most don't publish this yet, but I'm going to reach out to folks and advocate for it)
Add the ability to manage your relay list from this app (auth with Alby or similar and add / remove relays right from the discovery tools)
The code is open source so feel free to log issues or make suggestions or contribute! github.com/gregorygmwhite/nostr-relay-explorer
Feedback welcome!
write
preview
related posts
0 sats \ 0 replies \ @lsp 11 Aug 2023
You could potentially add a feature for users to rate or vote that would show the relays proven to be solid and stable
reply
0 sats \ 1 reply \ @nym 3 Aug 2023
Potential Issues:
  • In the file backend/explorer/validators/urls.py, the validate_url function might raise an exception if the URL is not valid. It would be good to handle this exception gracefully.
  • In the file backend/explorer/tasks/update_metadata.py, the update_metadata function makes an HTTP request without handling potential exceptions that might occur during the request. It might be beneficial to add error handling here.
  • In the file backend/nostr_relay_explorer/settings.py, sensitive information like secret keys and database credentials might be exposed. It's recommended to use environment variables or a separate configuration file to store such information securely.
reply
0 sats \ 0 replies \ @gregory OP 3 Aug 2023
  1. Fair! But I think that it'll raise a HTTP 400 error which is exactly the error to send to the frontend to handle. It even tells the frontend which field needs to be fixed and the specific error on that field. Django does some great work here.
  2. Agreed it could use some more robust error handling, but the several places that call update_metadata do have try except blocks around them to process any errors and re-raise if appropriate.
  3. Totally, I am using env variables the defaults there are just the values that are used in development (they match how the db is set up via docker-compose). The only one I see that's set that could be an issue is the Django Secret Key, which is only important for encrypted fields which I don't think there are any in this data model.
I'll definitely be making improvements but thanks for taking the time to look through it!
reply
0 sats \ 1 reply \ @OriginalSize 3 Aug 2023
Relay discovery and choice is an understudied part of how Nostr works. If you want anything like a global, one-world view you want a diverse set of relays that overlaps with the greatest number of users. NIP support and reliability are other qualities I like to consider. Good luck with the project!
Are you thinking others will want to run this or do you envision a main website that runs this as a community project?
reply
0 sats \ 0 replies \ @gregory OP 3 Aug 2023
I think that it can go either way, but for now I think a main site where people can add features to it if they like. I'm planning to do a majority of the work until people find it useful enough they want it improved faster than I can do it.
I agree with you, relays are something we need more focus on as we scale. Can't wait to be of use!
reply