It is wrong to describe these P2P products as server-less. In order to connect two peers over WAN it needs a form of managed discovery process with a 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.
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.
I still have no comprehension of how curl piped into a shell command has become the default installation method for many projects (looking at you, Rust...). It breaks my brain as to how potentially unsafe it is.
Everyone’s eventually going to run a binary they downloaded from the same place, if you’ve already decided to do that, why is a curled install script worse?
Because it normalizes a practice that, while acceptable in context of a well known project with numerous dedicated eyeballs such as Rust language, is not a generally acceptable method of installing software.
The correct way is to have M of N signatures on specific package manager pinned versions. And you trust the auditors to look at each new version, of a well-known package.
We should start a project and get it funded, to do just that. The money can go to LLM tokens for audits, at least, and hosting the multisigs and the package managers.
Anyone want to partner on this? See my profile on HN and email me.
The issue does not have to do with whether the download is a binary or source code. It has to deal with verifying the integrity of the download before installation.
Curl piped into a shell command provides no means to verify that the download is uncorrupted and unmodified before running it. For example, whenever I download software manually I check the downloaded file against the verified checksums to ensure that I have an unmodified version. Ideally I check this with gpg --verify on the signed checksum file (against the source's public key). This is a standard procedure for many organizations [1]. If you just download something and immediately run it without this step, you could potentially run a hacked version of the installation script.
Curl does verify certificates [1]. That does confirm that your connection is to the right server, but it does not confirm that the files were unmodified.
SSL/TLS/HTTPS is more about encrypting the traffic and ensuring that there was no tampering with the file between you and the server. The steps that I describe are more about ensuring that there was no tampering between you and the original source. Those are two separate problems. If you just rely on HTTPS, somebody can replace the file on the server with a modified version, and you would not know.
It's because people are too obsessed with providing complete instructions to incorporate any package manager into their instructions.
What we are really missing is an explicit progression from new software to maintained packages across distribution. As it is, each distro expects each package to have a maintainer, and very few people actually want to do that across several distros just to release their software. Generally, the expectation is to instead just wait around for people to make and maintain those packages by virtue of their own interest in your software, but it takes a while, and discoverability isn't automatic.
Look, you are going to run an executable. There is no way around it. At some point you are going to fork over inscrutable, opaque sets of bits to your CPU and loudly proclaim them to be executable. The CPU does not know, cannot know and does not care. At some point this will be done. No matter how many hashes, digests and public keys you verify, the bits will be interpreted as instructions and energy will be expended to explore a state space you were told is or leads to the promised land. If deception is involved in any step in this process, the end result will not be what you expect it to be. The peculiarities of the transport mechanism by which these bits were transported to your particular device of computation is very nearly the absolute least interesting thing to worry about in this whole shit-show.
It's completely insane our desktop OSes are holding highly private data like banking details with zero meaningful support for sand-boxing.
This whole problem would be a non-issue if we got proper auditing and management tools. If we could properly inspect our system's resources and see what sandbox has access to what and when and how and at what time, etc. I could draw a line around a "file" or "directory" and proclaim it to be off-limits to everything but "banking app" or whatever.
All the signature verification in the world won't protect my sensitive data from being raw-dogged by this Verified(TM) binary blob. I understand it solves a different problem, but to me all this "proper package management" is theater if the other side of the equation is not being handled with the same amount of attention.
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.
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.
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 think for this kind of system to work, there has to be SOME kind of public/shared server to do the coordination. If the inviting node is behind a firewall then no amount of information can enable a guest node to connect to it without a node reachable by both.
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.
Partly. Partly because using EUF-CMA pins the record to the CA which makes membership deniability non-trivial which I don't love. It's not dumb, it's what Signal uses AFAIK and in transit message deniability is different than the signer. But still..
Going from starting the project two weeks ago to already having a flashy marketing site is another tell, unfortunately. As much as I would love to see a trustworthy version of this idea.
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.
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?
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?
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!
It is wrong to describe these P2P products as server-less. In order to connect two peers over WAN it needs a form of managed discovery process with a 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.
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.
I still have no comprehension of how curl piped into a shell command has become the default installation method for many projects (looking at you, Rust...). It breaks my brain as to how potentially unsafe it is.
Everyone’s eventually going to run a binary they downloaded from the same place, if you’ve already decided to do that, why is a curled install script worse?
Because it normalizes a practice that, while acceptable in context of a well known project with numerous dedicated eyeballs such as Rust language, is not a generally acceptable method of installing software.
Exactly this.
The correct way is to have M of N signatures on specific package manager pinned versions. And you trust the auditors to look at each new version, of a well-known package.
We should start a project and get it funded, to do just that. The money can go to LLM tokens for audits, at least, and hosting the multisigs and the package managers.
Anyone want to partner on this? See my profile on HN and email me.
The issue does not have to do with whether the download is a binary or source code. It has to deal with verifying the integrity of the download before installation.
Curl piped into a shell command provides no means to verify that the download is uncorrupted and unmodified before running it. For example, whenever I download software manually I check the downloaded file against the verified checksums to ensure that I have an unmodified version. Ideally I check this with gpg --verify on the signed checksum file (against the source's public key). This is a standard procedure for many organizations [1]. If you just download something and immediately run it without this step, you could potentially run a hacked version of the installation script.
[1] https://www.debian.org/CD/verify
For a Debian image, yeah, that is the threat.
But this is new software from someone no one trusts yet. Verifying the binary was not maliciously replaced by someone else doesn’t matter.
What we need here is a reproducible build made and published by an independent third-party.
Doesn't curl still validate ssl certificates? So long as I'm curling an https url from a trusted domain, don't I still have a chain of trust?
Curl does verify certificates [1]. That does confirm that your connection is to the right server, but it does not confirm that the files were unmodified.
SSL/TLS/HTTPS is more about encrypting the traffic and ensuring that there was no tampering with the file between you and the server. The steps that I describe are more about ensuring that there was no tampering between you and the original source. Those are two separate problems. If you just rely on HTTPS, somebody can replace the file on the server with a modified version, and you would not know.
[1] https://curl.se/docs/sslcerts.html
Every package manager does the same thing: run a script.
Would you feel safer if they offered a .deb? Do you unpack and inspect every .deb you install?
It's all about lowest friction + domain-name trust.
Depending on third party packaging (distribution-validated install) is much higher friction.
It's because people are too obsessed with providing complete instructions to incorporate any package manager into their instructions.
What we are really missing is an explicit progression from new software to maintained packages across distribution. As it is, each distro expects each package to have a maintainer, and very few people actually want to do that across several distros just to release their software. Generally, the expectation is to instead just wait around for people to make and maintain those packages by virtue of their own interest in your software, but it takes a while, and discoverability isn't automatic.
Look, you are going to run an executable. There is no way around it. At some point you are going to fork over inscrutable, opaque sets of bits to your CPU and loudly proclaim them to be executable. The CPU does not know, cannot know and does not care. At some point this will be done. No matter how many hashes, digests and public keys you verify, the bits will be interpreted as instructions and energy will be expended to explore a state space you were told is or leads to the promised land. If deception is involved in any step in this process, the end result will not be what you expect it to be. The peculiarities of the transport mechanism by which these bits were transported to your particular device of computation is very nearly the absolute least interesting thing to worry about in this whole shit-show.
It's completely insane our desktop OSes are holding highly private data like banking details with zero meaningful support for sand-boxing.
This whole problem would be a non-issue if we got proper auditing and management tools. If we could properly inspect our system's resources and see what sandbox has access to what and when and how and at what time, etc. I could draw a line around a "file" or "directory" and proclaim it to be off-limits to everything but "banking app" or whatever.
All the signature verification in the world won't protect my sensitive data from being raw-dogged by this Verified(TM) binary blob. I understand it solves a different problem, but to me all this "proper package management" is theater if the other side of the equation is not being handled with the same amount of attention.
You can create secure inaccessible directories for files via Cryptomator or Veracrypt or similar. It should be encouraged more IMO.
What would be your preferred solution?
so how did you install npm or docker?
Using a package manager usually
How did you install that package manager?
It's part of the OS
I didn't, it came with the system
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.
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.
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?
Iroh or n0 seems to solve that. It's they're underlying network protocol. When you're behind some cgnat, iroh falls back to public iroh relays hosted by n0: https://docs.iroh.computer/concepts/relays#public-relays
However you could self host one of these on a public server you own. Then you're independent.
I think for this kind of system to work, there has to be SOME kind of public/shared server to do the coordination. If the inviting node is behind a firewall then no amount of information can enable a guest node to connect to it without a node reachable by both.
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.
So it's effectively a clone of Nebula minus the need for a lighthouse.
Looks like no support for Windows :(
I don't know why your post was autoflagged but what makes your product unique from the rest?
> 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
What’s the sigh to, out of curiosity, just because this makes revocation hard?
Partly. Partly because using EUF-CMA pins the record to the CA which makes membership deniability non-trivial which I don't love. It's not dumb, it's what Signal uses AFAIK and in transit message deniability is different than the signer. But still..
Also that sentence structure is very claudelike.
The grandparent comment is correctly pointing out the sentence is an LLM tell.
"Membership is a question they ask a server" is a bogus sentence. "membership" is not a "question". It's syntactically valid semantic nonsense.
"Membership is dictated by a server" is one of several human sentences saying what that one is trying to.
Going from starting the project two weeks ago to already having a flashy marketing site is another tell, unfortunately. As much as I would love to see a trustworthy version of this idea.
https://github.com/rayfish/rayfish/commit/c49816e6dfba19e91a...
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.
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?
With IPv6 it's plausible that you can avoid collisions as long as you use an expensive hash function, but for v4 how do you avoid IP collisions?
With only 22 bits of entropy in your v4 addresses, you'll get accidental collisions with only ~2000 users.
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?
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!
If you have any previous experience in this domain and/or other relevant credentials it would help to mention them here as well.
> Honest [...]
> 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.
They can be spotted a mile away. Check the repo - 2 weeks to complete!
> Happy to get into ...
No reply to various questions an hour later. I guess they're not really watching.
could a MITM/poison-well attacks work here or susceptible ?
im also afraid of exploits disseminating from a mesh network it would be impossible to stop
great work