Private Cloud

Current decentralised storage solutions are generally complicated to use. For IPFS, you need to know about pinning services or how to run a node (or more likely a cluster thereof) yourself. On Swarm, you need to buy postage stamps, which involves a complicated onboarding flow to crypto. In addition to that, none of these services can realistically be used from a mobile phone, at least not without using a centralised API to do the heavy lifting.

In a lot of cases, users just want to store their data and potentially make it accessible to their friends. The idea of this project is to provide a tool to manage just that, with the added benefit of being privacy oriented. Basically, it's a base for a Google Drive of sorts, except self-hosted and without any centralised parts, while still remaining easy to use and compatible with mobile phones.

The general idea is to have three components:

• A companion app that is easy to install and runs on a computer that is always connected to the internet, be it a desktop, server, Dappnode or even just a small Raspberry Pi. This will host and serve the data through IPFS.
• A protocol to make it possible to push data to that node and retrieve it, without requiring port forwarding, VPNs or centralized services. Based on Waku.
• An application that uses the protocol to indirectly connect to companion apps.

On a higher level, the application initially needs to be linked to one or multiple companion apps. This is done for example by scanning a QR Code displayed by the companion app. This then negotiates encryption keys for all following communications. Once that is done, the app can send requests to the companion apps through Waku in a fully encrypted and private way.

On a more specific level:

1. The companion displays a public key to be used for ECIES encryption
2. The application then sends a message on a specific topic (which is a hash of the public key) to register. The message includes the name of the device and is signed.
3. The companion app recovers the public key from the signature and links its own unique public key to the one recovered from the application. This ensures that even if multiple users use the same companion app, or if one user uses multiple different companion apps, it would not be possible to link any of the users to any of the companion apps, as the topics and keys are always different. It also prevents attackers from front-running registrations.
4. The companion app continues to listen on the topic linked to its unique public key, forming a channel that can basically be used like an API.
5. The application sends storage requests or anything else it wants to implement. In this example, the companion app includes a Helia IPFS node and makes data available through the IPFS network, but in theory we could also implement SSH over this for example.