go-ipfs 0.10.0 support

[tabcat]

Issue to track support for go-ipfs 0.10.0

Tests run and pass:

using go-ipfs@0.10.0-rc1 via ipfs-http-client

• orbit-db
• orbit-db-store
• orbit-db-io@next
• ipfs-log

[tabcat]

the main package is passing. its using older versions of the other listed packages which are all failing after installing go-ipfs@next. the orbit-db-io test errors are concerning;

  3) IO tests (go-ipfs)
       dag-cbor
         writes with links:

      AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
+ actual - expected

+ 'zdpuAsrQMsQKMnCSv2bLU5scjbydUBQs8KCKCJ84DQVPXqT1Y'
- 'zdpuAqeyAtvp1ACxnWZLPW9qMEN5rJCD9N3vjUbMs4AAodTdz'
        ^
      + expected - actual

      -zdpuAsrQMsQKMnCSv2bLU5scjbydUBQs8KCKCJ84DQVPXqT1Y
      +zdpuAqeyAtvp1ACxnWZLPW9qMEN5rJCD9N3vjUbMs4AAodTdz

  9) IO tests (go-ipfs)
       raw
         reads:
     AssertionError [ERR_ASSERTION]: Expected values to be strictly deep-equal:
+ actual - expected

+ Uint8Array(13) [
+   161,
+   100,
+   116,
+   101,
+   115,
+   116,
+   102,
+   111,
+   98,
+   106,
+   101,
+   99,
+   116
+ ]
- {
-   test: 'object'
- }

all tests fail and the code returns differing cids than before.

I'll see what makes the older versions of the packages pass and change what is needed. Hopefully it is as straightforward as that.

[aschmahmann]

@tabcat take a look at the release notes ipfs/kubo#8176. There were some breaking changes made around the ipfs dag commands that might be impacting you. If you have suggestions for how to make the release notes better or easier for devs to notice the breaking changes, feel free to post on the issue or otherwise let me know.

[tabcat]

these issues seem to be stemming from the ipfs-http-client. the latest commits tests are failing after installing the rc.

  ipfs-http-client constructor tests

...

  .dag
    1) should be able to put and get a DAG node with format dag-pb
    2) should be able to put and get a DAG node with format dag-cbor
    ✔ should be able to put and get a DAG node with format raw
    ✔ should error when missing DAG resolver for multicodec from requested CID
    ✔ should error when putting node with esoteric format
    3) should attempt to load an unsupported format
    4) should allow formats to be specified without overwriting others

[tabcat]

scoping use of the block api exclusively as a work around and improvement of how everything is used currently for us. the block api doesnt seem to be broken by the ipfs-http-client + go-ipfs rc. encoding data ourselves using the same packages actually seems like it could be cleaner and allows us to get the cid sooner.

[tabcat]

the main package was never actually passing because orbit-db-test-utils was using its own ipfs deps. ive updated that and other packages and most everything is passing now with go-ipfs@0.10.0.rc1 and the latest js-ipfs.

[rvagg]

Hey @tabcat, can you give us a little more info about the failure you experienced here, the red flags for us from changed CIDs warrants a little more investigation to make sure that we've not introduced something wonky on our end.

Is orbitdb-archive/orbit-db-io#26 addressing the main problem? And therefore the source of the issue is:

supplying write with a 'raw' format param would result in ipfs.dag defaulting to encoding the data with dag-cbor

So by upgrading, you were suddenly actually using raw but were previously using dag-cbor? In this thread I'm only seeing dag-cbor CIDs though: zdpuAsrQMsQKMnCSv2bLU5scjbydUBQs8KCKCJ84DQVPXqT1Y, zdpuAqeyAtvp1ACxnWZLPW9qMEN5rJCD9N3vjUbMs4AAodTdz and the two bafyrei CIDs in the second failed test in the screenshot are all dag-cbor. Is there something we can help investigate here?

[tabcat]

Hi @rvagg,

So by upgrading, you were suddenly actually using raw but were previously using dag-cbor?

I didn't investigate that well enough to be sure, I believe the default is still dag-cbor. The dag api when used with the latest ipfs-http-client seems to be in a broken state currently due to the failed tests i ran after installing the go rc. since the block api tests werent failing i thought it was a good time to switch, also had it in mind anyway.

I haven't opened an issue in js-ipfs yet so if you dont want to switch to the block api i would suggest running the tests yourself and doing that.

[rvagg]

@tabcat I'm having a bit of trouble getting to an error state where I can see what's going on with mismatched CIDs because it's a concern regardless of how it's happening. I've tried orbit-db and orbit-db-io with go-ipfs@next, ipfs-http-client@next, on Linux and mac, all in various combinations, still all passing. What might I not be doing right here to get to an error state that I can dig into further and understand if this is a problem in either the js-ipfs or go-ipfs stacks that we should be aware of.

[tabcat]

@rvagg the ipfs-http-client's dag api tests fail with go-ipfs@next. If you clone the js-ipfs repo and run the ipfs-http-client packages test with go-ipfs@next installed to the devDependencies you should see the dag api tests fail. sorry if this was confusing, the failing test cases screenshot above are from the ipfs-http-client tests in the js-ipfs repo.

the orbit-db package doesnt fail because the orbit-db-test-utils package is outdated and installs its own versions of go and js ipfs. orbit-db-io should pass because the pr moving to the block api has been merged.

[tabcat]

Closed by: #912