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: Short Summary (#634) 

* Update add-short-summary-abstract

* Update README.md

* Update links + description

* Update README.md

* Update README.md
This commit is contained in:
Jimmy Debe 2023-12-04 10:26:39 -05:00 committed by GitHub
parent 9037874481
commit ddf3b3606a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 15 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -4,6 +4,7 @@ title: 61/STATUS-Community-History-Archives
name: Status Community History Archives
status: raw
category: Standards Track
description: Explains how new members of a Status community can request historical messages from archive nodes.
editor: r4bbit <r4bbit@status.im>
contributors:
- Sanaz Taheri <sanaz@status.im>
@ -288,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` ([6/PAYLOADS](/specs/6-payloads)) with a `payload` of `CommunityMessageArchiveIndex`.
All messages sent with this topic MUST be instances of `ApplicationMetadataMessage` ([62/PAYLOADS](/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.
@ -320,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` ([6/PAYLOADS](/spec/6#communitymessagearchive)) 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/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)).
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.
@ -377,4 +378,15 @@ Even if just a single message is missing in one of the histories, the hashes pre
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
# References
* [13/WAKU2-STORE](/spec/13/)
* [BitTorrent](https://bittorrent.org)
* [10/WAKU2](/spec/10/)
* [11/WAKU2-RELAY](/spec/11/)
* [Magnet URI scheme](https://en.wikipedia.org/wiki/Magnet_URI_scheme)
* [forum discussion](https://forum.vac.dev/t/status-communities-protocol-and-product-point-of-view/114)
* [org channels](https://github.com/status-im/specs/pull/151)
* [UI feature spec](https://github.com/status-im/feature-specs/pull/36)
* [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/)