Is there a precedent for a really delay-tolerant command line interface? (A bit off-topic)
Is there a precedent for a really delay-tolerant command line interface? (A bit off-topic)
I've been playing with an idea that would involve running a machine over a delay-tolerant mesh network. The thing is, each packet is precious and needs to be pretty much self contained in that situation, while modern systems assume SSH-like continuous interaction with the user.
Has anyone heard of anything pre-existing that would work here? I figured if anyone would know about situations where each character is expensive, it would be you folks.
Like MOSH? https://mosh.org/ Mosh has some predictive output and will resume sessions automatically.
Or more like tmux/screen? Has some fancy "nohup" like functions.
Mosh plus tmux is amazing.
That's really helpful. Thank you! MOSH might work, I'll have to play around with it.
Could you go into more detail about the tmux functions? If it's a way to write everything to files instead of a STDOUT in a predictable way, that would be great, since each packet could be a (compressed) shell script that explicitly includes which data to send back, if any.
Ask NASA
The 'ed' editor was designed for high latency networks. I would pull on that thread. That is, in your shoes, I would read up on 'ed' and related tools.
Delightful!
"Of course, on the system I administrate, vi is symlinked to ed. Emacs has been replaced by a shell script which 1) Generates a syslog message at level LOG_EMERG; 2) reduces the user's disk quota by 100K; and 3) RUNS ED!!!!!!"
Gave me a giggle. That 100k loss has got to hurt for a user who still tries to run 'vi' on a classic system, I imagine.
Edit:
Another gem:
"Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity."
I would pull on that thread. That is, in your shoes
Directions unclear; shoelaces tangled
Ed is great (in this context). I think there's been posts about it on here before. It's just a text editor, though.
Yeah. I've had mentors regail me of other tools they used alongside 'Ed', but I wasn't listening very attentively. Hopefully that's something that can be dug out of the history of the Internet.
I would definitely choose the old reliable stuff over something new and fancy, if I had this use case.
Secure Scuttlebutt is (was?) a protocol for high-latency communication between occasionally-networked humans. Pro: https://scuttlebutt.nz/; con (not read in detail): https://derctuo.github.io/notes/secure-scuttlebutt.html. I think it was supposed to be able to spread messages over Bluetooth, assuming a sufficiently connected web of nodes between person A and person B. Public keys were identities, and were bound to devices; unfortunately people may have multiple devices, or change devices over time, so this was a hindrance.
IPFS was supposed to be the Interplanetary File System. I think that was just because whatever pieces of content you ask for, you also cache, as part of the design: you keep a copy on the near side of the small high-latency pipe. But that's mostly about file transfer, not interactivity.
UUCP was definitely made in a time where a latency of days for delivery of email or netnews was common.
In the early days of CGI, the Web was just one way people imagined interacting with applications; another way was email. RFC 3834 has some recommendations for people who are going to automate email responses. There used to be services you could email a URL to, and receive the web page back as an email.
Using ed (in my experience) involves looking up the screen, or up the roll of paper on your teletype, to see what the lines of your file were, and imagine what they are now, given the changes you've wrought to them since they were printed, and then turn them into what they should be. With Mars rovers you have a simulation that you issue your command to, before sending it off to Mars. With correspondence chess you might keep a physical chessboard for each game you have going, and/or send a form back and forth that keeps track of several moves.
People used to do computation at universities and businesses by writing programs at their desks, submitting them to be typed on punchcards, and receiving printouts some time later. They would "desk check" their programs before sending them in, because each compute job took a couple days to come back.
I mention all these because, in an extreme censorship environment, any local state (session history on paper, an app on a smartphone, an odd device) might not be good to have around. So usability may require reducing the total amount of state that a command carries. The current working directory at the time a command is run changes the meaning and outcome of the command; you may not remember that directory in a day or two. The vocabulary and syntax of command-line switches are easy to look up in online manuals - but are there offline manuals? I don't know if this avenue of inquiry helps you, but it's interesting to think about for a moment.
Thanks for the effortpost! Scuttlebutt in particular is similar in spirit, although I agree with the blog post that the implementation sounds funny. One conceptual difference, I think, is Scuttlebutt sounding fully decentralised, which necessarily introduces an O(n2) kind of overhead. Hubs could operate more like the content distribution networks that already exist in really locked-down countries, which are proven to work, just with the new protocol as a lower risk way of getting to the end user. Their own page is loading blank for me, unfortunately.
Public keys were identities, and were bound to devices; unfortunately people may have multiple devices, or change devices over time, so this was a hindrance.
I'm not sure why even they added that, haha. How hard is moving a private key? I'm also imagining it would be pretty routine to just discard a key-identity and make a new one, for anonymity's sake.
I mention all these because, in an extreme censorship environment, any local state (session history on paper, an app on a smartphone, an odd device) might not be good to have around. So usability may require reducing the total amount of state that a command carries. The current working directory at the time a command is run changes the meaning and outcome of the command; you may not remember that directory in a day or two. The vocabulary and syntax of command-line switches are easy to look up in online manuals - but are there offline manuals? I don’t know if this avenue of inquiry helps you, but it’s interesting to think about for a moment.
Some local state is probably necessary for usability. I mean, at the very least you need to have the software, which is probably illegal itself. The trick, as always with contraband, is either hiding it or not getting searched in the first place. In emergency situations having a way to securely delete everything quickly is the best that can be done, I think.
I don't expect the average user wouldn't be writing shell scripts themselves. There should be user-friendly frontends for common tasks like email messaging, but that doesn't help developers. A certain level of statelessness at the hub end would be good, just to avoid unwanted interactions like that. Maybe execution always starts with the same environment variables in the same directory, and your payload bootstraps other shell scripts or actual programs needed to add context.
As long as you're using TCP (what SSH uses) or a similar protocol, you should be able to deal with a situation like that. You'd mainly need to ensure that your client and server are tuned to meet your needs. With TCP, every packet is considered important and if the receiver does not acknowledge receipt, the sender will resend.
I'm not talking a lot of latency, I'm talking snail-mail levels. Hours probably won't even be unusual, because hops will happen partly by sneakers net as people move around with their nodes. The concept is distributed burst radio for extreme censorship environments.
The point of the containers in the first place is to make as much as possible work offline, without the user having to be in the loop.