Interstellar internet use cases, or "What if the internet was mail-order?"
This question builds off Information Exchange In Space and How would interstellar internet work?, and specifically uses the communication system I developed here because of this.
In a summary of those links, imagine that FTL transportation is easier than FTL communication, and that there are no causality violations 'cause reasons. So, rather than really long wires running from star to star, you have analogs to the Pony Express and Carrier Pigeons. Voluntary runners (really, every ship that can spare the space) are automatically paid for having a box on their ship which handles all the storage, uploading, and downloading, and each planet has a "post office" system to handle routing and "layovers". Messages get from star to star reliably and cheaply, but slowly. Think days to weeks, like snail mail.
Note: this doesn't become the only network; the regular internet works just fine, but only on a planetary scale 'cause light speed.
What I'm looking for in this question is how people would use the internet if it worked like this. Personally, I think it would be a lot less like "browsing" and a lot more like "inter-library loan". Usenet, StackOverflow, and maybe modified versions of Facebook and Reddit would work, but IRC, Twitter, and real-time gaming would probably be limited to individual planets.
What do you think? What would the novel and/or utilitarian implications of the system be if this existed? What would its use look like to the end user? How would we go about doing all the myriad things we use the internet for today, but in space? How would this interact with each individual planetary internet?
This post was sourced from https://worldbuilding.stackexchange.com/q/10601. It is licensed under CC BY-SA 3.0.
1 answer
For many uses, I agree with this answer that you would see local internets serving live content (as now) backed by interplanetary replication. The technology exists today to manage large data repositories over unreliable or highly-latent networks with eventual consistency; we'd see that applied to this problem.
But not all Internet use is web-site consumption with immediate results, and for those uses -- individual email, for example -- communication would slow down, just like it used to be here on Earth. Before (and then concurrent with) the Internet, which grew out of the ARPANet, was UUCP, the Unix-to-Unix Copy Protocol. This was used to move email and posts to Usenet newsgroups around the net. There was a backbone of nodes that sent and received updates to each other several times a day, and other nodes routed their messages to this backbone. If you were a couple hops away from the backbone it might take a couple days for your email to get delivered, and if you were farther out (digitally speaking) it could take close to a week. That's not ideal, but it was ok because people knew that and set their expectations accordingly. If you needed fast, synchronous communication with somebody, you picked up a phone. Instead of sending many short messages back and forth, you usually wrote longer messages covering several points -- think letters more than texts.
Behavior informs requirements for technology, but technological abilities also inform behavior. In your scenario people will have access to both modes -- fast but local (planet), and slow but universal (can go anywhere, eventually). We should expect to see local "pockets" of more-interactive communication that -- for sites like Stack Overflow and Reddit -- would eventually be replicated elsewhere. (Some modifications would need to be made, like how late-arriving answers interact with question closures, but those are matters for each site to work out.) We will probably also see a preference for the "in" sites; if Facebook is replicated across the universe and your blog isn't, you might move more of your participation to Facebook -- unless you specifically want to keep it local, which some do. If you have friends on other planets and want to stay in touch you'll still send email, adjusting your approach to the expected cycle time.
0 comment threads
0 comment threads