[delayed]

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?

> and membership is a signed record they each carry, not a question they ask a server.

Sigh..

I like the project though. It looks very similar to something I vibed up recently, must be in the air

Looks like no support for Windows :(

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.

I don't know why your post was autoflagged but what makes your product unique from the rest?

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.

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.

Code: https://github.com/rayfish/rayfish

Happy to get into the addressing scheme, the iroh transport, the admission and coordinator model, or anything else.