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

f

This commit is contained in:
Felicio Mununga 2024-09-12 11:52:17 +02:00
parent 0b4d151638
commit 2d585c2a6b
No known key found for this signature in database
GPG Key ID: B8A18D62FCD9EA6E
4 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
status/61/community-history-service.md
View File

@ -129,7 +129,7 @@ Message history archives are implemented using the following protocol buffer.
### WakuMessageHistoryArchive
The `from` field SHOULD contain a timestamp of the time range's lower bound.
The type parallels the `timestamp` of [WakuMessage](../../waku/standards/core/14/message.md/#payloads).
The type parallels the `timestamp` of [WakuMessage](../../waku/standards/core/14/message.md).
The `to` field SHOULD contain a timestamp of the time range's the higher bound.
@ -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/STATUS-PAYLOAD](../62/payload.md)) with a `payload` of `CommunityMessageArchiveIndex`.
All messages sent with this topic MUST be instances of `ApplicationMetadataMessage` ([62/STATUS-PAYLOAD](../62/payloads.md)) 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.

5
status/62/payloads.md
View File

@ -1,8 +1,9 @@
---
slug: 62
title: 62/STATUS-Payloads
title: 62/STATUS-PAYLOADS
name: Status Message Payloads
status: draft
description: Describes structure of chat-related messages.
editor: r4bbit <r4bbit@status.im>
contributors:
- Adam Babik <adam@status.im>
@ -310,7 +311,7 @@ enum MessageType {
If a user sends a new message before the messages sent while the user was offline are received, the new message is supposed to be displayed last in a chat.
This is where the basic algorithm of Lamport timestamp would fall short as it's only meant to order causally related events.
The status client therefore makes a "bid", speculating that it will beat the current chat-timestamp, s.t. the status client's Lamport timestamp format is: `clock = `max({timestamp}, chat_clock + 1)`
The status client therefore makes a "bid", speculating that it will beat the current chat-timestamp, s.t. the status client's Lamport timestamp format is: `clock = max({timestamp}, chat_clock + 1)`
This will satisfy the Lamport requirement, namely: a -> b then T(a) < T(b)

1
status/65/account-address.md
View File

@ -113,4 +113,3 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
- [EIP1581](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1581.md)
- [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)
- [Ethereum Name System](https://ens.domains/)
- [Status Multiaccount](../63/account-address.md)

2
status/raw/simple-scaling.md
View File

@ -475,7 +475,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
## References
* [56/STATUS-COMMUNITIES](../56/communities.md)
* [55/STATUS-1TO1-CHAT](.../55/1to1-chat.md)
* [55/STATUS-1TO1-CHAT](../55/1to1-chat.md)
* [23/WAKU2-TOPICS](../../waku/informational/23/)
* [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md)
* [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md)