chore: fix markdown identation

Author: lidel

src/ipips/ipip-0383.md

@@ -33,7 +33,6 @@ The first step in a larger strategy to enable decentralized content moderation
 in IPFS setups is to agree in a denylist format that different implementations
 can rely on and share.
 
-
 ## Detailed design
 
 See :cite[compact-denylist-format].
@@ -57,46 +56,46 @@ following aspects, which are a must for such a system:
 The proposed design is part of a holistic approach to content-moderation for IPFS for which we have the following detailed wishlist of items ultimately related to the denylist format:
 
 - Regarding the type of blocking:
-    - Ability to block content from being retrieved, stored or served by multihash
-    - Ability to block content that is referenced with an IPFS-path from a blocked multihash or traversing a blocked multihash.
-    - Ability to block by regexp-matching an IPFS path
-    - Ability to block based on content-type (i.e. only store/serve plain-text,and pictures)
-    - Ability to block based on CID codec (only allow Codec X)
-    - Ability to block based on multihash function (”no identity multihashes”)
-    - Ability to block IPNS names
+  - Ability to block content from being retrieved, stored or served by multihash
+  - Ability to block content that is referenced with an IPFS-path from a blocked multihash or traversing a blocked multihash.
+  - Ability to block by regexp-matching an IPFS path
+  - Ability to block based on content-type (i.e. only store/serve plain-text,and pictures)
+  - Ability to block based on CID codec (only allow Codec X)
+  - Ability to block based on multihash function (”no identity multihashes”)
+  - Ability to block IPNS names
 
 - Regarding the lists:
-    - Compact format, compression friendly
-    - Line-based so that updates can be watched
-    - Lists support CIDs
-    - Lists support CIDs+path (explicit)
-    - Lists support CIDs+path (implicit - everything referenced from CID)
-    - Lists support double-hashed multi-hashes
-    - Lists support double-hashed cid+path (current badbits format)
-    - Lists can be edited by hand on a text editor
-    - Lists are ipfs-replication-friendly (adding a new entry does not require downloading more than 1 IPFS block, to sync the list).
-    - Lists support comments
-    - Lists support gateway http error hints (i.e. type of block)
-    - `echo "/ipfs/cid" >> ~/.config/ipfs/denylists/custom` should work
-    - Lists have a header section with information about the list.
+  - Compact format, compression friendly
+  - Line-based so that updates can be watched
+  - Lists support CIDs
+  - Lists support CIDs+path (explicit)
+  - Lists support CIDs+path (implicit - everything referenced from CID)
+  - Lists support double-hashed multi-hashes
+  - Lists support double-hashed cid+path (current badbits format)
+  - Lists can be edited by hand on a text editor
+  - Lists are ipfs-replication-friendly (adding a new entry does not require downloading more than 1 IPFS block, to sync the list).
+  - Lists support comments
+  - Lists support gateway http error hints (i.e. type of block)
+  - `echo "/ipfs/cid" >> ~/.config/ipfs/denylists/custom` should work
+  - Lists have a header section with information about the list.
 
 - Regarding the implementation:
-    - Multiple denylists should be supported
-    - Hot-reloading of list (no restart of IPFS required)
-    - List removal does not require restart
-    - Minimal introduction of latency
-    - Minimal memory footprint (i.e. only read minimum amount of data into memory)
-    - Clean denylist module entrypoints (easy integration in current ipfs stack layers)
-    - Portable architecture (to other IPFS implementations). i.e. good interfaces to switch from an embedded implementation to something that could run separately, or embedded in other languages (i.e. even servicing multiple ipfs daemons).
-    - Text-based API. `ipfs deny <cid>` and the like are nice-to-have but not a must to work with denylists.
-    - Security in mind: do not enable amplification attacks through lists (i.e. someone requesting a recursively blocked CID repeteadly over the gateway endpoint causes traversal of the whole CID-DAG.
+  - Multiple denylists should be supported
+  - Hot-reloading of list (no restart of IPFS required)
+  - List removal does not require restart
+  - Minimal introduction of latency
+  - Minimal memory footprint (i.e. only read minimum amount of data into memory)
+  - Clean denylist module entrypoints (easy integration in current ipfs stack layers)
+  - Portable architecture (to other IPFS implementations). i.e. good interfaces to switch from an embedded implementation to something that could run separately, or embedded in other languages (i.e. even servicing multiple ipfs daemons).
+  - Text-based API. `ipfs deny <cid>` and the like are nice-to-have but not a must to work with denylists.
+  - Security in mind: do not enable amplification attacks through lists (i.e. someone requesting a recursively blocked CID repeteadly over the gateway endpoint causes traversal of the whole CID-DAG.
 
 - Regarding list distribution:
-    - Ability to subscribe to multiple lists, and fetch any updates as they happen
-    - Ability to publish own lists so that others can subscribe to them
-    - List-subscription configuration or file details remote lists that the user is subscribed to. Editable by hand.
-    - Ability to subscribe to list subscriptions.
-    - List subscriptions can carry context (i.e. publisher, email, type of blocking.
+  - Ability to subscribe to multiple lists, and fetch any updates as they happen
+  - Ability to publish own lists so that others can subscribe to them
+  - List-subscription configuration or file details remote lists that the user is subscribed to. Editable by hand.
+  - Ability to subscribe to list subscriptions.
+  - List subscriptions can carry context (i.e. publisher, email, type of blocking.
 
 ### User benefit
 
@@ -113,7 +112,6 @@ The old JSON-based Protocol Labs denylist format
 [https://badbits.dwebops.pub/denylist.json](https://web.archive.org/web/20230610082307/https://badbits.dwebops.pub/denylist.json) can be easily converted into the
 proposed compact format. This is shown at <https://badbits.dwebops.pub/badbits.deny>.
 
-
 ### Alternatives
 
 This proposal is a follow up to a [previous proposal](https://github.com/ipfs/specs/pull/340), which has several shortcomings that make it not very practical when working at scale. Both list formats can co-exist though but ultimately it will be a matter of implementation support, and it would be better to settle on one thing.