Oddbean

Can we build a Nostr-native onion routing for private events using DVMs? Each onion hop is a GiftWrap using an Ephemeral event kind encrypted to the next onion DVM. The client assembles all hops and sends the private message to the first DVM via the user's main relay. That DVM decrypts the ephemeral event and sends it to the next DVM. The last DVM will send it to the user. This minimizes the user's IP leakage to the set of trusted relays that user likes while sustaining the relay decentralization properties of NIP-65. User's would never connect directly to the read relays of other users because they might not be trusted. Since the relay knows your Nostr filters, it does know which pubkeys you are interested in (including your own key). Decoupling sending an event to a pubkey and filtering events for your pubkey in the same connection/IP is key to reducing the power that the relay has over you. This would be akin to using several Tor sessions, a new session for every new message you send, while giving the Client the power to choose different "exit" nodes (DVMs) at each new message. Am I crazy or is this actually better?

Someone actually wrote a non official nip for this a while back. I started writing some python code doing the basics ... But i wasn't sure if it was crazy good or crazy bad! https://github.com/monty888/republishstr

Nice! So, we just need to updated it to be a DVM and the new encryption scheme. Maybe we can add a cashu token in each hop to pay for those services? nostr:nprofile1qqs9pk20ctv9srrg9vr354p03v0rrgsqkpggh2u45va77zz4mu5p6ccpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0dehhxarj9ehx7mmwv4ejucm0d5hsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshs26ym66 , if I encrypt a cashu token from the same mint in each hop, can each server use that info to identify who am I?

Well, it has been 30 minutes since I posted so I bet nostr:nprofile1qqs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75sprpmhxue69uhhyetvv9ujucm4wfex2mn59en8j6f0qyfhwumn8ghj7mmxve3ksctfdch8qatz9uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z79z4kue has built it already.

Even better for privacy, suppose you could specify a delay between hops, and also specify a file size change (add or subtract useless data). Then once you got some mass of people using this, it would be extremely difficult to track events by either timing or size.

I’m still a bit mind rumbling with those tech terminologies, just a few things come to mind hopefully it would be helpful 1. Simplify process at user end 2. Security and user privacy as priority 3. Workable measures for potential cooperation with regulators when Necessary 4. Cost efficiency at all levels of participation

干脆用闪电网络来组建投递网络算了哈哈 nostr:nevent1qqs85yw72h69u70l2mfaqju8hzelmfzu68f26ktr9mftvju7nyg284qpr3mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmqzyprqcf0xst760qet2tglytfay2e3wmvh9asdehpjztkceyh0s5r9cqcyqqqqqqg89cm8h

Neat - but I'd rather use Tor. This would introduce such an absurd amount of complexity to what Nostr is supposed to do... Yes, it would be Amethyst local - but even then, it feels overkill. That said - this is worthy of being documented as a "imaginary NIP" - random ideas that do not, currently, have a place and could be beneficial in the future for someone else. :)

without a scheme to pay for it it's gonna be bogged down with spam, and no, PoW isn't gonna solve the problem forever (tor project has kicked the can with their use for rendezvous routing) because eventually someone will find it valuable enough to overwhelm average user hashpower to push spam without any recourse for users or on the network i've worked on a huge codebase, over 20k lines of code for doing this and it's not a simple task to implement, and we still haven't got clients supporting NIP-42 yet also, aside from everything else, this is outside the domain of relaying in an architectural sense, you are essentially proposing to turn relays into a network transport