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!
Iroh can use multiple discovery methods, one of them is DNS. When a node comes online it publishes its addresses[1]. Another node can resolve from the node id those addresses and attempt a direct or hole-punched connection. If that works, relays aren't needed.
So agree not serverless, but also does not NEED a coordination server (unless you class DNS as a coordination server which is debatable).
We do have understanding of networks. Claude doesn't come up with concepts by itself. It is not too good to do that yet.
We run an HFT firm as a main enterprise, not an easy job. Requires a lot of network fundamentals understanding.
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.
Because if I download a binary package I can then fully inspect it before installation and be sure it's actually what I intended to install. If it's actually a package for my chosen variety of package manager it's probably signed too. Even if we're talking about just a single static binary distributed by the developer where I don't have the skills to usefully analyze it, the fact that I can verify that the binary I downloaded is the same as the binary everyone else using it on my platform has been using for however long without issue that still offers some level of trust.
By comparison, a curl|bash not only skips over my ability to do any of that but it also introduces two new potential paths to exploitation if a malicious user has control over the web server. There's the classic "hidden text that doesn't appear visually but will be in the copy/paste version" and the more complicated "server detection of manual download vs. curl|bash to deliver different content".
A curl|bash saves the "friction" of a `chmod +x` command and maybe an unzip/untar in exchange for introducing multiple different ways for malicious actions to be hidden.
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.
But where do you get the checksum from? I realize in some cases you are downloading from a mirror (thus as long as you trust the source of the checksum, that is quite useful) - but if it is from the same host - then you are just comparing against the same webserver.
You raise a good point. This is why people sign the checksums. The signature confirms that authenticity of the checksums. That somewhat moves the goalpost, though, since it then depends on where you got the source's public key, but it is still a more secure practice overall. The advantage of having the public key is that you only need to get it once and you can check many downloads later.
It is also possible to have a signed file that you can use to check the authenticity of a downloaded file directly without having to use checksums. Rust [1] does it that way for its other installation methods.
I get what you are saying, but my issue is not that it runs a script. My issue is that curl piped into a shell does not verify that the download is from the original source before running the script.
A .deb file has many advantages over curl piped into a shell. You can check the contents before installation, you can potentially verify the authenticity of the .deb file, and dpkg makes it possible to uninstall the package later since it keeps track of what it installed in an organized manner.
I won't say that I would feel safer with a .deb file. That depends on the source, what the package does, and other factors. Security is about tradeoffs. I personally find the tradeoffs associated with a .deb file better than the tradeoffs of curl piped into a shell, but I myself do not install .deb files in the first place since I get almost everything that I need from package repositories.
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.
Yeah, if the script only downloads something from GH releases and doesn’t even put it in a bin dir… why not just make it a normal download from the website
Said in the post, if they're savvy enough to inspect an install script they can click and download a binary for their OS, chmod +x and move to whatever bin they want.
Although really something like this you unproven you should compile it.
Until recently it was the one single time in my entire computers livespan I would paste the curl command into the terminal then everything else would be through package manager.
Now thanks to claude code etc it's been normalized that everyones doing it and normies who shouldn't be doing it are getting used to doing it.
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
thank you for the tip here! would you say tinc can work more or less like tailscale?
I saw this: "As long as one node in the VPN allows incoming connections on a public IP address (even if it is a dynamic IP address), tinc will be able to do NAT traversal, allowing direct communication between peers."
And wondered if tailscale was doing a bit more magic than tinc is here?
> And wondered if tailscale was doing a bit more magic than tinc is here?
Yes, tailscale, rayfish, zerotier and all use an existing network of relays to do nat traversal. Tinc doesn't provide that, but allows you to be completely independent if you get (or already have) a $5 VPS.
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?
Seems like nothing can really get around this without a server/relay/TUN/STUN server. Peer to Peer messaging just doesn't work otherwise.
Saw Iroh post on HN. Just wonder how it differ from Nostr, Scuttlebutt or Yggdrasil or DHT etc? Many from Nostr claim that they are successor of scuttlebutt, but many devs from Scuttlebutt highly dispute that.
Be good to get a comparison between these protocols for devs who want to use them.
Stable IP addresses solve it as well, but these kinds of things are not generally aimed at contexts where those are an option. Even IPv6 isn't generally stable - the prefix is ISP-defined and tends to vary similarly to IPv4 with CGNAT.
There's also "dynamic DNS", which is basically just caching one side of that server/relay/TUN/STUN handshake, and relying on DNS for global discovery.
For Iroh vs Scuttlebutt / DHT, I'll break that into two parts:
1) Iroh uses DHT for host discovery: https://docs.iroh.computer/about/faq#how-is-iroh-different-f... , and Iroh is more about "use that DHT to get a usually-direct connection globally and then you can do whatever you want", while Scuttlebutt is strictly "... and use that connection to exchange append-only logs via gossip, to implement the Scuttlebutt protocol". (Iroh does have some first-party protocols you can use, but it's lower level in general)
2) Scuttlebutt isn't DHT-based, it's "connect to a known IP to get its data and discover connections" -> "connect to them and repeat..." -> "connect further..." -> etc, plus limited-hop feed replication by default. There isn't a global lookup to connect to any member or retrieve any data, it's all friend-of-a-friend connections and you can (and do) lose connection to someone if they get a new IP address and there's no F-o-a-F(-o-a-F(...)) replication route from them that reaches you (rare in practice since they likely re-connected to people they follow, which eventually trickles data through the mesh similarly to before). This is also part of the reason that it works instantly when you're on the same network as someone - it's less "it can work locally if you don't have internet access" and more "local is just a discovery method, the internet isn't special at all because it's all just direct connections".
And as far as I understand Nostr, it's conceptually similar to Scuttlebutt, but with direct support for centralizing for performance (relays) and some degree of mutability / forgetfulness / etc. Scuttlebutt is a bit extreme about its logs being immutable and the only way to exchange data, and it's part of the reason it can have rather major perf issues (like needing to pull gigabytes of data before you can discover a feed's display name). (I say this as a fan of Scuttlebutt in principle, but not in practice - there are lots of practical issues with existing implementations that could be solved, but haven't, and it's a large part of why the ecosystem split into other protocols)
It may also be worth pointing out that DHTs also need stable hosts to serve as initial bootstrappers, and apps that use them tend to hard-code a web URL where they can get a small list of those nodes. They just use them to discover other nodes, and save them for next time so the bootstrappers aren't constantly needed.
Iroh doesn't use DHT as its main discovery mechanism. It uses DNS/pkarr and relays as the primary method. DHT is a separate feature if folks like to do that, we don't have it on by default and don't have it on the public relays.
The whole idea is p2p but trying to be realistic about what network environments actually look like.
There has definitely been a lot of blind-idealism in a lot of P2P systems, yea. Though sometimes that's because it was/is just a PoC to see if it works at all, and then it grows too large to change / needs to be forked.
Iroh is definitely near the top of my "play with it some time" list, that pragmatism is very important for building normal things that normal people will be using :)
I see, so a coordination server is necessary which kinda somewhat defeats the "mesh" claim, though I do wonder if achieving this in a manner similar to DHT could eliminate the centralized entity controlling the servers at least, allowing the "peer-to-peer mesh" claim to be there in spirit.
Not that I have anything against the software or company to be clear, just that I wish one of these p2p vpns would be _totally_ actually independent of any coordination server or central entity!
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.
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.
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)
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
But ... Rayfish creates a layer 3 network too. It assigns IP addresses to each node. I don't really see why it matters from this point of view whether it uses Iroh or something else to provide its backhaul. That's like saying Wireguard works at layer 4 because it uses UDP. The whole point of VPNs is to offer some kind of tunneling over higher level protocols.
Computers are pretty fast these days. It depends on exactly what kind of general purpose use you're talking about. Trying to push 10 Gbps through a slow old machine? You're doomed. Trying to run SSH, browse the web, or even watch Netflix over a tunnel? Probably fine to send the packet up and down the stack an extra time or two.
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
I believe the main usecases for this is not requiring changing code, not requiring adding a reverse proxy in front of code I can't change, and "OSI"ish protocols (as in, not really TCP protocols - Remote Database Access, Oracle Net Services/Java Message Queues/X.500, LDAP/smb/ncacn_np).
Those days, rather that actual "vpn overlay", I use Tailscale myself mostly for the Tailscale Funnel - a somewhat stable, yet free arbitrary DNS and free reverse proxy termination of incoming data for anonymous users.
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.
Actually the flashy website was built 4 years ago by another person.
We actually tried to build it 4 years ago, but other ventures with higher upside kept our focus.
Now you get a VPN for free, no strings attached, although it is vibecoded you still complain :cry:
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..
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.
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?
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.
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
Because it's security related, the trust needed to consider using it is just higher.
Trust at two levels: who are you? What HFT firm do you run? How do we know you are actually this HFT leader? What are you doing in the HFT firm that lends credibility to build a project like this? I.e. if you lead the sales team, and have no software dev background, it doesn't increase trust in this project. If you built all the software for the HFT firm, that matters.
Since it's security related, we want there to be signals in the project that we can trust it to not start sending all our data to some bad actor state or org.
Then there is trust at the code level... Does it work? Will it continue to work?
You built it in two weeks because, for the last four years, you were busy with other things. If you get busy again, will the project lag for the next four years?
You don't owe us any of these answers. It's OSS, engage at whatever level you want. But, understand that when you publish your efforts to a place like HN, we are going to find and mention the things that make us uncomfortable.
That said, it's a good sign that people are pushing back. It is a cool project and fits a real need. So if you can increase the trust signals in the project, I think you will get more users... If you really want them. More users means more critique. :)
I hope you do make an effort to increase the trust signals and keep working on the project because I'd like to use it.
It's the attention economy. You're engaging in something that is related to privacy and security, thus the credibility of the author in this domain will also be a factor for people wanting to invest their time exploring these solutions.
To not care who you are would mean not only having to review the current code as is, but to review every update that follows as possibly written by a hostile party. Ie, the time invested would be several times of that invested in something written by a more trusted party.
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.
Hello! dev here.
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!
Iroh can use multiple discovery methods, one of them is DNS. When a node comes online it publishes its addresses[1]. Another node can resolve from the node id those addresses and attempt a direct or hole-punched connection. If that works, relays aren't needed.
So agree not serverless, but also does not NEED a coordination server (unless you class DNS as a coordination server which is debatable).
[1] https://docs.iroh.computer/concepts/address-lookup#endpoint-...
>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.
But that would take understanding network fundamentals, architecture, etc. Who needs any of that cruft any longer?
We do have understanding of networks. Claude doesn't come up with concepts by itself. It is not too good to do that yet. We run an HFT firm as a main enterprise, not an easy job. Requires a lot of network fundamentals understanding.
Lol thats right who needs this now we have gpt duh
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.
Because if I download a binary package I can then fully inspect it before installation and be sure it's actually what I intended to install. If it's actually a package for my chosen variety of package manager it's probably signed too. Even if we're talking about just a single static binary distributed by the developer where I don't have the skills to usefully analyze it, the fact that I can verify that the binary I downloaded is the same as the binary everyone else using it on my platform has been using for however long without issue that still offers some level of trust.
By comparison, a curl|bash not only skips over my ability to do any of that but it also introduces two new potential paths to exploitation if a malicious user has control over the web server. There's the classic "hidden text that doesn't appear visually but will be in the copy/paste version" and the more complicated "server detection of manual download vs. curl|bash to deliver different content".
A curl|bash saves the "friction" of a `chmod +x` command and maybe an unzip/untar in exchange for introducing multiple different ways for malicious actions to be hidden.
The web server is able to detect and change the response of a curl | sh thus a malicious actor could avoid some detection.
Having a binary also allows for antivirus software to be ran on it before deciding to run the binary itself or not.
I am not sure if curl | sh bypass sandboxing by default, but definitely is the case when compared to flatpak or just regular packaging
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
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
But where do you get the checksum from? I realize in some cases you are downloading from a mirror (thus as long as you trust the source of the checksum, that is quite useful) - but if it is from the same host - then you are just comparing against the same webserver.
You raise a good point. This is why people sign the checksums. The signature confirms that authenticity of the checksums. That somewhat moves the goalpost, though, since it then depends on where you got the source's public key, but it is still a more secure practice overall. The advantage of having the public key is that you only need to get it once and you can check many downloads later.
It is also possible to have a signed file that you can use to check the authenticity of a downloaded file directly without having to use checksums. Rust [1] does it that way for its other installation methods.
[1] https://forge.rust-lang.org/infra/other-installation-methods...
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.
A webserver could alter the payload based on the client.
An evil person could present a normal install script for other browsers and randomly present a malicious one for curl clients.
At least with the downloaded file, that is the thing you get.
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?
I get what you are saying, but my issue is not that it runs a script. My issue is that curl piped into a shell does not verify that the download is from the original source before running the script.
A .deb file has many advantages over curl piped into a shell. You can check the contents before installation, you can potentially verify the authenticity of the .deb file, and dpkg makes it possible to uninstall the package later since it keeps track of what it installed in an organized manner.
I won't say that I would feel safer with a .deb file. That depends on the source, what the package does, and other factors. Security is about tradeoffs. I personally find the tradeoffs associated with a .deb file better than the tradeoffs of curl piped into a shell, but I myself do not install .deb files in the first place since I get almost everything that I need from package repositories.
It's all about lowest friction + domain-name trust.
Depending on third party packaging (distribution-validated install) is much higher friction.
Those that ask for trust, deserve no trust.
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.
you can also do `cargo install rayfish`. But not everybody has cargo, etc etc etc
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.
If your files and folders are rw even in a encrypted form, you're still vulnerable to ramsomware if you don't have some sort of immutable ro backups.
Yeah, if the script only downloads something from GH releases and doesn’t even put it in a bin dir… why not just make it a normal download from the website
Because the script can do branching logic and checks that you otherwise have to explain to the user.
Not defending the practice, I don’t like it. But the intent is to make it easier.
What would be your preferred solution?
Said in the post, if they're savvy enough to inspect an install script they can click and download a binary for their OS, chmod +x and move to whatever bin they want.
Although really something like this you unproven you should compile it.
so how did you install npm or docker?
Using a package manager usually
How did you install that package manager?
Until recently it was the one single time in my entire computers livespan I would paste the curl command into the terminal then everything else would be through package manager.
Now thanks to claude code etc it's been normalized that everyones doing it and normies who shouldn't be doing it are getting used to doing it.
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.
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.
Thanks for taking the time to reply.
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
thank you for the tip here! would you say tinc can work more or less like tailscale?
I saw this: "As long as one node in the VPN allows incoming connections on a public IP address (even if it is a dynamic IP address), tinc will be able to do NAT traversal, allowing direct communication between peers."
And wondered if tailscale was doing a bit more magic than tinc is here?
> And wondered if tailscale was doing a bit more magic than tinc is here?
Yes, tailscale, rayfish, zerotier and all use an existing network of relays to do nat traversal. Tinc doesn't provide that, but allows you to be completely independent if you get (or already have) a $5 VPS.
Some other similar projects: https://github.com/anderspitman/awesome-tunneling#overlay-ne...
Interesting to see this built on Iroh.
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.
Seems like nothing can really get around this without a server/relay/TUN/STUN server. Peer to Peer messaging just doesn't work otherwise.
Saw Iroh post on HN. Just wonder how it differ from Nostr, Scuttlebutt or Yggdrasil or DHT etc? Many from Nostr claim that they are successor of scuttlebutt, but many devs from Scuttlebutt highly dispute that.
Be good to get a comparison between these protocols for devs who want to use them.
IPv6 gets around it!
Stable IP addresses solve it as well, but these kinds of things are not generally aimed at contexts where those are an option. Even IPv6 isn't generally stable - the prefix is ISP-defined and tends to vary similarly to IPv4 with CGNAT.
There's also "dynamic DNS", which is basically just caching one side of that server/relay/TUN/STUN handshake, and relying on DNS for global discovery.
For Iroh vs Scuttlebutt / DHT, I'll break that into two parts:
1) Iroh uses DHT for host discovery: https://docs.iroh.computer/about/faq#how-is-iroh-different-f... , and Iroh is more about "use that DHT to get a usually-direct connection globally and then you can do whatever you want", while Scuttlebutt is strictly "... and use that connection to exchange append-only logs via gossip, to implement the Scuttlebutt protocol". (Iroh does have some first-party protocols you can use, but it's lower level in general)
2) Scuttlebutt isn't DHT-based, it's "connect to a known IP to get its data and discover connections" -> "connect to them and repeat..." -> "connect further..." -> etc, plus limited-hop feed replication by default. There isn't a global lookup to connect to any member or retrieve any data, it's all friend-of-a-friend connections and you can (and do) lose connection to someone if they get a new IP address and there's no F-o-a-F(-o-a-F(...)) replication route from them that reaches you (rare in practice since they likely re-connected to people they follow, which eventually trickles data through the mesh similarly to before). This is also part of the reason that it works instantly when you're on the same network as someone - it's less "it can work locally if you don't have internet access" and more "local is just a discovery method, the internet isn't special at all because it's all just direct connections".
And as far as I understand Nostr, it's conceptually similar to Scuttlebutt, but with direct support for centralizing for performance (relays) and some degree of mutability / forgetfulness / etc. Scuttlebutt is a bit extreme about its logs being immutable and the only way to exchange data, and it's part of the reason it can have rather major perf issues (like needing to pull gigabytes of data before you can discover a feed's display name). (I say this as a fan of Scuttlebutt in principle, but not in practice - there are lots of practical issues with existing implementations that could be solved, but haven't, and it's a large part of why the ecosystem split into other protocols)
It may also be worth pointing out that DHTs also need stable hosts to serve as initial bootstrappers, and apps that use them tend to hard-code a web URL where they can get a small list of those nodes. They just use them to discover other nodes, and save them for next time so the bootstrappers aren't constantly needed.
One of the n0/iroh devs here.
Iroh doesn't use DHT as its main discovery mechanism. It uses DNS/pkarr and relays as the primary method. DHT is a separate feature if folks like to do that, we don't have it on by default and don't have it on the public relays.
The whole idea is p2p but trying to be realistic about what network environments actually look like.
> It uses DNS/pkarr and relays as the primary method.
Thanks for clarifying that. So does that mean Iroh still require a DNS server or domain name even though it doesn't rely on IP address?
I thought dial by key means the other party just need to be on internet and has the right key/pubic identifier then they can reached.
Where does the message resides if the other end is NOT online?
There has definitely been a lot of blind-idealism in a lot of P2P systems, yea. Though sometimes that's because it was/is just a PoC to see if it works at all, and then it grows too large to change / needs to be forked.
Iroh is definitely near the top of my "play with it some time" list, that pragmatism is very important for building normal things that normal people will be using :)
I see, so a coordination server is necessary which kinda somewhat defeats the "mesh" claim, though I do wonder if achieving this in a manner similar to DHT could eliminate the centralized entity controlling the servers at least, allowing the "peer-to-peer mesh" claim to be there in spirit.
Not that I have anything against the software or company to be clear, just that I wish one of these p2p vpns would be _totally_ actually independent of any coordination server or central entity!
It’s not a coordinator server, it’s a relay, a dumb pipe, for when the peers can’t talk to each other directly because of a CGNAT.
Presumably you could disable it and the VPN would continue to work, just not on CGNATs.
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.
I don't know why your post was autoflagged but what makes your product unique from the rest?
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 cool, I'd like to try it, but how can I use it to connect peers over the public internet?
3 vpn segments:
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?
So it's effectively a clone of Nebula minus the need for a lighthouse.
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
Not really. Nebula creates a layer-3 network[1]. Rayfish is built upon Iroh which is a layer-7 network.
[1]: https://nebula.defined.net/docs/#technical-details
But ... Rayfish creates a layer 3 network too. It assigns IP addresses to each node. I don't really see why it matters from this point of view whether it uses Iroh or something else to provide its backhaul. That's like saying Wireguard works at layer 4 because it uses UDP. The whole point of VPNs is to offer some kind of tunneling over higher level protocols.
I always imagined that the application layer had some kind of extra overhead that would be unacceptable for general purpose use.
Computers are pretty fast these days. It depends on exactly what kind of general purpose use you're talking about. Trying to push 10 Gbps through a slow old machine? You're doomed. Trying to run SSH, browse the web, or even watch Netflix over a tunnel? Probably fine to send the packet up and down the stack an extra time or two.
rayfish is a layer-69
Looks like no support for Windows :(
Not yet. I'll support it in the future
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
I believe the main usecases for this is not requiring changing code, not requiring adding a reverse proxy in front of code I can't change, and "OSI"ish protocols (as in, not really TCP protocols - Remote Database Access, Oracle Net Services/Java Message Queues/X.500, LDAP/smb/ncacn_np).
Those days, rather that actual "vpn overlay", I use Tailscale myself mostly for the Tailscale Funnel - a somewhat stable, yet free arbitrary DNS and free reverse proxy termination of incoming data for anonymous users.
> Remote Database Access
Postgres also has TLS + oauth2 support
> rather that actual "vpn overlay", I use Tailscale myself
I actually already had tailscale in mind when talking about "vpn overlays" :D
Yes, you can also do it. VPN is just one of those applications to be honest. Think of it as relaying packets over iroh.
> 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?
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...
Actually the flashy website was built 4 years ago by another person. We actually tried to build it 4 years ago, but other ventures with higher upside kept our focus. Now you get a VPN for free, no strings attached, although it is vibecoded you still complain :cry:
If you dont like it dont use it
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.
English is not my mothertongue, therefore I told Claude (and GLM-5.2) to improve the wording as much as they could.
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.
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.
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.
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?
If you dont like the use of AI dont use it. Very simple. I went from idea (4 years ago) to implementation in 2 weeks.
Part of the n0/iroh team, cool to see this here, looking forward to play with it :)
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.
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!
Thank you. I am working on the android app right now
If you have any previous experience in this domain and/or other relevant credentials it would help to mention them here as well.
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
Because it's security related, the trust needed to consider using it is just higher.
Trust at two levels: who are you? What HFT firm do you run? How do we know you are actually this HFT leader? What are you doing in the HFT firm that lends credibility to build a project like this? I.e. if you lead the sales team, and have no software dev background, it doesn't increase trust in this project. If you built all the software for the HFT firm, that matters.
Since it's security related, we want there to be signals in the project that we can trust it to not start sending all our data to some bad actor state or org.
Then there is trust at the code level... Does it work? Will it continue to work?
You built it in two weeks because, for the last four years, you were busy with other things. If you get busy again, will the project lag for the next four years?
You don't owe us any of these answers. It's OSS, engage at whatever level you want. But, understand that when you publish your efforts to a place like HN, we are going to find and mention the things that make us uncomfortable.
That said, it's a good sign that people are pushing back. It is a cool project and fits a real need. So if you can increase the trust signals in the project, I think you will get more users... If you really want them. More users means more critique. :)
I hope you do make an effort to increase the trust signals and keep working on the project because I'd like to use it.
It's the attention economy. You're engaging in something that is related to privacy and security, thus the credibility of the author in this domain will also be a factor for people wanting to invest their time exploring these solutions.
To not care who you are would mean not only having to review the current code as is, but to review every update that follows as possibly written by a hostile party. Ie, the time invested would be several times of that invested in something written by a more trusted party.
> 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.
When the wise man points to the moon, the fool looks at the finger
> Happy to get into ...
No reply to various questions an hour later. I guess they're not really watching.
I'm sure any moment now the next openclaw heartbeat will fire.
They can be spotted a mile away. Check the repo - 2 weeks to complete!
bro ditched the car to use the horse
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