Dear devs,

I think how clients set the default relays is a very important key topic to ensure future decentralization of the nostr protocol. The non-tech masses won't care about relays, they just want it to work. Max performance/connectivity and max decentralization are not the same route. We have to find the right balance.

We should develop a best pratice how to set default relays on clients.

Some form of randomness is vital to not fall for the centralization trap. It should be combined with some important metrics (eg traffic, reputation, ping, uptime, location ...). Defining these metrics and combine it with randomness is the key from my perspective.

Example for 12 default relays:

1. Connect to random ~3 relays with high user count, reputation score > 90 and uptime >99

2. Connect to random ~4 relay with mid user count, reputation score > 80, ping < 500 and uptime >95

3. Connect to random ~5 relays with low user count, reputation score > 70, ping < 100 and uptime >90

Let me know your thoughts on this.

Reply to this note

Please Login to reply.

Discussion

Relays we subscribe to could be based on who we follow… kinda easy to figure out the right balance that’s needed by analyzing relays someone’s following send to.

The relay list would end up being different from one user to another, keeping centralization to a minimum.

Thats great but not applicable for new users right, since they don’t have a following list yet, right?

The concept should also include the follower list, to make sure you reach your audience or is it included in the same list?

Of course, new users would have to bootstrap somehow in a more centralized way, I guess. Thing is, relay subscription could evolve in the background without the user noticing. Just making sure to keep in touch with the most people with the least possible amount of subscriptions.

I’d still keep a list of relays, so that the client can start quick, without needing to download a ton of profiles doing so.

I also see smart clients noticing a much needed relay becomes unstable or down, and replace it with another automatically.

As power users, it’s OK we can select relays in the current nostr state, but least technical people won’t want to tinker with this, or even know it exists.

Should just feel like magic. ✨

Yes agree. However, I think the option for manual management should still be there, just to endure censorship resistance. If you take the choice away of choosing your relays manually means that controlling your relays = controlling you. Even so most people won’t use it anyway. Or do I miss something?

Obviously yes... manual or automatic relay management can coexist.

Great thoughts! Thank you 🙏

They must, in fact, if a non-technical user wants to make sure it's connected to a private relay.

*to ensure

Sounds like the perfect solution to me 🤙

Plenty of heuristics to look at, such as ping, uptime, message redundancy. It depends on where the accounts you follow are writing to. It's possible to transiently connect to relays too, where they have been hinted at in protocol messages

There are different kinds of clients. One kind connects to a community relay (or more than one) and operates like IRC, and hears people only on those relays. The other kind (my kind) operates like a web browser, and if a webpage references a resource at a web server, it goes and gets it, without the user having to setup a list of approved webservers from which to fetch resources.

Gossip has write relays - that is where you post and I think users *should* manage them. Gossip doesn't have "read" relays. It finds people and events wherever they are, and uses a lot of things to do this (but not randomness) including kind2, kind3, kind10001, nip05, nip23, p and e tag hints, previous success with that pubkey at that relay, and also relay statistics (number of successes versus number of failues, hangups, etc).

When you first get started with gossip it often gets stuck and can't find anything. There is a good argument to be made to have "read" relays to get past this point, and I will probably have to do that.

I could have a list of approved relays to read from to give the user a sense of more control. But then I would have popups saying "This event/person was not found, but I have reason to believe they are on this other relay XYZ. Do you want me to fetch them from there?" IMHO everybody will press 'yes' when presented with that question, so I don't see the point of asking.