Ok, not to diss this project or anything, but relay-proxy from earlier this year does the same thing. Multiplextr does as well, but using a wrapper protocol so clients can make non-static relay selections.
Proxies like this hurt the ability for clients to intelligently route. They also have significant privacy drawbacks, especially if proxying AUTH (they can exfiltrate protected data).
I'd love to see more work in this area, especially since proxies have the ability to improve routing without clients having to do anything by inspecting filters coming through. I recently wrote a bit about this, see below:
https://habla.news/u/hodlbod@coracle.social/1700155417145
I'm not going to be able to read this right away but thank you so much for this article. I've been thinking about some of the same concepts and this article looks really well thought out.
I feel like the whole reason this exists because we don't have routing or gossip on all clients, so people are trying to find work arounds to make Nostr more usable. If we had routing and gossip, we wouldn't need this most likely.
Well, this breaks gossip in clients that have it. It would be possible for a proxy to add gossip to clients that don't, and that would be awesome, but this isn't it.
Just like an IRC bouncer, You are expected to run the software for your own actually.
And no. NIP-42 was not enabled by default & only supported for personal use due to the reasons that you've provide above.
And again, NIP-42 requires domain name validation. So #bostr could not use NIP-42 for public usage.
I am rather questioning the privacy at multiplextr than in #bostr as it tell to coracle that the event was sent from "that" relays, and then coracle sign the AUTH for "that" relays also.
Yes, multiplextr absolutely has the privacy problem you're describing. The advantage it has is it allows clients to implement routing.
How to keep this proxy relay address private? Does anybody can connect to this proxy relay silently if they know the address ?
In config.js, You put your public key in `authorized_keys` array. After restart, bostr will only allow users in `authorized_keys` to use the bouncer.
However, You need to ensure that NIP-42 is supported in your client. Otherwise the bouncer will not doing anything for you during authentication.
Additionally, You could enable internal NIP-42 for NIP-42 relays for your own use by inserting public & private key in `private_keys`.
It works when left authorized -keys empty, but Every time I added key to authorized_keys, seems it doesn’t work.🤔️
Did your client supports NIP-42? I've tested this funcion in #Amethyst client.
Ok,thanks. It work in snort web client. Seems most clients donot support nip-42.
By the way, about the bounce, can it bounce to local host, like ws://127.0.0.1:port
It could bounce to wherever you want to.
I think so, but failed🤔️
How so?
If you want to debug, You could enable `log_about_relays` in config.js to see whenever the bouncer connects to your relay or no.
Sorry, saw the configuration in the file. Can whitelist
// For personal usage. Leaving this empty allows everyone to use this bostr instance.
// NOTE: Requires NIP-42 on client.
authorized_keys: [
// "pubkey-in-hex",
// "npub ....",
// ....
], 
Oddbean new post about login | logout