Closed SgtPooki closed 10 months ago
Maybe we should accept false
for libp2p
for this?
const helia = await createHelia({
blockBrokers: [
trustlessGateway()
],
libp2p: false
})
Thinking about this a bit more, if there's no libp2p/bitswap then you're pulling in a whole lot of extra deps for zero benefit and I wonder if this is even Helia any more.
It might be another implementation of the Helia interface? This keeps it compatible with @helia/unixfs
etc.
I think Helia can be Helia even without libp2p (people don't want to do p2p stuff, but they do want to do content-addressing stuff), but I agree it feels odd.
It might be another implementation of the Helia interface? This keeps it compatible with @helia/unixfs etc.
@achingbrain are you thinking of going with something like
import {type HeliaRaw} from '@helia/interface`
import {createHelia} from 'helia'
const helia: HeliaRaw = await createHelia({
blockBrokers: [
trustlessGateway()
],
libp2p: false
})
so modules like @helia/unixfs
can indicate whether they support Helia without libp2p or not?
modules like @helia/unixfs can indicate whether they support Helia without libp2p or not?
Yes! The factory for @helia/unixfs
only requires a blockstore for this exact reason.
So it's more like:
import type { Helia } from '@helia/interface'
import { createHeliaThatOnlyUsesGateways } from '@helia/http'
import { unixfs } from '@helia/unixfs'
const helia = createHeliaThatOnlyUsesGateways()
const fs = unixfs(helia)
// ...do unixfs stuff
The Helia type is already there so you don't need HeliaRaw
and it's generic for the libp2p type so you can make it unknown
or perhaps we'd remove it entirely.
Got it, so we can create @helia/http
and import that instead of helia
, and that would handle the appropriate configuration of the Helia
interface. I think that makes sense.. and putting it in a separate package would mean we can ensure other deps (libp2p/bitswap/others) are not ~pulled in~ exported.
Sounds good to me, going to update this title to reflect this? but I still imagine this is low-priority.
I've added what I think to be the general action items for this into the issue description
Thanks @SgtPooki - sounds good. Lets also make sure there is accompanying information too. There should probably be a Helia readme item for something like "want an even lighterweight Helia that still has the goodness of CIDs and verifiable retrieval? see..."
Instead of modifying Helia interface we could extend and omit the libp2p bits
interface HeliaHTTP extends Omit<Helia, 'start'|'stop'|'libp2p'> {}
@SgtPooki I have a branch where I'm working on this. Can you assign to me?
Currently @meandavejustice is working on this in https://github.com/meandavejustice/helia-http/
This is now being covered by https://github.com/ipfs/helia/pull/372
Helia consumers should be able to use Helia without depending on the p2p network. Ideally, users could use Helia modularly, with trustless-http-gateway (or other source of getting blocks) and validate those blocks, using only the IPFS portion of Helia.
Current
It doesn't seem like we can "remove" libp2p entirely, but we can disable it:
Future (with
@helia/http
)No runtime js-libp2p deps are pulled in with this module