dag visualized as a tree

[jbenet]

e27f6a4 (Juan Batiz-Benet, 3 minutes ago)

optional newline in regex (daemon changed)

ffdb0b2 (Juan Batiz-Benet, 14 hours ago)

added all-versions

a383961 (Juan Batiz-Benet, 14 hours ago)

Makefile now builds before publish

e44b51a (Harlan T Wood, 2 months ago)

debugging

License: MIT Signed-off-by: Harlan T Wood <code@harlantwood.net>

107ec66 (Harlan T Wood, 3 months ago)

rename variable

License: MIT Signed-off-by: Harlan T Wood <code@harlantwood.net>

6021cea (Harlan T Wood, 3 months ago)

Tree-shaped visualization of IPFS DAG.

License: MIT Signed-off-by: Harlan T Wood <code@harlantwood.net>

1e5b0a2 (Harlan T Wood, 3 months ago)

D3 + D3 tree example + license

[jbenet]

@harlantwood i'm going to merge this one -- fixed a newline thing and improved the makefile. thanks again!

[jbenet]

to try it out, see: http://gateway.ipfs.io/ipfs/QmVppgFNC8TCJg3zJmSebFtZAJRSw1pS8seuYVstbzEW78/viz#QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D

(but not yet-- @lgierth looks like we haven't deployed the readable-API changes? thought we had? cc @krl)

[ghost]

@krl pinged me about that a couple of days ago and the gateways are running this commit since then: https://github.com/ipfs/infrastructure/commit/dd11325f869611a00987029ee8796fad310aaa23

[ghost]

Hrm except they don't...

[jbenet]

explorable dag, looks very cool!!!

(the ipfs dataviz tree stored on an ipfs tree, visualized as a tree on ipfs)

[ghost]

Nevermind, the gateways do run ipfs/go-ipfs@fbac82046dd28e6d98c34db88db9f56d7b617027 as expected

[krl]

@lgierth This is what i get:

http://gateway.ipfs.io/api/v0/cat?arg=%2Fipfs%2FQmZTR5bcpQD7cFgTorqxZDYaew1Wqgfbd2ud9QqGPAkK2V&stream-channels=true Failed to load resource: the server responded with a status of 403 (Forbidden)
http://gateway.ipfs.io/api/v0/cat?arg=%2Fipns%2FQmReJX55vhC5HbkBEZFW9V37vvirR1E7s2JW63cRt23BiN&stream-channels=true Failed to load resource: the server responded with a status of 403 (Forbidden)
http://gateway.ipfs.io/api/v0/object/get?arg=%2Fipfs%2FQmZTR5bcpQD7cFgTorqxZDYaew1Wqgfbd2ud9QqGPAkK2V&stream-channels=true Failed to load resource: the server responded with a status of 403 (Forbidden)
http://gateway.ipfs.io/api/v0/id?stream-channels=true Failed to load resource: the server responded with a status of 403 (Forbidden)
http://gateway.ipfs.io/api/v0/object/get?arg=%2Fipns%2FQmReJX55vhC5HbkBEZFW9V37vvirR1E7s2JW63cRt23BiN&stream-channels=true Failed to load resource: the server responded with a status of 403 (Forbidden)

[krl]

The id should fail of course

[jbenet]

maybe an nginx route missing?

[ghost]

I know, I get the same.

This seems to work fine though:

curl -v 'gateway.ipfs.io/api/v0/cat?arg=%2Fipfs%2FQmZTR5bcpQD7cFgTorqxZDYaew1Wqgfbd2ud9QqGPAkK2V&stream-channels=true'

and also works if I directly request it in the browser: http://gateway.ipfs.io/api/v0/cat?arg=%2Fipfs%2FQmZTR5bcpQD7cFgTorqxZDYaew1Wqgfbd2ud9QqGPAkK2V&stream-channels=true

Not sure what's happening, maybe a lack of CORS headers or something like that?

[ghost]

Mh no, it must be nginx yielding a 403 for some reason.

[jbenet]

oh it might be CORS, not sure. see the updated docs on ipfs daemon:

> ipfs daemon --help
<snip>

    HTTP Headers

    IPFS supports passing arbitrary headers to the API and Gateway. You can
    do this by setting headers on the API.HTTPHeaders and Gateway.HTTPHeaders
    keys:

        ipfs config --json API.HTTPHeaders.X-Special-Header '["so special :)"]'
        ipfs config --json Gateway.HTTPHeaders.X-Special-Header '["so special :)"]'

    Note that the value of the keys is an _array_ of strings. This is because
    headers can have more than one value, and it is convenient to pass through
    to other libraries.

    CORS Headers (for API)

    You can setup CORS headers the same way:

        ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["*"]'
        ipfs config --json API.HTTPHeaders.Access-Control-Allow-Methods '["PUT", "GET", "POST"]'
        ipfs config --json API.HTTPHeaders.Access-Control-Allow-Credentials '["true"]'

    DEPRECATION NOTICE

    Previously, IPFS used an environment variable as seen below:

       export API_ORIGIN="http://localhost:8888/"

    This is deprecated. It is still honored in this version, but will be removed in a
    future version, along with this notice. Please move to setting the HTTP Headers.

[krl]

as on irc: gateway api test page:

http://gateway.ipfs.io/ipfs/QmZmgC5Cw1scmQwUZp9X7QZBPFyPrXt1Uz1hXYSTeV1tL1/

same page but local:

http://localhost:5001/ipfs/QmZmgC5Cw1scmQwUZp9X7QZBPFyPrXt1Uz1hXYSTeV1tL1/

[harlantwood]

Awesome, looks like this is working on the gateway now : )

[jbenet]

@harlantwood nice!

btw, looks like the dag is unixfs aware? (i.e. distinguishes files and dirs). so i cant use it to visualize file chunking algorithms. it may be worth not distinguishing unixfs, and just showing the raw dag (i.e. files have links too)

[harlantwood]

Not on purpose ; )

It's pulling all refs from the refs api call: https://github.com/ipfs/dataviz/pull/5/files#diff-aab1e940c09e6ef405d72f6e75b9a432R15

Is that call suppose to be unixfs aware?

We are switching over to using the ipfs node api lib, and the ls command from that, in another viz. We could move this D3 viz to that too, if that call is better behaved...