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
Agreed it’s a shit show
We haven’t found a reason to specialize an MLS key package relay.
I have no idea what that means. This is my point. Appreciate what you're building. It's great. But relay management is a hazard.
In 0xchat lite, we don’t use keypackage relays, inbox relays, outbox relays, or DM relays. By default, all messages are only sent to your current circle relay.
Bravo. This way will win.
What is a circle relay? I just downloaded the app and have no idea what that is
I just published a note. For the circle relay, you can use any public relay or a private relay. All messages within a circle will only be sent to the relay you’ve set for that circle.
Thank you, and yes, I saw the help text
we need square relays
Is there a table comparing whitenoise, 0xchat and keychat?
Not yet might be a good idea to put one together though.
To be honest, Whitenoise, Keychat, and 0xchat-lite share many similarities. Here are a few points focused on privacy and security for comparison. Also, both Whitenoise and 0xchat-lite are still in beta, and will continue to be improved over time—so this table is just a snapshot based on the current state. There may be some aspects missing.
Is the fact that White Noise and 0xchat are both on NIP-EE enough for interop? Or do the differences in receiver key rotation, media encryption, etc., make interop tricky, even though both are on NIP-EE?
Not enough — for now, only basic interoperability is possible. However, i believe whitenoise is expected to support key rotation and media encryption in the future as well; we’ve just taken those steps a bit earlier. 😂
Making an app user have to *think* about relays early and upfront is bad UX.
You are making a tradeoff: cognitive burden for censorship resistance.
When 99% of your users do not face a direct censorship threat, you only add overhead.
Especially now with multiple categories of relays, that are confusing to even nerds like us.
All this effectively does: annoys the users who want nostr, and repels those who are curious.
Instead of offering on-ramps to newbies, we are offering on-walls.
Relay management is a must *and* it belongs in advanced settings. The word "relay" should be used sparingly and deliberately.
Convention over configuration all the way.
50 shades of relay.
Currently designing a better relay management UX, and its a nightmare, send help!
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