Replying to Avatar Cyph3rp9nk

Tips for Relays.

Forget about having a thousand and one relays.

The first option is to pay for nostr.wine, it allows you to use the filter.nostr.wine filter. The filter works both requesting events from other relays and sending events to other relays. In case you want to send events to other relays you have to add the relay with the following syntax:

wss://filter.nostr.wine/REPLACE_WITH_YOUR_NPUB?broadcast=true

Reading list:

wss://relay.damus.io

wss://nos.lol

wss://relay.current.fyi

wss://brb.io

wss://nostr.oxtr.dev

wss://relay.nostr.bg

wss://no.str.cr

wss://nostr.mom

wss://nostr.zebedee.cloud

wss://relay.plebstr.com

wss://offchain.pub

Writing list:

wss://relay.damus.io

wss://nos.lol

wss://relay.snort.social

wss://nostr.oxtr.dev

wss://relay.nostr.bg

wss://nostr.fmt.wiz.biz

wss://nostr.mom

wss://nostr.zebedee.cloud

wss://no.str.cr

wss://relay.plebstr.com

wss://offchain.pub

The next special relay is relay.nostr.band. This relay reads events from all relays and applies a spam filter, in the case of writing you only write to relay.nostr.band but it is a good complement to add content to relay filter.nostr.wine as it only requests events from your contacts and your contacts' contacts. It is not clear to me from which relay is requesting the events as the code is not available.

And finally the relay nostr.mutinywallet.com. This relay uses blastr which is a nostr cloudfare worker proxy that publishes to all known relays. Basically what it does is to read the list of online relays from nostr.watch and all events are queued to be executed in batches by another worker that rotates every 30s if there is an event queued, or once a certain amount of events are queued. In this case the relay is write-only.

In short, your relays could be reduced to 4:

wss://nostr.wine

wss://filter.nostr.wine/REPLACE_WITH_YOUR_NPUB?broadcast=true

wss://relay.nostr.band

wss://nostr.mutinywallet.com

With them you save bandwidth and battery, actually filter.nostr.wine in write mode and nostr.mutinywallet are redundant, but I put the two because nostr.mutinywallet.com has more amplitude because it publishes in all the online relays of nostr.watch and also because it has high availability in case of failure of any of the two relays mentioned above.

The same case is applicable in the case of reading for filter.nostr.wine and relay.nostr.band.

If I only download from nostr band, I'm missing a bunch of notes in the feed. So this isn't a standalone download proxy?

Reply to this note

Please Login to reply.

Discussion

As I explained to a colleague I am not sure from which relays relay.nostr.band collects the information, its author says from all of them but I cannot verify it.

In my case the combination of relay.nostr.band together with filter.nostr.wine gives me practically all the followers.

At the moment I don't know any relay that allows the reading of "all" in the same way that nostr.mutinywallet.como does with the writing. In this case if I have been able to verify its code and what it does is to read the api of nostr.watch of relays online and to write in all of them.

When reply to an event is posted most clients include the source relay in the reply (relay of event to which you're replying). So by reading from one relay you eventually learn about other relays, when users interact with them. That's what my server does. As soon as it discovers a new relay it starts reading from it and expands it's network. Right now the number of active relays I read from is 1126 (at the bottom of https://stats.nostr.band/).

But, it doesn't mean that I will _serve_ all events from all relays to clients. 70% of all events published on big public relays is spam, which I filter. Sometimes there might be false-positives. So it's probably not about 'which relays I'm reading from', but 'was that event spam filtered'.

#[3]​

I forgot this detail, relay.nostr.band seems to have a limit in the contact query, that's why I use it as a complement of filter.nostr.wine, however it seems to read all the events.

Not sure what limit you mean. All relays limit the number of evens they could return in 1 request, all clients know how to request the next batch to consume everything that relay has.

If I only attach your relay, my number of followers goes up to 1000 and it doesn't go beyond that, that's why I assumed that the query from your relay had some limit.

Which client are you using?

Damus, but it only affects the follower count, I have been able to verify that if it serves events of all the followers.

Well I guess Damus doesn't bother paging through followers atm and just hopes most people have lowish number that fits relays' per-request limits.

Your data is correct, so it seems to be a problem with Damus.

Can I get data on which relays are using your relay to read?

I read from all relays. I don't know who reads from me. Whoever wants to?

Most relays don't read from anyone, they just accept events from clients. Maybe nostr.wine reads from many relays, maybe there are others - I don't know.

Perhaps I have expressed myself badly.

For example nostr.mutinywallet.com reads the nostr.watch api and writes to all relays marked as online.

In the case of filter.nostr.win the list is small, they are the ones indicated in the main post.

In the case of nostr.band I don't know where it gets the data from, i.e. which list of relays.

My relay has 1234 followers of yours, maybe your client doesn't know how to fetch them properly.