Merge branch 'theme/migrate-to-doks' of github.com:libp2p/docs into t…

…heme/migrate-to-doks-pshahi

content/concepts/nat/autonat.md

@@ -1,9 +1,10 @@
 ---
 title: "AutoNAT"
-weight: 3
-pre: '<i class="fas fa-fw fa-book"></i> <b> </b>'
-chapter: true
-summary: AutoNAT lets peers request dial-backs from peers providing the AutoNAT service.
+description: AutoNAT lets peers request dial-backs from peers providing the AutoNAT service.
+weight: 2
+aliases:
+    - /concepts/autonat
+    - /concepts/nat/autonat
 ---
 
 While the [identify protocol][spec_identify] described above lets peers inform each other about their observed network addresses, not all networks will allow incoming connections on the same port used for dialing out.
@@ -13,6 +14,6 @@ If this succeeds, we can rely on other peers being able to dial us as well and w
 
 A libp2p protocol called AutoNAT lets peers request dial-backs from peers providing the AutoNAT service.
 
-> AutoNAT is currently implemented in go-libp2p via [go-libp2p-autonat](https://github.com/libp2p/go-libp2p/tree/master/p2p/> host/autonat).
->
+> AutoNAT is currently implemented in go-libp2p via [go-libp2p-autonat](https://github.com/libp2p/go-libp2p/tree/master/p2p/host/autonat).
+
 [spec_identify]: https://github.com/libp2p/specs/tree/master/identify

content/concepts/nat/circuit-relay.md

@@ -1,9 +1,10 @@
 ---
 title: "Circuit Relay"
-weight: 4
-pre: '<i class="fas fa-fw fa-book"></i> <b> </b>'
-chapter: true
-summary: Circuit relay is a transport protocol that routes traffic between two peers over a third-party "relay" peer.
+description: "Circuit relay is a transport protocol that routes traffic between two peers over a third-party relay peer."
+weight: 3
+aliases:
+    - /concepts/circuit-relay
+    - /concepts/nat/circuit-relay
 ---
 
 Circuit relay is a [transport protocol](../../transports/overview) that routes traffic between two peers over a third-party "relay" peer.

content/concepts/nat/hole-punching.md

@@ -1,7 +1,10 @@
 ---
 title: "Hole Punching"
-description: The internet is composed of countless networks, bound together into shared address spaces by foundational transport protocols. As traffic moves between network boundaries, it's very common for a process called Network Address Translation to occur. Network Address Translation (NAT) maps an address from one address space to another.
-weight: 2
+description: "The internet is composed of countless networks, bound together into shared address spaces by foundational transport protocols. As traffic moves between network boundaries, it's very common for a process called Network Address Translation to occur. Network Address Translation (NAT) maps an address from one address space to another."
+weight: 4
+aliases:
+    - /concepts/hole-punching
+    - /concepts/nat/hole-punching
 ---
 
 Nodes on a peer-to-peer network can be categorized into two groups:
@@ -76,7 +79,7 @@ Take two nodes, `A` and `B`, that would like the dial each other:
 
 The following use case diagram illustrates the above process.
 
-<img src="../../assets/hole-punching/libp2p-hole-punching-2.svg/" alt="hp">
+<img src="../../assets/hole-punching/libp2p-hole-punching-2.svg/" >
 
 > This process assumes a mechanism to synchronize `A` and `B` simultaneously.
 
@@ -90,7 +93,7 @@ for central coordination servers like STUN and TURN.
 
 The following sequence diagram illustrates the whole process.
 
-<img src="../../assets/hole-punching/libp2p-hole-punching-4.svg/" alt="hp">
+<img src="../../assets/hole-punching/libp2p-hole-punching-4.svg/" >
 
 libp2p hole punching can be divided into two phases, a preparation phase and
 a hole punching phase.
@@ -103,7 +106,7 @@ a hole punching phase.
    > This is equivalent to the
    > [STUN protocol](https://www.rfc-editor.org/rfc/rfc3489) in ICE.
 
-   <img src="../../assets/hole-punching/libp2p-hole-punching-5.svg/" alt="hp">
+   <img src="../../assets/hole-punching/libp2p-hole-punching-5.svg/" >
 
    - `B` reaches out to `Other_Peers` (e.g., boot nodes) on the network it
      is on and asks each node to dial it on a set of addresses it suspects
@@ -122,7 +125,7 @@ a hole punching phase.
    > IPFS discovers the k-closest public relay nodes using a lookup method
    > via Kademlia DHT): `/<RELAY_ADDR>/p2p-circuit/<PEER_ID_B>`
 
-    <img src="../../assets/hole-punching/libp2p-hole-punching-6.svg/" alt="hp">
+    <img src="../../assets/hole-punching/libp2p-hole-punching-6.svg/" >
 
     - `Other_Peers` outside `B`'s network can dial `B` indirectly through
       a public relay node. In the case of [IPFS](https://ipfs.tech/), each public
@@ -138,7 +141,7 @@ a hole punching phase.
    > This is equivalent to the
    > [TURN protocol](https://datatracker.ietf.org/doc/html/rfc5766) in ICE.
 
-    <img src="../../assets/hole-punching/libp2p-hole-punching-7.svg/" alt="hp">
+    <img src="../../assets/hole-punching/libp2p-hole-punching-7.svg/" >
 
    - `Relay` can limit the resources used to relay connections (e.g., by the number
      of connections, the time, and bytes) via Circuit Relay v2. In the case of IPFS,
@@ -158,7 +161,7 @@ a hole punching phase.
    the relay node, creating a bi-directional channel and uses TLS to secure the
    channel.
 
-    <img src="../../assets/hole-punching/libp2p-hole-punching-8.svg/" alt="hp">
+    <img src="../../assets/hole-punching/libp2p-hole-punching-8.svg/" >
 
     - `A` establishes a relayed connection to `B` via the `Relay` using the
       information contained in `B`'s advertised address.
@@ -176,7 +179,7 @@ a hole punching phase.
 2. [DCUtR](https://github.com/libp2p/specs/blob/master/relay/DCUtR.md): Use
    DCUtR as a synchronization mechanism to coordinate hole punching.
 
-    <img src="../../assets/hole-punching/libp2p-hole-punching-9.svg/" alt="hp">
+    <img src="../../assets/hole-punching/libp2p-hole-punching-9.svg/" >
 
     - `A` sends a `Connect` message to `B` through `Relay`.
         - `Connect` contains the addresses of A. libp2p offers multiple

content/concepts/pubsub/overview.md

@@ -13,7 +13,7 @@ topic:
 Scattered within the shaded area are twelve dots representing peers. A label
 points to the dots which reads “Peers subscribed to topic”.]-->
 
-<img src="../../assets/publish-subscribe/subscribed_peers.png" alt="hp">
+<img src="../../assets/publish-subscribe/subscribed_peers.png" width="650" height="2%">
 
 Peers can send messages to topics. Each message gets delivered to all peers
 subscribed to the topic:
@@ -25,7 +25,7 @@ second panel all dots now have a copy of the speech bubble above them
 representing that the message has been transmitted to all peers subscribed to
 the topic.]-->
 
-<img src="../../assets/publish-subscribe/message_delivered_to_all.png" alt="hp">
+<img src="../../assets/publish-subscribe/message_delivered_to_all.png" width="650" height="2%">
 
 Example uses of pub/sub:
 
@@ -93,7 +93,7 @@ lighter lines labelled “Metadata-only peering”. These lines run from each do
 almost every other dot around it, criss-crossing over each other
 frequently.]-->
 
-<img src="../../assets/publish-subscribe/types_of_peering.png" alt="hp">
+<img src="../../assets/publish-subscribe/types_of_peering.png" width="650" height="2%">
 
 ### Full-message
 
@@ -122,7 +122,7 @@ Upper bound = 4; Lower bound = 2“ accompanied with small symbols showing dots
 with three, four and two lines running from them
 respectively.]-->
 
-<img src="../../assets/publish-subscribe/full_message_network.png" alt="hp">
+<img src="../../assets/publish-subscribe/full_message_network.png" width="650" height="2%">
 
 <div class="notices note" ><p>Throughout this guide, numbers
 <span class="configurable">highlighted in purple</span> can be configured
@@ -156,7 +156,7 @@ many thin, light lines representing metadata-only peerings between peers. The
 lines between the dots are labelled “Each peering is a network connection
 between two peers”.]-->
 
-<img src="../../assets/publish-subscribe/metadata_only_network.png" alt="hp">
+<img src="../../assets/publish-subscribe/metadata_only_network.png" width="650" height="2%">
 
 ## Grafting and pruning
 
@@ -179,7 +179,7 @@ process; two dots are connected by a thick, dark line which becomes a thin,
 light line labelled “Metadata-only peering”. The speech bubble reads “I’m
 pruning our connection back to a metadata-only peering.”]-->
 
-<img src="../../assets/publish-subscribe/graft_prune.png" alt="hp">
+<img src="../../assets/publish-subscribe/graft_prune.png" width="650" height="2%">
 
 When a peer has too few full-message peerings it will randomly graft some of its
 metadata-only peerings to become full-message peerings:
@@ -200,7 +200,7 @@ to get to the ideal number”. In the final panel the highlighted green lines an
 dots have become dark to indicate they have become full-content peerings. The
 title reads “Grafting complete”.]-->
 
-<img src="../../assets/publish-subscribe/maintain_graft.png" alt="hp">
+<img src="../../assets/publish-subscribe/maintain_graft.png" width="650" height="4%">
 
 Conversely, when a peer has too many full-message peerings it will randomly
 prune some of them back to metadata-only:
@@ -223,7 +223,7 @@ the final panel the highlighted pink lines and dots have become light to
 indicate they have become metadata-only peerings. The title reads “Pruning
 complete”.]-->
 
-<img src="../../assets/publish-subscribe/maintain_prune.png" alt="hp">
+<img src="../../assets/publish-subscribe/maintain_prune.png" width="650" height="4%">
 
 In libp2p’s implementation, each peer performs a series of checks every
 <span class="configurable">1</span> second. These checks are called the
@@ -246,7 +246,7 @@ One of the smaller dots that does not share a shaded area with the large dot is
 labelled “Peers keep track of other’s subscriptions even if not subscribed to
 the same topics as them”.]-->
 
-<img src="../../assets/publish-subscribe/subscriptions_local_view.png" alt="hp">
+<img src="../../assets/publish-subscribe/subscriptions_local_view.png" width="650" height="2%">
 
 Keeping track of subscriptions happens by sending **subscribe** and
 **unsubscribe** messages. When a new connection is established between two peers
@@ -258,7 +258,7 @@ connecting line towards the other dot. The left dot’s speech bubble says “I
 subscribed to: Topic 1, Topic 2, Topic 3”. The right dot’s speech bubble says “I
 am subscribed to: Topic 1, Topic 5”.]-->
 
-<img src="../../assets/publish-subscribe/subscription_list_first_connect.png" alt="hp">
+<img src="../../assets/publish-subscribe/subscription_list_first_connect.png" width="650" height="2%">
 
 Then over time, whenever a peer subscribes or unsubscribes from a topic, it will
 send each of its peers a subscribe or unsubscribe message. These messages are
@@ -270,7 +270,7 @@ speech bubble emanating from it with an arrow showing it moving along the
 connecting line towards the right dot. The speech bubble says “I am
 subscribed to: Topic 5. I am unsubscribed from: Topic 2, Topic 3.”]-->
 
-<img src="../../assets/publish-subscribe/subscription_list_change.png" alt="hp">
+<img src="../../assets/publish-subscribe/subscription_list_change.png" width="650" height="2%">
 
 Subscribe and unsubscribe messages go hand-in-hand with graft and prune
 messages. When a peer subscribes to a topic it will pick some peers that will
@@ -289,7 +289,7 @@ now inside the shaded area labelled “Topic 3” and the line connecting the
 central and right dots has become thick and dark indicating a full-message
 peering.] -->
 
-<img src="../../assets/publish-subscribe/subscribe_graft.png" alt="hp">
+<img src="../../assets/publish-subscribe/subscribe_graft.png" width="650" height="3%">
 
 When a peer unsubscribes from a topic it will notify its full-message peers that
 their connection has been pruned at the same time as sending their unsubscribe
@@ -310,7 +310,7 @@ labelled “Topic 3” and the line connecting the central and right dots has be
 thin and light like the left line to indicate a metadata-only
 peering.]-->
 
-<img src="../../assets/publish-subscribe/unsubscribe_prune.png" alt="hp">
+<img src="../../assets/publish-subscribe/unsubscribe_prune.png" width="650" height="3%">
 
 ## Sending messages
 
@@ -324,7 +324,7 @@ outward from it. The second panel is titled “Message sent to all other
 full-message peers”. It shows four copies of the speech bubble now moving away
 from the dot along each of the four lines.]-->
 
-<img src="../../assets/publish-subscribe/full_message_send.png" alt="hp">
+<img src="../../assets/publish-subscribe/full_message_send.png" width="650" height="2%">
 
 Similarly, when a peer receives a new message from another peer, it stores the
 message and forwards a copy to all other full-message peers it is connected to:
@@ -339,7 +339,7 @@ titled “Message forwarded to all other full-message peers”. It shows three
 copies of the speech bubble now moving away from the dot along the three lines
 that the speech bubble has not appeared on yet.]-->
 
-<img src="../../assets/publish-subscribe/full_message_forward.png" alt="hp">
+<img src="../../assets/publish-subscribe/full_message_forward.png" width="650" height="2%">
 
 In the [gossipsub specification](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md#controlling-the-flood),
 peers are also known as *routers* because of this function they have in routing
@@ -376,7 +376,7 @@ bubble, in different shades of purple to indicate three different messages.
 One of the small purple speech bubbles is labelled “Seen messages specify the
 sender and sequence number, but not the full message contents”.]-->
 
-<img src="../../assets/publish-subscribe/gossip_deliver.png" alt="hp">
+<img src="../../assets/publish-subscribe/gossip_deliver.png" width="650" height="2%">
 
 Gossiping gives peers a chance to notice in case they missed a message on the
 full-message network. If a peer notices it is repeatedly missing messages then
@@ -415,7 +415,7 @@ broadcast to full-content peers”. There are now three copies of the purple
 speech bubble travelling outwards from the right dot along the three thick, dark
 lines connected to it.] -->
 
-<img src="../../assets/publish-subscribe/request_gossiped_message.png" alt="hp">
+<img src="../../assets/publish-subscribe/request_gossiped_message.png" width="650" height="6%">
 
 In the [gossipsub specification](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md#control-messages),
 gossip announcing recently seen messages are called *IHAVE* messages and
@@ -447,7 +447,7 @@ they are connected to. These lines represent fan-out peerings. A dice symbol is
 present indicating random selection of which metadata-only peerings became
 fan-out peerings.]-->
 
-<img src="../../assets/publish-subscribe/fanout_initial_pick.png" alt="hp">
+<img src="../../assets/publish-subscribe/fanout_initial_pick.png" width="650" height="2%">
 
 Unlike the other types of peering, fan-out peerings are unidirectional; they
 always point from the peer outside the topic to a peer subscribed to the topic.
@@ -469,7 +469,7 @@ speech bubbles have moved from outside the shaded area to inside out. Now there
 is a copy of the speech bubble above every dot in the shaded
 area.]-->
 
-<img src="../../assets/publish-subscribe/fanout_message_send.png" alt="hp">
+<img src="../../assets/publish-subscribe/fanout_message_send.png" width="650" height="2%">
 
 If the sender goes to send a message but notices some of their fan-out peers
 went away since last time, they will randomly select additional fan-out peers
@@ -494,7 +494,7 @@ become thick, dark lines representing former fan-out peerings becoming
 full-message peerings. The other lines from the dot are still thin and light as
 before.]-->
 
-<img src="../../assets/publish-subscribe/fanout_grafting_preference.png" alt="hp">
+<img src="../../assets/publish-subscribe/fanout_grafting_preference.png" width="650" height="2%">
 
 After <span class="configurable">2</span> minutes of not sending any messages to
 a topic, all the fan-out peers for that topic are forgotten:
@@ -509,7 +509,7 @@ peerings”. In this panel the three previously blue, arrowed lines connecting
 the single dot to dots inside the shaded area have become thin and light,
 representing the peer’s fan-out peerings becoming metadata-only peerings.] -->
 
-<img src="../../assets/publish-subscribe/fanout_forget.png" alt="hp">
+<img src="../../assets/publish-subscribe/fanout_forget.png" width="650" height="2%">
 
 ## Network packets
 
@@ -555,7 +555,7 @@ grafted or pruned. There are three rows in this table. Two of the topics
 have been grafted and one has been pruned (no particular connection to the
 previous table). -->
 
-<img src="../../assets/publish-subscribe/network_packet_structure.png" alt="hp">
+<img src="../../assets/publish-subscribe/network_packet_structure.png" width="650" height="7%">
 
 See the [specification](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md#protobuf) for the exact [Protocol Buffers](https://developers.google.com/protocol-buffers)
 schema used to encode network packets.
@@ -611,7 +611,7 @@ seconds ago in the bottom row. Some of the sequence numbers are shared between
 messages, but only where the sender is different.]
 -->
 
-<img src="../../assets/publish-subscribe/state.png" alt="hp">
+<img src="../../assets/publish-subscribe/state.png" width="650" height="7%">
 
 ## More information