Apply suggestions from code review

Co-authored-by: Hector Sanjuan <code@hector.link>

Author: 2color

src/ipips/ipip-0499.md

@@ -22,7 +22,7 @@ tags: ['ipips']
 
 This proposal introduces configuration profiles for CIDs used to represent files and directories with UnixFS. These ensure that the deterministic CID generation for the same data, regardless of the implementation.
 
-Profiles explicitly define the UnixFS parameters, e.g. dag width, hash algorithem, and chunk size, that affect the resulting CID, such that given the profile and input data different implementations will generate identical CIDs.
+Profiles explicitly define the UnixFS parameters, e.g. dag width, hash algorithm, and chunk size, that affect the resulting CID, such that given the profile and input data different implementations will generate identical CIDs.
 
 ## Motivation
 
@@ -31,7 +31,7 @@ UnixFS CIDs are not deterministic. This means that the same file tree can yield
 This lack of determinism makes has a number of drawbacks:
 
 - It is difficult to verify content across different tools and implementations, as the same content may yield different CIDs.
-- Users are requires to store and transfer UnixFS merkle proofs in order to verify CIDs, adding storage overhead, network bandwidth, and complexity to the verification process.
+- Users are required to store and transfer UnixFS merkle proofs in order to verify CIDs, adding storage overhead, network bandwidth, and complexity to the verification process.
 - In terms of developer experience, it deviates from the mental model of a hash function, where the same input should always yield the same output. This leads to confusion and frustration when working with UnixFS CIDs
 
 By introducing profiles, we can benefit from both the optionality offered by UnixFS, where users are free to chose their own parameters, and determinism through profiles.
@@ -49,7 +49,7 @@ The profiles define a set of parameters that affect the resulting CID. These par
 1. CID version (currently only CIDv0 or CIDv1)
 1. Hash function
 1. UnixFS chunk size
-1. UnixFS DAG layout (e.g. balanced, trickle)
+1. UnixFS DAG layout (e.g. balanced, trickle etc...)
 1. UnixFS DAG width (max number of links per `File` node)
 1. `HAMTDirectory` fanout (must be a power of 2)
 1. `HAMTDirectory` threshold (max `Directory` size before switching to `HAMTDirectory`): based on an estimate of the block size by counting the size of PNNode.Links
@@ -115,7 +115,7 @@ Kubo 0.35 will have [`Import.*` configuration](https://github.com/ipfs/kubo/blob
 
 ### Alternatives
 
-As an alternative to profiles, users can store and transfer CAR files of UnixFS content, which include the merkle proofs needed to verify the CID.
+As an alternative to profiles, users can store and transfer CAR files of UnixFS content, which include the merkle DAG nodes needed to verify the CID.
 
 ## Test fixtures