Failed to install `helia-http-gateway` using NPM

[bludnic]

Seems that the app is not yet published on NPM, so npm i helia-http-gateway fails.
https://www.npmjs.com/search?q=helia-http-gateway

The Docker installation though works but it doesn't fit my needs. Is there a way to install the package as NPM dependency? What do you suggest?

[SgtPooki]

@bludnic we haven't targeted releasing this as an npm package yet, but we will eventually =) right now we're focusing on making sure https://github.com/ipfs/helia-verified-fetch is solid and passing gateway conformance. once that is done, we will make it easier for folks to run this.

Adin, Lidel, or Alex may have other thoughts? I've added this to our helia WG call for tomorrow. feel free to join! https://lu.ma/7uncn5aw

[SgtPooki]

Also, we may release this as @helia/http-gateway but ill defer to @achingbrain on that

[achingbrain]

I think at we should have the gateway compliance tests running and decent results in tiros before release. It doesn't feel too far off.

But yes, @helia/http-gateway most likely.

[bludnic]

We a building decentralized file transfer in ADAMANT Messenger. We plan to use IPFS with Helia and Node.js. It would be great if you could release the @helia/http-gateway as a beta, so we can experiment with it. @SgtPooki

[SgtPooki]

@bludnic this package is mostly just a small fastify wrapper on top of @helia/verified-fetch, which you can install and use today!

Do you mind talking a small bit more about how you will be using helia-http-gateway?

[SgtPooki]

One more thing: https://github.com/ipfs-shipyard/service-worker-gateway is pretty cool too (but also not installable via npm yet). we're still fleshing things out, but this would allow all the users of adamant-im to fetch content from the network directly, instead of having them all use a centralized gateway you host at some endpoint

[bludnic]

@SgtPooki We created a repo Adamant-im/ipfs-node based on helia, and deployed three instances to our servers. For retrieving files we added a custom endpoint GET /file/:cid.

The @helia/http-gateway, in this sense, is more preferable than a custom endpoint, since it follows the standard described in the docs.

[SgtPooki]

got it :)

instead of standing up helia-http-gateway itself and wrapping only the /file/:cid with a proxy to the helia-http-gateway, it looks like you would benefit more from using @helia/verified-fetch directly.

if you convert the code at https://github.com/Adamant-im/ipfs-node/blob/e11b82353d0916ba5d29f1df63f291c2614858d0/src/index.js#L80-L92 to use @helia/verified-fetch, you can customize libp2p and Helia however you need and have all the gateway specs support we have in @helia/verified-fetch.

---

we're actually targeting the gateway specs directly in verified-fetch, instead of this repo (but this gateway will then support them as well)

You can see that we're constructing a verified-fetch instance with a custom helia node at

helia-http-gateway/src/index.ts

Lines 173 to 174 in b4531c0

	const helia = await getCustomHelia()
	const fetch = await createVerifiedFetch(helia, { contentTypeParser })

and then basically just forwarding the fastify request directly to helia fetch in

helia-http-gateway/src/helia-http-gateway.ts

Lines 82 to 95 in b4531c0

	async function fetch (request: FastifyRequest, reply: FastifyReply): Promise<void> {
	const url = getFullUrlFromFastifyRequest(request, log)
	log('fetching url "%s" with @helia/verified-fetch', url)
	const signal = getRequestAwareSignal(request, log, {
	url
	})
	// if subdomains are disabled, have @helia/verified-fetch follow redirects
	// internally, otherwise let the client making the request do it
	const resp = await opts.fetch(url, { signal, redirect: USE_SUBDOMAINS ? 'manual' : 'follow' })
	await convertVerifiedFetchResponseToFastifyReply(resp, reply)
	}

@helia/verified-fetch supports multiple urls, so you could simply change https://github.com/Adamant-im/ipfs-node/blob/e11b82353d0916ba5d29f1df63f291c2614858d0/src/index.js#L251-L258 to be:

const filePromise = await verifiedFech(`ipfs://${cid}`, {headers: req.headers}) // plus any query/format/accept support you want to add

and benefit from all the spec compliance

[SgtPooki]

but, yes, for running a legit endpoint that supports /ipns and /ipfs and subdomains, using this library would help you out. If that's what you're looking to do, we can work on getting a v0.0.1 published when we feel it's generally usable with a warning :)