IpfsCloud aims to be a decentralized cloud storage interface.
I started the first version of IpfsCloud last year as a side project. It got a good response from the community, and right now Ipfscloud has around 3000+ users. I thank all of our early adopters who encouraged me to build this ecosystem of apps and tools under an umbrella called Cluster Labs.
Right now, we support:
- Uploading and pinning data using a user-friendly interface
- Data encryption on user-side
We have also built a number of other apps:
- IpfsHost: Website Builder and hosting service on IPFS
- IpfsDocs: Google Docs on IPFS
- Quasar: Search Engine on IPFS
- Collab: 3d model collaboration tool on IPFS
You can check out our Youtube demos, Github and Website
But there were a few things that are needed to be changed in order to scale the projects.
- First, a decentralized identity solution. Right now, we use Firebase, which is not good when you are focusing on decentralization.
- Second, we needed better storage infrastructure to manage the nodes and pinset. Right now we use independent nodes(a few from our side, and infura nodes). Thus current infrastructure is not good when it comes to redundancy and scalability.
- Project is not modular enough to cultivate a rich ecosystem of apps and services around.
So, I am presenting a draft of IpfsCloud v2.0
The project(IpfsCloud) uses these 3 components, which makes it modular.
- KeyBase: A decentralized identity module
- Grafia: A modular interface to interact with the data, that exposes a number of endpoints to interact with other services and also could serve as a standalone application in some contexts.
- Egress: A IPFS Cluster based infrastructure of nodes, which can be managed and monitored using a GUI called Horizon.
Let’s take a more detailed look on these components(This is an informal draft. The formal draft will be added in the links at the end of this draft):
KeyBase
KeyBase uses **DID**s as a base for its functioning.
The basic idea of KeyBase is to define a multi-DID management framework so that it can be used by an dapp to manage users which can have identities from different DIRs(Distributed Registries)
The supported DID methods need to define a set of functions(as mentioned in W3C DID Spec draft) in order to be compatible as a KeyBase implementation.
A brief overview of how it will work.
- An app/service will have a service endpoint.
- A user(owner of a DID) with a DID(registered on a DIR) visits website/app of a service.
- [SIGN UP] The user Signs up on the service. This adds the service endpoint of the service to the DID-document of the user. It is recommended to follow DID-Auth spec when signing up a user.
- [LOG IN] When the user logins, the user needs to prove his ownership of the DID.
- [RECOVER] When the user loses control of the DID(eg. loses the private key controlling the DID), then the DID method must provide a function to recover his/her DID.
There are also many optional, but good to have functions in a DID method
- A user can associate verifiable claims, such as claims of owning a social network account(such as Keybase). These verifiable claims can be self-signed or can be issued by an external service(if an external service is involved, then the service endpoint to that claims service must be added to the DID-document). The more the claims linked to a DID, the more authentic it becomes.
- DID delegates prove to be a really powerful tool when it comes to seamless and secure, cross-platform or cross-device experience.
Design goals:
- Intuitive and Familiar experience for the end-users. The users should have minimal interaction with the private keys and cryptographic operations.
- It should be clear and easy for developers to authenticate the users.
Proposed implementation
It is easy to store and manage keys and other information when it to mobile users. But the real problem comes when interacting with the web user. So, in order to cover all the platforms, i.e. mobile, web and desktop we will have
- SDK for mobiles
- Modules for desktop
- Browser extensions for the web
Grafia
Grafia aims to be a modular interface which exposes a number of endpoints to interact with other services(for identity management, networking, etc.). It can also be used as a standalone application in some contexts.
Uses-cases
- Can be used as a file browser for a Storage service based on IPFS.
- Can be used as a stand-alone Libp2p peer. The interface can be used for streaming videos peer-to-peer, collaborating on documents, etc. using pub-sub.
The ideas are pretty initial for the technical details of Grafia. I want that it could be used by as many applications by the community, rather than just for a singular application.
I WOULD REALLY LOVE SOME SUGGESTIONS HERE.
Egress
Egress aims to become an infrastructure utility. It uses IPFS Cluster for orchestration of the pinset and managing the peers.
The functions for managing peers and data are exposed by the IPFS Cluster, which can be utilized by a GUI like Horizon for a better experience.
For IpfsCloud we also plan to use MFS in order to maintain a virtual file system. This solves the problem of “How to store the directory structure of the user’s data?”
Links
IpfsCloud v1.0: Github
KeyBase: Github
Grafia: Github
Egress: Github
@josselinchevalay @olizilla @daviddias @lidel @hector @NukeManDan @NatoBoram @hacdias
