NIP-51: Adds user's preferred Index, Proxy, Broadcasting and Trusted relay lists

[vitorpamplona]

Amethyst will be using these lists in our outbox implementation

[staab]

Looks great with some nitpicks

• I think index relays probably only need 10002, since profiles can be found on a user's outbox relays. Right?
• I assume proxy/broadcast relays will mostly get the outbox model right, but what about other use cases like NIP 72 or 29? Or write-protected relays, which the proxy isn't allowed to write to? Proxies can only work for specific use cases, so we should define what use cases they should actually be used for.

[fiatjaf]

• I don't get "broadcast". Isn't "broadcast" the same as "write" from kind:10002?
• How do you use "trusted"? If a user has a list of trusted relays that means an app won't try to connect to any other?

[vitorpamplona]

I think index relays probably only need 10002, since profiles can be found on a user's outbox relays. Right?

Yes, but in case it cannot be found there, the Indexer list serves as the user's preferred backup. Amethyst will also send any change to the kind 0 or 10002 to this list as well.

I assume proxy/broadcast relays will mostly get the outbox model right, but what about other use cases like NIP 72 or 29

The goal of the proxy is to be an aggregator in such a way that the app only connects with one relay. That would include NIP-72 and 29 relays. The broadcast relay should do a special treatment for NIP-72 and NIP-29.

I don't get "broadcast". Isn't "broadcast" the same as "write" from kind:10002?

Broadcast relays take the responsibility from the client to figure out which relays should get a given event. The client only sends to that relay and it should send to the appropriate locations.

How do you use "trusted"? If a user has a list of trusted relays that means an app won't try to connect to any other?

If a relay is trusted, we connect via the open web, if not via Tor. I accept better names for these.

[vitorpamplona]

My main goal here is to get people to remove these special relays from their kind 10002 records. People are putting purplepages as an outbox, makes all followers do REQs that that relay simply cannot handle. Same for proxy/broadcasting relays.

[staab]

The goal of the proxy is to be an aggregator in such a way that the app only connects with one relay. That would include NIP-72 and 29 relays.

This is impossible, NIP 42 was specifically designed to prevent proxying AUTH. Also, relay selection can't be inferred from REQ filters for NIP 29 requests (and would be annoying to implement for NIP 72 as well). A wrapper protocol is necessary to allow for full-featured proxies. See https://github.com/coracle-social/multiplextr for one I created a while ago; I've seen other examples in the wild.

[vitorpamplona]

This is impossible

Yes, but only to those that require auth. NIP-72 doesn't. Most NIP-29 also don't. Maybe we need to specify which NIP-29 groups require auth on the NIP-29 follow list so that the app can go around the proxy in those cases?

General Proxy with auth is tricky. But having your own proxy relay that has access to your nsec (via bunker or Amber) works quite well.

[staab]

Most NIP-29 also don't.

It doesn't matter if the server doesn't require auth, you can't select relays with a proxy, which is part of NIP 29.

My point is clients have to know what a proxy can and can't do so it knows when to use it. Either we define this in painful detail, or enumerate proxy types that clients can choose to use or not.

[fiatjaf]

Looks good to me, although I hope people don't overuse these broadcast and proxy things it's good to get them out of people's default lists.

[vitorpamplona]

It doesn't matter if the server doesn't require auth, you can't select relays with a proxy, which is part of NIP 29.

You don't select. The proxy is constantly downloading everything from all the NIP-29 relays that the user is interested on. For the app, the proxy is the NIP-29 relay.

My point is clients have to know what a proxy can and can't do so it knows when to use it. Either we define this in painful detail, or enumerate proxy types that clients can choose to use or not.

I don't think this is the point. It can be done, but I think it defeats the purpose of the proxy. If you just want to have a single server to route each filter to each separate relay, then you can just connect through SOCKS, like Tor does. That requires the client to know which relay to ask for what, and it handles auth directly.

[fiatjaf]

@staab no one should be using these proxies and we should do the best we can to make people stop using proxies.

In the meantime it's good to have a place to put them instead of people's default lists.

[vitorpamplona]

In the meantime it's good to have a place to put them instead of people's default lists.

Now that I have been using it for a while, I do think the proxy and broadcast lists are extremely important for seamless operations of an outbox client. The proxy should receive all the read relays from the old Kind 3 relay lists. And the broadcast list should receive all the write relays from the same list. In that way, an "outbox" client can function as an old list-based client if needed.

This means that kind 3 lists should NEVER be automatically migrated to NIP-65 lists as clients (specifically primal and snort) do today.

If I want to use Amethyst only with a NIP-29, I can just put my NIP-29 relays in the proxy/broadcast list, and the app will only use those.

[sondreb]

My feedback on the PR and comments above:

Naming: I suggest naming it "Discovery relays" instead of "Indexer relays". It's not indexed differently than any other type of relay and "Indexer" sounds more like it's supposed to be used for searching (NIP-50).

"Broadcast relays: Relays to send events to".

Broadcast relays take the responsibility from the client to figure out which relays should get a given event. The client only sends to that relay and it should send to the appropriate locations.

This increases ecosystem complexity and reduces decentralization. I would like to hear more about what potential benefits this brings that makes it valuable to implement support for? Is it not enough to have Nostr clients broadcast events to a specific user, by sending to all of their 10002 relays?

"Trusted relays | 10089 | Trusted relays that can see the user's IP"

I think it is a dangerous game to start building privacy into the Nostr protocol as it's not a privacy preserving protocol. Telling user's that these relays explicit can see the user's IP, might communicate that others are not supposed to see the IP? The IP of anyone using Nostr leaks very easily, I don't think it's advisable to give false impression of privacy.

Kinds for Discovery relays: 10002 and 3 (fallback). They should not store the profile. It should act as akin to a DNS lookup, where you get the IPs (relays) for the domain, and then you go to the servers to get the actual data (profiles).

Data should be kept on user's relays, that is where it will be maintained and not go stale.

My main goal here is to get people to remove these special relays from their kind 10002 records. People are putting purplepages as an outbox, makes all followers do REQs that that relay simply cannot handle. Same for proxy/broadcasting relays.

Does the Discovery (Indexer) relays have to be stored as events on relays? For Nostria, they are a client-specific relay that is discovered and probed for optimal performance. It will select a discovery relay that has lower latency for you.

Having a stored list of discovery relays on some relays, does not help with the initial login of existing accounts. The initial login needs to have the Nostr client make a decision on which discovery relay to query against. Also, I would rather want a seamless automatic change of discovery relays, than having it be a manual management. Agree it's a good idea to keep out of the 10002 list, but I probably won't use kind 10086 as that doesn't bring any value in my view. Would like to hear more why it makes sense to keep this as events and not an app specific implementation.

Nostria will host multiple discovery relays in different global regions, and they will be synced together. If we could pool together and have multiple discovery relays hosted, all with sync between them, we would have a reliable means of account discovery.

[vitorpamplona]

"Discovery relays" instead of "Indexer relays"

Neither name is good. The discover relay is not really discovering anything. But I can change.

This increases ecosystem complexity and reduces decentralization. Is it not enough to have Nostr clients broadcast events to a specific user, by sending to all of their 10002 relays?

Not really. Most people edit their relay lists to be the places they want their posts at, as opposed to the places their followers are supposed to go to download their posts. These are different needs. If they are instructed to place the relays they want their info broadcasted to in a separate list that what the followers need, we actually reduce ecosystem complexity.

The IP of anyone using Nostr leaks very easily, I don't think it's advisable to give false impression of privacy.

We ship with an embed Tor. So, that promise can easily be achieved for clients supporting this list (Not everybody needs to support).

Kinds for Discovery relays: 10002 and 3 (fallback)

Kind 3 is not a fallback for kind 10002. Kind 3 relays is just a compilation of relays from the user's contacts. not where they want their posts to be at.

For Nostria, they are a client-specific relay that is discovered and probed for optimal performance. It will select a discovery relay that has lower latency for you.

That's fine. The list is there for those that want to override the app's default list because they don't trust those to not track them over time.