Relay Type Nomenclature

[vitorpamplona]

We need to find good labels for each relay type. Apps need to request users to put a relay of a given type in certain fields and relays need help to advertise which type they are made for.

The final goal is to have apps asking for "x" and relays that can provide that service advertise themselves as "x" as well

• Public Home (Outbox) Relays: Relays that store all the public content of a user in a way that anyone out there can download them. This is a requirement to find posts on NIP-65 clients.

• Public Inbox Relays: Relays that accept any event from anyone as long as they tag one of the subscribers or the public in general. These relays are where your client looks for replies, comments, likes and zaps on your posts. They can be paid or free relays. Limits set by the relay operator can limit the notifications you receive for the good and for the bad. For example, if you are being attacked by comment spam, using paid relays that can filter the spam out can be useful. Make sure anyone can download these events.

• Private Inbox: Relays that accept any event from anyone as long as they tag one of the subscribers or the public in general, however only the tagged individual can download their tagged events. In general, the public cannot download events. Great for DMs and RPC-like calls: NSec Bunker, Nostr Wallet Connect and DVM relays.

• Private Storage: Relays that accept events from an author and make sure only the author can download them. This is great for Private Drafts or other private content the author is not sharing with anyone, like settings private pet names, follow lists, etc.

• Search Relays: Relays that implement NIP-50 and can help find content.

• Index Relay: Relays that only track kind 0 and kind 10002 to help find people and distribute content.

• Community Manager Relays: Relays whose read or write access is closed to members of a NIP-29 group or NIP-71 community with https://github.com/nostr-protocol/nips/pull/875. They can also offer tools to manage NIP-28 Public Chats.

• Archival Relays: Relays that serve as archival nodes for the network.

• Local Cache Relays: Private Storage relays that take priority given their closer proximity (in ping latency) to the Client.

• Blob Relays: Storage relays for NIP-95 content and other types of binary content.

• Broadcast Relays: Re-broadcast content to other relays (Blastr)

• Proxy Relays: Aggregator proxy that connects to multiple relays while sustaining only one connection to the Client (bostr).

• Trusted Relays: Relays that store events that are not verifiable (like Decrypted NIP-17 DMs). These are usually local or have strong authentication procedures to write.

• Push Notifications Relays: Ephemeral relays that Push to the receiver any event received by them. These relays are not queryable

Are there any other relay types out there?

Type	Who can Download	Who can Upload	Usage on
Public Home	Everyone	Authors	All NIPs
Public Inbox	Everyone	Everyone (or white-listed p-tags)	All NIPs
Private Storage	Authors	Authors	#1124
Private Inbox	p-Tagged Users	Everyone (or white-listed p-tags)	17, 46, 47, 90, 04
Search	Everyone (or white-listed users)	Nobody (generally read-only)	50
Index	Everyone (or white-listed users)	Nobody (generally read-only)	01, 65
Community Manager	Members or Everyone	Members	28, 29, 71
Archival	Everyone (or white-listed users)	Nobody (generally read-only)
Local Cache	Limited by device/network	Limited by device/network	All NIPs
Blob Relays	Everyone (or white-listed users)	Everyone (or white-listed users)	#345
Broadcast	No one	Everyone (or white-listed users)	All NIPs
Proxy	Everyone (or white-listed users)	Everyone (or white-listed users)	All NIPs
Trusted	Trusted Parties	Trusted Parties	17
Push	Nobody	Everybody	All Nips

[mikedilger]

I had not thought of all of those since half of those are not things I intend to support. But this list makes sense.

I was calling purple page relays "Discovery" relays, but they should serve the 10050 kind now too.

[lingmann]

Should there be a call-out for "caching" style relays similar to what Nostrudel is doing with nostr-rs-relay or nostr-relay-tray? If I'm understanding the distinctions above, the closest would be "Community" or "Local Database Relays".

I could see this becoming a pattern where one or more users run a local high-performance cache relay which they connect up to multiple clients, but only whitelisted users can read and write events (NIP-42 style or perhaps IP restricted, but any event is accepted).

[staab]

That list seems pretty complete to me, I agree it would be great to have all this as a first-class thing. For the "purple pages" relays, I prefer to call those "indexers", because they're basically a key-value store of pubkey -> profile/relays. In addition to kind 0 and 10002, they should probably include the blossom server selections document, as well as any other kinds that come out of this discussion intended to track relay selections. It might also be useful to include nip 89 handlers and lists, although that's probably overkill if you know the pubkey's relay selections. But if that seems useful, it could be worthwhile to add some sort of indexed_kinds key to NIP 11.

[vitorpamplona]

Both Discovery and Index are good words. Maybe Discovery is too generic.

[jeremyd]

Some thoughts: I am tempted to describe these as relay features or usages, not 'types' as a relay can function as more than one of these categories.. As you start configuring relays to do certain things you realize "there is no relay types". There are only usages from a client's perspective.

I also think clients should be able to understand more about a relay's capability before attempting to use the outbox model. For example, I want to use mostly paid relays. I know that most of my friends use the WINE relay and even though the description for "public inbox" says anyone should be able to write, this is un-true as I know a majority of the replies I want to see will come from WINE. I may want to filter this further showing only replies from paid relays vs. replies from free relays (spam).

I think there may need to be levels of granularity, and also usage. I have always thought the amethyst config screen is nice because each icon next to a relay entry represents a usage and you can toggle them on or off. Perhaps something more along these lines would make sense instead of categorization by 'type'.

[jeremyd]

So to summarize, I would potentially do it more like gossip's relay config, where for each relay you configure it's usages and ALSO it's rank. Then I would have the client be able to filter by rank...

[vitorpamplona]

Features work for us but not for users. We need to be able to say: "Find a relay that is made for Private Inbox and put the URL here". Then they need to search for relays that can do "Private Inbox". And from there they can evaluate the other details the relay providers, but there must be a way to reduce the options down.

[frbitten]

I imagine another type of relay or service for relays that I don't think is described in any NIP yet.

A relay that suggests events based on my preferences. It would be a relay for feed suggestions. Today, clients basically download everything from all relays, generating a lot of noise from irrelevant posts.

I believe that a relay that suggests events based on my preferences would bring NOSTR closer to the interactivity of large social networks and would also be a good weapon against spam and unwanted topics.

The competition between relays to provide a better service could evolve this functionality quickly.

[Yonle]

For the Proxy, Uploading is Everyone (or white-listed users) as it also does rebroadcasting events to other relays.

[dskvr]

Would be very interested in this for #230. The atomization of relays could also be expressed in NIP-11.

Note: Index Relays also often store Kind 3 events.

More generally, there are other types of Index Relays that store only specific kinds. So maybe this needs to be generalized more.

[jeremyd]

Here's an attempted re-wording for "Public Inbox Relays"

These relays are where your client looks for replies, comments, likes and zaps on your posts.  These relays can be paid or free relays, keep this in mind as it can limit the notifications you receive if the relay limits access.  For example if you are being attacked by comment spam, using paid relays here can be useful.

As a side note in relation to this above, I think it would be extremely useful to have filters on these notifications, similar to how there is a filter in amethyst for notifications "from follows" and "global". Relays could have a rank, and you could filter by rank. IE: set your paid relays as rank 1, and free relays rank 2. Then you can filter just for rank 1, and later if you want more notifications and your attackers go away, you can expand to ranks 1 and 2.

Another attempted re-wording for DM Inbox Relays:

Insert between 1-3 relays to serve as your private inbox.  Others will use these relays to send DMs to you.  If you want to receive DMs from the open network then these relays must accept messages from anyone.  However if you only want verified, paid, or WoT users to be able to send you DMs then these relays can limit access to only these users.
Good options are: ...

General Relays: I'd like to see this description expanded to what amethyst uses these for. I'm unclear exactly when they come into play.

[vitorpamplona]

Then you can filter just for rank 1, and later if you want more notifications and your attackers go away, you can expand to ranks 1 and 2.

Interesting idea.

I changed the description for public inbox.

The private inbox however, can't do what you describe. The author of NIP-17 DMs is random. The relay choice cannot protect users against spam in DM (or gift wraps in general). The client must take that responsibility.

General Relays

That is only a fallback for everything else in Clients that are migrating from Kind3 relay lists.

[jeremyd]

Then you can filter just for rank 1, and later if you want more notifications and your attackers go away, you can expand to ranks 1 and 2.

Interesting idea.

I changed the description for public inbox.

The private inbox however, can't do what you describe. The author of NIP-17 DMs is random. The relay choice cannot protect users against spam in DM (or gift wraps in general). The client must take that responsibility.

The author of the event is random yes. However, with NIP42 auth, the authenticating user does not have to be random (IE, you're not doing an auth request with the random newly generated key are you?). Using AUTH means, if the relay has an ACL and NIP42-AUTH enabled, the client can establish the connection with this and publish with as many other keys as they like. This will cut back on un-solicited DMs as scammers will not be on the ACL as frequently as on a wide open relay.

General Relays

That is only a fallback for everything else in Clients that are migrating from Kind3 relay lists.

[vitorpamplona]

Suggested two new relay lists for Proxy and Broadcasters (Publishers?) so that they don't end up mixed with other relay lists. https://github.com/nostr-protocol/nips/pull/1303

[jeremyd]

Suggested two new relay lists for Proxy and Broadcasters (Publishers?) so that they don't end up mixed with other relay lists. #1303

I think it'd be nice to have a relay type that is 'hidden' IE, not advertised in your relay list and still used by the client.

[jeremyd]

General Relays

That is only a fallback for everything else in Clients that are migrating from Kind3 relay lists.

Sorry to clog the thread, maybe this is off-topic. But, I still would like to know exactly what the list is used for. Is amethyst still publishing kind3 relay lists with this? Is that *all it is doing? Are these relays connected to when notes aren't found? What happens if I remove them all? Is the global icon going to be depricated? Will there be any way to selectively create a global feed in the new versions?

[vitorpamplona]

Is Amethyst still publishing kind3 relay lists with this?

Yes. Kind3 lists operate just like they were before NIP-65. Most new events will be sent to that list. The only ones that were already migrated are Drafts and NIP-17 DMs.

Are these relays connected to when notes aren't found?

They are still connected at all times. So they can bring in new chats, products or other events that might not be on the NIP-65 lists.

What happens if I remove them all?

The app probably won't work very well at this point. Many sections of the app still rely on Kind 3 lists.

Is the global icon going to be depricated? Will there be any way to selectively create a global feed in the new versions?

We are likely to migrate to NIP-51 Relay sets (30002) for Global. Users will switch between relay lists from the Top bar when browsing global.

This might take a while though.

[cameri]

So far I think this classification is pretty good. I think we are missing Bridges to other networks like the ones built by @alexgleason.

[vitorpamplona]

Hey @nostr-wine, is filter.nostr.wine a proxy or just a broadcaster?

[nostr-wine]

Both! We read from and broadcast to a list of public relays. The broadcasting also uses NIP-65 to select relays in addition to our fixed list.

https://docs.nostr.wine/filter/readme

[jeremyd]

This list is looking great. I would like to use these types as tags in the NIP11 (relay info via http) spec, and also in NIP66 (relay discovery via events). Once this is finalized can we have tag names as part of the standard. We could use the "Type" mentioned here with dashes instead of spaces.

[vitorpamplona]

This list is looking great. I would like to use these types as tags in the NIP11 (relay info via http) spec, and also in NIP66 (relay discovery via events). Once this is finalized can we have tag names as part of the standard. We could use the "Type" mentioned here with dashes instead of spaces.

Feel free to kickstart that. The list here will constantly change with new relay types. As long as we call the same thing between relays and clients, we should be good.