[sofixa]

But if the app doesn't have internet access, how would it discover the others on that same partition? (Assuming it's a wholesale internet/specific domains being fully blocked). If your phone/computer can't contact Telegram's servers, it doesn't matter.

[m3047]

By making its own "internet in a box": open wifi, DHCP and DNS, and Bob's your uncle. Anybody in range can play; everyone else is out of luck. Install NNTP so that news can move around by flooding, as nodes form new associations. Add a second wifi transceiver and some clever dynamic route discovery and you have a mesh network.

[__MatrixMan__]

I imagine using bluetooth for peer discovery, so you find peers by sharing an elevator with them, or stopping at the same intersection, standing in line at the grocery store etc. Although the network would probably never converge entirely, it would drift approximately towards convergence as long as the gossiped dataset stayed small.

The gossiped data would be:

> My public key is ABCD1234... and the most recent CID of my data is DCBA9876...

These devices need be on no other network at the time, just in range of each other.

At other times when they're near a node on the larger network they offload their discovered peers and the consult their trust graph to see which peers (new or already known) are both trusted in some capacity (maybe transitively) and interested in the same topics/apps. In those cases, that data syncs to their mobile device, and apps which reference it update.

This would work better if you dedicate some device somewhere to be permanently attached to a network node, but unlike what we're doing today there's no need for it to be maintained by the author of your apps. We can decouple those personas. If the device hosting your data ends up on another partition, you can dedicate a new device to the task without updating anyone, since nobody is hanging onto device identifiers anyway. Probably this just means leaving yesteryear's busted phone plugged in at home so it can be a cache for your data while the device in your pocket is offline. Your mobile device an update when it gets on the wifi.

So now you've got users carrying around data which other users might be interested in (beyond the peer-finding data), and it's organized by topic/app, so when two peers are nearby which share an interest (perhaps on the behalf of their peers, transitively), they can directly sync heavier data as well. I think that attaching a wifi router to every delivery truck would get you most of the way there, since it could move the data between houses it's delivering to.

This might mean network latencies measured in hours or days, which would be awkward, but at least it's never hard down because it never depends on the state of a unique server. Besides, if the partition-tolerant fallback works beyond a certain usability threshold then you've removed the incentive to disable the internet in the first place.

Maybe I don't have the details perfect, but something like this is possible and I don't think the difficult part is getting the underlying protocol right. Rather it's getting the apps we rely on to also work under the fallback paradigm. The necessary shift is to get away from request/response architectures and towards pub/sub ones. Fewer unique server identifiers and more trusted user keys and predicates about the degree to which those users trust different content hashes.