fix grammar and typos

04.md

@@ -50,4 +50,4 @@ This standard does not go anywhere near what is considered the state-of-the-art
 
 ## Client Implementation Warning
 
-Client's *should not* search and replace public key or note references from the `.content`. If processed like a regular text note (where `@npub...` is replaced with `#[0]` with a `["p", "..."]` tag) the tags are leaked and the mentioned user will receive the message in their inbox.
+Clients *should not* search and replace public key or note references from the `.content`. If processed like a regular text note (where `@npub...` is replaced with `#[0]` with a `["p", "..."]` tag) the tags are leaked and the mentioned user will receive the message in their inbox.

05.md

@@ -64,7 +64,7 @@ For example, if after finding that `bob@bob.com` has the public key `abc...def`,
 
 ### Public keys must be in hex format
 
-Keys must be returned in hex format. Keys in NIP-19 `npub` format are are only meant to be used for display in client UIs, not in this NIP.
+Keys must be returned in hex format. Keys in NIP-19 `npub` format are only meant to be used for display in client UIs, not in this NIP.
 
 ### User Discovery implementation suggestion
 

11.md

@@ -154,7 +154,7 @@ all, and preferably an error will be provided when those are received.
 `retention` is a list of specifications: each will apply to either all kinds, or 
 a subset of kinds. Ranges may be specified for the kind field as a tuple of inclusive
 start and end values. Events of indicated kind (or all) are then limited to a `count`
-and or time period.
+and/or time period.
 
 It is possible to effectively blacklist Nostr-based protocols that rely on
 a specific `kind` number, by giving a retention time of zero for those `kind` values.
@@ -175,8 +175,8 @@ It is not possible to describe the limitations of each country's laws
 and policies which themselves are typically vague and constantly shifting.
 
 Therefore, this field allows the relay operator to indicate which
-country's' laws might end up being enforced on them, and then
-indirectly on their users's content.
+countries' laws might end up being enforced on them, and then
+indirectly on their users' content.
 
 Users should be able to avoid relays in countries they don't like,
 and/or select relays in more favourable zones. Exposing this
@@ -220,7 +220,7 @@ To support this goal, relays MAY specify some of the following values.
   the major languages spoken on the relay.
 
 - `tags` is a list of limitations on the topics to be discussed.
-  For example `sfw-only` indicates hat only "Safe For Work" content
+  For example `sfw-only` indicates that only "Safe For Work" content
   is encouraged on this relay. This relies on assumptions of what the
   "work" "community" feels "safe" talking about. In time, a common
   set of tags may emerge that allow users to find relays that suit

13.md

@@ -90,4 +90,4 @@ $ echo '["REQ", "subid", {"ids": ["000000000"]}]'  | websocat wss://some-relay.c
 Delegated Proof of Work
 -----------------------
 
-Since the `NIP-01` note id does not commit to any signature, PoW can be outsourced to PoW providers, perhaps for a fee. This provides a way for clients to get their messages out to PoW-restricted relays without having to do any work themselves, which is useful for energy constrained devices like on mobile
+Since the `NIP-01` note id does not commit to any signature, PoW can be outsourced to PoW providers, perhaps for a fee. This provides a way for clients to get their messages out to PoW-restricted relays without having to do any work themselves, which is useful for energy-constrained devices like mobile phones.

22.md

@@ -22,7 +22,7 @@ This NIP formalizes restrictions on event timestamps as accepted by a relay and
 
 The event `created_at` field is just a unix timestamp and can be set to a time in the past or future. Relays accept and share events dated to 20 years ago or 50,000 years in the future. This NIP aims to define a way for relays that do not want to store events with *any* timestamp to set their own restrictions.
 
-[Replaceable events](16.md#replaceable-events) can behave rather unexpected if the user wrote them - or tried to write them - with a wrong system clock. Persisting an update with a backdated system now would result in the update not getting persisted without a notification and if they did the last update with a forward dated system, they will again fail to do another update with the now correct time.
+[Replaceable events](16.md#replaceable-events) can behave rather unexpectedly if the user wrote them - or tried to write them - with a wrong system clock. Persisting an update with a backdated system now would result in the update not getting persisted without a notification and if they did the last update with a forward dated system, they will again fail to do another update with the now correct time.
 
 A wide adoption of this NIP could create a better user experience as it would decrease the amount of events that appear wildly out of order or even from impossible dates in the distant past or future.
 

25.md

@@ -16,7 +16,7 @@ A reaction with `content` set to `-` SHOULD be interpreted as a "dislike" or
 "downvote". It SHOULD NOT be counted as a "like", and MAY be displayed as a
 downvote or dislike on a post. A client MAY also choose to tally likes against
 dislikes in a reddit-like system of upvotes and downvotes, or display them as
-separate tallys.
+separate tallies.
 
 The `content` MAY be an emoji, in this case it MAY be interpreted as a "like" or "dislike",
 or the client MAY display this emoji reaction on the post.

40.md

@@ -43,7 +43,7 @@ Clients SHOULD ignore events that have expired.
 Relay Behavior
 --------------
 
-Relays MAY NOT delete an expired message immediately on expiration and MAY persist them indefinitely.  
+Relays MAY NOT delete expired messages immediately on expiration and MAY persist them indefinitely.  
 Relays SHOULD NOT send expired events to clients, even if they are stored.  
 Relays SHOULD drop any events that are published to them if they are expired.  
 An expiration timestamp does not affect storage of ephemeral events.

45.md

@@ -6,7 +6,7 @@ Event Counts
 
 `draft` `optional` `author:staab`
 
-Relays may support the `COUNT` verb, which provide a mechanism for obtaining event counts.
+Relays may support the `COUNT` verb, which provides a mechanism for obtaining event counts.
 
 ## Motivation
 

51.md

@@ -10,7 +10,7 @@ A "list" event is defined as having a list of public and/or private tags. Public
 
 If a list type should only be defined once per user (like the 'Mute' list), the list type's events should follow the specification for [NIP-16 - Replaceable Events](16.md). These lists may be referred to as 'replaceable lists'.
 
-Otherwise the list type's events should follow the specification for [NIP-33 - Parameterized Replaceable Events](33.md), where the list name will be used as the 'd' parameter. These lists may be referred to as 'parameterized replaceable lists'.
+Otherwise, the list type's events should follow the specification for [NIP-33 - Parameterized Replaceable Events](33.md), where the list name will be used as the 'd' parameter. These lists may be referred to as 'parameterized replaceable lists'.
 
 ## Replaceable List Event Example
 

78.md

@@ -8,7 +8,7 @@ Arbitrary custom app data
 
 The goal of this NIP is to enable [remoteStorage](https://remotestorage.io/)-like capabilities for custom applications that do not care about interoperability.
 
-Even though interoperability is great, some apps do not want or do not need interoperability, and it that wouldn't make sense for them. Yet Nostr can still serve as a generalized data storage for these apps in a "bring your own database" way, for example: a user would open an app and somehow input their preferred relay for storage, which would then enable these apps to store application-specific data there.
+Even though interoperability is great, some apps do not want or do not need interoperability, and it wouldn't make sense for them. Yet Nostr can still serve as a generalized data storage for these apps in a "bring your own database" way, for example: a user would open an app and somehow input their preferred relay for storage, which would then enable these apps to store application-specific data there.
 
 ## Nostr event