[NIP-65](https://github.com/nostr-protocol/nips/blob/master/65.md) will contain great advice on which relays to consult for which purposes. This post does not supersede NIP-65. NIP-65 may be getting some smallish changes, mostly the addition of a private inbox for DMs, but also changes to whether you should read or write to just some or all of a set of relays.

### How often to fetch kind-10002 relay lists for someone

This is up to you. Refreshing them every hour seems reasonable to me. Keeping track of when you last checked so you can check again every hour is a good idea.

### Where to fetch events from

If your user follows another user (call them jack), then you should fetch jack's events from jack's OUTBOX relays. I think it's a good idea to use 2 of those relays. If one of those choices fails (errors), then keep trying until you get 2 of them that worked. This gives some redundancy in case one of them is censoring. You can bump that number up to 3 or 4, but more than that is probably just wasting bandwidth.

To find events tagging your user, look in your user's INBOX relays for those. In this case, look into *all* of them because some clients will only write to *some* of them (even though that is no longer advised).

### Picking relays dynamically

Since your user follows many other users, it is very useful to find a small subset of all of their OUTBOX relays that cover everybody followed. I wrote some code to do this as (it is used by gossip) that you can look at for [an example](https://github.com/mikedilger/gossip-relay-picker).

### Where to post events to

Post all events (except DMs) to *all* of your users OUTBOX relays. Also post the events to *all* the INBOX relays of anybody that was tagged or mentioned in the contents in a nostr bech32 link (if desired). That way all these mentioned people are aware of the reply (or quote or repost).

DMs should be posted only to INBOX relays (in the future, to PRIVATE INBOX relays). You should post it to your own INBOX relays also, because you'll want a record of the conversation. In this way, you can see all your DMs inbound and outbound at your INBOX relay.

### Where to publish your user's kind-10002 event to

This event was designed to be small and not require moderation, plus it is replaceable so there is only one per user. For this reason, at the moment, just spread it around to lots of relays especially the most popular relays.

For example, the gossip client automatically determines which relays to publish to based on whether they seem to be working (several hundred) and does so in batches of 10.

### How to find replies

If all clients used the gossip model, you could find all the replies to any post in the author's INBOX relays for any event with an 'e' tag tagging the event you want replies to... because gossip model clients will publish them there.

But given the non-gossip-model clients, you should also look where the event was seen and look on those relays too.

### Clobbering issues

Please read your users kind 10002 event before clobbering it. You should look many places to make sure you didn't miss the newest one.

If the old relay list had tags you don't understand (e.g. neither "read" nor "write"), then preserve them.

### How users should pick relays

Today, nostr relays are not uniform. They have all kinds of different rule-sets and purposes. We severely lack a way to advice non-technical users as to which relays make good OUTBOX relays and which ones make good INBOX relays. But you are a dev, you can figure that out pretty well. For example, INBOX relays must accept notes from *anyone* meaning they can't be paid-subscription relays.

### Bandwidth isn't a big issue

The outbox model doesn't require excessive bandwidth when done right. You shouldn't be downloading the same note many times... only 2-4 times depending on the level of redundancy your user wants.

Downloading 1000 events from 100 relays is in theory the same amount of data as downloading 1000 events from 1 relay.

But in practice, due to redundancy concerns, you will end up downloading 2000-3000 events from those 100 relays instead of just the 1000 you would in a single relay situation. Remember, per person followed, you will only ask for their events from 2-4 relays, not from all 100 relays!!!

Also in practice, the cost of opening and maintaining 100 network connections is more than the cost of opening and maintaining just 1. But this isn't usually a big deal unless...

### Crypto overhead on Low-Power Clients

Verifying Schnorr signatures in the secp256k1 cryptosystem is not cheap. Setting up SSL key exchange is not cheap either. But most clients will do a lot more event signature validations than they will SSL setups.

For this reason, connecting to 50-100 relays is NOT hugely expensive for clients that are already verifying event signatures, as the number of events far surpasses the number of relay connections.

But for low-power clients that can't do event signature verification, there is a case for them not doing a lot of SSL setups either. Those clients would benefit from a different architecture, where half of the client was on a more powerful machine acting as a proxy for the low-power half of the client. These halves need to trust each other, so perhaps this isn't a good architecture for a business relationship, but I don't know what else to say about the low-power client situation.

### Unsafe relays

Some people complain that the outbox model directs their client to relays that their user has not approved. I don't think it is a big deal, as such users can use VPNs or Tor if they need privacy. But for such users that still have concerns, they may wish to use clients that give them control over this. As a client developer you can choose whether to offer this feature or not.

The gossip client allows users to require whitelisting for connecting to new relays and for AUTHing to relays.

## See Also

[The Gossip Model: Outstanding Issues](https://habla.news/u/mike@mikedilger.com/gossip-model-outstanding-issues)

Me during zapathon today https://video.nostr.build/13efe9b49c612905185fca47564ecfe809261b4df193e6d6db2c67afb8b8df8b.mp4

https://github.com/nostr-protocol/nips/blob/master/13.md

https://video.nostr.build/5d301f3b30bdf4f971979d67dcc4ecbbacf9f2cd777dc046687ea620e477d16c.mp4