Hello IPFS people,
I am starting to test out the p2phttp package found here: GitHub - libp2p/go-libp2p-http: HTTP on top of libp2p
In order to get the server running it must created by passing a “host” to the gostream.Listen() function
In the example this isn’t defined what that variable is supposed to be but I assume it’s an instance of a libp2p node. My question for this forum is if this can instead be an IPFS node instead of a vanilla libp2p node?
If an IPFS node can be used this would be advantageous for bootstrapping peers and connecting to a wider network. To this end I was also looking at the Kubo as a Library example; do I need to use it as a library to connect it to the p2phttp server, or could I connect the p2phttp server directly to an already running Kubo daemon?
I attempted to run the the example from the Kubo as a library repo: kubo/docs/examples/kubo-as-a-library at master · ipfs/kubo · GitHub
But was having a couple problems. First at line 133 of main.go, where
api is throwing an error as part of the return statement:
cannot use api (variable of type “GitHub - ipfs/interface-go-ipfs-core”.CoreAPI) as “github.com/ipfs/boxo/coreiface”.CoreAPI value in return statement: “GitHub - ipfs/interface-go-ipfs-core”.CoreAPI does not implement “github.com/ipfs/boxo/coreiface”.CoreAPI (wrong type for method Block)
However, that is in my project repo where I copy pasted the example code into a fresh repo. When I clone all of Kubo, and cd into the example, use go get to install everything, and run main.go it works just fine. I’m not super familiar with go so this error seems related to other dependencies within the broader Kubo repo that breaks when I try to run the example in isolation.
Before I trouble shoot this further I’d like to return to my main question in case I’m barking up the wrong tree here so to speak.
- If an IPFS node cannot be used with p2phttp I’ll stop here, switching to just libp2p
- If it can and be connected to a regular daemon that would also be preferable. How though, just
- If an IPFS node can work, but it needs to be used as a library I’ll continue learning more of the Go nuances and see what I broke.
Thanks in advance to anyone that can provide clarity on this!
Edit: I found this reference to the host.Host interface that must be provided to
gostream.Listen(host.Host): go-libp2p/host.go at master · libp2p/go-libp2p · GitHub
My main question about whether or not it’s possible to connect this listener to the Kubo daemon or not is still what I’m working on. Seems like most of that interface could be reconstructed from making several RPC API calls to the daemon but I’m less than 50% confident this would actually work.
Edit #2: I think I found a hint of what’s going on with the error I mentioned from the example when run in isolation. When comparing my go.mod file with the one from the example I see that one dep. has a specific commit version:
github.com/ipfs/boxo v0.8.1-0.20230411232920-5d6c73c8e35e but even then, when simply copy pasting the example directory out of the main Kubo repo it breaks on it’s own with the original .mod and everything. And I thought managing deps in Node was a pain.
Steps to replicate:
git clone https://github.com/ipfs/kubo
cp -r kubo/docs/examples/kubo-as-a-library ./
- Comment out the following line from go.mod
replace github.com/ipfs/kubo => ./../../..
go mod tidy
And you’ll see the error I’m talking about. I even tried it with version 1.18 of go as that’s what’s noted in the original .mod file but this throws another error that quic requires v1.19 at least.