Reminds me of Fido BBS from the late 80's early 90's. How it hop-scotches from one local call to another to avoid long distance calls when sending messages.
I've been thinking about distributed, rag tag tech solutions for decades, but theyve been in sharp focus the past few weeks and days in particular.
I'm imagining a community of people who each run some services which will be down some of the time, but you always want everyone to be able to use everything all the time.
At first I was thinking load balancers, round robin DNS, failover... you know, the tried and true solutions. But those all have huge problems in this type of environment.
Then it hit me. Go back to computing in the 80s and 90s, where it was expected that people and even servers would be offline regularly. Take inspiration from BBSes, email, and the more modern systems like git, RSS (with auto-downloading).
#Nostr is designed along these same lines too. Nostr clients don't let you post while offline like you can send an email while offline, but that's just a client implementation decision.
Effectively, the point is to make things work well offline.
This strategy doesn't work well for some things like real time communications (video teleconferencing, voice calls, etc.) or when multiple people make changes to the same file at the same time. So we need different solutions there.
That could be a low-tech solution like scheduling a meeting on a meet.jit.si server but if that's down then falling back to https://vc.autistici.org/ You could have a tertiary option if needed, or even more.
Discussion
That was before my time, but I've heard about it and it sounds like it was a clever & fun system!
it worked great. in 1990, I lived in California and my brother lived in Maryland. His roommate had a fidonet node. I could connect to a local number in Los Angeles and be able to send files and emails to my brother living in College Park, MD. might take a day or two to get the message out, but worked great!