Add private relays to kind 10002 in NIP-65

[SilberWitch]

I'm having increasing difficulty switching from one client, to another, as I have so many different types of relays in use, and only a few are useful for the outbox model. The rest are relays that I use in all/most clients, but that are only meant for some in-app purpose, such as search relays, local relays (ws://localhost:4869, for instance), filters or aggregators, read-restricted project group relays, etc.

I wasn't sure of the best way to fix this, without making it onerous to use multiple clients, but I thought a private flag would maybe help.

[SilberWitch]

@staab would this be a possibility, to solve for local relays?

[vitorpamplona]

Each relay type should be a different kind and added to the NIP that uses them. Clients that implement that NIP would then use the list as you migrate from one to another. Gathering all of them under one private label is not that helpful because it doesn't inform where this relay should be used.

For instance,

1. Search relays are defined by 10007 on NIP-51.
2. DM relays use kind 10050 as per NIP-17
3. Public chat relays are defined in the metadata event on each chat on NIP-28
4. Private Storage relays use 10013 as defined by the Drafts NIP
5. Proxy and Broadcasting relays should use kinds 10017 and 10018 as per Adds Proxy and Broadcasting relay lists. #1303
6. Local relays should use kind 30006 as per Local Relay list #1272

I would see which relays you have that and not being migrated over to the new client and see which client is not implementing it.

[SilberWitch]

I agree that we need the categorization. Also, just so that we can finally have relay catalogs with useful, standardized categories. People keep asking me which relay to use for what, and that's information that should come from the relay operator.

[vitorpamplona]

Yeah, there is some of that work here as well: #1282

However, most relays operators are trying make their relay fit everywhere, which is not really that helpful for users. Yeah, software can be abstracted so that any relay can be used everywhere, but humans need labels to know which ones go where.

[SilberWitch]

My problem is that I switch clients a lot, both testing and because I use a lot of OtherStuff clients. They all pull this list, to know where to read and write from, so I need to make sure that all of the necessary relays are on the list, but they all need a subset of the relays, not the whole list.

So, I'll set everything up in Nostrudel with the differentiation between in-app and mailbox relays, and it looks fine. Then I switch to Coracle or Nostter, and they pull the mailbox relays, but are missing the in-app ones. So, I manually add them in. But then I go back to Nostrudel, and find out that I now have 16 mailboxes, instead of the previous 2. So, I change it again. Then I switch back...

I don't know how to tell the apps "don't use these relays as mailboxes, but just use them in the app".

[SilberWitch]

The only apps that let me categorize are Nostrudel and Amethyst. Everything else has only one list, so I have to put everything on that list, and then it updates my 10002 relay list with stuff like localhost and purplepag.es.

[vitorpamplona]

Looks like a post for https://github.com/nostrability/nostrability, @alltheseas

Apps should not put everything on kind 10002

[alltheseas]

This is a great example of imperfect, incomplete, and/or partially implemented NIPs unintended consequences/poor user experience, and a great fit for nostrability repo. Added and linked an issue.

[staab]

@vitorpamplona is right, different lists are the right way to handle this. For the record, coracle does support kind 10002 and 10050 separately, you enable/disable them using the buttons on the relay selection screen. More refinement coming soon.

[SilberWitch]

Okay, then I can close this PR, if @alltheseas is tracking it in his repo.

That alleviates the tension, thanks. Then I'll wait on more refinement possibilities. 👍🏼