I'm all for the idea of a long range, decentralized, encrypted mesh net. I've read a fair number of papers proposing and analyzing different approaches to make this happen.
Unfortunately, unlike the internet, or a local mesh network the total collective bandwidth isn't there. If it worked people would try to do full duplex audio with loved ones, file sharing, monitoring GPS coordinates of fleets of vehicles, internet gateways, and a zillion other bandwidth intensive things.
Bandwidth is so low, that even sending bytes is rare, encoding that average a few bits per character are common. Such encodings try to minimize the bits by using less bits for more common english characters, so they often are measured in words per minute instead of bits or bytes.
There was exist various hybrid solutions like APRS (which can use ham + internet), winmail (ham + internet email), various digital radio protocols (ham to tower, which has an internet connection). But a pure radio mesh net just doesn't seem practical.
Done enough research into this that I'm familiar with the stuff you're describing. I remember looking into those packet radio protocols, and honestly, they seemed kinda rudimentary, especially (IIRC) the error correction algos. Seems like there's a lot of low-hanging fruit in that area.
> I'm all for the idea of a long range, decentralized, encrypted mesh net. I've read a fair number of papers proposing and analyzing different approaches to make this happen.
What do you think the fundamental value of a meshnet would be? For my part, seems like an (encrypted) text-only system with high latency (15 minutes per paragraph, even) and a range of hundreds of miles between hops, would be preferable to something capable of streaming HD video that was restricted to hops of only a few hundred feet.
I think that's a fair comparison of what the physics can handle, and I think that if the former existed, there'd be a lot of people using it.
Edit: looks like I edited out from under you. Sorry, didn't think you'd see it so quick.
The bandwidth is so low it's a bit mind boggling. On a particular frequency you might well be broadcasting/interfering with a fair chunk of the united states and only managing 4.6 bits/sec. If it's 3 hops then divide that by 3. I just don't see any kind of metadata tracking of peers, requests, mesh status, etc being reasonable at that low bandwidth.
Sure, could a few people handle email like setups, sure. But even a small bump in popularity and it would be saturated and everything would break and nobody could use that frequency.
Once you adapt fully to that bandwidth I think you'd end up with things much like what we already have like winmail and js8call.
I'm not convinced there aren't ways to make it feasible. It would certainly select for high-value messages, and there'd have to be systems for avoiding DDOS-style attacks.
I remember doing a back of the napkin protocol for such a network, and assuming that most messages were tweet-sized and took 5 minutes to send. I get it, though I think you're describing a worst-case scenario. Bunps in popularity would just extend the latency. I think there's ways to overcome the problems and exploit the unique advantages.
The thing with things like JS8call is that it's still like using a postcard instead of a letter. I don't use postcards because I wouldn't put anything more than a superficiality on them.
Heh, well, a single tweet (280 char max) would take 486 seconds 8 minutes. Assuming you wanted just to send it a single hop in the USA. If you wanted three hops it would take 24 minutes and during that time significant chunks of the USA could not send tweets for 8 minutes at a time.
Imagine:
1:00pm SF transmits east of the sierras for 8 minutes.
1:08pm Someone east of the sierras transmits to someone east of the rockies
1:16pm Someone east of rockies transmits to someone on the coast
1:24pm Someone on the east cost receives a tweet
Keep in mind that from 1:00 to 1:16pm that nobody west of the rockies could tweet on the same frequency. So the effective tweets/hour would be something like a few per hour per frequency.
And it's not just latency that is added, if the demand exceeds the bandwidth available you'd never catch up.
Or to think of it another way, the USA over some theoretical mesh over HF couldn't keep up with this thread.
Unfortunately, unlike the internet, or a local mesh network the total collective bandwidth isn't there. If it worked people would try to do full duplex audio with loved ones, file sharing, monitoring GPS coordinates of fleets of vehicles, internet gateways, and a zillion other bandwidth intensive things.
Bandwidth is so low, that even sending bytes is rare, encoding that average a few bits per character are common. Such encodings try to minimize the bits by using less bits for more common english characters, so they often are measured in words per minute instead of bits or bytes.
There was exist various hybrid solutions like APRS (which can use ham + internet), winmail (ham + internet email), various digital radio protocols (ham to tower, which has an internet connection). But a pure radio mesh net just doesn't seem practical.