So it doesn’t need any port forwarding, and works on CGNAT? How the “NAT hole punching” works? Both clients connect to something on IPFS?
Afaik, for DHT with torrent, clients need to know at least one tracker, what is the “tracker” here? Something on IPFS? Who am I sending my IP addresses?
How much overhead does this add to speed? I love with Wireguard, that it’s barely noticeable, really close to p2p speeds, OpenVPN was awful in this regard.
DHT is autonomous and does not require a tracker. Usually it is only used as a fallback as a regular tracker is quicker. It’s p2p, and is split accross people hosting it.
Nix just calls the *.nix files, it’s still go under the hood. PKGBUILD is similar to the flake.nix and package.nix files to me, but I have no experience with nix.
First off great find. I didn’t think to check the AUR. I personally wouldn’t use it as that version is 3 years out of date but its existence means that it might be entirely possible to get a non Nix version. I’m not sure I fully understand why it needs Nix OS but what do I know.
It is all libp2p magic
There have been lots if talks on libp2p and Nat traversal. I suggest you check them out. How it actually works is pretty complex and requires someone more knowledgeable than me to explain. One way it works is that both devices start a TCP connection at the same time which gets the proper ports to open up.
AUR packages ending with"-git" or “-svn” always pull the latest commit from source. The version number means that was the last time the packager had to change something on the PKGBUILD script, not the actual version which would be installed.
Where should I look? Where were these talks? I’m interested.
It says it connects to a “Hole Punch Coordination (DCUtR - Direct Connection Upgrade through Relay)”. So for NAT traversal to work, you need a third party, this relay. As I expected. I guess you can self host this, but than you could just host a wireguard server. I guess if you are on a locked down network where you cannot connect to any relay (e.g. how the Chinese Great Firewall works technically they could block it) you can’t initiate a connection behind a NAT.
Nonetheless it seems interesting, but no magic here. Maybe the big difference that the relay servers are distributed, so no central authority to block easily.
That doesn’t match my experience with AUR at all. Usually it pulls a specific git revision and checks the hash. This also ensures that the build shouldn’t suddenly fail to some extent.
Though it’s entirely possible that it’s not like this for all packages, though I find it kind of counterintuitive since your package manager wouldn’t know when to perform an update in this case.
In the PKGBUILD file you can list sources (line 12,13) and their respective checksums (line 14,15). In this PKGBUILD there are 2 sources: the first is the systemd unit file, it’s coming from the package’s AUR repo, not from upstream, you can see its checksum. The second source is the actual source, and you can see, it’s checksum is ‘SKIP’ so it shouldn’t be checked.
With these kind of packages you can’t get notified if there is an update available, but if you install it again with your favorite AUR helper it would update itself for the latest version. It calculates version number from the latest commit hash, before building and installing, so if that is the same it won’t update again.
Interesting, it’s on AUR, I will try it.
So it doesn’t need any port forwarding, and works on CGNAT? How the “NAT hole punching” works? Both clients connect to something on IPFS?
Afaik, for DHT with torrent, clients need to know at least one tracker, what is the “tracker” here? Something on IPFS? Who am I sending my IP addresses?
How much overhead does this add to speed? I love with Wireguard, that it’s barely noticeable, really close to p2p speeds, OpenVPN was awful in this regard.
DHT is autonomous and does not require a tracker. Usually it is only used as a fallback as a regular tracker is quicker. It’s p2p, and is split accross people hosting it.
The PKGBUILD looks like it is just building via go. I’m not sure how you would configure it without Nix. I’ll try building it.
Nix just calls the *.nix files, it’s still go under the hood. PKGBUILD is similar to the flake.nix and package.nix files to me, but I have no experience with nix.
First off great find. I didn’t think to check the AUR. I personally wouldn’t use it as that version is 3 years out of date but its existence means that it might be entirely possible to get a non Nix version. I’m not sure I fully understand why it needs Nix OS but what do I know.
It is all libp2p magic
There have been lots if talks on libp2p and Nat traversal. I suggest you check them out. How it actually works is pretty complex and requires someone more knowledgeable than me to explain. One way it works is that both devices start a TCP connection at the same time which gets the proper ports to open up.
AUR packages ending with"-git" or “-svn” always pull the latest commit from source. The version number means that was the last time the packager had to change something on the PKGBUILD script, not the actual version which would be installed.
Where should I look? Where were these talks? I’m interested.
Edit: I found the whitepaper about hole punching: https://research.protocol.ai/publications/decentralized-hole-punching/
It says it connects to a “Hole Punch Coordination (DCUtR - Direct Connection Upgrade through Relay)”. So for NAT traversal to work, you need a third party, this relay. As I expected. I guess you can self host this, but than you could just host a wireguard server. I guess if you are on a locked down network where you cannot connect to any relay (e.g. how the Chinese Great Firewall works technically they could block it) you can’t initiate a connection behind a NAT.
Nonetheless it seems interesting, but no magic here. Maybe the big difference that the relay servers are distributed, so no central authority to block easily.
That doesn’t match my experience with AUR at all. Usually it pulls a specific git revision and checks the hash. This also ensures that the build shouldn’t suddenly fail to some extent.
Though it’s entirely possible that it’s not like this for all packages, though I find it kind of counterintuitive since your package manager wouldn’t know when to perform an update in this case.
It’s documented in the wiki, they are called VCS packages, and it’s not the usual, they work a bit differently: https://wiki.archlinux.org/title/VCS_package_guidelines
You can see in this instance, that it skips the sha checking for upstream source, in line 15 of the PKGBUILD it says ‘SKIP’: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=hyprspace-git#n15
sha1sums parameter is documented in the wiki: https://wiki.archlinux.org/title/PKGBUILD#sha1sums
In the PKGBUILD file you can list sources (line 12,13) and their respective checksums (line 14,15). In this PKGBUILD there are 2 sources: the first is the systemd unit file, it’s coming from the package’s AUR repo, not from upstream, you can see its checksum. The second source is the actual source, and you can see, it’s checksum is ‘SKIP’ so it shouldn’t be checked.
With these kind of packages you can’t get notified if there is an update available, but if you install it again with your favorite AUR helper it would update itself for the latest version. It calculates version number from the latest commit hash, before building and installing, so if that is the same it won’t update again.