I am still disagree with this proposal anyway.
https://github.com/nostr-protocol/nips/issues/1013#issuecomment-1921424702
And if you want to solve this problem just because of my project bostr, We do not need to change the current NIP. That proposal is stupid.
The fix is basically just implement nsecbunker for handling NIP-42 in bostr. However i do not have plan to do it anyway as people is still rarely using nsecbunker feature.
no, i want to change the nip42 because i think it's an irrelevant feature and constriction of the thing and i have been dreaming of nostr proxies since like 3 months
so i don't know why you are saying this is a bad thing
do you have a reason based on cryptography and network security theory why it's important to send a challenge and then require that be constrained by some arbitrary government registered address?
Relay spoofing.
Aside of revealing who are people talking to with PMs, it also breaks paid relays.
so you mean a replay attack, send a challenge without this
ok, then i am gonna revise this because the second problem is that the challenge should have this in the string or relay spoofing
in most challenge/response auth protocols you actually sign ONLY on the challenge string
in this nip42 you sign on a heap of other things, it's not relevant, there is no reason why the relay tag has to be there, at all.
Of course that tag was to validate that the client actually talks to the relay DIRECTLY.
Faked / sniffer: Auth please
Client:
Upstream relay to faked: The client AUTH response is not even having a match URL as mine. Ignoring.
i've amended my proposal to add the relay address to the challenge and to giftrap the response so that the MITM doesn't see the response signature
The effective one is still on hostname validation. Even we do with giftwrapping, Raw event (encrypted message content) will still be seen anyway.
*sigh*
the message should not just have a challenge but a challenge pubkey, and then the response can be encrypted, and it can be done over a proxy
TLS has been broken several times before, it's not immune to various kinds of MITM and side channel attacks, and enabling proxy relays opens up a heap of options for relay services
What do you want to encrypt?
The challenge message?
It won't work anyway.
If you try to encrypt the entire event JSON, You are making things harder than nostr promised.
What NIP-42 actually does is basically this:
Relay: Who are you?
Client: I am
Relay: Hello
And then the relay know who the client was, and allows some certain events to be retrieved.
