Show repository migration progress in go-ipfs 0.12+

[lidel]

Ref. brave/brave-browser#20106, ipfs/kubo#8344

• MVP in Desktop case would be to show window with startup log that contains migration progress.
• It should also detect migration errors like: Add meaningful GUI error when migration fails #1823

[lidel]

How to test or simulate migration

One can create ~/.ipfs (IPFS_PATH with a repo that needs to be migrated) by:

1. downloading go-ipfs v0.11
2. executing IPFS_PATH=/migration-test ipfs init and IPFS_PATH=/migration-test ipfs add --cid-version 1 on some files
3. downloading go-ipfs 0.12-rc1
4. executing IPFS_PATH=/migration-test ipfs daemon --migrate=true with 0.12 binary

Wireframe

My initial idea is to have something very simple and generic:
(just an inspiration, implementer should feel free to course-correct as they go)

Key points

• detects when go-ipfs runs a migration and inform user why it takes long to start IPFS Desktop

  • one sentence should be enough, most users do not care and will just dismiss and let it run in the background

• shows stdout+stderr from ipfs daemon as a way to eyeball migration progress

  • 👉 we were lucky until now, could skip this for most migrations, but we have to have some progress indicator for 0.12 where migration may take anywhere from a few seconds/minutes to hours (if someone has a slow HDD and hosts hundreds of gigabytes of CIDv1 data such as wikipedia snapshots). showing the daemon output feels like the best we can do given existing APIs.
    • ℹ️ ipfsd-ctl pipes both stdout and stderr to debug logger – i wonder if we could read it somehow? In terminal I can do DEBUG="ipfsd-ctl:daemon:*" npm start and see the daemon output. I know that ipfs log tail also exists but it does not seem to be wired up to show migration log.
  • 💡 this could be useful outside migrations – we could show this window also when go-ipfs fails to start. Original error from ipfs daemon may allow more savvy users to self-service and fix basic problems.

• easy to dismiss

  • one button that closes the info window
  • closing the window does not interrupt migration/startup process, it should continue in the background

[lidel]

@hacdias will you have time to poke at this sometime in next two weeks?
Not a fire, but we won't be able to ship ipfs-desktop 0.12 without this, and I am just planning ahead :)

[hacdias]

@lidel yes, I can work on this. I can read the stdout and stderr in this way:

// define ipfsd

const interval = setInterval(() => {
    const sub = ipfsd.subprocess
    if (!sub) {
      return
    }

    sub.stdout.on('data', data => console.log(data.toString()))
    sub.stderr.on('data', data => console.log(data.toString()))
   	clearInterval(interval)
}, 100)

ipfsd.start()

However, .subprocess is undocumented and probably should't be directly used. Besides, the interval to try to get the subprocess variable between it is created and the daemon is actually created is a bit fiddly, but it works! I will try using this for now to implement the logging. Perhaps we should consider adding some API for this on IPFSD CTL later.

[lidel]

Thanks!

• FYSA 0.12 got released, so you can test with official release now :)
• subprocess is part of the public Controller interface, so I think it is safe to use for now
• when we have a PR demonstrating our use case, we can ping Hugo to advise on improving the ipfsd-ctl API