hm i just checked and #orly doesn't actually have handling code for deleting expired events, i will make an issue
Discussion
Using reverse-proxied local relays, like nostr:npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl and you do, means that you could create an authed p2p message channel with kind 24 events. Completely bypassing the shitshow that is DMs.
And nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub1yjxerh4msvgqf230ej3648a28xhvxjstqr2rhpjt2eelf538e70scnl9d0 it's a target for #Samiz and other local coms. You could Bluetooth public messages to people in range.
yes, having the reverse proxy would enable better DMs, because you could send it only to the relay trusted by one of the parties. only one side has to have it, for it to work.
so, for 1 to 1 it's 50% need inbound routing, but for a group, only the group admins/operators need to have them, that's where i get my 10% inbound routing solves the privacy claim.
btw, a small detail but the reverse proxy actually deciphers the TLS encryption on the network transport. the second leg is secured by wireguard in my setup. the point being that the reverse proxy is a potential surveillance point as it is a man in the middle. so the messages must be encrypted, as well.
Well, you could also use authed sockets, directly, rather than over a proxy.
My point is just that kind 24 messages are unencrypted, so the amount of privacy they offer is determined by the channel they are sent on.
You could also encrypt the content, rather than giftwrapping, as an obfuscatory fallback, if it leaks or is accidentally broadcast.
There are options.
yeah, using a wireguard network would enable a lot too, and that is encrypted end to end, HTTP proxy is just the simplest way but i'm sure there is options also for improving that
ultimately if the relay and the proxy are on the same machine it's not really an issue, it's only for the case of running relays locally, the signal is decrypted at the reverse proxy, idk what options there are for remedying this exactly, part of the problem is that a true end to end encryption would probably need to be added at the message level to eliminate that risk at the remote proxy. if you control it, then it's not so bad but yeah, ideally you would want to use nip-44 encryption, basically