I've had some ideas bouncing around my head for infrastructureless communications, and an @ajroach42 thread revived some of them.

I should probably do my own thread, so, here. (It'll be built slowly.)

Let's define what the ideal of a safe communications system is: it is private (onlookers cannot see what you are saying unless you want them to), and it is anonymous (onlookers cannot see who you are or who you're talking to unless you want them to). There are various other parameters in play - provability vs. deniability is a big one - but those are the two I want to focus on.

Let's also define infrastructureless: with zero infrastructure, or at most, with ad-hoc infrastructure. There's no guaranteed direct connection to the other party of your communication, just ad-hoc nodes between your node and the recipient's node. This necessitates wireless technology - anything else is functionally infrastructure. (Note that wires can be part of the ad-hoc infrastructure, but the system must be designed to work without them.)

The first thing everyone goes after when talking about infrastructureless communications is amateur radio.

The amateur radio service provides long distance, surprisingly reliable infrastructureless communications, both through direct contact across the world, as well as through relay networks that can use as little technology as someone at a radio with a pen and paper manually relaying through Morse code or voice, or as much technology as AREDN relaying TCP/IP applications over long distances using Wi-Fi.

There's loads of experience in how to get the message across with very, very little infrastructure, in the amateur radio community.

However, what amateur radio is not, is safe.

Encryption is forbidden. (Yes, I know about the US exceptions for spacecraft control signals, as well as encryption being allowed when you share the keys, and it's my opinion that cryptographically signing your transmissions is legal as no meaning is obscured. But for safe communications, the entire point is that meaning is obscured, which is what is forbidden.)

Anonymity is forbidden, for both ends. You must identify yourself by your callsign, which is issued to you by your government, and many governments have a public database identifying the assignee of a callsign, as well as their address. You must also - with few exceptions - transmit to another amateur operator, which invariably means that callsigns are getting exchanged.

Additionally, there's content restrictions as far as what can be transmitted over amateur radio. In the US, obscenity, music, and (almost all) commercial activity are forbidden.

So, ultimately, a service or band that does not require users to apply for a license (to allow anonymity), and that does not have significant content restrictions (to allow encryption, and not claim that the encryption is an attempt to evade the content restrictions), is required to meet the safety requirements.

I’m only going to be speaking of the US legal requirements here - other countries may have a different situation.

In the US, the personal radio services (the relevant ones being CB, MURS, and FRS) aren’t suitable - messages for hire, common carrier services, and obscene, profane or indecent words, language, or meaning are forbidden on those services. (You wouldn’t know that listening to a CB radio, but.) Additionally, data emissions are forbidden on CB and “plain language voice communications” (no obscured meaning) are required, and data emissions are heavily restricted on FRS, just leaving MURS (which has five channels).

That basically leaves Part 15 operations.

Part 15 means your performance is crap. There’s been a lot of discussion on Fedi in the past about setting up Part 15 mesh networks (note that this is explicitly intended as always-connected, Internet-routed infrastructure when typically proposed), and that can work in a dense area, especially one underserved by traditional Internet service providers. That does not work over spread-out areas at all, though.

And, before someone says free space optical… I don’t want to rely on that, as free space optical links are fixed infrastructure.

Anything involving Part 15 for long distance communications must necessarily be a store-and-forward system, caching messages to propagate them across the network.

So, how do you implement a short-hop long-distance store-and-forward system with any kind of scalability?

If you broadcast the messages across the network, you quickly clog the network with irrelevant traffic.

NDN was suggested elsewhere in this thread, but I’m not convinced that its pull model scales with any kind of delivery reliability at all to literal Part 15 communications (and interests would have to be propagated through the whole network to receive all e-mail addressed to you, I’d expect, creating the same problem of clogging the network).

My idea is, essentially, to put the tradeoff on the anonymity/efficiency line. Messages are addressed to a geographic area, and then an identifier within that area (this could be a unique identifier, or it could be something non-unique intended to be received by multiple people).

An example that we can take from amateur radio is the Maidenhead Locator System, which is a fairly straightforward system for dividing Earth into relatively small squares. A two-character locator gets you a large region of the world (multiple US states) four character gets you a significant local region (part of a US state), six character gets you a neighborhood, eight character gets you a block, ten character gets you a building. You can extend the system further to get more precision, but that’s generally unnecessary (technically ten character is an extension beyond the standard anyway).

Put an originating location field on a message (again, you can set this based on how much anonymity you want, although any less than four character is useless, and six character would be better), and now you have enough information to efficiently route it. When a station receives a message, it compares the originating location field to its own location and the destination, calculates how far each are from the destination grid square’s boundaries, and if it’s equidistant or closer, edits the originating location to its own location and retransmits the message (without recording how many hops the message has gone through).

Mobile stations can use some more intelligence here - for instance, if they know they’re heading towards the destination (whether through simply monitoring speed/direction of travel, or if they actually are aware of GPS routing towards the destination grid square), they can wait to transmit until they’re closer, or even store the message for multiple repeats along the route (as Part 15 may need a lot of tries to get a message through). (Grid connected stations can also use other transmission methods - it would be up to the station to determine how to do more intelligent routing than simple Part 15 RF repeating.)

As a message nears its destination, the local stations will all saturate with the message for a fixed time - within the address area stations repeat the message at fixed intervals. (I’d say that the more address characters, the longer the message persists in the network. Maybe stations hold onto it for a week for four character, a month for six character, three months for eight character - it’s easier to get a message to a larger target area, after all.) And, have a mechanism for keeping track of what messages are seen, so a station can just automatically discard already-seen messages.

So, you could address a message to, say, bhtooefr@EN80, and all an eavesdropper would know is that someone using the screen name bhtooefr is in the northern half of central Ohio. Or, if you wanted better delivery, you could address it to a 10 character grid square that includes my apartment, and if it made it that close, you would be all but guaranteed delivery.

Note that announcements could also be delivered through this system - sending an unencrypted message to, say, broadcast@EN80SA,EN80SB,EN80SC,EN80TA,EN80TB,EN80TC,EN80TD10,EN80TD20 (I’m annoyed by that tiny bit of the city that just goes into EN80TD, so I just called out the 8 character squares it’s in…) could effectively push announcements out to everyone in Newark, OH - useful for applications like public safety announcements, if the system is well-adopted.

@bhtooefr This has been solved quite efficiently in Distributed Hash Table protocols https://en.wikipedia.org/wiki/Distributed_hash_table where you can quite efficiently search a large number of nodes for content without a single directory index.