booster-bitswap add ability to dynamically add Peer ID to denylist

[LaurenSpiegel]

For #709 adoption by Evergreen, need the ability to configure so that deny retrievals from certain peer id's.

Need to be able to do this without restarting.
Need to clearly document how to set and modify the configuration.

Reference -- https://www.notion.so/pl-strflt/Bitswap-Retrieval-Requirements-WIP-ed17a22b006e4ba79c9ca9ec85fcf93e

[LaurenSpiegel]

@ribasushi, do you have some context on this requirement? Have you heard that SP's would want a separate denylist for bitswap than for other retrieval methods?

[ribasushi]

No requirement was made for a separate list. The requirement is for the bitswap daemon to be able to consume a peerid denylist from some source ( whether it is shared with the rest of retrieval or not is an implementation detail ). And the second requirement is for this consumption to be dynamic/can happen at runtime: how exactly is also an implementation detail, as long as it doesn't require a reboot and thus shutdown of all current service sessions.

[hannahhoward]

@ribasushi already implemented this for the badbits list - which does update dynamically without need for a reboot (every five minutes). Do you want the ability to configure the source as something other than BadBits? or do you want to add an additional source?

[ribasushi]

@hannahhoward do the minimum: make the badbits url a config param. Do not add ability to parse multiple list formats: this comes later.

[LaurenSpiegel]

@hannahhoward , I believe this ticket is a separate requirement from the badbits list. this is about denying requests from a peer (not about the actual cid's). CID Gravity has a deny list so we should start with being able to honor that.

[hannahhoward]

Goal:

• ultimately, we need a sync with a list of blocked peers available over a URL
• we can use an architecture exactly like the badbits periodic fetch but for cid lists.

CC: @s0nik42

Let's chat about CIDGravity exposing an API that meets this specification -- this would enable your white/list black list peers to actually be used within Bitswap.

[s0nik42]

definitely interested to work on that with you

[hannahhoward]

closing in favor of #954

This describes how this requirement is actually being implemented, and is already implemented with #994