Currently designing a better relay management UX, and its a nightmare, send help!
I'm seeing references to "key package relays" in nostr:npub1whtn0s68y3cs98zysa4nxrfzss5g5snhndv35tk5m2sudsr7ltms48r3ec and nostr:npub1h0uj825jgcr9lzxyp37ehasuenq070707pj63je07n8mkcsg3u0qnsrwx8, maybe others. I kind of have to laugh. I'm a nerd, and I barely understand the current rats nest of relay management. Now we have more. Something has to give here.
Discussion
why is it a nightmare? does it use normal relay lists or a new kind? what does it need to use a relay is it similar to nip17? would it help if relay operators publish a nip66 with a whitenoise tag to indicate suitable for use with whitenoise?
to answer some of my own questions: nip-EE does have a new relay list type the keypackage relays, and then, it has lists of relays in the events. it does not require anything special to function other than, open unthrottled access from any random pubkey just like nip17. I dont know if whitenoise supports auth, so it may not be suitable with nip17 relays like auth.nostr1.com unless it does.
It's a mess because now there are four different relay lists, and that's difficult to design.
We have something pretty coming in the next release tho!
Yeah, it's not easy. Here's a mockup I created (via a broken mkstack implementation 😂):
?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NTI2ODg2ODYsIm5iZiI6MTc1MjY4ODM4NiwicGF0aCI6Ii8yNDk0ODQyLzQ2MzMzNDA0Mi0xNjIyYjNhNy1jNWI1LTQzMzItYjYwMS1lMDg0ZWUwMjNmYTEucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI1MDcxNiUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNTA3MTZUMTc1MzA2WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9MTZhM2ZmOTVkYjBiMzQzZWFiOTY1MzRkYmQ2MDhmN2EwYTg2YjIxZDQzNjRlMTFhNTZhOTMxNWZkMzM0NTlhYyZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.H0VyGiYT9R9pM0-cw84wohSabLLuqXnte6YSecUQ6WI
One difficult decision is whether to group selections by relay with the ability to change their function (like coracle does), or to group by category with the ability to add/remove relays (like flotilla does). The many different categories of relay make it difficult for users to comprehend, which probably requires clients to help out.
All that to say, I don't really know how to solve it.
Mmmh, the "Relay Sets" section got me thinking:
- Right now I feel like there are mostly two "kind" of relays: the ones you set which are used globally on the nostr ecosystem, like inbox, outbox, DMs etc.. (for which this relay management tool would be perfect) and then there are apps related relays, for example the ones you set on noStrudel or Amethyst just to download global stuff or find other nostr "data" and are not tied to the user per se.
- Is your idea of a relay managment tool only for the first "type" of relays (the user ones), or would you like to somehow manage all possible relays that an npub will ever come into contact with?
- So maybe we should ask: where is the line between these two types of relays? And should we expand on the gossip idea and have a set of relays for each "purpose" that could ever be possible in the nostr world (like inbox, outbox, DMs, blossom, search, index, video/stream, mls, etc...) that will be tied to the user and that each app must respect (so hypothetically no more app related relays, because every app would know which one is designed to be used for that user and scope)?
I don't know, maybe I am just over my head here, but I feel like we are going towards too much caos on the relay side, and I am ok with custom options, wierd clients and freedom of choice/implementation obviously, but maybe we also need stronger standards/defaults for this. Then this relay management tool can really be effective I think and make sense overall.
Yes, every relay connection should be justified. This means the purpose behind connecting to a relay should be defined and configurable by the user. Right now we have a lot of heuristics built into clients. These should be defined and shared (although there will always be some creativity involved). I wrote more about this here: https://github.com/coracle-social/how-to-nostr/blob/master/04-relays-are-repositories.md#the-outbox-model-and-friends
