Kubo ships with built-in support for denylist format from IPIP-383.
Official Kubo build does not ship with any denylists enabled by default.
Content blocking is an opt-in decision made by the operator of ipfs daemon
.
Place a *.deny
file in one of directories:
$IPFS_PATH/denylists/
($HOME/.ipfs/denylists/
ifIPFS_PATH
is not set)$XDG_CONFIG_HOME/ipfs/denylists/
($HOME/.config/ipfs/denylists/
ifXDG_CONFIG_HOME
is not set)/etc/ipfs/denylists/
(global)
Files need to be present before starting the ipfs daemon
in order to be watched for updates.
If a new denylist file is added, ipfs daemon
needs to be restarted.
CLI and Gateway users will receive errors in response to request impacted by a blocklist:
Error: /ipfs/QmQvjk82hPkSaZsyJ8vNER5cmzKW7HyGX5XVusK7EAenCN is blocked and cannot be provided
End user is not informed about the exact reason, see How to debug if you need to find out which line of which denylist caused the request to be blocked.
NOpfs supports the format from IPIP-383.
Clear-text rules are simple: just put content paths to block, one per line. Paths with unicode and whitespace need to be percend-encoded:
/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR
/ipfs/bafybeihfg3d7rdltd43u3tfvncx7n5loqofbsobojcadtmokrljfthuc7y/927%20-%20Standards/927%20-%20Standards.png
Sensitive content paths can be double-hashed to block without revealing them. Double-hashed list example: https://badbits.dwebops.pub/badbits.deny
See IPIP-383 for detailed format specification and more examples.
Set IPFS_CONTENT_BLOCKING_DISABLE
environment variable to true
and restart the daemon.
Debug logging of nopfs
subsystem can be enabled with GOLOG_LOG_LEVEL="nopfs=debug"
All block events are logged as warnings on a separate level named nopfs-blocks
.
To only log requests for blocked content set GOLOG_LOG_LEVEL="nopfs-blocks=warn"
:
WARN (...) QmRFniDxwxoG2n4AcnGhRdjqDjCM5YeUcBE75K8WXmioH3: blocked (test.deny:9)