Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

browser/nodejs interop issues #720

Closed
haadcode opened this issue Jan 19, 2017 · 13 comments
Closed

browser/nodejs interop issues #720

haadcode opened this issue Jan 19, 2017 · 13 comments
Labels
kind/support A question or request for support

Comments

@haadcode
Copy link
Member

As I'm trying to get the interop between js-ipfs browser and js-ipfs node.js version working, I ran into some issues that I'll add here as notes and for discussion to solve them.

@haadcode haadcode added the kind/support A question or request for support label Jan 19, 2017
@haadcode
Copy link
Member Author

I have the following setup:

npm i -g libp2p-webrtc-star
npm i -g ipfs
star-sig

I have a browser instance connected to the same star-sig server at 127.0.0.1:9090.

I did:

jsipfs init
nano ~/.jsipfs/config

I added "/libp2p-webrtc-star/ip4/127.0.0.1/tcp/9090/ws/ipfs/QmbqtQaNqb7zQcrRGaG5WDPs8swwYM5M8sRQvLmFWMKjV9"toAddresses.Swarm` and removed the tcp address, ie. only the webrtc-star address is defined in the config.

I then ran

jsipfs daemon

And in a separate shell:

jsipfs add file.txt

I get the following error output in the shell that was running the daemon:

Initializing daemon...
Starting at /Users/samuli/.jsipfs
Swarm listening on /libp2p-webrtc-star/ip4/127.0.0.1/tcp/9090/ws/ipfs/QmbqtQaNqb7zQcrRGaG5WDPs8swwYM5M8sRQvLmFWMKjV9
API is listening on: http://127.0.0.1:5002
Gateway (readonly) is listening on: http://127.0.0.1:9090
Daemon is ready
/Users/samuli/.npm-packages/lib/node_modules/ipfs/node_modules/libp2p-mdns/src/index.js:120
        const port = multiaddrs[0].toString().split('/')[4]
                                  ^

TypeError: Cannot read property 'toString' of undefined
    at EventEmitter.gotQuery (/Users/samuli/.npm-packages/lib/node_modules/ipfs/node_modules/libp2p-mdns/src/index.js:120:35)
    at emitTwo (events.js:106:13)
    at EventEmitter.emit (events.js:191:7)
    at Socket.<anonymous> (/Users/samuli/.npm-packages/lib/node_modules/ipfs/node_modules/multicast-dns/index.js:45:40)
    at emitTwo (events.js:106:13)
    at Socket.emit (events.js:191:7)
    at UDP.onMessage (dgram.js:550:8)

Also, after that, trying to restart the daemon, I get the following:

Initializing daemon...
Starting at /Users/samuli/.jsipfs
This repo is currently being used by another daemon

@haadcode
Copy link
Member Author

haadcode commented Jan 19, 2017

@diasdavid was quick to respond on IRC:

05:12 <@daviddias> ah, that is a quick one to solve
05:13 <@daviddias> so, you removed the tcp multiaddr completely?
05:13 < haad> yes
05:13 <@daviddias> `and removed the tcp address`
05:13 <@daviddias> yeah, that is the thing causing the bug
05:14 <@daviddias> which is the bug, that went through tests since we always use TCP

This fixes the problem above.

Learning: for js-ipfs-nodejs, you need to specify a TCP address too (@diasdavid correct me if I'm wrong)

@daviddias
Copy link
Member

daviddias commented Jan 19, 2017

This will fix the issue all together libp2p/js-libp2p-mdns#55 :) Thanks for catching that

@haadcode
Copy link
Member Author

Now having added a file with jsipfs successfully, I have the jsipfs daemon running and I restart the browser instance. The following error happens:
screen shot 2017-01-19 at 11 18 04

And the full stack trace:
screen shot 2017-01-19 at 11 19 57

@daviddias
Copy link
Member

You are starting the sig server and the jsipfs gateway on the same ports

  • star-sig server at 127.0.0.1:9090.
  • Gateway (readonly) is listening on: http://127.0.0.1:9090

@haadcode
Copy link
Member Author

You are starting the sig server and the jsipfs gateway on the same ports

Ah! Great catch! We should prolly change the default of either one (both currently at port 9090) as it's common to use both in development at the same time. What do you think?

@daviddias
Copy link
Member

daviddias commented Jan 19, 2017

Sounds wise :) Wanna submit a PR to webrtc-star?

@haadcode
Copy link
Member Author

Changed the http gateway port of the daemon, restarted it. Restarting the browser now gives me the following error:

index.js:361 Uncaught Error: need dictionary: 
    at Zlib._binding.onerror (index.js:361)
    at Zlib._error (binding.js:229)
    at Zlib._write (binding.js:187)
    at binding.js:117
    at Item.run (browser.js:153)
    at drainQueue (browser.js:123)
Zlib._binding.onerror @ index.js:361
Zlib._error @ binding.js:229
Zlib._write @ binding.js:187
(anonymous) @ binding.js:117
Item.run @ browser.js:153
drainQueue @ browser.js:123

@daviddias
Copy link
Member

daviddias commented Jan 19, 2017

Since this is becoming a log of valuable information. Here goes the answer to that

10:29 <haad> daviddias: and the next one! :D https://github.com/ipfs/js-ipfs/issues/720#issuecomment-273737337
10:29 <haad> daviddias: haha yeah, sorry for spam. let us know if we should move this to private.
10:29 <@daviddias> it's fine :)
10:29 <@daviddias> that is the browserify-zlib thing
10:29 <@daviddias> remember the chats in Berlin?
10:30 <@daviddias> https://github.com/ipfs/browserify-zlib you need to use this one
10:30 <@daviddias> https://github.com/substack/node-browserify/issues/1672

@haadcode
Copy link
Member Author

Ok, the issue above was in aegir, we have a custom version of browserify-zlib which was missing from the deps. This was fixed by @dignifiedquire in [email protected]

05:43 <@dignifiedquire> just published [email protected] which fixes the dependency

I am now able to cat a file from js-ipfs (node.js) to js-ipfs (browser) \o/ 🎉 🎆

screen shot 2017-01-19 at 11 42 06

@haadcode
Copy link
Member Author

Posting the link to the relevant issues here re. browserify-zlib for reference: browserify/browserify#1672
webpack/node-libs-browser#51

And the custom lib we use in aegir at the moment is: https://github.com/ipfs/browserify-zlib

@daviddias
Copy link
Member

awesome!

However, it seems there was a huge missed opportunity of saving time, cat'ing a file in the browser by adding it with js-ipfs cli was a demo built and presented at the last All Hands before Holidays, available here: https://github.com/diasdavid/graph-explorer/tree/feat/fetch-visualize. It would have saved you so much time of debugging these problems (I'm sorry @haadcode), we should have asked ourselves "what is the closest thing that we have done towards this demo" and just to avoid this happens again, for the File Explorer, you can find two prototypes here:

I see that you won't have the time to complete the tutorial part of these demos, but can you outline all the steps and information pieces the demo needs to have so that another person can tackle that?

Thank you!

@daviddias
Copy link
Member

Ok, seems that all issues have been solved, let's close this one and follow specific bugs on each example:

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/support A question or request for support
Projects
None yet
Development

No branches or pull requests

2 participants