fix: fix build errors

fetch-content.js

@@ -181,7 +181,7 @@ function parseSlugFromFrontmatter(content) {
 }
 
 function unescapeHtmlComments(htmlString) {
-  return htmlString.replace(/\\<\!--/g, '<!--').replace(/--\\>/g, '-->')
+  return htmlString.replace(/\\<\!--/g, '\n<!--').replace(/--\\>/g, '-->\n')
 }
 
 async function downloadAndSaveFile(url, filePath) {

nomos/claro.md

@@ -123,7 +123,10 @@ The algorithm is divided into 4 phases:
 3. Transition function
 4. Opinion and Decision
 
+
 <!-- NOTE from CP: not sure this fits, commenting for now -->
+
+
 <!-- ### Proposal Identification
 
 The node has a semantics and serialization of the proposal, of which
@@ -142,6 +145,7 @@ proposal, it enters a quiescent state in which it optionally discards
 all information gathered during the query process retaining only the
 final opinion on the truth of the proposal. -->
 
+
 ### Setup Parameters
 
 The node initializes the following integer ratios as constants:

status/1to1-chat.md

@@ -145,7 +145,9 @@ message MembershipUpdateEvent {
   }
 }
 ```
+
 <!-- Note: I don't like defining wire formats which are out of the scope of the rfc this way. Should explore alternatives -->
+
 Note that the definitions for `ChatMessage` and `EmojiReaction` can be found in [chat_message.proto](https://github.com/status-im/status-go/blob/5fd9e93e9c298ed087e6716d857a3951dbfb3c1e/protocol/protobuf/chat_message.proto#L1) and [emoji_reaction.proto](https://github.com/status-im/status-go/blob/5fd9e93e9c298ed087e6716d857a3951dbfb3c1e/protocol/protobuf/emoji_reaction.proto).
 
 ##### Chat Created

status/account-address.md

@@ -56,8 +56,10 @@ The Status node verifies or derives everything else associated with the contact
 ### User Profile Picture
 - An account MAY edit the `IK` generated identicon with a chosen picture.  This picture will become part of the publicly broadcasted profile of the account.
 
+
 <!-- TODO: Elaborate on wallet account and multiaccount -->
 
+
 ## Wire Format
 
 Below is the wire format for the account information that is broadcasted publicly.

status/communities.md

@@ -74,6 +74,7 @@ The following cryptographic primitives are used in the design -
 
 ## Wire format
 
+
 <!--   
 The wire format is described first to give an overview of the protocol.
 It is referenced in the flow of community creation and community management.
@@ -81,6 +82,7 @@ More or less an intersection of https://github.com/status-im/specs/blob/403b5ce3
 
 -->
 
+
 ```protobuf
 syntax = "proto3";
 
@@ -317,7 +319,9 @@ contentTopic = "/waku/1/0x" + topic + "/rfc26"
 #### Community channels/chats
 
 The unique identifier for a community channel/chat is the chat id.
+
 <!-- Don't enforce any constraints on the unique id generation -->
+
 The content topic that Community channels/chats use MUST be the hex-encoded keccak-256 hash of the public key of the community concatenated with the chat id.
 
 ```
@@ -365,7 +369,9 @@ The flows for Community management are as described below.
 1. The Community owner generates a public/private key pair.
 2. The Community owner configures the Community metadata, according to the wire format "CommunityDescription".
 3. The Community owner publishes the Community metadata on a content topic derived from the public key of the Community. 
-the Community metadata SHOULD be encrypted with the public key of the Community. <!-- TODO: Verify this-->
+the Community metadata SHOULD be encrypted with the public key of the Community. 
+<!-- TODO: Verify this-->
+
 The Community metadata MAY be sent during fixed intervals, to ensure that the Community metadata is available to members.
 The Community metadata SHOULD be sent every time the Community metadata is updated.
 4. The Community owner MAY advertise the Community out of band, by sharing the public key of the Community on other mediums of communication.

status/keycard-usage.md

@@ -248,9 +248,11 @@ To verify the pin of the keycard.
 
 Status code reference:
 - 3: PIN is valid
+
 <!--TODO: what are the other status codes?-->
 
 
+
 ### 9. Change the pin (`/change-pin`)
 
 To change the pin of the keycard.

status/payloads.md

@@ -286,9 +286,11 @@ message DiscordMessageAttachment {
 A node requires message types to decide how to encrypt a particular message and what metadata needs to be attached when passing a message to the transport layer.
 For more on this, see [10/WAKU2](../../waku/standards/core/10/waku2.md).
 
+
 <!-- TODO: This reference is a bit odd, considering the layer payloads should interact with is Secure Transport, and not Whisper/Waku. This requires more detail -->
 
 
+
 The following messages types MUST be supported:
 * `ONE_TO_ONE` is a message to the public group
 * `PUBLIC_GROUP` is a private message

vac/mvds.md

@@ -114,8 +114,10 @@ Nodes MAY have two modes with which they can send records: `BATCH` and `INTERACT
  3. When a node receives an `ACK`, the `MESSAGE` is removed from the state for the given peer.
  4. All records that require retransmission are added to the payload, given `Send Epoch` has been reached.
 
+
 <!-- diagram -->
 
+
 \<p align="center"\>
     \<img src="../assets/mvds/batch.png" /\>
     \<br /\>
@@ -125,8 +127,10 @@ Nodes MAY have two modes with which they can send records: `BATCH` and `INTERACT
 
 \> ***NOTE:** Batch mode is higher bandwidth whereas interactive mode is higher latency.*
 
+
 <!-- Interactions with state, flow chart with retransmissions? -->
 
+
 ### Retransmission
 
 The record of the type `Type` SHOULD be retransmitted every time `Send Epoch` is smaller than or equal to the current epoch.

vac/remote-log.md

@@ -33,8 +33,10 @@ content addressed storage, or the name system. It is assumed these capabilities
 are abstracted away in such a way that any such protocol can easily be
 implemented.
 
+
 <!-- TODO: Elaborate on properties required here. -->
 
+
 ### Payloads
 
 Payloads are implemented using [protocol buffers v3](https://developers.google.com/protocol-buffers/).
@@ -60,8 +62,10 @@ message Content {
 }
 ```
 
+
 <!-- XXX/TODO: Can we get rid of the id/data complication and just use bytes? -->
 
+
 **NS service**:
 
 ```protobuf
@@ -92,9 +96,13 @@ message Response {
 }
 ```
 
+
 <!-- XXX: Response and data type a bit weird, Ok/Err enum? -->
+
+
 <!-- TODO: Do we want NameInit here? -->
 
+
 **Remote log:**
 
 ```protobuf
@@ -114,10 +122,14 @@ message RemoteLog {
 }
 ```
 
+
 <!-- TODO: Better name for Pair, Mapping? -->
 
+
+
 <!-- TODO: Consider making more useful in conjunction with metadata field. It makes sense to explicitly list what sequence a message is \<local hash, remote hash, data, seqid\> this way I can easily sync a messages prior or after a specific number. To enable this to be dynamic it might make sense to add page info so that I am aware which page I can find seqid on -->
 
+
 ## Synchronization
 
 ### Roles
@@ -133,21 +145,29 @@ The *remote log* protobuf is what is stored in the name system.
 
 "Bob" can represent anything from 0 to N participants. Unlike Alice, Bob only needs read-only access to NS and CAS.
 
+
 <!-- TODO: Document random node as remote log -->
+
+
 <!-- TODO: Document how to find initial remote log (e.g. per sync contexts -->
 
+
 ### Flow
 
+
 <!-- diagram -->
 
+
 \<p align="center"\>
     \<img src="./images/remote-log.png" /\>
     \<br /\>
     Figure 1: Remote log data synchronization.
 \</p\>
 
+
 <!-- Document the flow wrt operations -->
 
+
 ### Remote log
 
 The remote log lets receiving nodes know what data they are missing. Depending
@@ -202,10 +222,14 @@ log. The latter is useful for things like backups on durable storage.
 The pointer to the 'next page' is another remote log entry, at a previous point
 in time.
 
+
 <!-- TODO: Determine requirement re overlapping, adjacent, and/or missing entries -->
 
+
+
 <!-- TODO: Document message ordering append only requirements -->
 
+
 ### Interaction with MVDS
 
 [vac.mvds.Message](../2/mvds.md/#payloads) payloads are the only payloads that MUST be uploaded. Other messages types MAY be uploaded, depending on the implementation.

waku/standards/application/swap.md

@@ -177,6 +177,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 3. [Book of Swarm](https://web.archive.org/web/20210126130038/https://gateway.ethswarm.org/bzz/latest.bookofswarm.eth)
 4. [13/WAKU2-STORE](../../core/13/store.md)
 
+
 <!--
 
 General TODOs:
@@ -188,3 +189,4 @@ General TODOs:
 - Specify chequeboo
 
 -->
+

waku/standards/core/12/filter.md

@@ -145,9 +145,13 @@ implementation, though a reasonable default is one minute.
 
 --- 
 # Future Work
+
 <!-- Alternative title: Filter-subscriber unlinkability -->
+
 **Anonymous filter subscription**: This feature guarantees that nodes can anonymously subscribe for a message filter (i.e., without revealing their exact content filter). As such, no adversary in the `WakuFilter` protocol would be able to link nodes to their subscribed content filers. The current version of the `WakuFilter` protocol does not provide anonymity as the subscribing node has a direct connection to the full node and explicitly submits its content filter to be notified about the matching messages. However, one can consider preserving anonymity through one of the following ways: 
-- By hiding the source of the subscription i.e., anonymous communication. That is the subscribing node shall hide all its PII in its filter request e.g., its IP address. This can happen by the utilization of a proxy server or by using Tor<!-- TODO: if nodes have to disclose their PeerIDs (e.g., for authentication purposes) when connecting to other nodes in the WakuFilter protocol, then Tor does not preserve anonymity since it only helps in hiding the IP. So, the PeerId usage in switches must be investigated further. Depending on how PeerId is used, one may be able to link between a subscriber and its content filter despite hiding the IP address-->. 
+- By hiding the source of the subscription i.e., anonymous communication. That is the subscribing node shall hide all its PII in its filter request e.g., its IP address. This can happen by the utilization of a proxy server or by using Tor
+<!-- TODO: if nodes have to disclose their PeerIDs (e.g., for authentication purposes) when connecting to other nodes in the WakuFilter protocol, then Tor does not preserve anonymity since it only helps in hiding the IP. So, the PeerId usage in switches must be investigated further. Depending on how PeerId is used, one may be able to link between a subscriber and its content filter despite hiding the IP address-->
+. 
   Note that the current structure of filter requests i.e., `FilterRPC` does not embody any piece of PII, otherwise, such data fields must be treated carefully to achieve anonymity. 
 - By deploying secure 2-party computations in which the subscribing node obtains the messages matching a content filter whereas the full node learns nothing about the content filter as well as the messages pushed to the subscribing node. Examples of such 2PC protocols are [Oblivious Transfers](https://link.springer.com/referenceworkentry/10.1007%2F978-1-4419-5906-5_9#:~:text=Oblivious%20transfer%20(OT)%20is%20a,information%20the%20receiver%20actually%20obtains.) and one-way Private Set Intersections (PSI).
 

waku/standards/core/filter.md

@@ -234,9 +234,13 @@ and that it matches filter criteria belonging to that subscription.
 
 --- 
 ## Future Work
+
 <!-- Alternative title: Filter-subscriber unlinkability -->
+
 **Anonymous filter subscription**: This feature guarantees that nodes can anonymously subscribe for a message filter (i.e., without revealing their exact content filter). As such, no adversary in the `WakuFilter` protocol would be able to link nodes to their subscribed content filers. The current version of the `WakuFilter` protocol does not provide anonymity as the subscribing node has a direct connection to the full node and explicitly submits its content filter to be notified about the matching messages. However, one can consider preserving anonymity through one of the following ways: 
-- By hiding the source of the subscription i.e., anonymous communication. That is the subscribing node shall hide all its PII in its filter request e.g., its IP address. This can happen by the utilization of a proxy server or by using Tor<!-- TODO: if nodes have to disclose their PeerIDs (e.g., for authentication purposes) when connecting to other nodes in the WakuFilter protocol, then Tor does not preserve anonymity since it only helps in hiding the IP. So, the PeerId usage in switches must be investigated further. Depending on how PeerId is used, one may be able to link between a subscriber and its content filter despite hiding the IP address-->. 
+- By hiding the source of the subscription i.e., anonymous communication. That is the subscribing node shall hide all its PII in its filter request e.g., its IP address. This can happen by the utilization of a proxy server or by using Tor
+<!-- TODO: if nodes have to disclose their PeerIDs (e.g., for authentication purposes) when connecting to other nodes in the WakuFilter protocol, then Tor does not preserve anonymity since it only helps in hiding the IP. So, the PeerId usage in switches must be investigated further. Depending on how PeerId is used, one may be able to link between a subscriber and its content filter despite hiding the IP address-->
+. 
   Note that the current structure of filter requests i.e., `FilterRPC` does not embody any piece of PII, otherwise, such data fields must be treated carefully to achieve anonymity. 
 - By deploying secure 2-party computations in which the subscribing node obtains the messages matching a content filter whereas the full node learns nothing about the content filter as well as the messages pushed to the subscribing node. Examples of such 2PC protocols are [Oblivious Transfers](https://link.springer.com/referenceworkentry/10.1007%2F978-1-4419-5906-5_9#:~:text=Oblivious%20transfer%20(OT)%20is%20a,information%20the%20receiver%20actually%20obtains.) and one-way Private Set Intersections (PSI).
 

waku/standards/core/relay.md

@@ -26,11 +26,13 @@ As such the scope is limited to defining a separate [`protocol id`](https://gith
 The `11/WAKU2-RELAY` protocol is designed to provide the following security properties under a static [Adversarial Model](#adversarial-model).
 Note that data confidentiality, integrity, and authenticity are currently considered out of scope for `11/WAKU2-RELAY` and must be handled by higher layer protocols such as [`14/WAKU2-MESSAGE`](../14/message.md).
 
+
 <!-- May add the definition of the unsupported feature: 
 Confidentiality indicates that an adversary should not be able to learn the data carried by the `WakuRelay` protocol.
 Integrity indicates that the data transferred by the `WakuRelay` protocol can not be tampered with by an adversarial entity without being detected.
 Authenticity no adversary can forge data on behalf of a targeted publisher and make it accepted by other subscribers as if the origin is the target. -->
 
+
 - **Publisher-Message Unlinkability**:
 This property indicates that no adversarial entity can link a published `Message` to its publisher.
 This feature also implies the unlinkability of the publisher to its published topic ID as the `Message` embodies the topic IDs.
@@ -38,8 +40,10 @@ This feature also implies the unlinkability of the publisher to its published to
 - **Subscriber-Topic Unlinkability**:
 This feature stands for the inability of any adversarial entity from linking a subscriber to its subscribed topic IDs.
 
+
 <!-- TODO: more requirements can be added, but that needs further and deeper investigation-->
 
+
 ### Terminology
 
 _Personally identifiable information_ (PII) refers to any piece of data that can be used to uniquely identify a user.
@@ -133,15 +137,19 @@ Note that this does not merely imply that these fields be empty, but that they M
 
 ## Security Analysis
 
+
 <!-- TODO: realized that the prime security objective of the `WakuRelay` protocol is to provide peers unlinkability as such this feature is prioritized over other features e.g., unlinkability is preferred over authenticity and integrity. It might be good to motivate unlinkability and its impact on the relay protocol or other protocols invoking relay protocol.-->
 
+
 - **Publisher-Message Unlinkability**:
 To address publisher-message unlinkability, one should remove any PII from the published message.
 As such, `11/WAKU2-RELAY` follows the `StrictNoSign` policy as described in [libp2p PubSub specs](https://github.com/libp2p/specs/tree/master/pubsub#message-signing).
 As the result of the `StrictNoSign` policy, `Message`s should be built without the  `from`, `signature` and `key` fields since each of these three fields individually counts as PII for the author of the message (one can link the creation of the message with libp2p peerId and thus indirectly with the IP address of the publisher). 
 Note that removing identifiable information from messages cannot lead to perfect unlinkability.
 The direct connections of a publisher might be able to figure out which `Message`s belong to that publisher by analyzing its traffic.
-The possibility of such inference may get higher when the `data` field is also not encrypted by the upper-level protocols. <!-- TODO: more investigation on traffic analysis attacks and their success probability-->
+The possibility of such inference may get higher when the `data` field is also not encrypted by the upper-level protocols. 
+<!-- TODO: more investigation on traffic analysis attacks and their success probability-->
+
 
 - **Subscriber-Topic Unlinkability:**
 To preserve subscriber-topic unlinkability, it is recommended by [`10/WAKU2`](../10/waku2.md) to use a single PubSub topic in the `11/WAKU2-RELAY` protocol.
@@ -159,13 +167,17 @@ At a high level, peers utilize a scoring function to locally score the behavior
 `11/WAKU2-RELAY` aims at enabling an advanced spam protection mechanism with economic disincentives by utilizing Rate Limiting Nullifiers.
 In a nutshell, peers must conform to a certain message publishing rate per a system-defined epoch, otherwise, they get financially penalized for exceeding the rate.
 More details on this new technique can be found in [`17/WAKU2-RLN-RELAY`](../17/rln-relay.md). 
-  <!-- TODO havn't checked if all the measures in libp2p GossipSub v1.1 are taken in the nim-libp2p as well, may need to audit the code --> 
+  
+<!-- TODO havn't checked if all the measures in libp2p GossipSub v1.1 are taken in the nim-libp2p as well, may need to audit the code -->
+ 
 
 - Providing **Unlinkability**, **Integrity** and  **Authenticity** simultaneously:
 Integrity and authenticity are typically addressed through digital signatures and Message Authentication Code (MAC) schemes, however, the usage of digital signatures (where each signature is bound to a particular peer) contradicts with the unlinkability requirement (messages signed under a certain signature key are verifiable by a verification key that is bound to a particular publisher).
 As such, integrity and authenticity are missing features in `11/WAKU2-RELAY` in the interest of unlinkability.
 In future work, advanced signature schemes like group signatures can be utilized to enable authenticity, integrity, and unlinkability simultaneously.
-In a group signature scheme, a member of a group can anonymously sign a message on behalf of the group as such the true signer is indistinguishable from other group members. <!-- TODO: shall I add a reference for group signatures?-->
+In a group signature scheme, a member of a group can anonymously sign a message on behalf of the group as such the true signer is indistinguishable from other group members. 
+<!-- TODO: shall I add a reference for group signatures?-->
+
 
 ## Copyright
 

waku/standards/core/rln-relay.md

@@ -25,8 +25,10 @@ Peers that violate the messaging rate are considered spammers and their message
 Spammers are also financially punished and removed from the system. 
 
 
+
 <!-- **Protocol identifier***: `/vac/waku/waku-rln-relay/2.0.0-alpha1` -->
 
+
 ## Motivation
 
 In open and anonymous p2p messaging networks, one big problem is spam resistance. 
@@ -50,7 +52,9 @@ The higher-level layers adopting `17/WAKU2-RLN-RELAY` MAY choose to enforce the
 
 ### Setup and Registration
 Peers subscribed to a specific `pubsubTopic` form a [RLN group](../../../../vac/32/rln-v1.md).
+
 <!-- link to the RLN group definition in the RLN RFC -->
+
 Peers MUST be registered to the RLN group to be able to publish messages.
 Registration is moderated through a smart contract deployed on the Ethereum blockchain. 
 Each peer has an [RLN key pair](../../../../vac/32/rln-v1.md) denoted by `sk`  and `pk`.
@@ -59,7 +63,9 @@ The state of the membership contract contains the list of registered members' pu
 For the registration, a peer creates a transaction that invokes the registration function of the contract via which registers its `pk` in the group. 
 The transaction also transfers some amount of ether to the contract to be staked. 
 This amount is denoted by `staked_fund` and is a system parameter.
-The peer who has the secret key `sk` associated with a registered `pk` would be able to withdraw a portion `reward_portion` of the staked fund by providing valid proof. <!-- a secure way to prove the possession of a pk is yet under discussion, maybe via commit and reveal -->
+The peer who has the secret key `sk` associated with a registered `pk` would be able to withdraw a portion `reward_portion` of the staked fund by providing valid proof. 
+<!-- a secure way to prove the possession of a pk is yet under discussion, maybe via commit and reveal -->
+
 `reward_portion` is also a system parameter.
 
 Note that  `sk` is initially only known to its owning peer however, it may get exposed to other peers in case the owner attempts spamming the system i.e., sending more than one message per `epoch`.
@@ -92,7 +98,9 @@ The `proof` field is a zero-knowledge proof signifying that:
 3. The `nullifier` is constructed correctly.
 For more details about the proof generation check [RLN](../../../../vac/32/rln-v1.md)
 The proof generation relies on the knowledge of two pieces of private information i.e., `sk` and `authPath`.
-The `authPath` is a subset of Merkle tree nodes by which a peer can prove the inclusion of its `pk` in the group. <!-- TODO refer to RLN RFC for authPath def -->
+The `authPath` is a subset of Merkle tree nodes by which a peer can prove the inclusion of its `pk` in the group. 
+<!-- TODO refer to RLN RFC for authPath def -->
+
 The proof generation also requires a set of public inputs which are: the Merkle tree root `merkle_root`, the current `epoch`, and the message for which the proof is going to be generated. 
 In `17/WAKU2-RLN-RELAY`, the message is the concatenation of `WakuMessage`'s  `payload` filed and its `contentTopic` i.e., `payload||contentTopic`. 
 
@@ -153,8 +161,10 @@ The `sk` then can be used to delete the spammer from the group and withdraw a po
 An overview of the routing procedure and slashing is provided in Figure 2.
 
 
+
 <!-- TODO: may consider [validator functions](https://github.com/libp2p/specs/tree/master/pubsub#topic-validation) or [extended validators](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#extended-validators) for the spam detection -->
 
+
 ![Figure 2: Publishing, Routing and Slashing workflow.](./17/images/rln-message-verification.png)
 
 -------
@@ -198,7 +208,9 @@ Below is the description of the fields of `RateLimitProof` and their types.
 | ----: | ----------- | ----------- |
 | `proof` | array of 256 bytes | the zkSNARK proof as explained in the [Publishing process](##Publishing) |
 | `merkle_root` | array of 32 bytes in little-endian order | the root of membership group Merkle tree at the time of publishing the message |
-| `share_x` and `share_y`| array of 32 bytes each | Shamir secret shares of the user's secret identity key `sk` . `share_x` is the Poseidon hash of the `WakuMessage`'s `payload` concatenated with its `contentTopic` . `share_y` is calculated using [Shamir secret sharing scheme](../../../../vac/32/rln-v1.md) | <!-- todo specify the poseidon hash setting -->
+| `share_x` and `share_y`| array of 32 bytes each | Shamir secret shares of the user's secret identity key `sk` . `share_x` is the Poseidon hash of the `WakuMessage`'s `payload` concatenated with its `contentTopic` . `share_y` is calculated using [Shamir secret sharing scheme](../../../../vac/32/rln-v1.md) | 
+<!-- todo specify the poseidon hash setting -->
+
 | `nullifier`  | array of 32 bytes | internal nullifier derived from `epoch` and peer's `sk` as explained in [RLN construct](../../../../vac/32/rln-v1.md)|
 
 

waku/standards/core/store.md

@@ -221,13 +221,21 @@ However, one can consider preserving anonymity through one of the following ways
   This can happen by the utilization of a proxy server or by using Tor. 
   Note that the current structure of historical requests does not embody any piece of PII, otherwise,
   such data fields must be treated carefully to achieve query anonymity. 
-  <!-- TODO: if nodes have to disclose their PeerIDs (e.g., for authentication purposes) when connecting to other nodes in the store protocol, then Tor does not preserve anonymity since it only helps in hiding the IP. So, the PeerId usage in switches must be investigated further. Depending on how PeerId is used, one may be able to link between a querying node and its queried topics despite hiding the IP address--> 
+  
+<!-- TODO: if nodes have to disclose their PeerIDs (e.g., for authentication purposes) when connecting to other nodes in the store protocol, then Tor does not preserve anonymity since it only helps in hiding the IP. So, the PeerId usage in switches must be investigated further. Depending on how PeerId is used, one may be able to link between a querying node and its queried topics despite hiding the IP address-->
+ 
   - By deploying secure 2-party computations in which the querying node obtains the historical messages of a certain topic,
   the queried node learns nothing about the query. 
   Examples of such 2PC protocols are secure one-way Private Set Intersections (PSI). 
-  <!-- TODO: add a reference for PSIs? --> <!-- TODO: more techniques to be included --> 
+  
+<!-- TODO: add a reference for PSIs? -->
+ 
+<!-- TODO: more techniques to be included -->
+ 
+
 <!-- TODO: Censorship resistant: this is about a node that hides the historical messages from other nodes. This attack is not included in the specs since it does not fit the passive adversarial model (the attacker needs to deviate from the store protocol).-->
 
+
 - **Robust and verifiable timestamps**: Messages timestamp is a way to show that the message existed prior to some point in time.
 However, the lack of timestamp verifiability can create room for a range of attacks,
 including injecting messages with invalid timestamps pointing to the far future.   

waku/standards/core/waku2.md

@@ -352,10 +352,14 @@ therefore the service obtained in the protocol is linkable to the beneficiary's
 For `13/WAKU2-STORE`, the queried node would be able to link the querying node's `PeerID` to its queried topics.
 Likewise, in the `12/WAKU2-FILTER`, a full node can link the light node's `PeerID`s to its content filter.
 
+
 <!-- TODO: to inspect the nim-libp2p codebase and figure out the exact use of PeerIDs in direct communication, it might be the case that the requester does not have to disclose its PeerID-->
 
+
+
 <!--TODO: might be good to add a figure visualizing the Waku protocol stack and the security features of each layer-->
 
+
 ## Appendix C: Implementation Notes
 
 ### Implementation Matrix