Nostr

i have also thought about this "relay as proxy" idea as well, but the limitations of nip-42 auth make it difficult.

but if you added a HTTP proxy to orly, and configure your client apps to use the http proxy, then it can intercept requests to itself, ok, fine, but then your client can auth to remotes, and then orly takes over and can then publish to them with auth enabled.

this is a bit of a complicated, advanced feature. part of the reason why i haven't done it is because HTTP proxy auth methods are pretty weak and i wouldn't trust that on a remote server.

but it could be done.

extending nip-42 auth and nip-01 req/event methods could also fix this problem by enabling relays to issue an auth token that can be used in place of the regular auth flow, and then the relay can proxy these queries, cache the results and then forward them back to you.

there is multiple ways to solve this problem but the first version with http proxy interception is probably the most practical right now.

Silberengel 5mo ago

I wouldn't do this on a remote relay, yeah, too insecure. It's actually building a tiny backend-client into the relay, to handle traffic cross-client.

Reply to this note

Please Login to reply.

Discussion

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

ah yes, that's the easy solution, local only and configure it with your nsec so it can auth to remote relays as you. then it can read and write to your relay list when they have auth required.

that's probably something you can actually feasibly do without having to step outside of the confines of the nostr protocol too.

i definitely want that PR merged if you make it!