fix: fix build errors

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