progress

Author: 2color

docs/quickstart/publish.md

@@ -16,6 +16,7 @@ Pinning a file to IPFS is how content is published to IPFS. Any given file repre
 :::callout
 Data pinned to the IPFS network is public by default and retrievable by anyone. Make sure to avoid publishing private data or take the necessary measures to adequately encrypt it before publishing.
 :::
+
 ## Prerequisites
 
 - A free [web3.storage](https://web3.storage/) account.
@@ -55,7 +56,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 (if above ~1MB) which are 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:
 
@@ -71,16 +72,18 @@ 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).
+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 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. 
+   - **Advertising:** Making it discoverable to the IPFS network by advertising a record linking between the CID and the server's IP address to <VueCustomTooltip label="Distributed Hash Table: a decentralized data store that maps data based on key-value pairs." underlined multiline is-left>the DHT</VueCustomTooltip>. This advertising stage is a continuous process that repeats typically every 12 hours.
    - **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. **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. -->
+3. **Retrieval:** refers to when an IPFS node fetches the blocks of the CID and constructs the Merkle DAG. This usually involves several steps:
+   - **Block fetching:** An IPFS node fetches the blocks of the Merkle DAG (of the file or folder) from providers.
+   - **Verifying** the IPFS node verifies the blocks fetched by hashing them and ensuring the resulting hash is correct. Note that blocks can come from any node in the network and this type of retrieval is _trustless_.
+   - **File access:** once all the blocks are present, the Merkle DAG can be constructed making the CID successfully replicated and accessible.
 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.
 
+Note that once the CID is replicated, it is typically advertised by default, even if it isn't explicitly pinned.
+
 ## Fetching your published file
 
 Now that the file is published and you have a CID, you will learn how it can be fetched from the IPFS network.
@@ -94,7 +97,7 @@ The first option allows you to speak the native IPFS protocol. The latter serves
 
 ### Using an IPFS Node
 
-
+Using a Kubo
 
 ### Fetching the CID with an IPFS Gateway