Sounds about right. Currently we are missing the nostr signer (in my case amber) being able to differentiate per-relay auth so it's automatic auth for all relays or manual for all.. setting. Seems like amber could implement this though. I know of no signers that currently have this feature..
what's the ideal UX for nostr relay auth? in my humble opinion:
- prompt the user for auth when receiving AUTH from relay, offer yes/no and remember my choice
- ask by default, allow/deny list is remembered
- allow the user to tweak the allow and deny lists in settings
cc nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku
Discussion
gooti might be a good base for it. it's very basic and low on features, and has a pretty poor UI/UX. but it supports multiple logins very well, there's just a half dozen or more things that i can see it doing better. also, it could integrate neatly with NWC to become a serious competitor for Alby, whose UI work is *cough* lol.
It would be good for the signer to be aware of auth. But ideally the apps shouldn't be spamming the signer with requests to auth
clients should really avoid using more than one socket anyway. closing the socket needlessly or opening a dozen of them, the real spam going on here is websocket handshakes.
idk exactly what the best way to do this is because if it was Go, i would have a client connection goroutine with a channel that other parts of the app send requests to, and this would isolate the management of the client connection from the app. my guess is that the right way to do it is put the client connection management into a service worker and use its IPC as a channel in the same way as i would do it if it was using go, which i think anyway is going to be a serial queue, thus processing requests as they arrive as the socket becomes available after the previous message is dispatched.