Open AustinFoss opened 1 year ago
in a browser you can observe the proper output in the console
Can you check epiphany / gnome web too? It's a browser based on webkitgtk which we use as the webview.
Otherwise the only potentially related issue i found was this: https://github.com/ipfs/js-ipfs/issues/3878#issuecomment-1015815324 - it's for safari on ios, but that's still webkit so i think it's worth to try the workaround mentioned there.
I just tried it with epiphany and got the same result.
I wasn't sure how to implement the same logic check for isSafari
so I independently checked it for all 3 cases on both the Epiphany Browser and the Tauri view. According to these types, the algorithm property of the options object passed to create()
can be any of these 3:
export const Ed25519 = 'Ed25519'
export const RSA = 'RSA'
export const secp256k1 = 'secp256k1'
export type KeyType = typeof Ed25519 | typeof RSA | typeof secp256k1
All three work in Brave (what I'm testing with), as well as firefox, but all 3 fail in epiphany and the tauri view.
Does epiphany have a problem with those 3 encryption algorithms?
Depending on where that info leads I could link this issue over in that closed issue in the js-ipfs repo, or the gnome epiphany gitlab repo.
It sounds like a webkitgtk issue to me if it works fine in Safari. so either the webkitgtk repo or the ipfs repo or both.
epiphany is basically in the same place as we are. they just use webkitgtk
Describe the bug
My goal was to implement a desktop IPFS app using JS-IPFS that could ultimately be ported to mobile after seeing last week's alpha announcement.
I started with the Nuxt3 framework but ran into some other errors, seemingly related to Nuxt's router. So I switched to the vanilla-ts template generated using
yarn create tauri-app
for my starting point.When trying to call the function
creat()
from the 'ipfs' npm package, lines 16-27 of the 'main.ts' file, I get a very non-descriptive error message.Because this works in a browser just fine I'm not to sure what's going on in the Tauri side, whether it's Tao or Wry related.
Any insight would be greatly appreciated!
Reproduction
cd
into the directory,yarn install && yarn tauri dev
to run the basic demoExpected behavior
If you run
yarn dev
and open the server address, mine is 'http://127.0.0.1:1420/', in a browser you can observe the proper output in the console. Something like:IPFS2 {hashers: Multihashes, bases: Multibases, name: NameAPI, ipns: IPNSAPI, preload: ƒ, …}
Much larger when expanded.
Platform and versions
Environment › OS: Pop!_OS 22.04 X64 › Node.js: 16.15.1 › npm: 8.13.1 › pnpm: Not installed! › yarn: 1.22.19 › rustup: 1.25.1 › rustc: 1.65.0 › cargo: 1.65.0 › Rust toolchain: stable-x86_64-unknown-linux-gnu
Packages › @tauri-apps/cli [NPM]: 1.2.2 › @tauri-apps/api [NPM]: 1.2.0 › tauri [RUST]: 1.2.2, › tauri-build [RUST]: 1.2.1, › tao [RUST]: 0.15.7, › wry [RUST]: 0.23.4,
App › build-type: bundle › CSP: unset › distDir: ../dist › devPath: http://localhost:1420/ › bundler: Vite
App directory structure ├─ .git ├─ .vscode ├─ src-tauri ├─ node_modules └─ src
Stack trace
Additional context
IPFS has some extra info from their examples how to configure Vite to bundle the package: https://github.com/ipfs-examples/js-ipfs-examples/tree/master/examples/browser-vite
I adapted their vite.config.js for use in my project so the default vite.config.js in my repo has some changes. Although is seems the only one that's needed after Vite 4 was: