feat/discussion: use boxo directly instead of kubo?

[SgtPooki]

should we migrate ipfs-desktop to utilizing boxo instead of kubo? It could make sense to use wails+boxo for ipfs-desktop (i.e. https://github.com/SgtPooki/ipfs-desktop-wails) instead of booting up a kubo daemon as a separate process

[BigLep]

Boxo doesn't have Kubo's RPC layer which ipfs-webui depends on right? I don't know how hard that is to do.

It might be worth getting into the pros/cons of having Kubo as a separate process in Desktop to help motivate this as well. (I'm not up on the specifics here.)

[SgtPooki]

Boxo doesn't have Kubo's RPC layer which ipfs-webui depends on right? I don't know how hard that is to do.

The cool thing about using boxo directly would be that we'd bind js methods directly to the go methods, so we don't need the RPC api. However, i'm not sure whether this would be more or less difficult for ipfs-desktop maintenance. That would depend greatly on wails.

Either way, i looked at the wails roadmap and there seems to be a number of features missing that we should have before switching (if we do).

[lidel]

Removing electron sounds nice, but the price may be very high.

Some open questions from my end:

• Would we stub a subset of Kubo RPC somehow, to keep ipfs-webui working, or is the intention to replace ipfs-webui as well?
  • both are heavy lifts, and unlikely be P0-P1 to pull this off any time soon given the resourcing/priorities we have
  • reusing webui and "just stubbing rpc" may not be as easy as it sounds:
    • ipfs-webui uses a significant amount of Kubo RPC commands, including very hairy code like one for remote pins
    • boxo is not "feature complete" -- most likely additional extraction work would be necessary to allow for code reuse. this could be beneficial to boxo and ecosystem, but we need to be aware this is an unknown amount of work.
• How would autoupdate work?
  • Wails does not seem to have officially supported library for this, and there do not seem to be a canonical, well maintained solution. This means we either use something someone created in one evening, and may stop supporting next month, or have to write our own, preferably on top of IPNS (Hardening Updates with Content-Addressing and IPNS #789).
  • How would we update/migrate existing Electron users that rely on electron-updater and github release?

[whizzzkid]

Regarding auto-update, tauri provides auto-update functionality out of the box.

Is Wails the preferred framework to move forward with? Even though it's written in Go, IMO, desktop should be agnostic to what binary is running in the background, kubo, or parts of boxo. Additionally path should be left open for running other binaries to run experiments like punchrr, etc.

Desktop should eventually evolve into a certified runtime for such projects.

[SgtPooki]

The plan for ipfs-desktop is to tie it directly to kubo, so tauri would align more directly with a rust impl of IPFS. Makes sense that wails+boxo isn't quite where it would need to be for this yet, I just wanted to get this conversation out there. Closing this as there is no clear next steps (and we have enough open issues in this repo as it is), but we can continue to track any convo on this issue if folks wish.