Hosting, Backup and Fallback Planning

[Arlodotexe]

Overview

• The new system will be self-hosted, while the old systems are hosted by heroku and a postgres database.
• Our SDK has moved to using ipfs for everything, so we really will be fully selfhosted-- the idea being that ipfs will enable our users to selfhost as well without losing anything. We have details on github about this.
  • IPLD Database Migration #144
• I have onsite machines that I'll be using to host the discord bot and SDK data.
• See also IPFS Gateway planning for windowsappcommunity.com #13

Re-hosting and backups

We'll be self-hosting on local hardware, which naturally increases our risk of data loss.

Since everyone is now built on IPFS, re-hosting should be straightforward.

The main thing missing here is an inventory of everything that needs to be rehosted. This should include, but may not be limited to:

• Nomad repo data for Users/Publishers/Projects
  • CAR export of local and roaming IPLD data, including hosted assets (images, etc)
  • Export of local and roaming IPNS keys

The backup needs to be held offsite by at least one other staff member.

Fallback hosting

Since everything will be locally hosted, we need to also account for network downtimes.

If the internet or power locally dies-- so be it. We should be able to accommodate.

Assuming we've re-hosted our data with another staff member, we could build a fallback for the Discord bot.

Using IPFS to coordinate, we can leave multiple instance of our code running. When one instance goes down, another instance can take over seamlessly.

This is easy to do with our Server Companion bot, but may not be as easy with our IPFS-powered HTTP gateway. Such a setup will require additional planning.

It would provide the best experience to pre-swarm our staff or community members, but most people won't be running their own local node. In a way, our HTTP gateway acts as this pre-swarm for those users.

Alternatively, we have tools like inbrowser.link which avoid the need for downloading and running Kubo, but HTTP is our first choice right now.

Open questions and concerns

Fallback is easy for the code running our discord bot, but much less so for the code running our IPFS-HTTP gateway.

This may get complex.

Since only one person has control over DNS-level code and accounts, trying to do fallback delegation to another staff member creates an unsolved challenge.

How can we handoff DNS-level control of our HTTP gateway in a safe and reliable manner?