search

ipfs / ipfs-desktop

An unobtrusive and user-friendly desktop application for IPFS on Windows, Mac and Linux.
https://docs.ipfs.tech/install/ipfs-desktop/
MIT License
5.85k stars 849 forks source link

"Nativeness" of IPFS Desktop #867

Open hacdias opened 5 years ago

hacdias commented 5 years ago

As of building #866, we clearly verify that the app could be much better and simpler if done natively or with something else than Electron that is even snappier/faster. Although, the approach of going full native have pros and cons. I'd like to discuss with you all if this is an effort we should focus on or not.

How

By going native, we'd need to create separate macOS, Windows and Linux apps. During transition period, we could eventually build one by one and keep the Electron version alongside.

We could perhaps have a shared library in C++ if needed for something like a ipfsd-ctl. Or perhaps we wouldn't even need it.

Cons

Usually people start by the pros, but I thought about starting with the negative aspects of going native:

  1. We'd need to support three different technologies.
  2. The above requires more work to keep the three platforms in parity of functionality.
  3. We'd need to, perhaps, ditch the "so-deep" integration with Web UI. It's not that deep: it's just the language and three preferences. We could just open the Web UI on user's default browser.

Pros

On the bright side of the situation:

  1. Native means native.
  2. Better functionality:
    • Right now, the macOS app is the one which seems more native because Electron uses the native menus. On the other hand, on Windows, Electron doesn't use the native menu's and doesn't feel as native.
    • There are some features really hard to implement using the current solution. Please see https://github.com/ipfs-shipyard/ipfs-desktop/issues/678#issuecomment-472479791 for an example.
    • By being native we could perfect the functionality.
  3. Smaller binaries.
  4. Faster.

I'd really like your thoughts on this. There are some things I'd like to implement (native integrations) but that won't be really easy to do with Electron/Node.js. Not impossible, just harder.

This would be a big change and would require a lot of work. Would it be worth it?

cwaring commented 5 years ago

Not entirely "native" but DeskGap could be a viable lighter-weight alternative too, it uses the OS webview rather than bundling chromium. Might we worth experimenting with.

hacdias commented 5 years ago

@cwaring didn't know that! I'll keep an eye of them. They're still missing really important APIs for us such as Tray.

hacdias commented 5 years ago

Dear friends, just updated the main comment. Please read through it and leave your comments. /cc @cwaring @olizilla @alanshaw @lidel @fsdiogo 😄

lidel commented 5 years ago

My concerns about switching from a single language/library to three would be related to PMing challenges:

That being said, if we keep app's surface small, getting MVP in sync on all three platforms would be mostly a one-time effort. Everything else would be platform-specific native integrations that do not block/lag other implementations.

hacdias commented 5 years ago

@lidel for me, the main feature of IPFS Desktop is to keep running IPFS in the background. Everything else are native integrations (drag'n'drop, add to context menu, protocol handling, etc...).

I can't see many features that could be considered 'attached' to what IPFS Desktop is. Perhaps if we added the possibility of running multiple versions/nodes yes, that would be required to be in all implementations, but those are good functionalities. I think the main point is to provide good and reliable native integrations.

So... I agree with you and I believe that basically what we have now is IPFS running + native integrations. The only thing we'd need to ditch is the Web UI inside a Window perhaps. But I don't think that'd be a really big/important change IMO. We could even tell that Web UI's running through Desktop with a URL query value. What do you think?

I've been actually taking a look at Swift on macOS and it seems quite straightforward. The only API we use on Desktop and the one important for the native integrations are related to the files. Basically we'd just need to call the daemon directly or use the HTTP Api. It's not really a big thing to implement. At least this is what I think.

olizilla commented 5 years ago

I'd like to improve the stability of what we have first. I think 0.7 is a good release, but I know we can make it better.

We're a small team with a large number of websites and apps to look after, so I'd rather we spend the next quarter improving what we have before we explore starting again.

I do totally take your point @hacdias that now we have reduced the scope of IPFS Desktop right down, it'd make a lot of sense to try out a fully native alternative, but don't forget that we need to also come up with reliable installers and update mechanism for each platform, it just feels like we should spend our time improving proto.school and js-ipfs and webui in time for camp.ipfs.io as a much higher priority.

hacdias commented 2 years ago

Something just caught my eye: https://wails.io/

hacdias commented 2 years ago

cc @SgtPooki related to #2184

RubenKelevra commented 2 years ago

Something just caught my eye: https://wails.io/

I think Tauri would work better tbh, as there is Android and iOS support in the works right now, but I could be wrong here. :)

mainiak commented 1 year ago

Just FYI - I tried https://github.com/fyne-io/fyne and it looks promising, but I couldn't get it to work.
I agree that Wails might IMHO be best for GO apps and especially IPFS. I would be super happy if you decide to switch to it 😉

SgtPooki commented 12 months ago

Fyi that selfupdate is possible with wails. Example at https://github.com/achhabra2/riftshare/blob/main/internal/update/selfupdate.go

Wails self-update convo at https://github.com/wailsapp/wails/issues/1178

leaanthony commented 12 months ago

Wails maintainer here 👋 Would be happy to support your efforts if you decided to use it or do a PoC 👍

SgtPooki commented 12 months ago

Wails maintainer here 👋 Would be happy to support your efforts if you decided to use it or do a PoC 👍

@leaanthony I attempted a small PoC with https://github.com/SgtPooki/ipfs-desktop-wails but i'm not a gopher and i'm not sure how best to execute another go-cli(https://github.com/ipfs/kubo) as a subprocess. Ideally, Kubo functionality should all exist in https://github.com/ipfs/boxo but we're not there yet.

I attempted a PoC with https://github.com/SgtPooki/ipfs-desktop-wails. But I haven't touched it in a while. I think the only blocker for me right now is figuring out how to execute Kubo on the backend (and get TS types from Kubo's go types) to allow for easy migration to Boxo in the future.

If anyone wants to help with that repo, please let me know and I can add you as a maintainer.

mainiak commented 12 months ago

I attempted a PoC with https://github.com/SgtPooki/ipfs-desktop-wails. But I haven't touched it in a while. I think the only blocker for me right now is figuring out how to execute Kubo on the backend (and get TS types from Kubo's go types) to allow for easy migration to Boxo in the future.

If anyone wants to help with that repo, please let me know and I can add you as a maintainer.

I am not sure if I can be "maintainer" level, but count me interested.

Also, @SgtPooki, should we create GitHub discussion or maybe Discord channel on IPFS server to discuss this alternative implementation?

ie. I am not sure it is right move to have process fork to run Kubo, while you can just allow (for now) users to run pure Kubo or IPFS Desktop in background, while ipfs-desktop-wails is in alpha state.

Also, I was not entirely able to get the embed the IPFS (web) UI to get work from your repo, but that should (I hope) be easy fix, if all you need is Wails to be a wrapper around it.

Later on, ipfs-desktop-wails can be bound to Boxo library and even (ideally) use Go layer instead of JavaScript one.

Anyway, I am more than happy to dive into this - I just think we need different thread for that :-/

leaanthony commented 12 months ago

You can expose Go structs and methods to TS via the automatic bindings and model generator. It's not perfect but works for most use cases.

lidel commented 1 month ago

I wrote this as a slack update, but moving here so it can be referenced in future

My understanding is that the conversation on Wails stalled due to the lack of resources.
Mind, the current team does not have spare cycles to do basic maintenance like updating to latest Electron (https://github.com/ipfs/ipfs-desktop/issues/2775).

Personally, I'd love to make ipfs-desktop more lean, and leave Electron behind, but rewriting with a different engine requires full-time commitment over a long period of time, which the team is not able to allocate right now.

If someone is determined to help and make this happen, it is fine to work on this in their own repo until it is ready.

In my mind, problems that need to be solved by such person (in order):

Mind, until autoupdate story is not ready, there is no point in spending time porting functionality.

leaanthony commented 1 month ago

iiuc (Support Self-Updating wailsapp/wails#1178) Wails seems to have no robust anser for this, there are many competing libraries with single maintainer.

We don't have an official updater because the feedback from the community was that people wanted to make their own as they have different needs. Not that it's hard mind: https://github.com/achhabra2/riftshare/blob/main/internal/update/selfupdate.go

There are plenty of libraries to achieve this, such as https://github.com/fynelabs/selfupdate - The Go way is to compose. Wails is a bit of an exception in being so opinionated.

Anyway, if you need any help with this, you know where we are 👍