docs: mi/3294/peers-update (#3360)

* docs: mi/3294/peers-update

- Reorient Prerequisites list on Peers page into sections
- Added context for authTokens

* docs: mi/3294/peers-update

* docs: mi/3294/peers-update

Fixes broken links as a result of renaming H2 title from Prerequisites to Perform prerequisites

* docs: mi/3294/peers-update

* docs: mi/3294/peers-update

Author: hajjimo

packages/documentation/src/content/docs/integration/deployment/services/backend-service.mdx

@@ -39,7 +39,7 @@ Some of the responsibilities of a connector include:
 
 - Authenticating packets against ILP account credentials.
 - Forwarding packets to a sender or receiver.
-- Rejecting a packet for any number of reasons, including expiration, insufficient liquidity, rate limit exceeded, or if the amount exceeds the `maxPacketAmount` [agreed to](/integration/requirements/peers#prerequisites) by the connector and its peer.
+- Rejecting a packet for any number of reasons, including expiration, insufficient liquidity, rate limit exceeded, or if the amount exceeds the `maxPacketAmount` [agreed to](/integration/requirements/peers#perform-prerequisites) by the connector and its peer.
 - Converting currencies.
 - Fulfilling packets with an internal STREAM server.
 
@@ -48,7 +48,7 @@ The `backend` service includes an HTTP server listening on the configured `CONNE
 Similarly, if a packet's destination address corresponds to a peer, your connector forwards the packet to your peer over HTTP, along with your peer's outgoing HTTP `authToken`.
 
 :::note[Auth tokens]
-You and your peer should have exchanged incoming and outgoing auth tokens as part of establishing your [peering relationship](/integration/requirements/peers#prerequisites).
+You and your peer should have exchanged incoming and outgoing auth tokens as part of establishing your [peering relationship](/integration/requirements/peers#perform-prerequisites).
 :::
 
 A packet can either continue on to your peer via HTTP or end at your Rafiki instance's STREAM server. If the packet terminates at your STREAM server, your connector attempts to extract and decode the payment tag from the packet's destination address. When your connector successfully matches the tag with a locally managed wallet address or incoming payment, the connector does not forward the packet. Instead, it credits the corresponding balance and track the total amount received in Redis to support STREAM receipts. Packets addressed to a wallet address happen via SPSP.

packages/documentation/src/content/docs/integration/requirements/peers.mdx

@@ -3,6 +3,7 @@ title: Peers
 ---
 
 import { CodeBlock, LinkOut } from '@interledger/docs-design-system'
+import { Badge } from '@astrojs/starlight/components'
 
 To join the Interledger network and be able to send and receive payments, you must add one or more peers to your Rafiki instance. Peering establishes the connections needed for your Rafiki instance to interact with another account servicing entity (ASE). The purpose of this guide is to help you set up and manage peers.
 
@@ -14,25 +15,47 @@ Refer to the [Rafiki Admin user guide](/admin/admin-user-guide#peers) for detail
 Whether you are using the Backend Admin API or the Rafiki Admin application, the underlying configurations and requirements remain the same. Choose the interface that best suits your individual workflow.
 :::
 
-## Prerequisites
+## Perform prerequisites
 
 :::note
 Peering is not required unless you want to participate in transactions with another ASE on the Interledger network. For foundational peering concepts, refer to the Peers section of [Interledger Concepts](/overview/concepts/interledger/#peers).
 :::
 
 Before adding a peer, you and the account servicing entity you intend to peer with must both:
 
-- Run an implementation of an [Interledger connector](/integration/deployment/services/backend-service#interledger-connector) (ideally Rafiki).
-- Agree on an [asset](/overview/concepts/accounting#assets) for the peering relationship. You can set up multiple peering relationships with the same peer based on different assets. At least one asset shared by you and your peer must be added to your Rafiki instance prior to setting up the peering relationship. For more information, refer to [Assets](/integration/requirements/assets/).
-- Exchange static <LinkOut href="https://interledger.org/developers/rfcs/ilp-addresses/">Interledger (ILP) addresses</LinkOut> with your peer. Your ILP address is self-assigned during Rafiki setup and stored locally as the `ILP_ADDRESS` environment variable for the `backend` service.
-- Communicate a connection endpoint for the other peer to send packets to.
-- Exchange `auth` tokens for the connection endpoint.
-- Agree on a settlement mechanism (a means of paying one another for the successful forwarding and delivery of packets), which is outside the scope of Interledger and Rafiki.
+### Run an Interledger connector
 
-### Optional settings
+While you and your peer may run any implementation of an [Interledger connector](/integration/deployment/services/backend-service#interledger-connector) such as the <LinkOut href="https://github.com/interledger/interledgerjs">TypeScript implementation</LinkOut>, it is recommended to use Rafiki.
 
-- Deposit an `initialLiquidity` for your peer. You can deposit liquidity later using the `depositPeerLiquidity` mutation.
-- Define a `maxPacketAmount` value, which specifies the maximum packet size you are willing to accept from the peer. Your peer's `maxPacketAmount` value does not need to match, as this value is independently set by each ASE. If omitted, payments will not be broken into smaller packets.
+### Agree on an asset
+
+Both you and your peer must agree on an [asset](/overview/concepts/accounting#assets) for the peering relationship. You can set up multiple peering relationships with the same peer based on different assets. At least one asset shared by you and your peer must be added to your Rafiki instance prior to setting up the peering relationship. For more information, refer to [Assets](/integration/requirements/assets/).
+
+### Exchange static Interledger (ILP) addresses
+
+Your <LinkOut href="https://interledger.org/developers/rfcs/ilp-addresses/">ILP address</LinkOut> is self-assigned during Rafiki setup and stored locally as the `ILP_ADDRESS` environment variable for the `backend` service.
+
+### Communicate a connection endpoint
+
+The connection endpoint will be a url that the other peer will send packets to.
+
+### Exchange auth tokens for the connection endpoint
+
+Incoming `authtokens` allow you to authenticate that packets sent from your peer originated from your peer's Interledger connector and were not tampered en route. The outgoing `authtoken` allows your peer to authenticate that received packets originated from your Interledger connector and were not tampered with en route. The use of auth tokens is not required when [autopeering with the Test Network](/integration/playground/autopeering).
+
+### Agree on a settlement mechanism
+
+The settlement mechanism you both agree to use is what facilitates the transfer of actual funds between you and your peer. Neither Interledger nor Rafiki provide a settlement mechanism.
+
+## Perform optional prerequisites
+
+### Deposit an initial liquidity for your peer
+
+While you may deposit an `initiaLiquidity` for your peer, you can deposit liquidity later using the `depositPeerLiquidity` mutation.
+
+### Define a maxPacketAmout value
+
+The `maxPacketAmount` specifies the maximum packet size you are willing to accept from the peer. Your peer's `maxPacketAmount` value does not need to match, as this value is independently set by each ASE. If omitted, payments will not be broken into smaller packets.
 
 ## Set up peering in Rafiki
 

packages/documentation/src/content/docs/overview/concepts/interledger.mdx

@@ -18,7 +18,7 @@ Each packet represents a conditional IOU which affects financial accounting bala
 
 Interledger itself is a network of computers that enables sending payment messages across payment networks. Each computer on the network is a node.
 
-For two nodes on the Interledger network to exchange ILP packets with one another, the two nodes must be peers. There are a number of [requirements](/integration/requirements/peers#prerequisites) that both you and your potential peer must meet to form a peering relationship.
+For two nodes on the Interledger network to exchange ILP packets with one another, the two nodes must be peers. There are a number of [requirements](/integration/requirements/peers#perform-prerequisites) that both you and your potential peer must meet to form a peering relationship.
 
 Since the purpose of peering is to facilitate payments, which often involves extending lines of credit, your peer should be someone you trust. We strongly recommend you and your potential peer define your expectations and outline your agreements in a legally binding document peering with one another.