I think that secure scuttlebutt (SSB) is a very good start, but eventually we'll need something besides an append-only log. Something that removes data that is no longer interesting. Something that, when it runs up against its storage quota, prunes data based on whether it is more/less trusted or likely to be interesting to a peer. Something that knows which peers I'm likely to be near in the future, knows which topics they're subscribed to, and which tries to be an efficient mailman based on that understanding.

But yeah, my vision is pretty much just SSB all grown up.

...and it's close relative NNTP. There was a whole distribution structure built out of intermittent data transmission. We've had the tools for this stuff for a long time, we've just switched to centralized, always available services because that's easier to build a company around.

At some point, somebody will set up long range wireless communications and then the reward for running a message would likely drop to so small that it wasn't worth it... but yeah that's exactly the sort of thing that I had in mind. That way if something happens to the internet, prices for running a message go up, and suddenly running messages is worth it again.

The tricky part there would be working out a partition tolerant payments system. It's one thing to go offline in the middle of delivering a message, its another thing entirely to orchestrate payment across a smattering of disconnected networks (blockchains are not partition tolerant). I think it could be done, but that's an application layer concern... gotta get the peer finding and web-of-trust stuff working first.

Then you’d end up with something like Helium, which consumes energy and occupies spectrum for no productive benefit.

https://www.helium.com/

Yeah it's not ideal for sparse populations but I think you could get a lot of coverage by just running a node with a solar panel wherever your mailbox is and also having your mail driver put a node in their vehicle.

Really the thing I'm trying to push back against is the idea that the entire path between them must be connected all at once in order for two parties to communicate. If we design for short range, partition-tolerant, pocket-to-pocket background gossip, then that same protocol will work just fine if you attach specialty radio hardware and give it miles worth of range, and you've still got the fallback ready for cases where all you have is consumer grade hardware.

On the other hand, if you design for persistent connectivity and then try to use it in an intermittently-connected context, you're going to have a much worse time.

Well "internet" gets quotes because if the source and the destination are disconnected when the message arrives then they're not on the internet.

It might look something like this: As you stand in line at the grocery store your device notices that a nearby device (the guy behind you) belongs to somebody who is trusted by one of your peers in the "gardening" topic. You're not a gardener, but your room mate is. So your device pulls a gardening related update from their device. Then as you head home with groceries your device is not connected to anything, it's just sitting in your pocket with a filesystem full of data. And then when you get home your roommate's device gets a notification about a reply to their question on a gardening related message board. That data came to them on your device. It traveled a few feet wirelessly at the grocery store, and a few feet wirelessly at home, but the majority of the transit was handled the slow way, by hitching a ride on a human who was traveling that way anyhow.

It would only work for small bits of latency tolerant data, and work best for information of broad interest (not so great for an encrypted email to a single party, pretty good for map tiles, open/closed hours, restaurant menus, etc). The simplest app to build on such a platform would be a sort of of distributed BBS. VoIP would be nearly impossible. But I think that small snippets of high latency text can get you pretty far.