Comment on Is there a precedent for a really delay-tolerant command line interface? (A bit off-topic)
CanadaPlus@lemmy.sdf.org 2 months agoI’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.
nickwitha_k@lemmy.sdf.org 2 months ago
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.
CanadaPlus@lemmy.sdf.org 2 months ago
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.
nickwitha_k@lemmy.sdf.org 2 months ago
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?
CanadaPlus@lemmy.sdf.org 2 months ago
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 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. 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.