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://<pubkey>?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.
hodlbod /
npub1jl…jynqn
2025-06-02 21:58:17
Author Public Key
npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqnPublished at
2025-06-02 21:58:17Event JSON
{
"id": "5a19756fb5e4b11e3b6361e01d33204af598c9f13c668cbb2a55a6b39ae0442d",
"pubkey": "97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322",
"created_at": 1748901497,
"kind": 1,
"tags": [
[
"client",
"Coracle",
"31990:97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322:1685968093690"
]
],
"content": "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.\n\nThe 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.\n\nI 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.\n\nPeople could address these using something like `kelay://\u003cpubkey\u003e?relay=wss://relay.example.com\u0026relay=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.\n\nWhat 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.",
"sig": "d6b135003f4522831f33dcacb7c278b8275e78174c556f2c11da5bc99724eb0c9f6d2d2bfae6464bc870b6b51419c16777a86e3a23fcf48fec475c831813970d"
}