ipfs / go-ipfs-provider

go-ipfs-provider

❗ This repo is no longer maintained.

👉 We highly recommend switching to the maintained version at https://github.com/ipfs/boxo/tree/main/provider. 🏎️ Good news! There is tooling and documentation to expedite a switch in your repo.

⚠️ If you continue using this repo, please note that security fixes will not be provided (unless someone steps in to maintain it).

📚 Learn more, including how to take the maintainership mantle or ask questions, here.

Background

The provider system is responsible for announcing and reannouncing to the ipfs network that a node has content.

Install

Via go get:

$ go get github.com/ipfs/go-ipfs-provider

Requires Go 1.12

Usage

Here's how you create, start, interact with, and stop the provider system:

import (
	"context"
	"time"

	"github.com/ipfs/go-ipfs-provider"
	"github.com/ipfs/go-ipfs-provider/queue"
	"github.com/ipfs/go-ipfs-provider/simple"
)

rsys := (your routing system here)
dstore := (your datastore here)
cid := (your cid to provide here)

q := queue.NewQueue(context.Background(), "example", dstore)

reprov := simple.NewReprovider(context.Background(), time.Hour * 12, rsys, simple.NewBlockstoreProvider(dstore))
prov := simple.NewProvider(context.Background(), q, rsys)
sys := provider.NewSystem(prov, reprov)

sys.Run()

sys.Provide(cid)

sys.Close()

License

This library is dual-licensed under Apache 2.0 and MIT terms.

Copyright 2019. Protocol Labs, Inc.

go-ipfs-provider's Issues

Concurrent republishing ?

Unless I missed something, this package does only sequential republishing and thus is quite slow.

Would it make sense to have concurrent republishing ? Any constraint I should be aware of ?

Strange Behavior With Provider Correlated With Long Running Contexts

Currently, when instantiating the provider a context is passed in. This context is then used internally when providing records to the network.

In my usage of this library, the context that gets passed in during initialization is never cancelled until my custom node service stops. The issue appears to be that if the context being used when providing a record to the network never cancels, then the provide call doesn't actually complete. This has lead to strange behaviour that I've noticed if I'm starting+stopping my custom node multiple times, using different peerID's each time. And seemingly each time the node "starts", records that were previously being announced to the network started showing up.

Digging a little further this isn't actually the case. What's happening is that only when the node service stops, is the context cancelled, thus triggering the Provide call to finish.

Digging a little further, I forked the repository to introduce some custom behaviour which is to initialize a temporary context with a timeout of 1 minute. By doing this, records will be provided to the network as expected and everything is okay.

So the root of the issue appears to be that records aren't actually being provided to the network, until the context that's passed into the Provide call is cancelled.

Move (Re)Provider logic to Content Routers

The Reprovide logic is usually specific to the Content Router(s) in use. Hence, a Provider interface should be exposed through go-libp2p-routing-helpers, and the reprovide logic should move away from this repo to the specific Content Routers (e.g DHT, IPNI).

See:

• libp2p/go-libp2p-kad-dht#824
• libp2p/go-libp2p#2175

Fix Windows build on CI

#36 introduced Windows build, but it does not work:

Ref. https://github.com/ipfs/go-ipfs-provider/actions/runs/3657485328/jobs/6181129420

Note from Jorropo:

I am 90% confident it was broken before (in current and previous releases of kubo) but we were not running windows CI and thus missed them.