Oddbean new post about login | logout 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.
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.
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.
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.