That use case would be suicidal without encryption. I'll repeat my quote also - HAM radio has a future, but it needs to adapt.
Now if we are talking like a rebellious faction within a country, well they are technically breaking all other rules of the nation anyways, so no-encryption HAM rules suddenly becomes the line in the sand they draw as to not cross?
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.
> 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.
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 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.
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.