someone beat me to it and formulated some positive thoughts about the future of technology ( and yes, of course this has implications for the future of programming too!) ==> https://rbs.io/2019/05/a-revolution-in-your-pocket/

Cool! I agree with almost everything. The only thing that came to mind for me was that mobile devices aren't reliable. Your device might run out of battery, your internet connection might drop or you might destroy the device itself. The traditional answer to this is to use "the cloud" which has all the disadvantages you mention in your post. I was thinking that home servers might be the solution to that. This would make sure you're highly available (for receiving or providing information) without having to give your data to some distant data center. If setting up a home server and connecting it to your devices was as easy as setting up Amazon Echo, we'd probably see a lot more people doing it. Friends could even decide to connect their servers, thereby increasing availability and fault-tolerance. What do you think?

I've been thinking about this in the context of Curv, my future-of-coding project. When you run the Curv app, or run the Curv programming environment in a web browser, you should have access to all of your projects, and you should also be able to browse other people's projects, and link to other people's libraries. All this code should be stored "in the cloud", so that you can access your stuff from any device, and so that other people can access stuff you have published. How does this cloud storage work? Do I have to run a public facing server, curvhub.com, which stores everybody's projects? Do I pay for it by vacuuming up personal information and displaying ads? Does everybody lose all of their data if curvhub.com shuts down some day? Or maybe FOCI, the Future Of Coding Institute, with long term funding ensured by a $50M endowment from a tech billionaire, provides cloud storage on codehub.org for future-of-coding projects. As discussed in the Research-Centre channel. There is now an internet subculture around creating an independent, distributed, decentralized internet infrastructure. Mastodon replaces twitter, and so on. How would a decentralized CurvHub work? Maybe it uses IPFS (the interplanetary file system), and maybe the Curv app runs IPFS nodes on mobiles, laptops and desktops. I've never tried this technology, so I don't know how fast and reliable it would be compared to something like github.com.

Yes Doug! let start using IPFS 🙂

@curious_reader Sorry, I have not researched distributed slack alternatives. Let's take this to the meta channel.

@Doug Moen That's right, I should have mentioned IPFS as well. The central point though is that most data is only cached within the network. If I wanted to use my phone for hosting my blog using IPFS, it'd be possible that someone tries to access it while my phone doesn't have reception and no other host has my blog cached. Then my blog could not be accessed. Having my homeserver (and probably my friend's servers) pin my blog could improve reliability.

I think scuttlebut (andre staltz's project) just caches the whole network on your phone right now

I have been looking at IPFS recently and also came across the issue of devices with non-permanent network connections, for whatever reasons. My impression (which could be horribly wrong given how little I know about IPFS) is that this is considered an issue that software layers higher up in the stack should handle. IPFS does provide the required low-level support (pinning), but nothing for managing pinned content. A tool that does is IPFS Cluster, but it's for managing large pinned content collections spread over multiple servers. Another layer on top of IPFS that helps with this is [textile](https://textile.io/), which adds PIM support to IPFS. And perhaps there is more stuff that I haven't found yet.

Hi @Konrad Hinsen , Textile looks interesting I saw Juan benet sharing it over twitter

The most obvious use I see for IPFS and similar/add-on projects is getting out of dependency hell. An extreme approach of that kind is taken by [Unison](http://unisonweb.org/) (not using IPFS, but the same ideas) in which code is a data structure without any human-readable names, with name->data mapping considered separate information.

Textile looks interesting. You need a network of volunteers running "cafés" in order to provide the cloud servers needed to make it work, but that seems achievable in the context of a popular open source project. After all, Mastodon works; there are lots of Mastodon nodes to choose from. I think that part of the design is to consider what incentives there are for volunteers to run cloud nodes; what kinds of rewards do they get from contributing to the community in this way? I think that if cloud nodes are branded, if the volunteers get recognition for running a node, this might be important. If the cloud nodes are completely anonymous and invisible, that might reduce the incentive to run a cloud node.