From f5904df2bdc557b2cac34e0e63b01040d64292e5 Mon Sep 17 00:00:00 2001
From: Jimmy Debe <91767824+jimstir@users.noreply.github.com>
Date: Fri, 22 Dec 2023 14:29:57 -0500
Subject: [PATCH] 61/STATUS-Community-History-Archives: Update Name (#649)

* Update README.md

* Update README.md

* Update README.md
---
 content/docs/rfcs/61/README.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/content/docs/rfcs/61/README.md b/content/docs/rfcs/61/README.md
index 5a6aa7e1..52e7b4b2 100644
--- a/content/docs/rfcs/61/README.md
+++ b/content/docs/rfcs/61/README.md
@@ -1,7 +1,7 @@
 ---
 slug: 61
-title: 61/STATUS-Community-History-Archives
-name: Status Community History Archives
+title: 61/STATUS-Community-History-Service
+name: Status Community History Service
 status: raw
 category: Standards Track
 description: Explains how new members of a Status community can request historical messages from archive nodes.
@@ -289,7 +289,7 @@ The topic of that special channel follows the following format:
 /{application-name}/{version-of-the-application}/{content-topic-name}/{encoding}
 ```
 
-All messages sent with this topic MUST be instances of `ApplicationMetadataMessage` ([62/PAYLOADS](/specs/62/)) with a `payload` of `CommunityMessageArchiveIndex`.
+All messages sent with this topic MUST be instances of `ApplicationMetadataMessage` ([62/STATUS-PAYLOAD](/specs/62/)) with a `payload` of `CommunityMessageArchiveIndex`.
 
 Only the control node MAY post to the special channel. Other messages on this specified channel MUST be ignored by clients.
 Community members MUST NOT have permission to send messages to the special channel.
@@ -321,7 +321,7 @@ There are two scenarios in which member nodes can receive such a magnet link mes
 2. The member node requests messages for a time range of up to 30 days from store nodes (this is the case when a new community member joins a community)
 
 ## Downloading message archives
-When member nodes receive a message with a `CommunityMessageHistoryArchive` ([62/PAYLOADS](/spec/62/)) from the aforementioned channnel, they MUST extract the `magnet_uri` and pass it to their underlying BitTorrent client so they can fetch the latest message history archive index, which is the `index` file of the torrent (see [Creating message archive torrents](#creating-message-archive-torrents)).
+When member nodes receive a message with a `CommunityMessageHistoryArchive` ([62/STATUS-PAYLOAD](/spec/62/)) from the aforementioned channnel, they MUST extract the `magnet_uri` and pass it to their underlying BitTorrent client so they can fetch the latest message history archive index, which is the `index` file of the torrent (see [Creating message archive torrents](#creating-message-archive-torrents)).
 
 Due to the nature of distributed systems, there's no guarantee that a received message is the "last" message. This is especially true when member nodes request historical messages from store nodes. 
 
@@ -389,4 +389,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 * [Extensions for Peers to Send Metadata Files](https://www.bittorrent.org/beps/bep_0009.html)
 * [org channels spec](https://rfc.vac.dev/spec/56/)
 * [14/WAKU2-MESSAGE](/spec/14/)
-* [62/PAYLOAD](/spec/62/)
+* [62/STATUS-PAYLOAD](/spec/62/)