Roundtripping command outputs

[remram44]

The front page lists two commands:

• exec > >(nc streamhut.io 1337) 2>&1
• exec 3<>/dev/tcp/streamhut.io/1337 && head -1 <&3 && exec &> >(tee >(cat >&3))

However those work very differently, since the second one will only write to the socket (cat >&3) and duplicate the terminal output to the socket and terminal (tee), leaving streamhut's socket output on fd 3 (which doesn't go to the terminal), while the first one prints pipes all output through streamhut, relying on it printing back everything it gets.

This means that the first command:

• introduces a noticeable delay
• needs streamhut.io to send back everything it receives (wasting bandwidth)
• it's technically possible for streamhut to subvert your command outputs (not just changing what's printed on the website, but changing what's printed to your terminal)

I'm not completely sure how to fix the command since exec 3<>(nc streamhut.io 1337) won't work 🤔

Otherwise this app looks very nice! I was just surprised to see that those two commands, which are presented as equivalent (just the "no nc alternative") are in fact not (second is much better) and that the workings of the first one puts more demand on your infrastructure.

[remram44]

Something like this maybe?

exec 3> >(nc streamhut.io 1337 | head -1) && exec &> >(tee >(cat >&3))

It looks like streamhut is sending the first of my text back before the "streaming to ..." line though (changing && to && sleep 1 && fixes) #14. But that's not a problem anymore once you turn off echo in the server.

[miguelmota]

Hey @remram44 great observation! that's right, the first command is less bandwidth efficient but it's easier to reason about for people that just want something short and sweet that works which is why it's shown as the primary command.

The second command although more efficient is harder to decipher what's going on and more off-putting for people to run on their computers. I'll add explanations to the commands but open to shorter alternatives!

Ideally people use the streamhut cli to pipe data once they're more comfortable with the product since the cli will make things very simple to send and receive streams.

Streamhut is Apache 2.0 licensed so anyone concerned with censorship can self-host. Streamhut is a side project and I'm not making any money on it nor do I censor content. If there's a abuse then I might shift to a different model (like requiring user login) for the hosted instance.

[remram44]

You do make a good point about people understanding what they run -- my command definitely looks more contrived. Oh well, if nothing else it will be here if someone searches for it.