refine lifecycle and fetching section

Author: 2color

docs/quickstart/publish.md

@@ -55,7 +55,7 @@ Let's unpack what just happened, by looking at CIDs, and how they fits into the
 
 In IPFS, every file and directory is identified with a Content Identifier ([CID](../concepts/content-addressing.md)). The CID serves as the **permanent address** of the file and can be used by anyone to find it on the IPFS network.
 
-When a file is published to IPFS (like the image used in this guide), it's first transformed into a content-addressable representation by which the file is split into smaller chunks which linked and hashed to produce the CID.
+When a file is published to IPFS (like the image used in this guide), it's first transformed into a content-addressable representation by which the file is split into smaller chunks (if above ~1MB) which are linked, and hashed to produce the CID.
 
 The CID for the uploaded image is:
 
@@ -72,17 +72,25 @@ You can now share the CID and anyone should be able to fetch it.
 To understand what happens when you pin a file, it's helpful to understand the lifecycle of data in IPFS, which can be summarised as follows:
 
 1. **Content-addressable representation**: The file is transformed into a content-addressable representation with a CID. For this guide, the full details are not important. The basic idea is that this representation makes files and directories **content-addressable** via CIDs by chunking files into smaller blocks**, calculating their hashes, and constructing a [Merkle DAG](../concepts/merkle-dag.md).
-2. **Pinning:** refers to the stage where the blocks of the CID are saved on an IPFS node (or multiple nodes), in this case web3.storage. Since saving is not enough for the CID to be retrieveable, pinning typically refers to two things:
+2. **Pinning:** refers to the stage where the blocks of the CID are saved on an IPFS node (or multiple nodes), in this case, web3.storage. Since saving is not enough for the CID to be retrievable, pinning typically refers to two things:
    - **Advertising:** Making it discoverable to the IPFS network by advertising a record linking between the CID and the server's IP address to the network. This advertising stage is a continuous process that repeats. 
    - **Providing:** The content-addressable representation of the CID is persisted on one of web3.storage's IPFS nodes (servers running an IPFS node) and made publicly available to the IPFS network.
-3. **Fetching:** refers to step where another node in the IPFS network fetches the blocks of the CID and constructing the DAG locally essentially replicating the file.
-4. **Deleting**
+3. **Retrieval:** refers to when an IPFS node fetches the blocks of the CID and constructs the Merkle DAG. This achieves several things:
+   - **File access:** once the Merkle DAG is constructed, the file is essentially replicated and can be accessed.
+   - **Verifying** that the blocks received are the correct ones by hashing them. This allows blocks to come from any node in the network. This type of retrieval is *trustless*.
+   <!-- - **Replication:** when another IPFS node fetches the CID, it increases the replication factor of the CID, thereby increasing its resilience. -->
+4. **Deleting:** refers to the deletion of a CID from a node. Deletion is always a local operation. If a CID has been replicated by other nodes, it will continue to be available on the IPFS network.
 
 ## Fetching your published file
 
-There are two main ways you can fetch the CID:
-- IPFS node that implements the IPFS suite of protocols
-- IPFS gateway: an IPFS node that provides an HTTP interface to the IPFS network and bridges between IPFS and HTTP.
+Now that the file is published and you have a CID, you will learn how it can be fetched from the IPFS network.
+
+There are two primary ways to fetch files published with IPFS:
+
+- **IPFS node** by installing one of the IPFS implementations, e.g. [Kubo](/concepts/nodes/#kubo)
+- [**IPFS Gateway**](/concepts/ipfs-gateway/) HTTP interface to the IPFS network that allows fetching data from IPFS with HTTP.
+
+The first option allows you to speak the native IPFS protocol. The latter serves as a bridge in situations where you might be constrained to using HTTP, such as in web apps where your app users may not be running an IPFS node.
 
 ### Using an IPFS Node