webtty
webtty copied to clipboard
Making "one way" require a small 32 string to share
The purpose / idea behind this PR is make the one-way connections a little more condensed.
Rather then needing to share a very large SDP (if sending a -cmd also) this PR make is so the SDP is uploaded to the 10kbsite, and is referenced by a UUID of a 32 length string (with hyphens removed). So new way this will work is this.
- Note a tmux session named
pairis already created andtmuxversion 3.2.rc or greater
webtty -ni -o -cmd tmux attach-session -t pair -factive-pane &
Results in a more simple output, and easier string to share with the client
Setting up a WebTTY connection.
Warning: One-way connections rely on a third party to connect. More info here: https://github.com/maxmcd/webtty#one-way-connections
Connection ready. Here is your connection data:
f1660d3103794432a927367b8f86227d
Paste it in the terminal after the webtty command
Also, thanks for the awesome feedback and consideration of this feature.
@maxmcd bump. I see you made an update that caused me to have a conflict here. Would love to figure this out. Unless you aren't interested in it. Please let me know and I will close the PR if that is what you decide.
hey @casonadams, I think we still want this feature, but I might make some additional changes. you're welcome to leave the branch as-is and I'll merge it in with fixes and edits later
hey @maxmcd if you want to give me some feedback I can help make the changes. I was thinking one nice thing might to allow the host to set a uuid as runtime. Not sure if that is a good idea based on the 10kb website and it handling multiples of the same uuid.
@casonadams I think it might be better if we just switch to using 10kb.site for all requests.
https://peerjs.com/ seems to have risen in popularity recently and it uses a trusted server to exchange short ids. I think we should implement the same feature. When a user decides to connect we generate a short id for them (I think it should be something human readable, maybe random concatenated words or similar, not a random string or uuid), or allow then to pick a custom id themselves.
From there, I think we remove the very verbose key exchange and put it behind a flag, if a user wants to connect without using 10kb.site then they are more than welcome to.
I think we could do this without breaking the implementation by first parsing the passed connection string to see if it's a valid legacy connection string, and if it's not, assume it's a new user-selected identifier.
@Sean-Der maybe you have some thoughts as well on this general direction?
Also very open to alternatives, we could also just integrate with peerjs and use their id server, if that's more sane, or continue to use 10kb.site, but maybe better document the use and allow people to more easily spin up their own self-hosted version.