LogoLogo
v1.x (Deprecated)
v1.x (Deprecated)
  • What is Boost?
  • Features
  • Architecture
    • Repository
    • Database
    • DAG store
    • libp2p Protocols
  • Hardware requirements
  • Getting started
    • As a storage provider
    • As a client
  • Migrate from Lotus to Boost
    • Migrate a monolith lotus-miner to Boost
    • Migrate a Lotus markets service process to Boost
    • Roll back to Lotus markets service process
  • Configuration
    • UI Settings
    • HTTP Transfer limit
    • Deal Filters
    • Remote CommP
    • Legacy Deal configuration
    • HTTP indexer announcement
  • Backup and Restore
  • Tutorials
    • How to store files with Boost on Filecoin
    • Using filters for storage and retrieval deals
    • Setting up a monitoring stack for Boost
  • Bitswap Retrieval
  • HTTP Retrieval
    • Serving files with booster-http
  • Troubleshooting
  • Experimental Features
    • FVM Contract Deals
    • Local Index Directory
      • Architecture
      • Requirements
      • Initialisation
  • GraphQL API
  • JSON-RPC API
  • FAQ
  • Need help?
Powered by GitBook
On this page
Edit on GitHub
Export as PDF
  1. Configuration

Deal Filters

How to use deal filters

PreviousHTTP Transfer limitNextRemote CommP

Last updated 1 year ago

Using filters for fine-grained storage and retrieval deal acceptance

Your use case might demand very precise and dynamic control over a combination of deal parameters.

Lotus provides two IPC hooks allowing you to name a command to execute for every deal before the miner accepts it:

  • Filter for storage deals.

  • RetrievalFilter for retrieval deals.

The executed command receives a JSON representation of the deal parameters on standard input, and upon completion, its exit code is interpreted as:

  • 0: success, proceed with the deal.

  • non-0: failure, reject the deal.

The most trivial filter rejecting any retrieval deal would be something like: RetrievalFilter = "/bin/false". /bin/false is binary that immediately exits with a code of 1.

lets the miner deny specific clients and only accept deals that are set to start relatively soon.

You can also use a third party content policy framework like or bitscreen by Murmuration Labs:

# grab filter program
go get -u -v github.com/Murmuration-Labs/bitscreen

# add it to both filters
Filter = "/path/to/go/bin/bitscreen"
RetrievalFilter = "/path/to/go/bin/bitscreen"
This Perl script
CIDgravity