44 comments

[ 4.9 ms ] story [ 86.2 ms ] thread
Awesome, just wish I could install the server locally, would rather link someone at work to an internal URL. Some of the output at work would be too sensitive to trust to any third party.

This is the first I see software like this, has anybody seen other similarly useful utilities? I think it's invaluable to be able to share your console output with coworkers in real time so they can also help to troubleshoot.

>I think it's invaluable to be able to share your console output with coworkers in real time so they can also help to troubleshoot.

You can use tmux's shared sessions via ssh for that, no?

I've never tried any of the following, but have come across them:

* https://github.com/vitorbaptista/shellshare

* https://tmate.io/

* https://github.com/yudai/gotty - actually gives you a tty in a browser

* https://github.com/dtinth/ttycast

(edit: formatting)

tmate is awesome for pair programming
But it goes through a third party server instead of locally at least by default.
This idea is pretty neat. You can bulk upload some log file or conditionally pipe output to a service like that and send the URI via SMS. I'd think that most of services like those would like to use federated logins and be on premise only.
Great idea. For my usecase it appears to be missing support for unicode (emoji) though...
Neat! Congratulations on launching, it looks amazing.

I built a similar tool a while ago, but to share your entire (read-only) shell session interactively: https://shellshare.net/. Might be useful for some looking at this.

I think this is a great idea, like others said it's the first time I've seen it. The problem is that almost any use case where this is useful for, is almost surely data that people wouldn't want publicized. A self-hosted version of this is ideal (for businsesses). At the very least, allow for API tokens and require a login to see your output (for personal projects uses) instead of just relying on a short random string for security of output. (Understood that it wasn't meant to be secure)
How is random string not a password?
I think the point is that it's secure from 3rd parties, but not to the owner/operator of the service itself.
Piping output from shell into HTTP response bodies is exactly what CGI programming is about. What am I missing that this is considered innovative?
This uses the cloud...

In all seriousness, isn't the use case here more temporary? You're running a script that you want some else to see the output of without the faff of copy & paste to a gist.

In this case you're piping output from shell into HTTP _requests_. It's the mirrored version of CGI.
No support for encryption? It would be interesting to support HTTPS, even if the initial setup would be harder than "nc".
Looks nice.

This could be quite useful to demonstrate/teach/explain simple stuff to people but I am not so sure if I would like to expose anything else from my console in this way.

I created something similar years ago and it's open source:

https://stream.ht/

Try it out, you can pipe your terminal:

  exec > >(nc stream.ht 1337) 2>&1
Or just pipe a file:

  tail -F file.log | nc stream.ht 1337
Pipe htop (delay is required to see share url)

  (sleep 5; htop) | nc stream.ht 1337
Doesn't require installing anything! Requires netcat which is installed on most *nix systems but you can use a plain tcp socket connection to pipe data too:

  exec 3<>/dev/tcp/stream.ht/1337 && head -1 <&3 && exec &> >(tee >(cat >&3))
I really appreciate that the default port in both examples is 1337
I wonder if that could get registered for this purpose somehow?
Ports get registered? I just assumed we were all picking whatever open ports we could find.
Way back in the idealistic days of the internet you could apply for and reserve a port for your protocol.

I don't think you can do this anymore..., or if you can it's not easy.

Sometimes in Port Forwarding wizards on routers, you see a big list of ancient videogames. Presumably that has something to do with this.
hmmmmm.... that some very specific similarities... almost too specific.
Streamhut seems to be a more mature version of OPs.

The window for viewing streams appears to even have commenting (and file/image sharing?). I also like how you lead with the "stream the whole terminal" example which lets me see how I can continue streaming a terminal instead of just piping a single program like htop to it.

Another plus is you've open sourced the server-side unlike Seashells/OP: https://github.com/streamhut/streamhut

Nice work and thanks!

Another interesting project on a ".ht" domain, huh. (Thinking of "source hut / sir hat" -- sr.ht)
(comment deleted)
Your TLS certificate has expired and is throwing an error.
gah at the worst time too. Thanks for reporting that! it's updated now.
(comment deleted)
blatant self promotion of related tools

* oho[1] is the best ANSI CLI->HTML tool out there (If I'm wrong file a ticket ;) )

* fenestro[2] takes HTML output generated by your command line and displays it (macOS only). If you shove multiple things into it quickly it'll display the list of them in the sidebar. Later requests for display will be in new windows.

[1] https://github.com/masukomi/oho/#readme

[2] http://fenestro.xyz/

On a related note.. are there any good free shell session sharing tools out there? I used to use nutty.. but it went away.
It's cool to see all the different ways one can implement such services. So I'll throw my hat into the ring with liveshell.

* https://liveshell.43z.one

Nice idea, but I’d rather install `bcat` or something similar.
First thing to try, of course:

    telnet towel.blinkenlights.nl | nc seashells.io 1337
Ah, finally. So how do I use the 3 seashells?
An idea that may address the security concerns:

- an open-source client that symmetrically encrypts the output with a random key before sending it to the server (obviously, the key is not being sent),

- the key is appended after # in the URL, so it’s only available to the browser,

- client-side decryption in JS.