Background
A frequently requested feature is the ability to filter what content a go-ipfs node will download. While go-ipfs won't download anything that hasn't been requested by the user, that user might be:
- A dweb website requesting sub-resources via the local IPFS gateway.
- A user of a public IPFS gateway.
See libp2p/specs#173 for context.
Proposal
Ideally, IPFS would come with a feature out of the box for simply subscribing to a set of whitelists/blacklists. However, different users have different needs:
- Some users just need to download a static list, updating it once in a while.
- Some users need to query a remote service.
- Some users want to fetch their list from an HTTPs endpoint.
- Some users need to read their lists from local files.
Designing a one-size-fits-all solution is difficult and likely infeasible. However, there's a simple stop-gap solution: provide a plugin interface so users can implement their own versions.
The proposal here is to introduce new plugin types for filtering requests. Specifically:
type FilterBlock interface {
Plugin
// FilterBlock is called before fetching a block from an
// exchange and/or adding(?) a block to the local datastore.
FilterBlock(context.Context, cid.Cid) error
}
type FilterPath interface {
Plugin
// FilterPath is called before resolving a path (IPNS, dnslink, etc.).
FilterName(context.Context, path.Path) error
}
type FilterContent interface {
Plugin
// FilterContent is called before serving content via the gateway, etc.
//
// Note: FilterContent doesn't prevent the content from being stored.
// If desired, the passed CID can be used to delete or blacklist the
// content after the fact.
FilterContent(context.Context, cid.Cid, io.ReadSeeker) (io.ReadSeeker, error)
}Questions:
Implementation
This feature requires:
Background
A frequently requested feature is the ability to filter what content a go-ipfs node will download. While go-ipfs won't download anything that hasn't been requested by the user, that user might be:
See libp2p/specs#173 for context.
Proposal
Ideally, IPFS would come with a feature out of the box for simply subscribing to a set of whitelists/blacklists. However, different users have different needs:
Designing a one-size-fits-all solution is difficult and likely infeasible. However, there's a simple stop-gap solution: provide a plugin interface so users can implement their own versions.
The proposal here is to introduce new plugin types for filtering requests. Specifically:
Questions:
ipfs add)?Implementation
This feature requires:
fxoptions to be passed to the go-ipfs constructor.FilterBlockon all requested CIDs.FilterPathat every resolution step.Unixfs().Get()method to callFilterContent.