While it is evident that all Aragon apps require IPFS pinning for app assets, the following Aragon apps will require an IPFS pinning solution for user-generated content:
- Pando
- Projects
- Home
- Espresso
- P2P models Wiki
- Discussions
- Profiles
ā¦and the list will grow. Right now the go-to pinning solution for some of these projects is Infura as they have an open API, but this isnāt a sustainable solution. While Aragon One has a self-managed IPFS node, there is no public API for additional Flock, Nest or third-party teams to utilize.
A Potential Solution
Requirements
- Locally pinned files stay pinned when a user exits their session
- Files are accessible, preferably with a fast load time
- Files are verifiable, so that a user can verify the data retrieved is the data asked for
- The architecture can handle outages - if an IPFS node goes down, we should be able to continue giving access to our files
- Limit security vulnerabilities and expenses - only approved clients should be able to pin data on our node
- Data adheres to open standards
An initial architecture could look like:
Client applications send requests to our backend server, where information gets pinned across multiple providers. Our backend validates the data adheres to specific open standards (schema.org to begin with) when applicable and then pins the files/data.
Fallback Procedures If Our Node Goes Down
Itās conceivable weāll have some bumps along the road running our own node. We need to be able to handle those situations:
- Active monitoring services like http://pm2.keymetrics.io/ to ensure our node is up and running
- A queueing system to track unpinned files while nodes are down, and re-pin files once node is back online
- Modular infrastructure - the IPFS node will be hosted on its own (isolated from the REST API), so that the node going down will not cause the REST API to go down
Authentication
Initially, we canāt protect against every attack, so weāll attempt to deter them as much as possible:
- Require JWT authentication with an ethereum signature, so we can block any single ethereum address from pinning too many files at once
- A developer must obtain a developer token from us to pin data on our node (this idea needs to be fleshed out more)
- Possibly whitelisting domains and/or IP addresses (although this would make it hard to handle DAOās running locally on the browser or on a desktop app).
- Strict schema validation - we will only pin data that adheres to verified open standards when applicable. We wonāt pin data that does not fit the schema validation. (maybe there are some caveats here, so people can use our pinning service but just not our node). The community can submit PRs to include new MongoDB schema types, which will automatically be checked for validation and added to possible pin types. (i.e. - an Aragon Network team can submit a new schema for a type of data they want pinned. Once approved, the backend will accept this schema and pin data that fit this schema appropriately).
Querying / Verifiability
Itās conceivable that applications will want to query specific terms or vocabularies within metadata and files. Our backend system can offer that reliably by caching files in MongoDB without jeopardizing the validity of the information.
Internally, MongoDB documents will use CID as their ID schema, so that content requests made by clients can be based on specific hashes. The clients can therefore verify the content by either re-computing these hashes, or fetching the same hash from the IPFS network and comparing results.
IPFS-Cluster
It seems like IPFS Cluster could be used in two productive ways:
- Open Work Labs/Autark runs a node cluster instead of a single node
Benefits:
- Allows us to run more nodes and add extra pinning space (~7000 entries in pinset?)
- Provides fault tolerance - if we replicate files across more than one node in the cluster, pinned files can stay available if/when a single node in the cluster goes down
- Easier to scale as the network grows
Questions:
- What additional expenses get incurred (both economically and computationally) when running a cluster versus a single node?
- Can you turn a previously running node into a new cluster administrator without it going down?
- Are there any additional devops complications associated with running a cluster? More things to break? Harder to monitor? Link
- How hard is it to get up and running? Running cluster on Kubernetes, Local cluster setup and pinning example
- What happens if the clusterās leader goes down? (presumably the rest of the cluster stays alive perfectly fine)
- How difficult would it be to scale from running our own cluster (and each individual node in the cluster) into option number 2 (below)ā¦
- How could we remove pinned data from the cluster that was pinned by a node whose access was revoked?
- Aragon community uses IPFS cluster as a pinning ring to allow Nest and Flock teams to collaboratively pin files together
Benefits:
- The community has assurance that important files are pinned - without waiting for filecoin, paying for external services, or relying too heavily on centralized services
- More teams participating and strengthening the IPFS network!
Questions:
- (All the qās above apply here too)
- Who would be the cluster administrator? How hard would this responsibility be?
- What additional security concerns need to be thought out?
- How would we share secret keys with new partners?
- How would we develop trust models among peers in the cluster? How would we revoke trust?
- How large can we scale a cluster today? (this is currently not stress tested much)
- How hard would it be to build services on top of the cluster (for example, database querying with mongo. More on this below)
Future
Allowing other external node providers to get involved in our cluster would also provide some complications when it comes to managing the MongoDB - we would have to listen to changes to the cluster pinset that werenāt emitted by our backend, and then update our db. Conversely, if a GET request is received for a file thatās not in our mongoDB, we could resolve the content through the network, and then store it in mongo.
Textile Cafes also provide a lot of great offline services for pinning nodes. The problems theyāve solved in the mobile world have similarities to that of DAOās - local DAOās signing on and offline // pinning files locally and backing them up on an āalways onā pinning node. If each DAO ran a textile node, and we hosted a cluster of textile cafes, itās likely that we would have a very robust and distributed architecture. This would take a significant amount of dev work so something to consider for the future. In the meantime weāll see if we can use cafes on their own as a better pinning node.
Hereās what an architecture with Textile could look like:
Filecoin
We are very interested in building a filecoin integration in the future. A backend server to manage filecoin seems like a great place to start because it abstracts a lot of the UX and technical complications away from Aragon clients - no key pair management, no buy/ask spreadsā¦etc. Itās conceivable that a user friendly initial solution is to build a meta-transaction layer on top of filecoin - where DAOs can pay for filecoin storage and retrieval through our backend layer, where most of the complexities are handled by us.
A DAO app that manages filecoin payments in a fully distributed manner seems like an interesting future idea too. It makes sense to look into integrations between ethereum smart contracts and the filecoin blockchain, to see if any additional requirements would be burdened on the user (like a Filecoin metamask requirement for example). Something definitely worth exploring.
Appendix with more information and research
Reference links