-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: create @helia/http
library without bitswap/libp2p deps
#289
Comments
Maybe we should accept 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 |
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.
@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 |
Yes! The factory for 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 |
Got it, so we can create Sounds good to me, going to update this title to reflect this? but I still imagine this is low-priority. |
@helia/http
library without bitswap/libp2p deps
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 #372 |
Adds code from https://github.com/meandavejustice/helia-http to the monorepo. Fixes: #289 and #344 BREAKING CHANGE: the `libp2p` property has been removed from the `Helia` interface in `@helia/interface` - it is still present on the return type of `createHelia` from the `helia` module --------- Co-authored-by: David Justice <work@justice.engineering> Co-authored-by: Daniel Norman <1992255+2color@users.noreply.github.com> Co-authored-by: Daniel N <2color@users.noreply.github.com>
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
Tasks
The text was updated successfully, but these errors were encountered: