Hi HN, we built Rayfish, a peer-to-peer mesh VPN written in Rust on top of iroh.
The core idea: every node has a keypair, and its identity on the network is that public key. From the key we derive a stable IPv4 in 100.64.0.0/10 and a stable IPv6 in 200::/7, similar in spirit to yggdrasil. Those addresses are yours for as long as you hold the key, and they don't change when you move networks or your physical IP changes. You still reach peers by IP or by a name.ray DNS name, the difference is that the address comes from the identity rather than from where you happen to be.
"No server to trust" is the part we care about most. There is no central control plane that brokers your traffic or holds the keys to your network. Peers find each other and connect directly over iroh's QUIC stack, with NAT traversal, hole punching, and relay fallback handled underneath. Relays, when used, only forward encrypted packets and never see your keys or decide who is in your network. Membership and trust live with the peers, not with us.
How it works in practice:
- Networks are closed by default. You join with a one-time invite, a reusable key for fleets of servers, or live approval from a member already inside. The room id is only for discovery, it is never an admission credential.
- Any member can be granted the network key and act as a coordinator, so admitting new peers keeps working even if the original creator is offline.
- There is a per-device firewall, directional and scoped by port and protocol, plus Magic DNS so you can reach nodes at name.ray (or just name, no need for the .ray suffix).
- A "ray connect" flow links two people directly with no shared room, like a friend request between keys.
- No ACLs. Networks are logical partitions. Firewall is per-host. You can combine both to have custom ACLs.
It is a single binary with a daemon and a CLI. `ray up`, then `ray create` or `ray join <invite>`, and you have a private network.
Honest limitations: it is early. The mesh protocol is gated at the transport layer, so we break compatibility between releases when we need to. There has been no third-party security audit yet. Mobile is not there. It runs on Linux and macOS today.
Indeed.
So what we do is build your ipv4 using private key bits + collision_index.
It is not perfect but it has worked in our tests. We'll keep improving it.
The collision_index is incremented when a collision happens on a network. Let's say you join network A, B, C. But when you join C, another peer has the same IP. The coordinator (which is a role anybody can have in the network) will not accept you in the network unless you change your IP. Which means you need to increase your collision index. Now that process is repeated N times until you don't collide with any other peer.
Great work. I'm currently using tailscale and would love to have another option!
Hosting my own iroh-relay makes it truely independent then.
Only missing the mobile app now! Keep up the good work!
Yeah I run an HFT firm. Apart from that, why does it matter? This isn't finance! But of course, rayfish is NOT production ready. For home servers might be ok. BUT NOT PRODUCTION READY
Hey, thanks for sharing this, this is a very cool project and one that is the obvious next step with iroh. I'm curious if you plan to make it into a library to be used, or you intend to keep it solely as an application?
I did gauge that possibility. But iroh is already the library doing the heavy-lifting. So no, I don't think I'll make it a library. It is actually kinda a library now that I have to add android support. But it's not really fit to be a library.
Please disclose your use of AI. It's rather telling 2 weeks from repository commencement to release. Why should anyone use this over other products, and what testing have you done to PROVE it works as explained by your LLM?
My product is unique because it is not a product.
Like it is mentioned in the article. I don't care about monetization, I just want a good trustless p2p vpn that anybody can use. In the future even normies will be able to.
I am working on an android/ios app (ios not yet but in the future) to at least share my clipboard with my computer or send images. Which seems trivial but you dont have a really good (not battery consuming) solution for android<>macos.
Anyway. Rayfish is p2p no central coordination needed. Other's do need some central coordinator.
The main disadvantage one might find is that it uses iroh which is built on top of QUIC. Tailscale and others use wireguard, which is nice and compatible with legacy VPNs. Also they have a kernel driver which we dont. It's all userspace. I didn't want to reinvent the wheel.
This is very cool - I will likely see if I can use it in place of tailscale for my local LLM hosting. I feel like not having that required login would be great. Also the direct connect feature seems pretty cool, since that’s usually all I need for my use case.
Having an install script that you paste into the terminal and all it does is download a binary and stick it in a folder is wild.
If your users are savvy enough to be running random scripts they shouldn't need a script to do this and if they're not savvy enough to understand how to do that then the last thing they should be doing on earth is running a random terminal command off a website.
One thing I seem to struggle to understand is, a simple invite code system is showcased, but how does host Alice in one country know how to contact host Bob in another country with just the invite code? This seems to require a coordination server at least right, or does the invite embed some sort of information that'd allow Bob to directly reach Alice with just the invite code?
I didn't really knew what Nebula was until I saw the comparison made by claude.
I tried solutions like tailscale before but never nebula. If you like that product keep using it. The `it's nebula minus X feature` doesn't really fit here
Interesting project but can't find anything useful about the author's background on GitHub.
Commit history shows the project is a couple weeks old and the commit velocity only seems possible with heavy LLM involvement. Not unexpected but worth noting.
The repo's CLAUDE.md is huge which conflicts with published best practices around agent instructions and makes me wonder how much experience the author has using LLMs.
All that said, I'd like to use something like this for my personal devices since my personal and work Tailscale networks still can't run at the same time. But there aren't enough trust signals for me for this project yet.
Hello. Yeah this is my secondary account. Main one is dgrr. I still dont do much there. I have projects in github.com/infinitefield and now rayfish.
Indeed yes I do not use LLMs too much. Rayfish was a project we had pending for years and I had a lot of sketches about it in my obsidian folders.
After the release of iroh v1 I decided to try out claude and prompt it to solve the problem.
Still, there is a lot of boilerplate and over time it will become much more like a handmade project assisted by LLMs than anything.
That said, it is not my main focus, although I use the product of course. Contributions are always welcome.
tinc (https://tinc-vpn.org/), a OSS mesh vpn that has existed for a long, long time, is another great solution with no central server. You can manage the public key distribution yourself, or just keep them checked into a git repo (my preferred solution), and it's been solid for years.
Yes. There are good solutions out there. I just build rayfish because I want truly decentralized networks.
My thought process is more like: what if you have your job's network and your gaming network? if you use tailscale you need to log off of one, log into the other. Still, you have centralized coordination servers and so on.
With rayfish we also discard the ACL architecture and use network separation + per-device firewalls. So it is also trustless. In some way
It is wrong to describe these P2P products as server-less. In order to connect two peers over WAN it needs a form of coordination server. Since Rayfish appears to be a Claude coded wrapper over Iroh it should at-least give credit to use of Iroh's discovery and relay nodes.
Yes, we did use claude, somewhat. We do give a lot of credit to iroh. Check the description of the repo.
As per the AI stuff, rayfish is a very old idea. I had a lot of sketches on how a p2p mesh VPN should look like. So it started off as "hey claude, can you do this?" and of course because I use it I have to do a lot of things manually myself.
But of course, without iroh this project would have not been possible!
Nowadays I question the necessity of vpn overlay networks. Why not just serve QUIC/HTTP3/Iroh over the internet directly in your application? And use oidc/client cert for authn/authz
1. foss, p2p-only, no server or intermediate nodes to trust (rayfish)
2. foss, brokered if necessary with all nodes self-hosted (openziti, nebula, some wireguard variants)
3. non-foss, mix of p2p and brokered, host some of the nodes yourself (openvpn, myriad of wireguard variants/wrappers like tailscale, headscale, netbird, netmaker)
38 comments
[ 4.7 ms ] story [ 70.2 ms ] threadThe core idea: every node has a keypair, and its identity on the network is that public key. From the key we derive a stable IPv4 in 100.64.0.0/10 and a stable IPv6 in 200::/7, similar in spirit to yggdrasil. Those addresses are yours for as long as you hold the key, and they don't change when you move networks or your physical IP changes. You still reach peers by IP or by a name.ray DNS name, the difference is that the address comes from the identity rather than from where you happen to be.
"No server to trust" is the part we care about most. There is no central control plane that brokers your traffic or holds the keys to your network. Peers find each other and connect directly over iroh's QUIC stack, with NAT traversal, hole punching, and relay fallback handled underneath. Relays, when used, only forward encrypted packets and never see your keys or decide who is in your network. Membership and trust live with the peers, not with us.
How it works in practice:
- Networks are closed by default. You join with a one-time invite, a reusable key for fleets of servers, or live approval from a member already inside. The room id is only for discovery, it is never an admission credential. - Any member can be granted the network key and act as a coordinator, so admitting new peers keeps working even if the original creator is offline. - There is a per-device firewall, directional and scoped by port and protocol, plus Magic DNS so you can reach nodes at name.ray (or just name, no need for the .ray suffix). - A "ray connect" flow links two people directly with no shared room, like a friend request between keys. - No ACLs. Networks are logical partitions. Firewall is per-host. You can combine both to have custom ACLs.
It is a single binary with a daemon and a CLI. `ray up`, then `ray create` or `ray join <invite>`, and you have a private network.
Honest limitations: it is early. The mesh protocol is gated at the transport layer, so we break compatibility between releases when we need to. There has been no third-party security audit yet. Mobile is not there. It runs on Linux and macOS today.
Code: https://github.com/rayfish/rayfish
Happy to get into the addressing scheme, the iroh transport, the admission and coordinator model, or anything else.
With only 22 bits of entropy in your v4 addresses, you'll get accidental collisions with only ~2000 users.
The collision_index is incremented when a collision happens on a network. Let's say you join network A, B, C. But when you join C, another peer has the same IP. The coordinator (which is a role anybody can have in the network) will not accept you in the network unless you change your IP. Which means you need to increase your collision index. Now that process is repeated N times until you don't collide with any other peer.
(I really hope "private key" was a typo of "public key"?)
> Happy to get into the addressing scheme
I truly loathe how all of the HN spambots promoting shovelware include a stupid call-to-action for feedback/discussion.
im also afraid of exploits disseminating from a mesh network it would be impossible to stop
great work
Anyway. Rayfish is p2p no central coordination needed. Other's do need some central coordinator. The main disadvantage one might find is that it uses iroh which is built on top of QUIC. Tailscale and others use wireguard, which is nice and compatible with legacy VPNs. Also they have a kernel driver which we dont. It's all userspace. I didn't want to reinvent the wheel.
If your users are savvy enough to be running random scripts they shouldn't need a script to do this and if they're not savvy enough to understand how to do that then the last thing they should be doing on earth is running a random terminal command off a website.
Sigh..
I like the project though. It looks very similar to something I vibed up recently, must be in the air
Commit history shows the project is a couple weeks old and the commit velocity only seems possible with heavy LLM involvement. Not unexpected but worth noting.
The repo's CLAUDE.md is huge which conflicts with published best practices around agent instructions and makes me wonder how much experience the author has using LLMs.
All that said, I'd like to use something like this for my personal devices since my personal and work Tailscale networks still can't run at the same time. But there aren't enough trust signals for me for this project yet.
That said, it is not my main focus, although I use the product of course. Contributions are always welcome.
Yes, we did use claude, somewhat. We do give a lot of credit to iroh. Check the description of the repo.
As per the AI stuff, rayfish is a very old idea. I had a lot of sketches on how a p2p mesh VPN should look like. So it started off as "hey claude, can you do this?" and of course because I use it I have to do a lot of things manually myself.
But of course, without iroh this project would have not been possible!
1. foss, p2p-only, no server or intermediate nodes to trust (rayfish)
2. foss, brokered if necessary with all nodes self-hosted (openziti, nebula, some wireguard variants)
3. non-foss, mix of p2p and brokered, host some of the nodes yourself (openvpn, myriad of wireguard variants/wrappers like tailscale, headscale, netbird, netmaker)
why is #3 so much more popular?
Interesting to see this built on Iroh.