Alright, I’m back.

I was talking about amateur radio (in general) as a physical layer because I’m familiar with it, and know it can support short, wide-enough bursts with total radio silence in between. That’s an important requirement because if you’re loud continuously, in the “prod” case, jackboots with a yagi will show up and arrest you. Spies use fast, wide digital radio transmissions a bit like this in really locked-down countries, just not networked together in any way.

If more end-user hardware - or even a non-RF medium - would work, great, no issue. Like you said, there’s no way to support too many assuming they’re safe.

For routing, I would suggest no incoming transmission (or “transmission” if it’s really a hardwire connection) is ignored, but when to rebroadcast is left flexible for the user, who will be able to assess risk and likelihood of success getting closer to the destination in a way no reasonable software could.

Hybrid: Could take many forms but the one that comes to my mind is a multilevel hub and spoke architecture (I’ll draw this out). Basically, you end up having 2-3 “modes” for a client/server: hub, spoke, and endpoint. One or more client/servers operating in a hub “mode” act like traditional servers, kinda like a bulletin board, holding packets for local delivery or transmission to another hub. Client/servers in the spoke mode act as hops between hubs. Client/servers in the endpoint mode are the actual intended destination (this could be combined with the spoke mode). To protect endpoint identity, the destination could be part of the encrypted data packet allowing an endpoint to attempt to decrypt packets received from a hub locally, making it harder to know which endpoint a message is intended for. This does still require greater visibility of hub addresses for routing.

Yeah, so a hub just makes good sense - with such a modest network capacity relative to hardware capabilities, why not gather as much in one place as possible? Because one hub might get busted or just fall to some version of enshittification, it should be easy enough for a user to switch, but I think it’s the best choice of central organising principle.

Other than anonymity, is there a reason to separate out spokes from endpoints? One thing I already have worked out is a system where the hub can keep track of who has helped transmit things (in a cheat proof way), and could simply give credit for traffic moved, offsetting whatever cost there is to use it (ISPs aren’t usually free to start with, and this one is a safety risk to operate). The bandwidth overhead is literally just a key ID (address) and a hash per hop.

I figured switching keys frequently would be enough to ensure a degree of anonymity, since it’s completely pseudonymous. We don’t have a guarantee packets will arrive in order or in any reasonable timeframe, but if we did I’d suggest rolling through keys by count or timestamp.

A web of trust may be a good approach for authentication and identity.

I don’t really have anything to add there. Proving identity beyond just “I hold this key” is out of the scope of what I was considering. I’d probably go about it the same way I would over a more traditional network, if it came up.

Edit: Oh, and I’m not really sure how well this all dovetails into IP. If it can, that’s great, of course.

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.

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.

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.

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.

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

Well that’s a damn shame. I’m glad to hear there’s living exhibits elsewhere too now, though.

I don’t think that quantum physics is quite right, but the gist probably* is. Any finite system can have it’s states enumerated on a table. I’d think you’d need to calculate configurations over all of space-time at compile time, and then look up answers by boundary condition.

Good for you. You’re a counterexample then, I acknowledge that.

I mean… are we gatekeeping farms now?

Kind of. I’m not saying that’s bad, but it’s not quite the same thing. People I’ve met like that are really just rich retirees who want the cachet of being “farmers”. If you successfully do subsistence that’s not you.

The farmers where I live have got to be the most gatekeepy group I’ve ever met, BTW. I’m from a non-farming branch of an established farming family, and I get the cold shoulder - in general, not just on agricultural things.

though chickens are in the cards for next year

Do it. I had a backyard flock, they’re pretty easy to manage on small scales, they’ll eat many kinds of scraps and pests as a supplement, and they make more eggs than you personally can use very quickly. Do your homework first, of course, but it sounds like you get that. Honestly the most difficult part is keeping away predators, if they’re in the area.

The best case scenario for being commercially successful in that way would be to network with chefs in the bigger cities

And when people make the bespoke-organic thing work, aggressive and skilled networking/sales is how they do it. It’s just a really difficult, expensive way to make food, and people aren’t going to appreciate that for the exact reason they think it’s NBD as a career plan B. If you want to sell that stuff and make a profit you’ve got to be selling something else more intangible.

In Japan it might be different, though. I can’t say.

The local government says I am, in any case (buying registered farmland in Japan is a process, lemme tell ya).

I bet. I’m guessing you must be ethnically Japanese for it to even be possible. If not, I can only imagine the local scuttlebutt going on about you.

Honestly when I imagine someone in IT getting into farming, I imagine this. It’s really an acreage with a garden and some animals, but they call it a farm, and aren’t really interested in the actual farms.

That, or they do a hipster-bespoke-organic goat farm, which lasts a few years before they run it into the ground because they’re expecting it to be easy or work like IT. To anyone reading this, I would urge you to explore a significant but less radical change first - there’s plenty of jobs not like coding.

Okay, maybe not simple. Repetitive, though. I see you guys driving back and forth across a field all day.

With predictability I meant more like you have no idea when it will be wet or dry (for example), and everything depends on that. Sometimes you have to work hard pretty much as long as the sun is up, or at least that’s how it was in my family’s farming days. They would even eat on their tractors while they kept going. Other times it’s too muddy to do anything.

I don’t know about that, but it’s not a “free lunch” and it’s not the same as just looking at pretty scenery.

From a North American perspective, besides the absurd entry cost, it seems fairly similar to a being a long-haul truck driver or plumber. Simple, repetitive work that doesn’t follow any predictable schedule. Physical arduousness depends on what you’re growing and if you’re going to hire scared brown people to do it for you.

You also get to live in an area that’s close to nothing, surrounded by neighbors that think you’re an elitist city prick and will never respect you.