17 ms·

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 seem

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.

sliken 5y ago
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.
- generalizations 5y ago
  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.
  - sliken 5y ago
    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.
    - generalizations 5y ago
      Hah, fair enough.

sliken 5y ago

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.

generalizations 5y ago
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.
- sliken 5y ago
  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.
  - generalizations 5y ago
    Hah, fair enough.