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.

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.

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. View quoted note →

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?

Yeah, it's not easy. Here's a mockup I created (via a broken mkstack implementation 😂): 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.

Thank you, and yes, I saw the help text

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.

why not just use outbox relays for that?

we need square relays

That's what we're using, but there is nuance here, we need a new outbox list for key package events and for group events.

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

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. 😂

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!