Imagining software in a mesh-networked, potentially-disconnected future.


We’re living in an increasingly connected world. Phones synchronise our photo libraries to our cloud provider of choice. Content distribution networks handle edge caching to help us stream our favourite television shows. A message can be sent, encrypted, from one end of the globe to the other in milliseconds. Cars can share data collected from drives to improve machine learning.

Each of these functions is achieved with software on the device and software in the cloud. Client side and server side. Customer and business. This approach to software development enables a user to keep their data safe elsewhere, but also creates a user-reliance on the cloud provider to have this copy available when things go awry, or in Google’s case - to access anything.

There are two distinct approaches to developing applications—demonstrated by Apple and Google, respectively.

Google’s approach involves synchronising your specific, user-generated data to their cloud service. Google practices advanced machine learning tactics within Gmail, Google Photos, Google Drive and many other products to take the heavy lifting off your device and place it on their servers.

Apple’s approach revolves much around using the device for complex processing and merely synchronising the raw, encrypted data to their cloud service. This means you pay for storage and your device does the rest. There’s no heavy reliance on iCloud being available.

There are arguments for and against each methodology but I think there is a tremendous benefit in Apple’s approach—let me explain why.

We are living in a connected world, but we can also be disconnected.

People travel. International flights can knock 7 - 30 hours off your productive time. A camping trip may leave you offline for days. Travelling where roaming or wi-fi are not available can even mess up your travel plans if you can’t get that confirmation email open. People may spend months disconnected when travelling between Earth & Mars. This is the reality of our future.

We are living in a connected world, but we can also be disconnected. That’s the challenge that software developers face and it’s one of the best reasons to buy an iPhone (apologies for the unintentional sales pitch).

There are two concepts that I’d like operating system developers to trial in the future. Mesh Networking and my theory of a “Portable Private Cloud”.

Mesh Networking is already something practiced today. But, there is still much that can be achieved to advance the technology’s use. Imagine a situation where your iPhone is off-grid and meets its demise minutes after taking a photo. That photo is potentially lost but, thanks to Mesh Networking, your phone has relayed a copy of that photo to your iPad and Apple Watch so that it can be synchronised to the cloud later.

I like the idea of keeping my local devices in sync via their own private network. Caching content, synchronising offline files and even distributing recently edited documents or photos. Not only would this be more user-friendly from a user’s perspective, but reduces the likelihood that you lose a family photo from a water-related incident. Dropbox once achieved this with their LAN Sync feature—never really taking off.

Of course, many factors need to come into play before this can be achieved. Flash storage needs to be offered at higher volumes; devices need to be less power-hungry when talking to each-other; and software needs to be written to handle this style of communication.

When we expand on the idea of Mesh Networking, we can re-imagine the supercomputer.


Supercomputers pile together computer processing power to achieve a function. Things like Machine Learning and Artificial Intelligence are achieved when supercomputers handle advanced, high-intensity tasks in less time than a traditional computer can handle them. In fact, Google is offering a platform to allow people to take advantage of supercomputing power at Infrastructure as a Service (IaaS) prices (sorry, again).

This brings me to the concept of the Portable Private Cloud. If your devices can establish a Mesh Network and can act as storage backups to one-another, they should be perfectly capable of sharing compute challenges.

A good example on iOS is the photo library. The photos app will learn about the people and objects in your photos. The app creates metadata that can be used to search by object, landscape and face. So, type “Mountains” into your Photos Search and you’ll see mountains. This is all achieved through machine learning and image recognition libraries that run in the background. These tasks use a fair bit of compute, so it’s best done when your phone is plugged in and idling.

Imagine your devices—be it a smartwatch, laptop, phone and perhaps glasses—sharing their compute to solve machine learning problems, to synchronise your data and give you powerful insights while they’re idling or when you need it. Every device you carry could fit snuggly into your little portable computing ecosystem and keep your “cloud capabilities” available with you wherever you go.

Beyond this, an operating system malfunction doesn’t mean you should wait until you’re back in civilisation to recover your device. If you have devices adjacent with your data available on them, they should be able to act as a proxy for your cloud provider—this includes handling the authentication process, the synchronisation process and keeping everything nice and clean while doing it.

I’d say we’re a long way off this kind of capability—five to ten years at least. There are a lot of technical challenges involved with this kind of direction in software, but we’re at a point where the leap can be made. If tamagotchi taught us anything, it’s that a device-to-device network is capable of brilliant things and can even help us keep using the cloud services we love. Whether that be sending an iMessage while the internet is down, pulling up an airline ticket from an email or playing games with friends on the SpaceX flight to Mars—software is capable of bringing cloud technology to our devices—heading towards the true sense of cloud.


Now read this

Unit testing in Keystone JS

After many annoying tests and messing about with Keystone.JS, I’ve finally managed to get a proper Unit Testing system in place. What am I using? # We just need two super useful plugins to get started. Mocha—our test framework will tell... Continue →