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?
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.
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.
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.
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 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.
Would you feel safer if they offered a .deb? Do you unpack and inspect every .deb you install?
Depending on third party packaging (distribution-validated install) is much higher friction.
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.
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.
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?
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.
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.
However you could self host one of these on a public server you own. Then you're independent.
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.
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.
As far as 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 direct connection 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 server to get its data and discover connections" -> "connect to them and repeat..." -> "connect further..." -> etc. There isn't a global lookup to connect to any server or retrieve any data, it's all friend-of-friend connections and you can (and do) lose connection to someone if they move too many nodes away. 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".
It may also be worth pointing out that DHTs also need stable hosts to serve as entry points, and apps that use them tend to hard-code a web URL where they can get a small list of those nodes.
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.
Sigh..
I like the project though. It looks very similar to something I vibed up recently, must be in the air
"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.
https://github.com/rayfish/rayfish/commit/c49816e6dfba19e91a...
Also that sentence structure is very claudelike.
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 only 22 bits of entropy in your v4 addresses, you'll get accidental collisions with only ~2000 users.
> 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.
No reply to various questions an hour later. I guess they're not really watching.
im also afraid of exploits disseminating from a mesh network it would be impossible to stop
great work