Retrieval deal processing

Deals processing is a core component of CIDgravity, most of the features in CIDgravity will impact the acceptance of a deal. Through this article you will understand how all these components will work together to get the best out CIDgravity.

The decision outcome is binary:

• Accept: The proposal successfully meets all criteria, allowing for processing by Lotus/Boost.
• Reject: The proposal fails to satisfy one or more criteria, leading to rejection. The rejection reason is explicitly specified in the response.

How does it works ? #

When a deal is received and passed by Boost/Venus to CIDgravity, it follows the workflow below :

• Proposal integrity: verify the integrity of the incoming proposal

  • integrity checks
  • format
  • value threshold
  • etc…

• Client identification and authorization: identify the client associated with the incoming deal and grant authorization based on the libP2P address (for graphsync and bitswap, does not apply to HTTP)

• Maintenance mode: evaluate whether the miner is currently in maintenance mode (doc)

• Rate limits: Ensure that the global retrieval rate limit have not been exceeded (doc )

Upon failure of any of these components, the proposal is directly rejected. The proposal must pass all the components to be accepted.

In case the deal is rejected :

• An intenal detailed decision message is logged to CIDgravity (accessible via the History) and logged to the CIDgravity connector (on the miner).
• A simplified comprehensive error message is sent to the client (through Boost/Venus).