NIP-59: Fix heading levels (#2023)

59.md

@@ -13,7 +13,7 @@ This NIP *does not* define any messaging protocol. Applications of this NIP shou
 
 This NIP relies on [NIP-44](./44.md)'s versioned encryption algorithms.
 
-# Overview
+## Overview
 
 This protocol uses three main concepts to protect the transmission of a target event: `rumor`s, `seal`s, and `gift wrap`s.
 
@@ -29,13 +29,13 @@ This allows the isolation of concerns across layers:
 - A seal identifies the author without revealing the content or the recipient.
 - A gift wrap can add metadata (recipient, tags, a different author) without revealing the true author.
 
-# Protocol Description
+## Protocol Description
 
-## 1. The Rumor Event Kind
+### 1. The Rumor Event Kind
 
 A `rumor` is the same thing as an unsigned event. Any event kind can be made a `rumor` by removing the signature.
 
-## 2. The Seal Event Kind
+### 2. The Seal Event Kind
 
 A `seal` is a `kind:13` event that wraps a `rumor` with the sender's regular key. The `seal` is **always** encrypted
 to a receiver's pubkey but there is no `p` tag pointing to the receiver. There is no way to know who the rumor is for
@@ -55,7 +55,7 @@ without the receiver's or the sender's private key. The only public information
 
 Tags MUST always be empty in a `kind:13`. The inner event MUST always be unsigned.
 
-## 3. Gift Wrap Event Kind
+### 3. Gift Wrap Event Kind
 
 A `gift wrap` event is a `kind:1059` event that wraps any other event. `tags` SHOULD include any information
 needed to route the event to its intended recipient, including the recipient's `p` tag or [NIP-13](13.md) proof of work.
@@ -72,12 +72,12 @@ needed to route the event to its intended recipient, including the recipient's `
 }
 ```
 
-# Encrypting Payloads
+## Encrypting Payloads
 
 Encryption is done following [NIP-44](44.md) on the JSON-encoded event. Place the encryption payload in the `.content`
 of the wrapper event (either a `seal` or a `gift wrap`).
 
-# Other Considerations
+## Other Considerations
 
 If a `rumor` is intended for more than one party, or if the author wants to retain an encrypted copy, a single
 `rumor` may be wrapped and addressed for each recipient individually.
@@ -97,7 +97,7 @@ To protect recipient metadata, relays SHOULD only serve `kind 1059` events inten
 When possible, clients should only send wrapped events to `read` relays for the recipient that implement
 AUTH, and refuse to serve wrapped events to non-recipients.
 
-# An Example
+## An Example
 
 Let's send a wrapped `kind 1` message between two parties asking "Are you going to the party tonight?"
 
@@ -108,7 +108,7 @@ Let's send a wrapped `kind 1` message between two parties asking "Are you going
 Note that this messaging protocol should not be used in practice, this is just an example. Refer to other
 NIPs for concrete messaging protocols that depend on gift wraps.
 
-## 1. Create an event
+### 1. Create an event
 
 Create a `kind 1` event with the message, the receivers, and any other tags you want, signed by the author.
 Do not sign the event.
@@ -124,7 +124,7 @@ Do not sign the event.
 }
 ```
 
-## 2. Seal the rumor
+### 2. Seal the rumor
 
 Encrypt the JSON-encoded `rumor` with a conversation key derived using the author's private key and
 the recipient's public key. Place the result in the `content` field of a `kind 13` `seal` event. Sign
@@ -142,7 +142,7 @@ it with the author's key.
 }
 ```
 
-## 3. Wrap the seal
+### 3. Wrap the seal
 
 Encrypt the JSON-encoded `kind 13` event with your ephemeral, single-use random key. Place the result
 in the `content` field of a `kind 1059`. Add a single `p` tag containing the recipient's public key.
@@ -160,13 +160,13 @@ Sign the `gift wrap` using the random key generated in the previous step.
 }
 ```
 
-## 4. Broadcast Selectively
+### 4. Broadcast Selectively
 
 Broadcast the `kind 1059` event to the recipient's relays only. Delete all the other events.
 
-# Code Samples
+## Code Samples
 
-## JavaScript
+### JavaScript
 
 ```javascript
 import {bytesToHex} from "@noble/hashes/utils"