migrate-over-ipfs: address feedback

Author: Stebalien

proposals/migrate-over-ipfs.md

@@ -42,51 +42,62 @@ _How much would nailing this project improve our knowledge and ability to execut
 This is ones step towards our goal of updating go-ipfs itself over IPFS. In terms of knowledge, not much.
 
 #### Confidence
-_How sure are we that this impact would be realized? Label from [this scale](https://medium.com/@nimay/inside-product-introduction-to-feature-priority-using-ice-impact-confidence-ease-and-gist-5180434e5b15)_.
+_How sure are we that this is the right problem to tackle? Label from [this scale](https://medium.com/@nimay/inside-product-introduction-to-feature-priority-using-ice-impact-confidence-ease-and-gist-5180434e5b15)_.
 
-10? We're not shipping a new release to brave until we have _a_ way to ship repo migrations to users in China.
+3?
+
+- It's a frequent source of upgrade problems: https://github.com/ipfs/ipfs-desktop/issues?q=is%3Aissue+fs-repo-migrations
+- It's preventing us from shipping new go-ipfs releases (with important fixes) to brave users.
+- It hurts adoption in China.
 
 ## Project definition
 
 #### Brief plan of attack
 
 **Design sketch:**
 
-When migrating a repo:
-
-1. Create a new _temporary_ repo (go-ipfs can't read the current repo because it's an older version).
-    a. If the local go-ipfs node uses a swarm key, skip to step 3.a (download over HTTPs).
-2. Start a new _temporary_ go-ipfs node in the temporary repo.
-    a. This node should not listen for inbound connections as it has no way to know which ports/transports should be configured (can't read the config).
-    b. This node should not expose an API/gateway.
-3. Download the required migration binaries using the temporary go-ipfs node.
-    a. If this fails, download over HTTPs.
-4. Migrate the main go-ipfs node's repo.
-5. Start the main go-ipfs node and _transfer_ (but don't pin) the downloaded migrations into the main repo so that others can download it from this node.
-6. Shut down the temporary node and delete the temporary repo.
-
-Provide the following configuration section:
+Given a config section like:
 
 ```js
 {
     "Migration": {
-        // When true, always use IPFS. When false, never use IPFS. When unset, pick the default
-        // behavior.
-        "UseIPFS": true|false,
-        // When true or unset, use the default gateway. When false, don't use a gateway. When a
-        // string, use the specified gateway.
-        "UseGateway": true|false|"my-gateway",
+        // Sources in order of preference where "HTTPS" means our gateways and "IPFS" means over IPFS.
+        // (an empty list means "do the default thing")
+        "DownloadPolicy": ["HTTPS", "custom-gateway.io", "IPFS"],
         // Whether or not to keep the migration after downloading it.
         "Keep": "pin"|"cache"|"discard"
     }
 }
 ```
 
+For the initial version, the default download policy should be `["HTTPS", "IPFS"]` unless the local
+node uses private networks (has a swarm key) in which case it should just be `["HTTPS"]` for safety.
+As we gain confidence in our ability to reliably download migrations over IPFS, we should make it
+the default.
+
+When migrating a repo, until we succeed.
+
+1. If the next source is HTTPS, download from `ipfs.io`.
+2. If the source is IPFS:
+    1. Create a new _temporary_ repo (go-ipfs can't read the current repo because it's an older version).
+    2. Start a new _temporary_ go-ipfs node in the temporary repo.
+        a. This node should not listen for inbound connections as it has no way to know which ports/transports should be configured (can't read the config).
+        b. This node should not expose an API/gateway.
+    3. Download the required migration binaries using the temporary go-ipfs node.
+4. Migrate the main go-ipfs node's repo.
+5. Start the main go-ipfs node.
+6. Maybe store a copy of the migration:
+    1. If `Keep` is not "discard", import the migration binary into the main go-ipfs node's repo.
+    2. If `Keep` is "pin", pin the migration binary.
+7. If running, shutdown any temporary nodes and delete the temporary repo.
+
 **Implementation steps:**
 
-1. Implement everything but steps 3.a and 5.
-2. Implement step 3.a. We'd need this at a minimum before enabling this feature by default.
-3. Implement step 5. Unless nodes keep around a copy of the migration, this feature isn't going to be all that useful.
+1. Implement everything but step 6.
+2. Implement step 6. Unless nodes keep around a copy of the migration, this feature isn't going to be all that useful.
+3. Eventually, switch over to using IPFS by default instead of the gateway as the first option.
+
+NOTE: the only reason we're proposing using the gateway first is that the migration blocks startup so it needs to be fast and reliable.
 
 #### What does done look like?
 _What specific deliverables should completed to consider this project done?_
@@ -102,7 +113,7 @@ Users can start a new version of go-ipfs that switches to a new repo version wit
 #### Counterpoints & pre-mortem
 _Why might this project be lower impact than expected? How could this project fail to complete, or fail to be successful?_
 
-1. Downloading migrations over IPFS could be too slow/unreliable. Falling back on a gateway should mitigate.
+1. We may not be able to download/find the migration on IPFS. Trying the gateway first (or racing) should help mitigate this.
 2. The "temporary" node may be missing important parts of the configuration. For example, it may need alternative bootstrap nodes as our nodes may not be reachable. We'll need to think about this carefully and may need to "reach" into the old repo's config file a bit.
 
 #### Alternatives