What StreamBond does
StreamBond was built for sustained Linux uploads such as an OBS stream. A machine may have two internet connections available, but an ordinary TCP upload still follows one route. StreamBond gives selected application connections a Multipath TCP path through both uplinks without taking over the rest of the machine’s traffic.
An application opts in by binding to StreamBond’s local TUN address. Connections from that address enter a userspace TCP stack and travel to a self-hosted relay. Applications that do not bind to it continue using the host’s normal networking.
Two isolated paths
The client creates one network namespace and one Tailscale instance for each physical uplink. A separate bond namespace exposes both paths to the Linux MPTCP stack, which can create subflows across them. StreamBond reports the observed path and MPTCP state, while the kernel remains responsible for deciding how traffic moves between subflows.
The relay authenticates the request, applies its destination policy, and opens a normal TCP connection to the requested destination. Only the client-to-relay leg uses MPTCP. The documentation spells out where traffic is encrypted, where it terminates, and what the relay can see.
Checking the connection
streambondctl checks host readiness, enrols the two Tailscale identities, reports path state, and watches active connections. Installation packages include systemd units, example configuration, checksums, and uninstall scripts. Normal host routing and an existing Tailscale installation stay separate from StreamBond’s own resources.
Version 0.1.0 supports Linux at both ends, IPv4 application traffic, TCP, and versioned archive distribution. Traffic split and throughput depend on the two paths and the Linux MPTCP scheduler, so the release makes no fixed performance claim.