Relay Type Nomenclature #1282
Comments
|
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. |
|
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). |
|
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 |
|
Both Discovery and Index are good words. Maybe Discovery is too generic. |
|
Some thoughts: 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'. |
|
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... |
|
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. |
vitorpamplona
changed the title
|
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. |
|
For the |
|
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. |
|
Here's an attempted re-wording for "Public Inbox Relays" 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: General Relays: |
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.
That is only a fallback for everything else in Clients that are migrating from Kind3 relay lists. |
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.
|
|
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. |
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? |
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.
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.
The app probably won't work very well at this point. Many sections of the app still rely on Kind 3 lists.
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. |
|
So far I think this classification is pretty good. I think we are missing Bridges to other networks like the ones built by @alexgleason. |
|
Hey @nostr-wine, is filter.nostr.wine a proxy or just a broadcaster? |
|
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. |
|
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. |
|
A relay that would have several functionalities. How would it identify these functionalities to the client? I think it would be impractical to rely solely on the user to enter the address in the correct option. In NIP-11, it would be possible to identify the types supported by the relay. From the relay's point of view, would it be interesting for each type to have a different URI? Something like:
|
For the sake of sales, marketing, and user experience, I would break it into many products, one for each thing. Even if all of them just map it back to one main server. The goal is just to simplify the life for users who have to choose their providers for each category.
Later on, it will be nice to have a new event kind to declare the relay service to the network with tags for each service type. Then apps just need to pull all self-declarations, filter by tag and offer those to the users. |
|
Would a dedicated relay for NIP-78 be classified as "Private Storage" or "Blob Relays"? Would a specific classification for this NIP make sense? |
NIP 78 is use-case-agnostic, which means it's impossible to categorize. I'm not sure what to do about that. |
|
What if NIP-78 is for both? I don't know how confusing it would be for users if a nip could be in more than one type of relay. |
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 Add closed communities #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?
The text was updated successfully, but these errors were encountered: