Increase availability of Ceramic nodes by adding better DevOps documentation

[0xjjpa]

Background

For individuals involved in the web3 ecosystem for a long time, observations about the state of its infrastructure pointed by @moxie0 are not only valid but legit concerns. Right now, according to the docs, the way to use Ceramic is to use one of the current gateways hosted by 3BoxLabs, which at the time of writing, are currently backed by other 22 nodes, out of which 5 are controlled by Ceramic or 3BoxLabs. Furthermore, there is only the current Terraform template, despite existing projects trying to automate the deployment of Ceramic nodes.

Description

Ideally, I would like to see,

• A registry of all the existing Ceramic nodes in the ecosystem, perhaps via an Explorer or similar.
• Instructions on how to deploy Ceramic nodes in multiple providers, via Terraform, Puppet, in GCloud, AWS etc.
• Have a public-facing website and friendly set up to make this process as transparent as possible.
• Ideas on how to incentivize Ceramic nodes that do not involve necessarily a token (e.g. whitelisting node runners).

Technical Information

Due to the number of dependencies Ceramic nodes need, it's not easy to have a "one-click" deployment for most providers. However, it should be possible to create an app that "connect"'s to an IaaS and allow provisioning scripts to work their magic. For most technical users this can be done via simple GCP/AWS keys, but we can probably figure out a way to get them easily.

Additional notes

The Ceramic nodes are not the only moving piece for the network to work properly, a CAS service is also needed, which is also currently only at the discretion and control of Ceramic/3BoxLabs. Ideally, a push to decentralize this service should also be aimed in a separate issue.

[oed]

Hey @jjperezaguinaga, these are great ideas. I would also really like to see more instructions around how to spin up ceramic nodes in various different environments!

Currently the peerlist repo acts as a defacto registry of Ceramic nodes in the ecosystem. We are however working on improvements that will enable anyone to spin up ceramic nodes in a permissionless way. Right now our focus is on go-ipfs support, which should remove the need of adding your node to the centralized peerlist.

We are also planning to make it easier for others to run their own CAS service. In order to do this some improvements are needed in the protocol with regards to how key revocation is handled. Longer term we hope to get rid of the CAS service entirely.

All of that being said, I would love to hear suggestions or contributions around any of these topics.