Nostr Web Client

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

Reply to this note

Please Login to reply.

Discussion

Tabii 3w ago

Ohhh this makes sense. One extra UX nuance I’d add: context matters.

When prompting for AUTH, show why the relay is asking (read-only? write? DM access?) in plain language. Users don’t reason in NIP terms obviously.

Default = ask once, remember choice per relay + scope.

Settings = editable allow/deny with scopes, not just binary trust.

Silent auth is dangerous; noisy auth is exhausting. The sweet spot would be explicit, scoped, memorable consent.

cloud fodder 3w ago

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

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 3w ago

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.

hzrd149 3w ago

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

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 3w ago

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.

hzrd149 3w ago

This is exactly how noStrudel works. It never auths by default and let's the user set prr relay preferences.

The difficult part is notifying the user about the auth request. In most contexts the user doesn't care but if they are viewing their notifications then they probably care on if their relays is requiring auth

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 3w ago

can you tell me about how you envision relays preventing spam without identifying the users?

verbiricha 3w ago

interested in your feedback on the https://grimoire.rocks/ implementation of auth. i mostly yoinked the noStrudel approach.

nostr:nevent1qgs8lft0t45k92c78n2zfe6ccvqzhpn977cd3h8wnl579zxhw5dvr9qppemhxue69uhkummn9ekx7mp0qydhwumn8ghj7argv4nx7un9wd6zumn0wd68yvfwvdhk6tcqypcuukmtjaqwe7423vc7g4eptn6erg8frazug84ercae64pu9jjpv6vpq06

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 3w ago

i like it, and i think that it should be something like that.

i just learned about SharedWorkers btw, they can be used on chrome/edge/firefox but not safari, safari is gay like its CEO and you have to specially handle that with a DedicatedWorker per tab. this could then become an IPC that mimics the relay nip-01 RPC and lets you manage relay connections peristently as a worker thread. this would eliminate all risk of race conditions like you see with react apps using NDK because the worker is a single thread and effectively would queue processing - if you wanted it to, or you can fan it out with promises to individual relay sockets so it dispatches the request/event and when it returns, it then returns the response back to the component via teh IPC. this would also then let you restrict use of the signer/bunker to a single piece of code that is isolated from the rest, in a separate thread and runtime.

hodlbod 3w ago

I think this is correct, just something I haven't gotten around to yet. I do think AUTH notifications probably shouldn't be immediate, because you can get dozens of them at a time. Having a notification that opens a list where you can easily deal with them in bulk would probably be important.