One suggestion for the untrusted-PC part: bitbang serve -ephemeral. That uses a throwaway identity that dies with the process, so the URL is dead the moment you kill it -- rather than persisting and still working later from whatever browser history it's sitting in. --pin adds a second factor if you want one.

The pairing code is possibly handy too. If you'd rather not type a long URL on an unfamiliar machine, go to bitba.ng, enter the 6-digit code, and confirm the number it shows you back on the Pi.

And yes -- open source and self-hostable is a big part it. The other half is that the connecting side can be a browser, so there's no client to install on whatever you happen to be sitting at. Tailscale is a network you join, this is closer to a link you hand someone.

Also taking "read a whole bunch of text first" as a hint. That comparison probably belongs higher up the README.

A browser can't join a DHT though because of no UDP sockets, so the connecting side would need a native client, which is the thing bitbang avoids. And DHT lets you locate the peer, but you still need somewhere to trade SDP and ICE candidates, so the rendezvous stays either way I think.

What I can do is keep the broker small enough that self-hosting is realistic, which is where it is now -- no accounts, no registry, nothing that grants access, only a simple broker.

On cost: I pay for it on bitba.ng and it's capped right now at 10 minutes per connection (mostly to prevent people from connecting and walking away). But you're not stuck with mine -- the signaling server is open source, so you can self-host and point it at your own TURN. The Python library supports "bring your own TURN" by specifying (--turn-url, --turn-user, --turn-credential); adding the same flags to the CLI is a small gap I need to close. There are TURN providers that have reasonably generous free tiers.

The friends case is exactly the gap I kept running into. A mesh VPN is fine for my own devices and hopeless the moment someone else needs in, because now they're installing a client and making an account to look at one thing. Here they get a link.

Baking it into self-hosting flows is the right instinct and I'd love help figuring out where it fits. There's already an OctoPrint plugin; Jellyfin seems like the obvious next one.

On generalizing: wg wins for "put these machines on one network." WebRTC wins on reach, because the connecting side can be a browser -- a phone, a borrowed laptop, a machine you don't administer -- with nothing installed. A wg jumpbox still needs a client on both ends and a public IP for the box. Different tradeoff rather than a strictly better one.

The trick to having no accounts: a device's identity is the hash of its public key, so browser and device verify each other directly. The server keeps no registry, authorizes nothing, and isn't in the data path -- it brokers the introduction and steps aside. About 75% of connections go direct P2P. The rest fall back to a TURN relay that only sees ciphertext. The server is open source and self-hostable -- and since it's out of the data path, cheap to run.

BitBang started on an ESP32, as the networking for a tiny telepresence robot. Embedded development is difficult and slow, so this CLI is where I've beaten the security model into shape. The embedded version is next. :)

Comments URL: https://news.ycombinator.com/item?id=49123789

Points: 90

# Comments: 37

Comments URL: https://news.ycombinator.com/item?id=47675661

Points: 4

# Comments: 1

I built qast because I couldn’t find a tool that “just works” for casting content to a TV. Some TVs support YouTube natively, some do screen mirroring, and only a handful actually show up in Chrome's cast menu. Even when you do get a connection, one TV might accept MKV but not WebM, while another just drops the audio entirely.

qast sidesteps the compatibility problem. It takes whatever you give it -- a local file, a YouTube URL, your desktop screen, a specific window, or a webpage rendered via headless Chromium -- and transcodes it on the fly to H.264/AAC. Because practically every smart TV in the last decade supports this lowest common denominator, it just works.

(Note: You currently need to be running Linux to use it. macOS/Windows support is on the roadmap).

Under the hood:

Written in Python.

Relies on ffmpeg for the heavy lifting (transcoding, window capture).

Uses yt-dlp for extracting web video streams.

Uses Playwright to render web dashboards in a headless browser before casting.

Auto-discovers Chromecast, Roku, and DLNA devices on your local network.

Mostly, I want to get some early feedback. If you have experience wrestling with this problem (especially the endless DLNA quirks) or have ideas for other useful features, that would be fantastic as well.

Comments URL: https://news.ycombinator.com/item?id=47232340

Points: 4

# Comments: 1