vacp2p
/
rfc
mirror of https://github.com/vacp2p/rfc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

61/STATUS-Community-History-Archives: Update Name (#649) 

* Update README.md

* Update README.md

* Update README.md
This commit is contained in:
Jimmy Debe 2023-12-22 14:29:57 -05:00 committed by GitHub
parent 411eb1d639
commit f5904df2bd
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
content/docs/rfcs/61/README.md
View File

@ -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/)