retrocomputing

4130 readers

37 users here now

Discussions on vintage and retrocomputing

founded 1 year ago

MODERATORS

[email protected]

Is there a precedent for a really delay-tolerant command line interface? (A bit off-topic) (lemmy.sdf.org)

submitted 4 months ago by [email protected] to c/[email protected]

33 comments fedilink hide all child comments

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.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 1 points 4 months ago (1 children)

Will have to get back to you sometime this week - family took more time than anticipated. But, I can layout a few things:

jackboots with a yagi will show up and arrest you.

Yeah. This is why I recommend avoiding it altogether. Regulatory agencies are too on top of the licensed spectrum when just worrying about keeping HAMs and others in line. The tools to catch unlicensed operators are just too well-developed and proven to consider it practical for a transport layer, outside of things like natural disaster and the like where transmission in the clear isn't usually a concern.

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.

Exactly. If you're using RF as a physical layer, low-power in parts of the spectrum where encryption is both allowed and common is what you want.

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.

This is where IP may come in handy for Layer 3 (I'll come back to that).

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.

No. I think you are right. Spokes and endpoints should be indistinguishable from the outside. There are a number of mechanisms that could be used but, one that comes to mind would be having the packets wrapped in encryption that is decryptable only by the intended receiver, and having the final "hop" as part of the encrypted packet header. That would bring up some funky cryptography needs that is have to dwell on a bit.

A spoke could literally be servers connected via a "regular" network between hubs, a BLE or LoRA data transmitter, a USB stick, etc. As long as the L2-3 is supported in the stack, it should work.

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.

Might look into PGP/GPG. It could be a useful approach. Essentially, the idea being to be able to not take someone's word for who they are but rely on a consensus of trusted parties. Like PKI but not as centralized.

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

I really think it can pretty well. Using IP would give a native way to route on traditional networks and make traffic more likely to blend in with existing traffic. Building a protocol on Layer 4 reduces the implementation overhead by taking advantage of existing abstractions. Layer 3 doesn't need to know anything about the layers above it or below it, it just needs to know which server is sending, which server is receiving, and the payload.

[–] [email protected] 1 points 4 months ago* (last edited 4 months ago)

Will have to get back to you sometime this week - family took more time than anticipated. But, I can layout a few things:

No worries. I had just spent a bunch of time replying to another guy about this, and then had to pop into surgery and recover for days, which is why I felt bad and specifically mentioned it.

Yeah. This is why I recommend avoiding it altogether. Regulatory agencies are too on top of the licensed spectrum when just worrying about keeping HAMs and others in line. The tools to catch unlicensed operators are just too well-developed and proven to consider it practical for a transport layer, outside of things like natural disaster and the like where transmission in the clear isn’t usually a concern.

Like I mentioned, this is inspired by an existing thing, so I know it's possible to not get caught if transmissions are kept very short, and done in a busy area. Definitely not recommending it, though; it's also just rude to fill up spectrum with massive cyphertexts if you don't have a good reason. Industry Canada (in my case) is one thing, but basic human decency comes first.

I hadn't actually thought of natural disasters. I suppose that could be a niche just because low-power transmitters are so much more common now. Above the physical layer it makes little difference as far as I can tell, so we can talk about that and not worry about the philosophy or practice of law-breaking.

I really think it can pretty well. Using IP would give a native way to route on traditional networks and make traffic more likely to blend in with existing traffic. Building a protocol on Layer 4 reduces the implementation overhead by taking advantage of existing abstractions. Layer 3 doesn’t need to know anything about the layers above it or below it, it just needs to know which server is sending, which server is receiving, and the payload.

So would the hub just function as a local network, then? I can see what you mean by that. So basically, each container would get an IPv6 address, and could communicate with the outside world normally when a low-latency connection - like maybe via satellite constellation - is up.

and having the final “hop” as part of the encrypted packet header.

Hah, is there an official term for the move from one node to another? I'm pretty sure I've heard a complete mix of things IRL.

You could do full-blown onion encryption if you wanted, assuming you know in advance the path your traffic will take (or at least the very end of it). If you don't, you pretty much just have to trust everyone to see what route your traffic did take in the end. Given that nodes are mobile, can change identities, and optimally only share encrypted traffic, does that sound like a huge risk? (Honest question)

I suppose in a disaster situation, you could just openly publish the GPS coordinates of the hub, and make a transmission strategy by as-the-crow-flies distance.

Might look into PGP/GPG. It could be a useful approach. Essentially, the idea being to be able to not take someone’s word for who they are but rely on a consensus of trusted parties. Like PKI but not as centralized.

I'm familiar as a user, but I'm not sure how few packets you could fit that into. You could definitely set your container to do a web of trust check over the normal internet, and just ask the other party to sign something with their published key.

Also, a bit off topic, has PGP/GPG already been adapted for post-quantum algorithms? You'd think it would be one of the first things to get set up.