Nostr Web Client

Currently designing a better relay management UX, and its a nightmare, send help!

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.

Reply to this note

Please Login to reply.

Discussion

ciori 5mo ago

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.

hodlbod 5mo ago

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