update lists table

22.md

@@ -13,9 +13,6 @@ It uses `kind:1111` with plaintext `.content` (no HTML, Markdown, or other forma
 Comments MUST point to the root scope using uppercase tag names (e.g. `K`, `E`, `A` or `I`)
 and MUST point to the parent item with lowercase ones (e.g. `k`, `e`, `a` or `i`).
 
-Comments MUST point to the authors when one is available (i.e. tagging a nostr event). `P` for the root scope
-and `p` for the author of the parent item.
-
 ```jsonc
 {
   kind: 1111,
@@ -26,16 +23,10 @@ and `p` for the author of the parent item.
     // the root item kind
     ["K", "<root kind>"],
 
-    // pubkey of the author of the root scope event
-    ["P", "<root-pubkey>", "relay-url-hint"],
-
     // parent item: event addresses, event ids, or i-tags.
     ["<a, e, i>", "<address, id or i-value>", "<relay or web page hint>", "<parent event's pubkey, if an e tag>"],
     // parent item kind
-    ["k", "<parent comment kind>"],
-
-    // parent item pubkey
-    ["p", "<parent-pubkey>", "relay-url-hint"]
+    ["k", "<parent comment kind>"]
   ]
   // other fields
 }
@@ -55,6 +46,11 @@ Their uppercase versions use the same type of values but relate to the root item
 ```
 
 `p` tags SHOULD be used when mentioning pubkeys in the `.content` with [NIP-21](21.md).
+If the parent item is an event, a `p` tag set to the parent event's author SHOULD be added.
+
+```json
+["p", "<pubkey>", "<relay-url>"]
+```
 
 ## Examples
 
@@ -69,17 +65,13 @@ A comment on a blog post looks like this:
     ["A", "30023:3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289:f9347ca7", "wss://example.relay"],
     // the root kind
     ["K", "30023"],
-    // author of root event
-    ["P", "3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289", "wss://example.relay"]
 
     // the parent event address (same as root for top-level comments)
     ["a", "30023:3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289:f9347ca7", "wss://example.relay"],
     // when the parent event is replaceable or addressable, also include an `e` tag referencing its id
     ["e", "5b4fc7fed15672fefe65d2426f67197b71ccc82aa0cc8a9e94f683eb78e07651", "wss://example.relay"],
     // the parent event kind
-    ["k", "30023"],
-    // author of the parent event
-    ["p", "3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289", "wss://example.relay"]
+    ["k", "30023"]
   ]
   // other fields
 }
@@ -96,14 +88,11 @@ A comment on a [NIP-94](94.md) file looks like this:
     ["E", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"],
     // the root kind
     ["K", "1063"],
-    // author of the root event
-    ["P", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"],
 
     // the parent event id (same as root for top-level comments)
     ["e", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"],
     // the parent kind
-    ["k", "1063"],
-    ["p", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"]
+    ["k", "1063"]
   ]
   // other fields
 }
@@ -120,13 +109,11 @@ A reply to a comment looks like this:
     ["E", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "fd913cd6fa9edb8405750cd02a8bbe16e158b8676c0e69fdc27436cc4a54cc9a"],
     // the root kind
     ["K", "1063"],
-    ["P", "fd913cd6fa9edb8405750cd02a8bbe16e158b8676c0e69fdc27436cc4a54cc9a"],
 
     // the parent event
     ["e", "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36", "wss://example.relay", "93ef2ebaaf9554661f33e79949007900bbc535d239a4c801c33a4d67d3e7f546"],
     // the parent kind
-    ["k", "1111"],
-    ["p", "93ef2ebaaf9554661f33e79949007900bbc535d239a4c801c33a4d67d3e7f546"]
+    ["k", "1111"]
   ]
   // other fields
 }
@@ -191,9 +178,7 @@ A reply to a podcast comment:
     ["e", "80c48d992a38f9c445b943a9c9f1010b396676013443765750431a9004bdac05", "wss://example.relay", "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111"],
     // the parent comment kind
     ["k", "1111"]
-    ["p", "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111"]
   ]
   // other fields
 }
 ```
-

23.md

@@ -6,7 +6,9 @@ Long-form Content
 
 `draft` `optional`
 
-This NIP defines `kind:30023` (an _addressable event_) for long-form text content, generally referred to as "articles" or "blog posts". `kind:30024` has the same structure as `kind:30023` and is used to save long form drafts.
+This NIP defines `kind:30023` (an _addressable event_) for long-form text content, generally referred to as "articles" or "blog posts".
+
+Deprecated: `kind:30024` was used for long-form drafts (self-encrypted nip04, same format as `kind:30023`). The preferred way of doing long-form drafts is to use [NIP-37](37.md) instead.
 
 "Social" clients that deal primarily with `kind:1` notes should not be expected to implement this NIP.
 

32.md

@@ -157,7 +157,7 @@ considered open for public use, and not proprietary. In other words, if there is
 namespace that fits your use case, use it even if it points to someone else's domain name.
 
 Vocabularies MAY choose to fully qualify all labels within a namespace (for example,
-`["l", "com.example.vocabulary:my-label"]`). This may be preferred when defining more
+`["l", "com.example.vocabulary:my-label"]`. This may be preferred when defining more
 formal vocabularies that should not be confused with another namespace when querying
 without an `L` tag. For these vocabularies, all labels SHOULD include the namespace
 (rather than mixing qualified and unqualified labels).
@@ -173,4 +173,4 @@ Appendix: Known Ontologies
 
 Below is a non-exhaustive list of ontologies currently in widespread use.
 
-- [social ontology categories](https://github.com/CLARIAH/awesome-humanities-ontologies)
+- [social.ontolo.categories](https://ontolo.social/)

37.md

@@ -30,6 +30,19 @@ A blanked `.content` means this draft has been deleted by a client but relays st
 
 Tags `e` and `a` identify one or more anchor events, such as parent events on replies.   
 
+## Checkpoints
+`kind:1234` defines checkpoints that belong to a parent `kind:31234` event. These can serve to provide a revision history of a parent event.
+
+```js
+{
+  "kind": 1234,
+  "tags": [
+    ["a", "31234:<pubkey>:<identifier>"]
+  ],
+  "content": nip44Encrypt(JSON.stringify(draft_event)),
+}
+```
+
 ## Relay List for Private Content
 
 Kind `10013` indicates the user's preferred relays to store private events like Drafts. The event MUST include a list of `relay` URLs in private tags. Private tags are JSON Stringified, NIP-44-encrypted to the signer's keys and placed inside the .content of the event.

44.md

@@ -8,11 +8,11 @@ Encrypted Payloads (Versioned)
 
 The NIP introduces a new data format for keypair-based encryption. This NIP is versioned
 to allow multiple algorithm choices to exist simultaneously. This format may be used for
-many things, but MUST be used in the context of a signed event as described in NIP-01.
+many things, but MUST be used in the context of a signed event as described in NIP 01.
 
 *Note*: this format DOES NOT define any `kind`s related to a new direct messaging standard,
 only the encryption required to define one. It SHOULD NOT be used as a drop-in replacement
-for NIP-04 payloads.
+for NIP 04 payloads.
 
 ## Versions
 
@@ -41,7 +41,7 @@ On its own, messages sent using this scheme have a number of important shortcomi
 - No post-compromise security: when a key is compromised, it is possible to decrypt all future conversations
 - No post-quantum security: a powerful quantum computer would be able to decrypt the messages
 - IP address leak: user IP may be seen by relays and all intermediaries between user and relay
-- Date leak: `created_at` is public, since it is a part of NIP-01 event
+- Date leak: `created_at` is public, since it is a part of NIP 01 event
 - Limited message size leak: padding only partially obscures true message length
 - No attachments: they are not supported
 
@@ -86,7 +86,7 @@ NIP-44 version 2 has the following design characteristics:
    - Content must be encoded from UTF-8 into byte array
    - Validate plaintext length. Minimum is 1 byte, maximum is 65535 bytes
    - Padding format is: `[plaintext_length: u16][plaintext][zero_bytes]`
-   - Padding algorithm is related to powers-of-two, with min padded msg size of 32 bytes
+   - Padding algorithm is related to powers-of-two, with min padded msg size of 32bytes
    - Plaintext length is encoded in big-endian as first 2 bytes of the padded blob
 5. Encrypt padded content
    - Use ChaCha20, with key and nonce from step 3
@@ -148,8 +148,8 @@ validation rules, refer to BIP-340.
   - `x[i:j]`, where `x` is a byte array and `i, j <= 0` returns a `(j - i)`-byte array with a copy of the
     `i`-th byte (inclusive) to the `j`-th byte (exclusive) of `x`.
 - Constants `c`:
-  - `min_plaintext_size` is 1. 1 byte msg is padded to 32 bytes.
-  - `max_plaintext_size` is 65535 (64kB - 1). It is padded to 65536 bytes.
+  - `min_plaintext_size` is 1. 1bytes msg is padded to 32bytes.
+  - `max_plaintext_size` is 65535 (64kB - 1). It is padded to 65536bytes.
 - Functions
   - `base64_encode(string)` and `base64_decode(bytes)` are Base64 ([RFC 4648](https://datatracker.ietf.org/doc/html/rfc4648), with padding)
   - `concat` refers to byte array concatenation

47.md

@@ -107,7 +107,7 @@ The content of notifications is encrypted with [NIP04](https://github.com/nostr-
 ## Nostr Wallet Connect URI
 **client** discovers **wallet service** by scanning a QR code, handling a deeplink or pasting in a URI.
 
-The **wallet service** generates this connection URI with protocol `nostr+walletconnect://` and base path its hex-encoded `pubkey` with the following query string parameters:
+The **wallet service** generates this connection URI with protocol `nostr+walletconnect://` and base path it's hex-encoded `pubkey` with the following query string parameters:
 
 - `relay` Required. URL of the relay where the **wallet service** is connected and will be listening for events. May be more than one.
 - `secret` Required. 32-byte randomly generated hex encoded string. The **client** MUST use this to sign events and encrypt payloads when communicating with the **wallet service**.
@@ -175,7 +175,7 @@ Request:
 Response:
 
 For every invoice in the request, a separate response event is sent. To differentiate between the responses, each
-response event contains a `d` tag with the id of the invoice it is responding to; if no id was given, then the
+response event contains a `d` tag with the id of the invoice it is responding to, if no id was given, then the
 payment hash of the invoice should be used.
 
 ```jsonc
@@ -247,7 +247,7 @@ Request:
 Response:
 
 For every keysend in the request, a separate response event is sent. To differentiate between the responses, each
-response event contains a `d` tag with the id of the keysend it is responding to; if no id was given, then the
+response event contains an `d` tag with the id of the keysend it is responding to, if no id was given, then the
 pubkey should be used.
 
 ```jsonc

51.md

@@ -30,6 +30,7 @@ For example, _mute list_ can contain the public keys of spammers and bad actors
 | Blocked relays    | 10006 | relays clients should never connect to                      | `"relay"` (relay URLs)                                                            |
 | Search relays     | 10007 | relays clients should use when performing search queries    | `"relay"` (relay URLs)                                                            |
 | Simple groups     | 10009 | [NIP-29](29.md) groups the user is in                       | `"group"` ([NIP-29](29.md) group id + relay URL + optional group name), `"r"` for each relay in use     |
+| Draft relays      | 10013 | (nip44-encrypted) [NIP-37](37.md) draft relays              | `"relay"` (relay URL)                                                             |
 | Interests         | 10015 | topics a user may be interested in and pointers             | `"t"` (hashtags) and `"a"` (kind:30015 interest set)                              |
 | Emojis            | 10030 | user preferred emojis and pointers to emoji sets            | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set)                  |
 | DM relays         | 10050 | Where to receive [NIP-17](17.md) direct messages            | `"relay"` (see [NIP-17](17.md))                                                   |
@@ -54,8 +55,7 @@ Aside from their main identifier, the `"d"` tag, sets can optionally have a `"ti
 | Kind mute sets | 30007 | mute pubkeys by kinds<br>`"d"` tag MUST be the kind string                                  | `"p"` (pubkeys)                                                                   |
 | Interest sets | 30015 | interest topics represented by a bunch of "hashtags"                                         | `"t"` (hashtags)                                                                  |
 | Emoji sets    | 30030 | categorized emoji groups                                                                     | `"emoji"` (see [NIP-30](30.md))                                                   |
-| Release artifact sets | 30063 | group of artifacts of a software release  | `"e"` (kind:1063 [file metadata](94.md) events), `"a"` (software application event) |
-| App curation sets | 30267 | references to multiple software applications  | `"a"` (software application event) |
+| Release artifact sets | 30063 | groups of files of a software release  | `"e"` (kind:1063 [file metadata](94.md) events), `"i"` (application identifier, typically reverse domain notation), `"version"`  |
 
 ### Deprecated standard lists
 
@@ -118,39 +118,22 @@ Some clients have used these lists in the past, but they should work on transiti
   "pubkey": "d6dc95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c",
   "created_at": 1695327657,
   "kind": 30063,
-  "content": "Release notes in markdown",
   "tags": [
-    ["d", "com.example.app@0.0.1"],
+    ["d", "ak8dy3v7"],
+    ["i", "com.example.app"],
+    ["version", "0.0.1"],
+    ["title", "Example App"],
+    ["image", "http://cdn.site/p/com.example.app/icon.png"],
     ["e", "d78ba0d5dce22bfff9db0a9e996c9ef27e2c91051de0c4e1da340e0326b4941e"], // Windows exe
     ["e", "f27e2c91051de0c4e1da0d5dce22bfff9db0a9340e0326b4941ed78bae996c9e"], // MacOS dmg
     ["e", "9d24ddfab95ba3ff7c03fbd07ad011fff245abea431fb4d3787c2d04aad02332"], // Linux AppImage
-    ["e", "340e0326b340e0326b4941ed78ba340e0326b4941ed78ba340e0326b49ed78ba"], // PWA
-    ["a", "32267:d6dc95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c:com.example.app"] // Reference to parent software application
+    ["e", "340e0326b340e0326b4941ed78ba340e0326b4941ed78ba340e0326b49ed78ba"] // PWA
   ],
   "content": "Example App is a decentralized marketplace for apps",
   "sig": "a9a4e2192eede77e6c9d24ddfab95ba3ff7c03fbd07ad011fff245abea431fb4d3787c2d04aad001cb039cb8de91d83ce30e9a94f82ac3c5a2372aa1294a96bd"
 }
 ```
 
-### An _app curation set_
-
-```jsonc
-{
-    "id": "d8037fa866eb5acd2159960b3ada7284172f7d687b5289cc72a96ca2b431b611",
-    "pubkey": "78ce6faa72264387284e647ba6938995735ec8c7d5c5a65737e55130f026307d",
-    "sig": "c1ce0a04521c020ae7485307cd86285530c1f778766a3fd594d662a73e7c28f307d7cd9a9ab642ae749fce62abbabb3a32facfe8d19a21fba551b60fae863d95",
-    "kind": 30267,
-    "created_at": 1729302793,
-    "content": "My nostr app selection",
-    "tags": [
-        ["d", "nostr"],
-        ["a", "32267:7579076d9aff0a4cfdefa7e2045f2486c7e5d8bc63bfc6b45397233e1bbfcb19:com.example.app1"],
-        ["a", "32267:045f2486c7e5d8bc63bfc6b45397233e1bbfcb197579076d9aff0a4cfdefa7e2:net.example.app2"],
-        ["a", "32267:264387284e647ba6938995735ec8c7d5c5a6f026307d78ce6faa725737e55130:pl.code.app3"]
-    ]
-}
-```
-
 ## Encryption process pseudocode
 
 ```scala

91.md

@@ -1,88 +0,0 @@
-NIP-91
-======
-
-Extension Negotiation
----------------------
-
-`draft` `optional`
-
-This NIP defines a method for clients to negotiate new features with relays.
-
-## Extension Names
-
-Each extension has a **extension name** that can uniquely identify the extension. Currently the following formats are recommended:
-- `nip/XX-<description>`: For extensions that are standardized in NIPs. Experimental extensions are recommended to have a unique description to not conflict.
-- `<namespace>/<extension>`: For extensions standardized by an independent body. The namespace should uniquely identify the standardizing body for this extension with a DNS name. (example: `example.com/example-extension`)
-
-Any extension name outside this list MUST NOT be used.
-
-## Extension Offers
-
-The relay may send a extension offer as a `EN-OFFER` message. The client SHOULD NOT send any messages relating to extension negotiation until it receives an `EN-OFFER`.
-```jsonc
-[
-  "EN-OFFER",
-  {
-    "example.com/example-extension": {...},
-    "nip-XX-example-extension": {...}
-  }
-]
-```
-
-The first entry MUST be an object, with the keys being extension names, and the values being objects. The format of the object is left to the specification of the specific extension.
-
-A extension offer can be sent multiple times in a connection, such as to update availability based off of their [NIP-42](./42.md) authentication status.
-
-Clients SHOULD be able to handle extension offers being able to be withdrawn, and should treat them as if it was a `EN-SHUTDOWN` if they were in use. 
-
-Certain extensions, such as extensions to REQs, may not need negotiation. This is up to the extension specification.
-
-## Extension Requests
-
-A client may request a extension offered by the relay be enabled with the `EN-REQUEST` message:
-```jsonc
-[
-  "EN-REQUEST",
-  "example.com/example-extension",
-  {...}
-]
-```
-
-The first entry MUST be the extension name, and the second entry MUST be a extension-dependent object for the extension enable request.
-
-The relay SHOULD respond with a `EN-OK` or `EN-ERROR` message:
-```jsonc
-[
-  "EN-OK",
-  "example.com/example-extension",
-  {...}
-]
-```
-```jsonc
-[
-  "EN-ERROR",
-  "example.com/example-extension",
-  "improper extension request data"
-]
-```
-
-In both messages, the first entry MUST be the extension name. The second entry depends on the type:
-- `EN-OK`: Response data for the extension negotiation. After this message, the extension can be used.
-- `EN-ERROR`: An error message.
-
-An error message SHOULD start with a single-word prefix, followed by a colon (:) and space character, and a human readable message. The following types are defined:
-- `error`: An internal error has occurred in the relay.
-- `not-offered`: The extension was not offered. This may happen due to a `EN-REQUEST` being sent at the same time as a new `EN-OFFER`.
-- `bad-data`: The client has sent improper extension negotiation data.
-
-## Extension Cancel
-
-The relay or client may stop the usage of the extension any time with a `EN-CANCEL` message:
-```jsonc
-[
-  "EN-CANCEL",
-  "example.com/example-extension"
-]
-```
-
-After this message, the sending party will no longer accept and send new extension messages, and the receiver should not continue attempting to use the extension functionality.

94.md

@@ -10,7 +10,7 @@ The purpose of this NIP is to allow an organization and classification of shared
 
 ## Event format
 
-This NIP specifies the use of the `1063` event kind, having in `content` a description of the file content, and a list of tags described below:
+This NIP specifies the use of the `1063` event type, having in `content` a description of the file content, and a list of tags described below:
 
 * `url` the url to download the file
 * `m` a string indicating the data type of the file. The [MIME types](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types) format must be used, and they should be lowercase.

README.md

@@ -59,10 +59,10 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-39: External Identities in Profiles](39.md)
 - [NIP-40: Expiration Timestamp](40.md)
 - [NIP-42: Authentication of clients to relays](42.md)
-- [NIP-44: Encrypted Payloads (Versioned)](44.md)
+- [NIP-44: Versioned Encryption](44.md)
 - [NIP-45: Counting results](45.md)
-- [NIP-46: Nostr Remote Signing](46.md)
-- [NIP-47: Nostr Wallet Connect](47.md)
+- [NIP-46: Nostr Connect](46.md)
+- [NIP-47: Wallet Connect](47.md)
 - [NIP-48: Proxy Tags](48.md)
 - [NIP-49: Private Key Encryption](49.md)
 - [NIP-50: Search Capability](50.md)
@@ -130,6 +130,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `818`         | Merge Requests                  | [54](54.md)                            |
 | `1021`        | Bid                             | [15](15.md)                            |
 | `1022`        | Bid confirmation                | [15](15.md)                            |
+| `1234`        | Draft Checkpoint                | [37](37.md)                            |
 | `1040`        | OpenTimestamps                  | [03](03.md)                            |
 | `1059`        | Gift Wrap                       | [59](59.md)                            |
 | `1063`        | File Metadata                   | [94](94.md)                            |
@@ -170,7 +171,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `10006`       | Blocked relays list             | [51](51.md)                            |
 | `10007`       | Search relays list              | [51](51.md)                            |
 | `10009`       | User groups                     | [51](51.md), [29](29.md)               |
-| `10013`       | Draft relays                    | [37](37.md)                            |
 | `10015`       | Interests list                  | [51](51.md)                            |
 | `10019`       | Nutzap Mint Recommendation      | [61](61.md)                            |
 | `10030`       | User emoji list                 | [51](51.md)                            |
@@ -285,8 +285,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `l`               | label, label namespace               | --                              | [32](32.md)                                        |
 | `L`               | label namespace                      | --                              | [32](32.md)                                        |
 | `m`               | MIME type                            | --                              | [94](94.md)                                        |
-| `p`               | pubkey (hex)                         | relay URL, petname              | [01](01.md), [02](02.md), [22](22.md)              |
-| `P`               | pubkey (hex)                         | --                              | [22](22.md), [57](57.md)                           |
+| `p`               | pubkey (hex)                         | relay URL, petname              | [01](01.md), [02](02.md)                           |
+| `P`               | pubkey (hex)                         | --                              | [57](57.md)                                        |
 | `q`               | event id (hex)                       | relay URL, pubkey (hex)         | [18](18.md)                                        |
 | `r`               | a reference (URL, etc)               | --                              | [24](24.md), [25](25.md)                           |
 | `r`               | relay url                            | marker                          | [65](65.md)                                        |
@@ -344,9 +344,9 @@ Please update these lists when proposing new NIPs.
 
 ## Is this repository a centralizing factor?
 
-To promote interoperability, we need standards that everybody can follow, and we need them to define a **single way of doing each thing** without ever hurting **backwards-compatibility**, and for that purpose there is no way around getting everybody to agree on the same thing and keep a centralized index of these standards. However the fact that such an index exists doesn't hurt the decentralization of Nostr. _At any point the central index can be challenged if it is failing to fulfill the needs of the protocol_ and it can migrate to other places and be maintained by other people.
+To promote interoperability, we standards that everybody can follow, and we need them to define a **single way of doing each thing** without ever hurting **backwards-compatibility**, and for that purpose there is no way around getting everybody to agree on the same thing and keep a centralized index of these standards. However the fact that such index exists doesn't hurt the decentralization of Nostr. _At any point the central index can be challenged if it is failing to fulfill the needs of the protocol_ and it can migrate to other places and be maintained by other people.
 
-It can even fork into multiple versions, and then some clients would go one way, others would go another way, and some clients would adhere to both competing standards. This would hurt the simplicity, openness and interoperability of Nostr a little, but everything would still work in the short term.
+It can even fork into multiple and then some clients would go one way, others would go another way, and some clients would adhere to both competing standards. This would hurt the simplicity, openness and interoperability of Nostr a little, but everything would still work in the short term.
 
 There is a list of notable Nostr software developers who have commit access to this repository, but that exists mostly for practical reasons, as by the nature of the thing we're dealing with the repository owner can revoke membership and rewrite history as they want -- and if these actions are unjustified or perceived as bad or evil the community must react.