Use hugo ref tags for internal links

content/concepts/appendix/glossary.md

@@ -61,7 +61,7 @@ For example: `/ip4/192.0.2.0/udp/1234` encodes two protocols along with their es
 
 Multiaddresses can be composed to describe multiple "layers" of addresses.
 
-For more detail, see [Addressing](/concepts/fundamentals/addressing.md), or the [multiaddr spec](https://github.com/multiformats/multiaddr), which has links to many implementations.
+For more detail, see [Addressing]({{< ref "/concepts/fundamentals/addressing.md" >}}), or the [multiaddr spec](https://github.com/multiformats/multiaddr), which has links to many implementations.
 
 ### Multiaddress
 
@@ -205,7 +205,7 @@ agree upon what protocols to use.
 The implementation of the libp2p handshake is called
 [multistream-select](https://github.com/multiformats/multistream-select).
 
-For details, see the [protocol negotiation article](/concepts/fundamentals/protocols.md#protocol-negotiation).
+For details, see the [protocol negotiation article]({{< ref "/concepts/fundamentals/protocols.md#protocol-negotiation" >}}).
 
 ### Stream
 
@@ -231,9 +231,9 @@ without having to specify what transport to use.
 In addition to managing transports, the switch also coordinates the
 "connection upgrade" process, which promotes a "raw" connection from
 the transport layer into one that supports
-[protocol negotiation](/concepts/fundamentals/protocols.md#protocol-negotiation),
+[protocol negotiation]({{< ref "/concepts/fundamentals/protocols.md#protocol-negotiation" >}}),
 [stream multiplexing](#multiplexing), and
-[secure communications](/concepts/secure-comm/overview.md).
+[secure communications]({{< ref "/concepts/secure-comm/overview.md" >}}).
 
 Sometimes called ["swarm"](#swarm) for historical reasons.
 

content/concepts/discovery-routing/overview.md

@@ -40,16 +40,16 @@ implementation, discovery and routing usually happen concurrently.
 libp2p provides a set of modules for different network-level functionality,
 including peer discovery and routing. Peers in libp2p can discover other
 peers using various mechanisms, such as exchanging peer
-[multiaddresses](/concepts/fundamentals/addressing.md) over the
+[multiaddresses]({{< ref "/concepts/fundamentals/addressing.md" >}}) over the
 network, querying a directory service, or using a distributed hash table (DHT)
 to store and retrieve information about available peers.
 
 These methods include, but are not limited to:
 
-- [Rendezvous](/concepts/discovery-routing/rendezvous.md): a protocol that allows peers to exchange peer multiaddresses
+- [Rendezvous]({{< ref "/concepts/discovery-routing/rendezvous.md" >}}): a protocol that allows peers to exchange peer multiaddresses
   in a secure and private manner.
-- [mDNS](/concepts/discovery-routing/mDNS.md): a multicast Domain Name System (DNS) protocol that allows peers to
+- [mDNS]({{< ref "/concepts/discovery-routing/mDNS.md" >}}): a multicast Domain Name System (DNS) protocol that allows peers to
   discover other peers on the local network.
-- [DHT](/concepts/discovery-routing/kaddht.md): Distributed Hash Table, libp2p uses a DHT called Kademlia, it assigns
+- [DHT]({{< ref "/concepts/discovery-routing/kaddht.md" >}}): Distributed Hash Table, libp2p uses a DHT called Kademlia, it assigns
   each piece of content a unique identifier and stores the content on the peer whose
   identifier is closest to the content's identifier.

content/concepts/discovery-routing/rendezvous.md

@@ -23,11 +23,11 @@ serve as a hub for nodes to discover.
   solutions like DHT and Gossipsub. DHT (Distributed Hash Table) and Gossipsub are
   decentralized alternatives to Rendezvous.
 
-  [DHT](/concepts/discovery-routing/kaddht.md) is a distributed network protocol used to store and
+  [DHT]({{< ref "/concepts/discovery-routing/kaddht.md" >}}) is a distributed network protocol used to store and
   retrieve data in a P2P network efficiently. It is like a hash table mapping keys
   to values, allowing for fast lookups and efficient data distribution across the network.
 
-  [Gossipsub](/concepts/pubsub/overview.md), on the other hand, is a pub-sub (publish-subscribe) protocol
+  [Gossipsub]({{< ref "/concepts/pubsub/overview.md" >}}), on the other hand, is a pub-sub (publish-subscribe) protocol
   that is used to distribute messages and data across a network. It uses a gossip-based
   mechanism to propagate messages throughout the network, allowing fast and efficient
   distribution without relying on a central control point.
@@ -73,7 +73,7 @@ The rendezvous protocol runs over libp2p streams using the protocol ID `/rendezv
 
 ### Rendezvous and publish-subscribe
 
-For effective discovery, rendezvous can be combined with [libp2p publish/subscribe](/concepts/pubsub/overview.md).
+For effective discovery, rendezvous can be combined with [libp2p publish/subscribe]({{< ref "/concepts/pubsub/overview.md" >}}).
 At a basic level, rendezvous can bootstrap pubsub by discovering peers subscribed to a topic. The rendezvous would
 be responsible for publishing packets, subscribing, or unsubscribing from packet shapes.
 

content/concepts/fundamentals/addressing.md

@@ -14,19 +14,19 @@ A `multiaddress` (often abbreviated `multiaddr`), is a convention for encoding m
 
 For example: `/ip4/192.0.2.0/udp/1234` encodes two protocols along with their essential addressing information. The `/ip4/192.0.2.0` informs us that we want the `192.0.2.0` loopback address of the IPv4 protocol, and `/udp/1234` tells us we want to send UDP packets to port `1234`.
 
-Things get more interesting as we compose further. For example, the multiaddr `/p2p/QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N` uniquely identifies my local IPFS node, using libp2p's [registered protocol id](https://github.com/multiformats/multiaddr/blob/master/protocols.csv) `/p2p/` and the [multihash](/concepts/appendix/glossary.md#multihash) of my IPFS node's public key.
+Things get more interesting as we compose further. For example, the multiaddr `/p2p/QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N` uniquely identifies my local IPFS node, using libp2p's [registered protocol id](https://github.com/multiformats/multiaddr/blob/master/protocols.csv) `/p2p/` and the [multihash]({{< ref "/concepts/appendix/glossary.md#multihash" >}}) of my IPFS node's public key.
 
 {{< alert icon="💡" context="tip">}}
-For more on peer identity and its relation to public key cryptography, see [Peer Identity](/concepts/fundamentals/peers.md#peer-id).
+For more on peer identity and its relation to public key cryptography, see [Peer Identity]({{< ref "/concepts/fundamentals/peers.md#peer-id" >}}).
 {{< /alert >}}
 
 Let's say that I have the Peer ID `QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N` as above, and my public ip is `198.51.100.0`. I start my libp2p application and listen for connections on TCP port `4242`.
 
-Now I can start [handing out multiaddrs to all my friends](/concepts/appendix/glossary.md#peer-routing), of the form `/ip4/198.51.100.0/tcp/4242/p2p/QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N`. Combining my "location multiaddr" (my IP and port) with my "identity multiaddr" (my libp2p `PeerId`), produces a new multiaddr containing both key pieces of information.
+Now I can start [handing out multiaddrs to all my friends]({{< ref "/concepts/appendix/glossary.md#peer-routing" >}}), of the form `/ip4/198.51.100.0/tcp/4242/p2p/QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N`. Combining my "location multiaddr" (my IP and port) with my "identity multiaddr" (my libp2p `PeerId`), produces a new multiaddr containing both key pieces of information.
 
 Now not only do my friends know where to find me, anyone they give that address to can verify that the machine on the other side is really me, or at least, that they control the private key for my `PeerId`. They also know (by virtue of the `/p2p/` protocol id) that I'm likely to support common libp2p interactions like opening connections and negotiating what application protocols we can use to communicate. That's not bad!
 
-This can be extended to account for multiple layers of addressing and abstraction. For example, the [addresses used for circuit relay](/concepts/nat/circuit-relay.md#relay-addresses) combine transport addresses with multiple peer identities to form an address that describes a "relay circuit":
+This can be extended to account for multiple layers of addressing and abstraction. For example, the [addresses used for circuit relay]({{< ref "/concepts/nat/circuit-relay.md#relay-addresses" >}}) combine transport addresses with multiple peer identities to form an address that describes a "relay circuit":
 
 ```shell
 /ip4/198.51.100.0/tcp/4242/p2p/QmRelay/p2p-circuit/p2p/QmRelayedPeer

content/concepts/fundamentals/peers.md

@@ -25,7 +25,7 @@ peers. Every private key has a corresponding public key, which is shared with
 other peers.
 
 Together, the public and private key (or "key pair") allow peers to establish
-[secure communication](/concepts/secure-comm/overview.md) channels with each other.
+[secure communication]({{< ref "/concepts/secure-comm/overview.md" >}}) channels with each other.
 
 Conceptually, a Peer ID is a [cryptographic hash][wiki_hash_function] of a peer's
 public key. When peers establish a secure channel, the hash can be used to
@@ -66,7 +66,7 @@ libp2p multiaddress for me would be:
 
 As with other multiaddrs, a `/p2p` address can be encapsulated into
 another multiaddr to compose into a new multiaddr. For example, I can combine
-the above with a [transport](/concepts/transports/overview.md) address
+the above with a [transport]({{< ref "/concepts/transports/overview.md" >}}) address
 `/ip4/198.51.100.0/tcp/4242` to produce this very useful address:
 
 ```shell
@@ -78,7 +78,7 @@ transport. If some other peer has taken over that IP address or port, it will be
 immediately obvious, since they will not have control over the key pair used to
 produce the Peer ID embedded in the address.
 
-**For more on addresses in libp2p, see [Addressing](/concepts/fundamentals/addressing.md)**
+**For more on addresses in libp2p, see [Addressing]({{< ref "/concepts/fundamentals/addressing.md" >}})**
 
 {{< alert icon="💡" context="note">}}
 The multiaddr protocol for libp2p addresses was originally written `/ipfs` and was later renamed to `/p2p`.

content/concepts/fundamentals/protocols.md

@@ -11,7 +11,7 @@ There are protocols everywhere you look when you're writing network applications
 especially thick with them.
 
 The kind of protocols this article is concerned with are the ones built with libp2p itself,
-using the core libp2p abstractions like [transport](/concepts/transports/overview.md), [peer identity](/concepts/fundamentals/peers.md#peer-id), [addressing](/concepts/fundamentals/addressing.md), and so on.
+using the core libp2p abstractions like [transport]({{< ref "/concepts/transports/overview.md" >}}), [peer identity]({{< ref "/concepts/fundamentals/peers.md#peer-id" >}}), [addressing]({{< ref "/concepts/fundamentals/addressing.md" >}}), and so on.
 
 Throughout this article, we'll call this kind of protocol that is built with libp2p
 a **libp2p protocol**, but you may also see them referred to as "wire protocols" or "application protocols".
@@ -65,8 +65,8 @@ properties:
 - Supports backpressure
   - Readers can't be flooded by eager writers <!-- TODO(yusef) elaborate: how is backpressure implemented? is it transport-depdendent? -->
 
-Behind the scenes, libp2p will also ensure that the stream is [secure](/concepts/secure-comm/overview.md) and efficiently
-[multiplexed](/concepts/multiplex/overview.md). This is transparent to the protocol handler, which reads and writes
+Behind the scenes, libp2p will also ensure that the stream is [secure]({{< ref "/concepts/secure-comm/overview.md" >}}) and efficiently
+[multiplexed]({{< ref "/concepts/multiplex/overview.md" >}}). This is transparent to the protocol handler, which reads and writes
 unencrypted binary data over the stream.
 
 The format of the binary data and the mechanics of what to send when and by whom are all up to the protocol to determine. For inspiration, some [common patterns](#common-patterns) that are used in libp2p's internal protocols are outlined below.
@@ -160,7 +160,7 @@ The basic identify protocol works by establishing a new stream to a peer using t
 shown in the table above.
 
 When the remote peer opens the new stream, they will fill out an [`Identify` protobuf message][identify_proto] containing
-information about themselves, such as their public key, which is used to derive their [`PeerId`](/concepts/fundamentals/peers.md).
+information about themselves, such as their public key, which is used to derive their [`PeerId`]({{< ref "/concepts/fundamentals/peers.md" >}}).
 
 Importantly, the `Identify` message includes an `observedAddr` field that contains the [multiaddr][definition_multiaddr] that
 the peer observed the request coming in on. This helps peers determine their NAT status, since it allows them to
@@ -177,7 +177,7 @@ see what other peers observe as their public address and compare it to their own
 A slight variation on `identify`, the `identify/push` protocol sends the same `Identify` message, but it does so proactively
 instead of in response to a request.
 
-This is useful if a peer starts listening on a new address, establishes a new [relay circuit](/concepts/nat/circuit-relay.md), or
+This is useful if a peer starts listening on a new address, establishes a new [relay circuit]({{< ref "/concepts/nat/circuit-relay.md" >}}), or
 learns of its public address from other peers using the standard `identify` protocol. Upon creating or learning of a new address,
 the peer can push the new address to all peers it's currently aware of. This keeps everyone's routing tables up to date and
 makes it more likely that other peers will discover the new address.
@@ -186,7 +186,7 @@ makes it more likely that other peers will discover the new address.
 
 `kad-dht` is a [Distributed Hash Table][wiki_dht] based on the [Kademlia][wiki_kad] routing algorithm, with some modifications.
 
-libp2p uses the DHT as the foundation of its [routing](/concepts/discovery-routing/overview.md) functionality. To learn more about DHT and the Kademlia algorithm,
+libp2p uses the DHT as the foundation of its [routing]({{< ref "/concepts/discovery-routing/overview.md" >}}) functionality. To learn more about DHT and the Kademlia algorithm,
 check out the [Distributed Hash Tables guide][dht] on the IPFS documentation site. In addition, check out the [libp2p implementations page](https://libp2p.io/implementations/) for updates on all the kad-libp2p implementations.
 
 <!-- Consider adding general kad matrix on implementations page, then link -->
@@ -205,7 +205,7 @@ check out the [Distributed Hash Tables guide][dht] on the IPFS documentation sit
 [relay_js]: https://github.com/libp2p/js-libp2p-circuit
 [relay_go]: https://github.com/libp2p/go-libp2p-circuit
 
-As described in the [Circuit Relay article](/concepts/nat/circuit-relay.md), libp2p provides a protocol
+As described in the [Circuit Relay article]({{< ref "/concepts/nat/circuit-relay.md" >}}), libp2p provides a protocol
 for tunneling traffic through relay peers when two peers are unable to connect to each other
 directly. See the article for more information on working with relays, including notes on relay
 addresses and how to enable automatic relay connection when behind an intractable NAT.

content/concepts/introduction/overview.md

@@ -22,7 +22,7 @@ has something for you.
 
 {{< alert icon="" context="">}}
 If you have any questions or suggestions as you navigate the documentation,
-please don't hesitate to [reach out](/concepts/contribute/community.md), or help
+please don't hesitate to [reach out]({{< ref "/concepts/contribute/community.md" >}}), or help
 improve the documentation by
 [contributing to the site](https://github.com/libp2p/docs).
 {{< /alert >}}
@@ -36,7 +36,7 @@ libp2p, (short for "library peer-to-peer")
 is a peer-to-peer (P2P) networking framework that enables the development
 of P2P applications. It consists of a collection of protocols, specifications, and
 libraries that facilitate P2P communication between network participants, known as
-"[peers](/concepts/fundamentals/peers.md)."
+"[peers]({{< ref "/concepts/fundamentals/peers.md" >}})."
 
 ### Peer-to-peer basics
 
@@ -85,7 +85,7 @@ There are several reasons to consider using libp2p as a networking layer to crea
   to fit the specific requirements of any P2P application.
 
 - **Extensive transport configurability**: libp2p provides a set of specifications that can be adapted to
-  support various [transport protocols](/concepts/transports/overview.md), allowing libp2p applications to operate
+  support various [transport protocols]({{< ref "/concepts/transports/overview.md" >}}), allowing libp2p applications to operate
   in various runtime and networking environments as the wealth of transport protocol choices makes it possible
   to use libp2p in a variety of scenarios.
 
@@ -94,35 +94,35 @@ There are several reasons to consider using libp2p as a networking layer to crea
   [implemented in many programming languages](https://libp2p.io/implementations/), providing
   developers with great flexibility when building P2P applications.
 
-- **Security**: libp2p includes [several security features](/concepts/security/security-considerations.md),
+- **Security**: libp2p includes [several security features]({{< ref "/concepts/security/security-considerations.md" >}}),
   such as peer identity verification using public key cryptography and
-  [encrypted communication](/concepts/secure-comm/overview.md) between peers using modern cryptographic algorithms.
+  [encrypted communication]({{< ref "/concepts/secure-comm/overview.md" >}}) between peers using modern cryptographic algorithms.
 
 - **Robustness**: libp2p is a robust and reliable networking protocol that is designed to withstand stress,
   disturbance, and change. Its features and design choices ensure that it is able to function effectively
   and efficiently in a wide range of environments, and it is able to recover quickly from disruptions or
   failures. It also offers protection against network attacks through the use of
-  [mitigation techniques](/concepts/security/dos-mitigation.md).
+  [mitigation techniques]({{< ref "/concepts/security/dos-mitigation.md" >}}).
 
 - **Resiliency**: P2P networks are often more resilient than traditional client-server networks,
   as there is no single point of failure. libp2p includes features such as
-  [peer discovery and content routing](/concepts/discovery-routing/overview.md) that help
+  [peer discovery and content routing]({{< ref "/concepts/discovery-routing/overview.md" >}}) that help
   to ensure that the network remains available and accessible even if some peers are offline or unreachable.
 
 - **Efficiency**: P2P networks can be more efficient in resource utilization, as data is
   distributed across multiple peers rather than stored on a central server. libp2p includes various storage
   and retrieval patterns that allow developers to distribute data efficiently across the network, making it
   possible to store and retrieve data in a cost-effective and scalable way.
 
-- **Piercing NAT Barriers**: libp2p is equipped with capabilities for [NAT traversal](/concepts/nat/overview.md),
+- **Piercing NAT Barriers**: libp2p is equipped with capabilities for [NAT traversal]({{< ref "/concepts/nat/overview.md" >}}),
   which allows P2P communication between peers even when they are behind NAT devices or firewalls. This
   helps to maintain the connectivity of the network and ensure that it remains accessible despite the
   presence of these obstacles.
 
 - **Message Distribution and Dissemination**: One such pattern libp2p uses is
-  [publish/subscribe (pubsub)](/concepts/pubsub/overview.md), which allows a sender (publisher) to send a message
+  [publish/subscribe (pubsub)]({{< ref "/concepts/pubsub/overview.md" >}}), which allows a sender (publisher) to send a message
   to multiple recipients (subscribers) without the publisher having to know who the subscribers are.
-  libp2p implements pubsub through the use of protocols like [gossipsub](/concepts/pubsub/overview.md#gossip), providing
+  libp2p implements pubsub through the use of protocols like [gossipsub]({{< ref "/concepts/pubsub/overview.md#gossip" >}}), providing
   developers with a flexible and efficient means of exchanging data and messages within their P2P
   applications.