Replying to Avatar hodlbod

I had an idea this weekend for how to make running community or personal relays easier for non-technical people by piggy-backing on commodity relays to avoid dealing with DNS/incoming connections. This would allow people to simply run a "relay" on a computer they own, but have it publicly accessible.

The way this works is via a DVM-like flow, where the user NIP 59 wraps a message to the relay's pubkey, sends it to a public relay where the target relay is listening, and waits for a similarly wrapped response back.

I call these "kelays", which is a terrible name, but the best I could come up with within 8 seconds. You can see my proof of concept implementation at https://github.com/coracle-social/kelay. The go program allows proxying any relay, and the `example.sh` uses `nak` to demonstrate the flow.

People could address these using something like `kelay://?relay=wss://relay.example.com&relay=wss://relay.example.com` This obviously routes traffic through hubs, but I think that's a reasonable trade-off, especially with the option to use multiple broker relays.

What do you think? This could obviously be abused in any number of ways, and I still have to figure out how I can make NIPs 42 and 98 work. And maybe some other p2p technology would be more suitable for hole punching. But this is the kind of left-of-bell curve solution that made nostr famous, so I'm reasonably optimistic about it.

This is definitely one of the biggest hurdles to running a relay for just about any purpose, not just communities.

What do you think about the possibility of using something like Pear runtime for connecting to a community relay?

Reply to this note

Please Login to reply.

Discussion

Could work, I just don't know much about pear. In either case, it's a new transport protocol, so in theory they'd be functionally equivalent

I like that yours is using a Nostr relay to establish the connection. Once the connection is established, everything else is just straight from client to community relay, right?

No, that would be more like how p2p stuff usually works. NAT traversal is apparently a huge pain, in this scenario all messages would be proxied by the brokers

It looks like hyperDHT requires UDP, so you would need a bridge anyway.