Replying to Avatar Derek Ross

We've had a lot of talk about relays over the past day here on Nostr. This may be a bit confusing if you're new to Nostr.

What's going on with this discussion and why are many people making comments, jokes, or memes about relays?

The argument boils down to centralization and decentralization. On Nostr, we decentralize our infrastructure by using a potential wide variety of servers. Many of us are reading this note right now that's been retrieved from a variety of servers or as we call them, relays. Some relays are more popular than others. This leads to the questions surrounding decentralization. If many users are only using a top subset of relays, then we're not as decentralized as we could be or maybe even as decentralized as we should be.

I have various opinions on this subject. Even if Nostriches mostly only use ten relays, we're still magnitudes better than any existing social platform where only one entity runs the server infrastructure. We can do better though and we should do better. We have the tools to and the capabilities to make Nostr even more decentralized.

Now, this gets us into the next discussion. Which method of decentralization is best? For that, again, in my opinion, I'm a fan of the Gossip model. Simple put, Gossip makes relay selection not overly matter all that much. You can use any relay that you'd like and your follower's clients essentially fetch the notes and events from the relays that are being used without the need to be utilizing the same relay for communication to flow.

What should you do? Nothing, IMO. Relay selection and discovery aren't that great on most clients. I'd say keep using the same relays that you're using for now. Maybe, at some point, you'll update your relays to use smaller, community relays. For now, this is a developer problem to solve. You just keep creating notes and sending zaps. It will all work out in the end. Our developers LOVE to have problems to solve. Pura vida!

This is the correct answer. Relay selection isn't table stakes for new users. Use what your client recommends.

Eventually you may want better privacy or an archive of your notes, at which pount hand-selecting specific relays or self-hosting becomes relevant.

The key piece of advice for newcomers is: try to stay at 3-5 relay selections. More is not better!

Reply to this note

Please Login to reply.

Discussion

Agree. I use a few specific types of relays. I think this will be the norm going forward.

True to your word with three relays 👍

Does that work with any three or do these have special powers? Aggregating from other relays etc?

Pyramid only allows cool people to write to it (this supports global, and stores my notes)

hodlbod.nostr1.com is my personal relay (hosted on relay.tools, basically redundant with pyramid, but I control it, sort of)

purplepag.es is an index of pubkeys to profiles and relay selections (allows me to find notes by any pubkey that has published a relay selection)

It's really quite elegant

one day it will be trivial to start and run your own relay. then we'll be properly decentralized.

It's already not too hard if you have an umbrel or start9, or if you don't mind the compromises involved with something like relay.tools

Umbrel or Start9 make it super easy to setup, but people still need to use some sort of VPN or Tailacale to access their relay when outside of their home network. I have never used relay.tools, but I did use play around with relayable a bit when it first launched. It's definitely a nice solution for the average person to use.

We will need a better way to advise users on which relays they can pick from... maybe by testing if they are suitable and saying "pick again" if nothing else. Because relays are not at all uniform anymore, and most don't work as good inboxes (for example).

nostr:npub1uac67zc9er54ln0kl6e4qp2y6ta3enfcg7ywnayshvlw9r5w6ehsqq99rx and NIP-66 might provide some valuable information to give sane information here

How is migration supposed to work? The client just download the entire user history of events and rebroadcast them?

I did that kinda manually. There should be tools for that.

Just did a migration. Set it up in about 2 minutes with https://github.com/sandwichfarm/nostrawl/

one thing Nostr can't have without reinventing merkle trees with events (which be awfully inefficient): verifying that migration was pr wasn't complete.

Totally. If someone changes their relay list, outbox doesn't know it existed. In a perfect world, NIP-65 would also store timestamps for when a relay was added. When removing the relay, clients user events from that timestamp. Or otherwise, relays are not "removed" from NIP-65 lists, but marked inactive and marked with a timestamp indicating when the user left.

pre-coffee notes are imperfect.

post-coffee

*clients would sync events from that timestamp to other relays.

*but marked inactive with a timestamp indicating when the user left.

Not a bad idea