-
Notifications
You must be signed in to change notification settings - Fork 844
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: kubo 0.29 and native apple silicon #1856
base: main
Are you sure you want to change the base?
Conversation
@lidel, do we know where the difference in size comes from, specifically? We could find where they are and try something to minimize the impact of shipping the universal package. |
Not a dev, but I'm pretty sure the size increase is just the binaries about doubling in size due to basically containing two apps. |
Hello, any update? |
Thanks for the PR! I wanted to build this locally but ran into issues with the build step trying to download a arm ipfs binary that obviously didn't exist. How did you build this? |
It work fine with me, what error that you got? |
I think that Universal would be easier for the end users despite the storage size. In general, storage is cheap and 75 MB won't probably affect many people. Iff storage size is very important, we could either build universal + download go-ipfs on first run, or ship different binaries. |
@lidel Have we looked into https://github.com/tauri-apps/tauri at all? It claims significant improvements over electron across all platforms, though I haven't investigated more deeply. I also haven't found any apps that have migrated from electron to tauri |
Regarding universal app vs rosetta on M1.. the speed increases you get by running M1 native is significant in every benchmark I've seen. However, it would be great to see a breakdown of the risks & benefits for our specific application. I don't think we should decide to just force rosetta forevermore. If the decision is to wait for some period until we have more bandwidth, I think sticking with rosetta and the smaller bundle for now is fine. Ultimately, we should be moving to the type of app bundle the platform we're targeting recommends. For Apple/macOS, that is the universal build. |
I think we looked at it briefly, but it was very alpha back then. IIRC the main downside was lack of tooling for end-to-end autoupdate solution, which is raison d'être of ipfs-desktop. It seems they work on it, but it is still undocumented? tauri-apps/tauri#2776 Long term, we want to move away from fetching updates from centralized HTTP server like github and leverage IPFS+IPNS instead (see old notes in #789), so if we have working setup for that, we could move away from Electron (literally the only value it brings is https://www.electron.build/auto-update working on all three platforms: macOS+Windows+Linux(AppImage))
Usually I would be against doubling the size of download, but we talk Apple here – it is fair to assume that if someone uses mac they most likely don't care about additional download cost over the mobile carrier (just being realistic here).
Yeah, sounds like universal binary is the way to go. The caveat here is that we don't have "universal go-ipfs binary" – iiuc this PR (in current form) still bundles the intel version of go-ipfs. Figuring out how to include both binaries (arm64 and amd64) for darwin is the key to unblocking this. |
I wrote a plan for unblocking this in ipfs/distributions#770 (comment). |
I read that comment and the approach seems reasonable and clear. Thanks for the backlink! |
@lidel should this be closed as ipfs/distributions#770 (comment) is closed. I was also wondering if this could be solved as part of #2441 where instead of "shipping" a binary, we download and validate checksums and then use that? |
There are two separate topics at play (mind I am not macOS user, below is my rough understanding on Apple Silicon situation)
I agree we should close this, as universal DMG does not solve it end-to-end. |
please see #2681 for a continuation of this work |
Reopening because of #2813 I will prototype Universal DMG that includes Universal Kubo binary as well. |
303f306
to
50389dc
Compare
c416a4c
to
bb04002
Compare
bb04002
to
8839680
Compare
Fetching both
Remaining work is to upstream kubo+0.28.0.patch to npm-kubo repo and test DMG from this ZIP on both Intel and ARM macOS.
|
Also tested Tested https://dweb.link/ipfs/bafybeidw62sobej3qlfsmxxw5bbnczz6ithimvixf3xg7rwquur3iww66q/ipfs-desktop-0.35.1-mac.dmg on ARM and it worked. Can test on a MacOS Intel tonight. |
This is exploration into better support of Apple Silicon.
electron-builder supports producing either universal package or one for each architecture.
In case of Desktop, things are more complicated: we also bundle go-ipfs binary.
This means that unless the go-ipfs binary is also universal or per-arch, we can't improve much.
Due to the way we depends on go-ipfs via npm-go-ipfs universal binaries all the way sound like way easier route (downside being the disk size), however dist.ipfs.io already has amd64 and arm64 for darwin.
Universal binary test
Main cost of universal package is size, even with out go-ipfs (still being amd64) it adds ~75 MB:
TODO
amd64
: go-ipfs binary is amd64, it runs on M1 via Rosetta. Brave plans on usingarm64
in the near future, as they already providearm64
version of Brave itself.. In that contenxt universal binary is wasteful (IPFS component is fetched on-demand, so small size matters).go-ipfs
dependency (right now it downloadskubo
only for arch of CI worker, which is amd64).node_modules/kubo/bin/ipfs
update Electron (if needed)does not seem to be needed on ARM, tbd if Intel worksdownload
functionkubo
dependency with feat: expose standalone download function npm-kubo#73 (0.29.x)package-patch
forkubo
dependencyCloses #2813