Oddbean new post about | logout
▲ ▼
dtonon | 14 days ago (raw) | root | parent | reply | flag +2 
 Other's inbox relay are transparent from user's point of view, who should not have to worry about it.

I think that the main source of confusion is related to the fact the 99% of the time two different relays, inbox and outbox, are not really needed, they can be a single personal public relay.

Clients should just allow to add them, and only in an advanced configuration let the user tweak the read/write permissions (or deduce them by the actual permissions).

Then the user can be allowed to add an optional DM relay (suggesting that it enforces authentication), a search relay, etc.

As you see users think that the relay setting in Amethyst is quite confusing, after the Outbox model update; this approach could solve this.
▲ ▼
Vitor Pamplona | 13 days ago (raw) | root | parent | reply | flag 
 But how do we keep paid relays, or relays that restrict who can post, out of the inbox section? 

Similarly, how to we keep relays that restrict who can download from the outbox section? 

It's not even about restricting them because some users actually want that. For instance, if they use nostr.wine for Inbox, only notifications from paid users of nostr.wine will show up. Which is great if the person is getting spammed.

But the average person adding nostr.wine to inbox just gets pissed because they don't understand how nostr.wine works. 

Explaining that has been our main issue. The Inbox/Outbox difference seems to be fine with users. But even when they understand the difference, they misinterpret what happens when setting up each relay in each section.
▲ ▼
dtonon | 13 days ago (raw) | root | parent | reply | flag +1 
 The idea is actually not to have inbox and outbox sections at all, but a "personal relays" section that smartly manages read/write flags behind the scenes. If a relay requires auth to write, the client should (could) disable the read (inbox) flag.

The average person should just add a couple of big free relays and maybe a couple of paid relays. No need to explain much to new users; as soon thwy will understand more about Nostr, they will be free to tweak the details.
▲ ▼
Vitor Pamplona | 13 days ago (raw) | root | parent | reply | flag +1 
 But then we need to make that info available to clients. In many relays, clients don't know if the user is being restricted or not. There is literally nothing to inform the client.
▲ ▼
dtonon | 13 days ago (raw) | root | parent | reply | flag 
 The restriction issue is an additional point, which remains valid for any user interface. I would only start by simplifying the way relays are exposed to the user, but not blocking them if they want to make more complex configurations.
▲ ▼
Vitor Pamplona | 13 days ago (raw) | root | parent | reply | flag +1 
 No, because if app can't figure it out by itself the UI teach the user to do it. 

If we convert to your idea now, nothing is going to work because people will just add nostr.wine to the list and will never receive a notification.
▲ ▼
dtonon | 13 days ago (raw) | root | parent | reply | flag 
 How is the situation different today if you add nostr.wine to both incoming and outgoing mail, or flags both read and write, because you don't know the meaning of the terms and the implications, and then as is typical you turn everything on “to try if it works”?

Since nostr.wine requires auth the app might explain that this relay is poorly suited as a general inbox, but it might still be useful for users registered with it, and then suggest adding another public one, or disabling it as the inbox (read).

@Mike Dilger recently added a relay testing tool that could be a good example of how to direct the user to the most appropriate use of relays.