Darn, I have to go now. Apologies for the considerable latency there might be getting back to you on this, haha!

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(n²) 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.

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.

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.

West Ed is still dope. I don’t know about submarines, but they have a 10/10 water park in there, and a bunch of other stuff.

Man, I wish that became more of a thing here. I’m good enough at being a weird shut-in without the architecture pushing me to do so.

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.

Alright then. Thanks for the info!

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.

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.

Yeah, that’s pretty typical for a lot of computing these days. People are talking about exotic things like in-memory processing as a way forward because of that.

Is that the whole thing, or is there something more specific to VR? You can make a smartphone no problem, but portable goggles end up with an ungodly short battery life.

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.

Ed is great (in this context). I think there’s been posts about it on here before. It’s just a text editor, though.

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.

Do they post their software somewhere? What they use for space probes is exactly what I would need, but I kind of figured it would be a trade secret.

Yeah, I know, I’m not arguing against electric now, or even as a concept then. This was an alt-history exercise, remember?

Batteries could have been standard for a bit longer, but it seems to me that eventually the need to go faster for longer would have forced combustion engines to be a thing. All they had were lead-acid batteries (or primary cells, but that would be dumb) and new more energy-dense chemistries didn’t show up for a long time after. Maybe they could have found one if they really needed, but it’s a tricky science even today, so I’m skeptical.

It’s possible, I suppose, that infrastructure could have been rolled out for both en mass, but I don’t see an even mix lasting through the whole 20th century. Probably not even past WWII.

Normie. Real timezone-haters use Unix epoch. /s

Or, y’know, there’s a war on and you can’t stop to recharge, or you need to cross a desert, or you just want to do an express route with one vehicle…

Combustion is just a superior vehicle technology vs. lead-acid electric, assuming you don’t worry about emissions, and that will show up in plenty of contexts. Eventually, lead-acid would go the way of the other workable-but-not-as-nice technologies like crystal radios or black-and-white film.

“Thanks bro/comrade!” would be a great way to play this off diplomatically with someone you still want to be allies with, so that could be the origin of that bit.

Because it lead directly to feudalism and other forms of autocracy?