Display files as js-ipfs gateway

[vasco-santos]

The main goal of the service-worker-gateway is to be an alternative to the ipfs daemon gateway. This way, there are three different types of content that we need to deal with.

• simple file content preview (text, image, video, ...)
• directory content listing
• directory containing a web page

js-ipfs gateway already identifies these types and has templates for displaying them, as we may observe here.

All things considered, the first step for this issue consists of identifying which parts are similar among both gateways, in order to create a new repo responsible for resolving hashes, identifying the type of the content and generate the response template (if needed). Afterwards, it is necessary to create this repo and integrate it in both gateways (js-ipfs and service-worker-gateway).

File content examples:

• simple file
• directory listing
• directory containing a web page

References:

• https://github.com/ipfs/js-ipfs/pull/968/files

[vasco-santos]

Regarding this topic, there is an inconsistency between js-ipfs and go-ipfs gateways that should be discussed.

Basically, the hash QmRoYXgYMfcP7YQR4sCuSeJy9afgA5XDJ78JzWntpRhmcu contains a directory with several files, being index.htm one of them. In this case, js-ipfs assumes it is a website to be displayed, while go-ipfs sees it as a directory list display.

Going into the code, I found that js-ipfs consider this type of file being an Index HTML file (#L15) and go-ipfs only supports the index.html file name (#L287).

@diasdavid @whyrusleeping I think that this inconsistency should be fixed.

[linonetwo]

I think code in js-ipfs/gateway can be refactored into two parts:

1. DAG traverse: start from left most part of the path to the right most part of the path
2. resolve content by its type: single file, a directory with index.html, plain directory (or maybe other IPLD data types)

So there can be a traverse function and sets of resolvers, where resolver can be overridden, like providing a custom directory view.

But I think @ya7ya 's implementation covers most frequent usages now, we can just move two resolvers to new repo, and provide a function utilize two resolver, that receive an ipfs instance and a multihash, returns a node stream.

[linonetwo]

Both gateways receive stream as input, so I think a function (ipfs: IPFSNode, multihash: string, options: Object) => stream is enough.

options contains threshold, some resolver overrides and ipfsRoute that define the route handled by SW.

[vasco-santos]

@linonetwo I would like to go for the simplest version for now. This way, we should use @ya7ya's approach moving the two resolvers to a new repo, as well as the path utils and the dir view. I am analyzing the rest of the code, in order to understand what else can also be abstracted.

Did you get a conclusion regarding the Stream response? I am also having problems with it

[linonetwo]

I've got a working version, try https://github.com/linonetwo/ipfs-browser-gateway
The problem is that I was consuming the first chunk, so the response is empty. Now I use another stream to cache all chunks.

[linonetwo]

Let's move @ya7ya's code to a new repo. They are proved to work amazingly in SW.

We can refactor it later to support custom dir-view and so on.

[daviddias]

Note that the dir-view code is already present in https://github.com/ipfs/dir-index-html, just not friendly with JS templating. bonus points if you can all make it work in one single repo.

[vasco-santos]

@diasdavid For clearing things, you are suggesting both js-ipfs and go-ipfs to use that repo, right?

[linonetwo]

Even in JS, there seems to be no good way sharing HTML and CSS without using React or Vue or so. Sharing HTML between Go and JS is more difficult.
Because Web Components specification depends on HTML Templates and other three things, and only HTML Templates enter the NOTE phase, others are Working Draft.
W3C is laggy.

[linonetwo]

Will there be a new repo to contain ipfs-js-gateway(or different name)?

I think I'm ready to move shared part to the new repo.