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.
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.
Oh that's interesting. I might suggest looking at implementations of IP Over Avian Carrier (IPoAC). And I do mean that seriously. The idea started as an April Fools RFC but some people have actually implemented it. Basically, just using a different physical layer.
Yeah, that's probably worth a look. Good suggestion. There's also delay-tolerant protocols for space and similar, but I don't know if any of them define an endpoint, as opposed to just a transport layer.
Indeed. I'd really suggest going for something based upon Internet Protocol, with any software that you need at endpoints to read and/or transmit. I might poke about at some ideas on the weekend (long holiday). What languages are you thinking to use?
Probably Rust, although I'm not married to it. I'm just at the planning stage right now, though.
One open question is if you can use a fairly standard transceiver like a Bluetooth chip, or if you need an SDR. Obviously they weren't designed with this in mind, by maybe there's a profile that's close enough.
Packets should have a few kilobytes of payload so you can fit a postquantum cryptographic artifact. Thankfully, even with a BCH code, it seems doable to fit that much in a 1-second burst in a standard amateur radio voice channel, for testing. (In actual clandestine use I'd expect you'd want to go as wide as the hardware can support)
As envisioned there would be someone operating a hub, which might have actual network access through some means, and on which the containers run. They would send out runners to collect traffic from busy public spaces which might serve as hubs for burst activity, and dump outgoing packets, all without giving up any locations.
Accounts with their own small container would be opened by sending in a public key, and then further communication would be by standard symmetric algorithm - except in testing, because that's an amateur radio no-no, so just signed cleartext. ID would be derived from signature fingerprint, as I have been thinking about it. I have a lightweight hash scheme in mind that would allow awarding of credit for retransmitting packets in a way that couldn't be cheated.
You'd want to have some ability to detect and move around jamming, or just other people's bursts. That's more hardware research, basically.
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.
"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."
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.
Yeah, I want not real time. The goal of having containers in the first place is to enable as much as possible without needing to put a human in the loop, since you have no idea how long each packet will spend in transit.
If I could emulate Curiosity's onboard computer that would be a decent starting point.
In that case it might not hurt to reach out to some NASA email addresses. The people who write that stuff are, after all, nerds like us, and would probably be happy to share whatever they are allowed to share.
It’s funded by taxes so, security issues aside, there shouldn’t be a lot of trade secrets.
Government agencies, in my experience, tend to believe in security through obscurity; even the ones that don't worry about spies as much as NASA. That said, maybe it's worth a shot. I'll have to figure out who's the best person to bug.
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.
I mean, I guess you could just programmatically insert a > after every command. That's actually a pretty good idea. It's kind of obvious now that you mention it, haha!
It would be better if the tools expected to be used this way, but as a quick kludge for a project about something else it's probably sufficient.
You know, I was thinking the Thinkpad was going to go to crap after Lenovo bought it, but overall I didn't have anything negative to say. I wore mine out, keeping it way beyond it's end of life and it kept chugging. It was difficult to part, in fact, but so goes change.
We switched from Dell to Lenovo at work and the amount of times I’ve had to totally reformat a computer for something just randomly not working right and not being able to find another fix for it has gone to almost zero. Before, with 20 computers, every couple months we had to reformat at least one laptop.
Not a single person has complained about missing Dell in two years.
Encarta seems so quaint to me now, but it really was a well curated encyclopedia that had a designed charm to it.
I admit when I saw this headline I thought "but what about music" and for me, CD's lived long after the 90's due to small music players and cars having audio CD players but not yet being able to read MP3's. Decks with that feature and cars with that feature were not much later.... but we still burnt them to CDRs.
retrocomputing
Hot
This magazine is not receiving updates (last activity 0 day(s) ago).