Homogenize link style

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 [Concepts > Addressing](/concepts/addressing/), or the [multiaddr spec](https://github.com/multiformats/multiaddr), which has links to many implementations.
+For more detail, see [Addressing]({{< relref "/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/protocols/#protocol-negotiation).
+For details, see the [protocol negotiation article]({{< relref "/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/protocols/#protocol-negotiation),
+[protocol negotiation]({{< relref "/concepts/fundamentals/protocols.md#protocol-negotiation" >}}),
 [stream multiplexing](#multiplexing), and
-[secure communications](/concepts/secure-comms/overview).
+[secure communications]({{< relref "/concepts/secure-comm/overview.md" >}}).
 
 Sometimes called ["swarm"](#swarm) for historical reasons.
 

content/concepts/contribute/community.md

@@ -11,4 +11,4 @@ We love talking about libp2p, and we'd be happy to have you in the mix.
 
 Visit our [discussion forums](https://discuss.libp2p.io) to ask questions about [using libp2p](https://discuss.libp2p.io/c/users), discuss exciting [research](https://discuss.libp2p.io/c/research), and [stay up to date with important announcements](https://discuss.libp2p.io/c/news).
 
-We also hang out in the #libp2p-implementers channel in the [Filecoin slack](https://http://filecoin.io/slack).
+We also hang out in the #libp2p-implementers channel in the [Filecoin slack](https://filecoin.io/slack).

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) over the
+[multiaddresses]({{< relref "/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): a protocol that allows peers to exchange peer multiaddresses
+- [Rendezvous]({{< relref "/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): a multicast Domain Name System (DNS) protocol that allows peers to
+- [mDNS]({{< relref "/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): Distributed Hash Table, libp2p uses a DHT called Kademlia, it assigns
+- [DHT]({{< relref "/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]({{< relref "/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]({{< relref "/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).
+For effective discovery, rendezvous can be combined with [libp2p publish/subscribe]({{< relref "/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](/reference/glossary/#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]({{< relref "/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/peers/#peer-id/).
+For more on peer identity and its relation to public key cryptography, see [Peer Identity]({{< relref "/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/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]({{< relref "/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/circuit-relay/#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]({{< relref "/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) channels with each other.
+[secure communication]({{< relref "/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/transport/) address
+the above with a [transport]({{< relref "/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/addressing/)**
+For more on addresses in libp2p, see [Addressing]({{< relref "/concepts/fundamentals/addressing.md" >}})
 
 {{< alert icon="💡" context="note">}}
 The multiaddr protocol for libp2p addresses was originally written `/ipfs` and was later renamed to `/p2p`.
@@ -119,8 +119,8 @@ un-{known, identified} peers on the peer routing guide.
 [wiki_hash_function]: https://en.wikipedia.org/wiki/Cryptographic_hash_function
 [wiki_base58]: https://en.wikipedia.org/wiki/Base58
 
-[definition_multiaddr]: /concepts/appendix/glossary/#multiaddr
-[definition_multihash]: /concepts/appendix/glossary/#multihash
+[definition_multiaddr]: /concepts/appendix/glossary#multiaddr
+[definition_multihash]: /concepts/appendix/glossary#multihash
 
 [spec_peerid]: https://github.com/libp2p/specs/blob/master/peer-ids/peer-ids.md
 [identity]: https://github.com/libp2p/specs/blob/master/identify/README.md#identifypush

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/transport), [peer identity](/concepts/peers#peer-id/), [addressing](/concepts/addressing/), and so on.
+using the core libp2p abstractions like [transport]({{< relref "/concepts/transports/overview.md" >}}), [peer identity]({{< relref "/concepts/fundamentals/peers.md#peer-id" >}}), [addressing]({{< relref "/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-comms/) and efficiently
-[multiplexed](/concepts/stream-multiplexing/). This is transparent to the protocol handler, which reads and writes
+Behind the scenes, libp2p will also ensure that the stream is [secure]({{< relref "/concepts/secure-comm/overview.md" >}}) and efficiently
+[multiplexed]({{< relref "/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/peers/).
+information about themselves, such as their public key, which is used to derive their [`PeerId`]({{< relref "/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/circuit-relay/), or
+This is useful if a peer starts listening on a new address, establishes a new [relay circuit]({{< relref "/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 [peer routing](/concepts/peer-routing/) and [content routing](/concepts/content-routing/) functionality. To learn more about DHT and the Kademlia algorithm,
+libp2p uses the DHT as the foundation of its [routing]({{< relref "/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,10 +205,10 @@ 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/circuit-relay/), libp2p provides a protocol
+As described in the [Circuit Relay article]({{< relref "/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.
 
-[definition_switch]: /reference/glossary/#switch
-[definition_multiaddr]: /reference/glossary/#multiaddr
+[definition_switch]: /concepts/appendix/glossary#switch
+[definition_multiaddr]: /concepts/appendix/glossary#multiaddr