From c9b5fd5cc4e1e5cd6b7f9b2ec265dac3e6d05468 Mon Sep 17 00:00:00 2001
From: Jimmy Debe <91767824+jimstir@users.noreply.github.com>
Date: Mon, 5 Feb 2024 14:29:06 -0500
Subject: [PATCH] Update peer-exchange.md

---
 standards/core/peer-exchange/peer-exchange.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/standards/core/peer-exchange/peer-exchange.md b/standards/core/peer-exchange/peer-exchange.md
index 0441e17..f91d1e0 100644
--- a/standards/core/peer-exchange/peer-exchange.md
+++ b/standards/core/peer-exchange/peer-exchange.md
@@ -31,10 +31,10 @@ This protocol SHOULD only be used if [33/WAKU2-DISCV5](/spec/33/) is infeasible.
 
 The peer exchange protocol specified in this document is a simple request-response protocol.
 As Figure 1 illustrates, the requesting node sends a request to a peer, which acts as the responder.
-The responder replies with a list of ENRs as specified in [31/WAKU2-ENR](/spec/31/).
+The responder replies with a list of ENRs as specified in [WAKU2-ENR](../enr.md).
 The [multiaddresses](https://docs.libp2p.io/concepts/addressing/) used to connect to the respective peers can be extracted from the ENRs.
 
-![Figure 1: The responder provides a list of ENRs to the requester. These ENRs contain the information necessary for connecting to the respective peers.](/rfcs/34/protocol.svg)
+![Figure 1: The responder provides a list of ENRs to the requester. These ENRs contain the information necessary for connecting to the respective peers.](./images/protocol.svg)
 
 In order to protect its anonymity, the responder MUST NOT provide peers from its actively used peer list as this opens pathways to *Neighbourhood Surveillance* attacks, as described in the
 [Security/Privacy Considerations Section](#securityprivacy-considerations).
@@ -81,7 +81,7 @@ message PeerExchangeRPC {
 
 ```
 
-The `enr` field contains a Waku ENR as specified in [31/WAKU2-ENR](/spec/31/).
+The `enr` field contains a Waku ENR as specified in [WAKU2-ENR](../enr.md).
 
 Requesters send a `PeerExchangeQuery` to a peer.
 Responders SHOULD include a maximum of `num_peers` `PeerInfo` instances into a response.
@@ -146,7 +146,7 @@ Still, frequent queries can tigger the refresh cycle more often. The `seen cache
 
 ### Further Considerations
 
-The response field contains ENRs as specified in [31/WAKU2-ENR](/spec/31/).
+The response field contains ENRs as specified in [WAKU2-ENR](../enr.md).
 While ENRs contain signatures, they do not violate the [Waku relay no-sign policy](/spec/11/#signature-policy)),
 because they are part of the discovery domain and are not propagated in the relay domain.
 However, there might still be some form of leakage:
@@ -160,7 +160,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 ## References
 
 * [33/WAKU2-DISCV5](/spec/33/)
-* [31/WAKU2-ENR](/spec/31/)
+* [WAKU2-ENR](../enr.md)
 * [multiaddress](https://docs.libp2p.io/concepts/addressing/)
 * [libp2p discovery interface](https://github.com/status-im/nim-libp2p/issues/140)
 * [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md)