Most people don’t care about privacy, but it’s important that privacy tools are built so that they can say "I don’t want privacy" while having the option to anonymously and privately transact anyway. If our Bitcoin is not hidden from the government, they can easily throw a million $5 wrenches at us.
Discussion
10,000% agree. It's the most important tech there is.
I just find it funny when people make their attacks on Nostr with "it's not private enough" as if that is what will stop Nostr from gaining adoption.
Yes, people definitely don’t care about privacy on social media.
I’m not sure if this is possible (maybe nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 knows), but it might be cool if nostr relays could take on the role of a VPN. Maybe when you hit Post, your IP is sent to a single, random relay, and they broadcast your note to your other relays with their own IP.
You can run a bostr, it's a relay multiplexer where you can configure the relays to connect to and you can just read and write from them proxifying you connection, and also have nop-42 for auth so you don't need to worry for this. You can run this in a cheap vps payed in btc and if you connect just to your multiplexer the relay just would see the ip of the bostr. Also have another advantage that it's trim bandwidth since it decouples the events for you
Yeah, that's definitely one solution. But how many normal people are going to do something that complicated? 0.
Ultimately, you still have to be running a VPN. Otherwise your ISP can see the requests going to your Bostr on the VPS. Ultimate truth is that there is only so much you can do to lead a horse to water.
We should all strive to run software and services and businesses that respect user privacy as much as possible and track as little identifying data on them as possible. The real trick would be figuring out how to structure the incentives for businesses such that they really don't want your private info. E.g. it makes their businesses easier or more profitable without it...
The same when you use VPN. Your ISP will know it anyway. In fact, It's easily able to caught just by reading the header byte of the connection.
Of course your ISP still knows that you are connecting to bostr. But do they even care about this anyway? Mostly did not due to large amount of customers.
Even so, Packets are still secured with TLS. So you do not really need to worry about it.
does bostr take care of authing?
Yes, but only if it is your own bouncer because logically they need to have a matching hostname to have a proper NIP-42, Otherwise it will just invalidated.
You can add a list of valid keys to auth in the conf if im not wrong 👌
this is for the instance running on an off-site VPS? as in... nsec... in a configuration file that is not on a machine physically in your control
Yes. VPS, could be your home server or cloud server.
And yes, it is not physically controllable if it was in cloud machine. That's how things works.
If not via the config, then what else? Because that's how NIP-42 works. They have hostname validation so just forwarding these directly to relays with hostname field of bostr instance instead of the supposed hostname will absolutely piss the relays off and does not trust the AUTH. So NIP-42 is going to be handled in bouncer side.
The client will also need to have a working NIP-42 for being able to use the NIP-42 function in bostr, And that also for validation so nobody is going to auth with your nsec.
there's no reason i can see why the auth requests can't be forwarded to the client and bostr act as a pure proxy when it is given auth events on either side
the auth response message contains the relay to forward it to so there's no state required either
ahhhh... yeah that could be a problem if your client is only thinking it is talking to one relay
well, it could be fixed with an extra tag maybe... only the challenge is really important
it would be great to have a full proxying relay like this that does auth because you can't access your DMs or use paid relays without auth
i'd be happy to consult with you about making a NIP for proxying where the signed response can be different to the relay asking for it
I do not think this could be solved easily with new nip / modification on nips.
i have made a proposal to relax the requirement of the matching relay tag, as it's actually irrelevant anyway
with this accepted and relays changed to this the problem doesn't require any action by clients to make your project able to do auth proxying without making the user's nsec more vulnerable
I disagree with the proposal. Relays do this in order to only allow certain kind of events to be retrieved to specific users only.
Doing the otherwise will obviously break it is purpose to become secure.
I would say it is not due to it is security, rather than privacy itself.
the auth request (challenge) is sent from a relay to the client, this value is meaningless to anyone else
only the client can sign it, and anything else in the message is irrelevant
nobody can sign with the valid public key and challenge except the holder of the private key, so why does the relay address matter?
i already got one ack on this proposal and i am pretty confident the rest will ack also
and it solves the problem that makes your project more or less useless if you care about not exposing your nsec to remote attackers to hardware not in your direct physical control
this will mean that you can add one small feature to your project where it forwards AUTH messages back and forth to the relays, it only needs to keep track of the challenge and relay address so it forwards the auth response to the relay that will recognise it (and btw, typically these live for only 20 seconds at best).
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.
This sounds very cool. I agree with Jeff that no normies are going to do this though. However, if we expect to eventually move to paid relays, it may be a good opportunity for Bitcoin friendly VPNs to bundle their service with a relay multiplexer so that your IP is only exposed to the VPN that sees it anyway.
I don't think that is the best idea. I'd prefer to have different services doing different things. But I also don't trust these VPNs, so I don't know what to propose.
One thing that is nice are these image proxying servers that some clients are running on behalf of users.
But ultimately Nostr cannot solve everything.
Yes that is true. If you need to remain anonymous, it’s not too much of a hassle to get a VPN or use privacy focused clients. It’s a lot better than telling people to just use Monero.