use jsonc in some places.

01.md

@@ -14,7 +14,7 @@ Each user has a keypair. Signatures, public key, and encodings are done accordin
 
 The only object type that exists is the `event`, which has the following format on the wire:
 
-```json
+```jsonc
 {
   "id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>,
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
@@ -22,7 +22,7 @@ The only object type that exists is the `event`, which has the following format
   "kind": <integer between 0 and 65535>,
   "tags": [
     [<arbitrary string>...],
-    ...
+    // ...
   ],
   "content": <arbitrary string>,
   "sig": <64-bytes lowercase hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
@@ -58,17 +58,16 @@ To prevent implementation differences from creating a different event ID for the
 
 Each tag is an array of strings of arbitrary size, with some conventions around them. Take a look at the example below:
 
-```json
+```jsonc
 {
-  ...,
   "tags": [
     ["e", "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36", "wss://nostr.example.com"],
     ["p", "f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca"],
     ["a", "30023:f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca:abcd", "wss://nostr.example.com"],
     ["alt", "reply"],
-    ...
+    // ...
   ],
-  ...
+  // ...
 }
 ```
 

52.md

@@ -38,7 +38,7 @@ The list of tags are as follows:
 The following tags are deprecated:
 * `name` name of the calendar event. Use only if `title` is not available.
 
-```json
+```jsonc
 {
   "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
@@ -99,7 +99,7 @@ The list of tags are as follows:
 The following tags are deprecated:
 * `name` name of the calendar event. Use only if `title` is not available.
 
-```json
+```jsonc
 {
   "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,

72.md

@@ -12,7 +12,7 @@ The goal of this NIP is to create moderator-approved public communities around a
 
 `kind:34550` SHOULD include any field that helps define the community and the set of moderators. `relay` tags MAY be used to describe the preferred relay to download requests and approvals.
 
-```json
+```jsonc
 {
   "created_at": <Unix timestamp in seconds>,
   "kind": 34550,
@@ -42,14 +42,14 @@ The goal of this NIP is to create moderator-approved public communities around a
 
 Any Nostr event can be submitted to a community by anyone for approval. Clients MUST add the community's `a` tag to the new post event in order to be presented for the moderator's approval.
 
-```json
+```jsonc
 {
   "kind": 1,
   "tags": [
     ["a", "34550:<community event author pubkey>:<community-d-identifier>", "<optional-relay-url>"],
   ],
   "content": "hello world",
-  ...
+  // ...
 }
 ```
 
@@ -59,7 +59,7 @@ Community management clients MAY filter all mentions to a given `kind:34550` eve
 
 The post-approval event MUST include `a` tags of the communities the moderator is posting into (one or more), the `e` tag of the post and `p` tag of the author of the post (for approval notifications). The event SHOULD also include the stringified `post request` event inside the `.content` ([NIP-18-style](18.md)) and a `k` tag with the original post's event kind to allow filtering of approved posts by kind.
 
-```json
+```jsonc
 {
   "pubkey": "<32-bytes lowercase hex-encoded public key of the event creator>",
   "kind": 4550,
@@ -70,7 +70,7 @@ The post-approval event MUST include `a` tags of the communities the moderator i
     ["k", "<post-request-kind>"]
   ],
   "content": "<the full approved event, JSON-encoded>",
-  ...
+  // ...
 }
 ```