I had to find this post[0] to fully understand what Hyperswarm is.

You may or may not be surprised to hear that connecting two computers over the Internet is difficult. Software needs to negotiate NATs, firewalls, and limited IPv4 addresses. This is one of many reasons why cloud services are so entrenched: they accept connections more reliably than home or mobile computers.

This is a challenge for Dat and the Beaker browser. Dat is a peer-to-peer network which needs to reliably connect users over the Internet and over LANs. Beaker uses Dat to serve websites without needing servers.

We currently rely on a tracker to get users connected. This is a tracker that we run, which isn’t ideal because we want Dat to be decentralized. We tried using BitTorrent’s Mainline DHT but the results just weren’t very good. Mainline doesn’t have the tools to hole-punch so the connections frequently failed, and live tests tended to give a lot of false-positives with few good hits.

So mafintosh decided to solve this by creating a new DHT which fits our needs.

Announcing the Hyperswarm preview

Hyperswarm is a stack of networking modules for finding peers and creating reliable connections. Users join the swarm for a “topic” and query periodically for other peers who are in the topic. When ready to connect, Hyperswarm helps create a socket between them using either UTP or TCP.

Hyperswarm uses a Kademlia DHT to track peers and arrange connections. The DHT itself includes mechanisms to holepunch NATs. For LAN-based discovery, we currently use multicast DNS.

[0]: https://pfrazee.hashbase.io/blog/hyperswarm

I've been playing around with this, and it's pretty cool. Say I want to share a single file with a developer - maybe it's a config file, or a simple script, or a secret token. I would run:

  hyperbeam hey-jane-here-you-go < mygoodfile.txt

And Jane would run, on her end:

  hyperbeam hey-jane-here-you-go > fwips-good-file.txt

Note that the existence of npx makes this even simpler! You can tell your friend over discord "Hey, type in: 'npx hyperbeam hey-jane-here-you-go' and you'll get what I'm sending you. :)"

Note that "hey-jane-here-you-go" is effectively a one-time passphrase that I'm using, and will only be sent to computers listening for that exact passphrase at the time you send it. If you're sending military secrets, you might need to use very long and complicated passphrases. But if you're sending a cat picture, you could probably use "for-jane" without risk of collision.

> you could probably use "for-jane" without risk of collision

Sounds like it's begging for some troublemaker to build up a dictionary by cracking past exchanges and stock wordlists then intercepting other people's sessions as they show up.

(I know there is a timestamp based salt, but the attacker can even precompute the values for their dictionary far into the future)

This feels like the tor HS enumeration attack but a lot worse, since once you find one you can intercept its traffic.

It would be nice if there were a separate "name" and password, and the password used a zero knowledge secret comparison. Troublemakers could still block your sessions but they wouldn't have much luck trying to guess even fairly weak passwords.

From the documentation for hyperswarm, it appears the 'topic' (the shared secret) is limited to 32 bytes, so I don't see how that can be used for a very long crypto key.

Is 256 bits not enough? I'm curious what the standard is

It seems the difference between this and spiped is that this has a discovery protocol (DHT) and NAT hole punching.

Not sure how it compares to Magic Wormhole and the like.

it appears magic wormhole requires both clients to use a fixed known "mailbox" server (its own separate daemon) to communicate with and discover each other.

You don't need any server / daemon for magic wormhole. You can apt install it and just invoke the command without any server or setup.

Might the difference be that this is more about bidirectional communication and magic wormhole is unidirectional and specifically for file transfer?

Magic-wormhole does require a server, although it isn't a very demanding job. Brian Warner runs the default server.

This also requires a DHT though, it's not as if hyperbeam can work completely out of the box without third party systems. You'll need someone to run your default server somewhere either way.

Marilyn Manson?

Probably not the same Brian Warner, but I admit I've never seen them in the same room at the same time.

Reminds me of skypipe, from 8 years ago: https://github.com/progrium/skypipe

Used to work with a free dotcloud account, from the defunct company that started Docker.

This makes very little sense to me. Are you proposing to make your own router or switch with this stack in it, or add it onto an Arista or something?

What problem is this solving? Normally things like transit don’t have encryption because it occurs at a higher level.

To me it seems advantageous to keep the pipes dumb, curious of the rational behind this.

> What problem is this solving?

You have two machines on networks you don't know/control and no established identities/accounts. You want to pipe some data between them without setting up a more permanent network like ZeroTier with SSH or other access.

> Normally things like transit don’t have encryption because it occurs at a higher level.

OpenVPN, IPsec, nebula, ZeroTier, Hamachi, and many others would disagree.

Yeah, I'd be curious to see plaintext pros and cons between this and a quick Wireguard 1:1.

tl;dr: Hyperbeam is roughly a netcat tunnel that connects via a DHT topic instead of network address; use it where you want a secure one-off tunnel. (for example, to transfer a key for Wireguard)

Wireguard:

+ Can tunnel arbitrary IP traffic

~ Has stricter encryption, with full asymmetric keys (and optionally adding a symmetric key)

- requires permissions to load a kernel module and configure the network stack

Hyperbeam:

+ Only needs userland UDP sockets, not a kernel module

~ Derives its keys from a passphrase, so does not require transferring a full cryptographic key between devices

- is a single application-layer pipe, applicable in shell workflows but not transparently tunneling arbitrary applications

> Are you proposing to make your own router or switch with this stack in it,

this has nothing to do with that, to me this looks like the same general concept as using netcat (nc) to pipe text, but with auto discovery and encryption.

I shudder to think of a JavaScript adaptation of Hyperswarm.

— I design JavaScript IDS and this just cuts into it badly.

How does this deal with carrier NAT?

The Hyperswarm DHT has a hole-punching protocol