Yeah, I'm aware of that. It's unfortunate, but necessary in order to do work in the background. Maybe at some point I can improve the UX for control freaks like you 😉

For relay approval, I would likely keep a list of approved relays (and default to using those) so you wouldn't have to approve the same relay multiple times.

Reply to this note

Please Login to reply.

Discussion

I've been warming up to the keys.band method of signatures which is time based approval, *with history/audit. Possibly something like this would work, you approve everything, but have the ability to go in and audit/modify the list of relays that have been approved.

Time based approval would definitely be an improvement. nos2x-fox seems to have it (but I haven't tried it out).

Yes, I like that a lot. I think I saw a new extension recently that took this approach

You're the one behind https://keys.band?

Ah, no it's not me it's satoshisound. I did put a PR in over there tho. 😎

why does it have to constantly sign things? shouldn't signing only be for authenticating events? that's why i don't use it, but it made me aware that coracle is constantly doing ec sigs on everything.

Coracle auto-authenticates with relays, which requires a signature. Maybe I'll disable that by default.

does the protocol have some kind of macaroons or similar with expiry and such? i mean, obviously it must be something like this. but also at the same time, a signed event from a known key will be published without this or?

not important to answer these questions, hah. just wondering what level of sign activity is essential and unavoidable, obviously that has to be maintained if it is required.

It's pretty simple, basically just a challenge string that has to be signed in a particular way — no expiration or anything, because a relay can invalidate the session whenever they feel like it. In the future, I think it would be cool to authenticate with pubkeys other than your own (for example a single purpose pubkey exclusively used for holding a badge awarded by the relay admin). Lots of interesting possibilities.

https://github.com/nostr-protocol/nips/blob/master/42.md

ah, yeah, that is obviously going to need to be refined and expanded!

Disable what by default? supporting relays that require auth ?

Yep, because nos2x and manual-approve mode on Alby spam the user with signing requests

Then the user shouldn’t specify an auth-required relay in their list ? 🤷

Perhaps the auth request allow-listing should be per relay not just site.

I also don’t think a client should connect to arbitrary relays not already approved. The minimum intersection of my explicit relays and those I follow should be all I’d normally expect client connections to. If clients just keep expanding the relay list dynamically as part of the social graph I don’t see how everybody doesn’t end up hitting malicious relays with no control over it.

Exactly, ultimately I agree that granular control is the target, this is just a UX stopgap

how does anyone know they are auth required or not. but i'd say if they are then that's sorta creepy if you aren't paying.

The NIP-11 relay info response has a place where relays can specify auth is required.

If auth is required and the client doesn’t handle it well then it will just get NOTICEs in response to every REQ. and be oblivious to the fact none of them ever return responses. There’s no way to actually have a failed REQ unfortunately- other than never giving answers.

this will be a problem down the track.

Given the increased surveillance risk of automatically AUTHing to any relay that asks, this should be a relay specific toggle, something you can turn on/off for each relay.

The nostr.land relays are serving optional auths on connect only so they can track REQs by pubkey. People should be careful and only AUTH when there is a reason…

came here to say this 👆