[dspillett]

Not the author, but:

- Yes, this will be quickly abused now it has been made more public, unless the service at bore.pub has the shared secret set (have you tried to connect?).

- The service may currently be running on a host that has “unlimited” bandwidth as a limited speed, so there may be no extra bandwidth feeds to offset (though the bandwidth will be increasingly saturated and so progressively much slower for each active connection).

- I don't think scaling was intended, more than people would run their own version on their own service. Scaling could be achieved to an extent with a fatter bandwidth allowance (a faster rate cap, if I'm right about that being the limit not a fixed bandwidth cap). Unless the service is running on a very fast link on a very slow (or congested) CPU, bandwidth will likely be the limiting factor not anything else. If the process is large and forks for each connection then memory could be a limitation, but that could be increased easily or you could have multiple servers on the same name using a load-balancer or simple round-robin DNS.

Though I'm not sure what this offers beyond using a reverse SSH tunnel, if you have your own server/VM to host it on. Of course if you do not have your own external server but an account on someone else's which does not allow tunnels like that then this tool could be useful, but you could also get your own VM with full access for not much more than $1/month.

[ekzhang]

See my comment below about differences in goals from remote SSH port forwarding (which I also use regularly).

Scaling issues are not a problem for me, but thank you for your concern. The nice thing about scaling is that you only have to worry about it if your service is used a lot, and bore is just a small hobby project. I mention in the FAQ where I’m currently at with CPU/memory usage and network egress; it’s very cheap and not even close to hitting limits. (thanks Rust!)