Update 52.md

Spelling corrections.

52.md

@@ -16,7 +16,7 @@ It reserves two event kinds (30001, 1001) for immediate use.
 - `30001 - issue claim`
 - `1001 - refresh claim request`
 
-A issue claim event records what one user attests is true about another user. 
+An issue claim event records what one user attests is true about another user. 
 
 ## Kind 30001: Issue Claim
 
@@ -39,7 +39,7 @@ Sent by a user acting as an issuer, submitting a claim about another user, the c
 }
 ```
 
-`"d" tag` is required as event is treated as a parameterized replaceable event [NIP-33](https://github.com/nostr-protocol/nips/blob/master/33.md). Issuers issuing more than one type of claim will need to append a claim type identifier to the subject's pubkey hex to prevent overwrites.
+`"d" tag` is required as the event is treated as a parameterized replaceable event [NIP-33](https://github.com/nostr-protocol/nips/blob/master/33.md). Issuers issuing more than one type of claim will need to append a claim type identifier to the subject's pubkey hex to prevent overwrites.
 
 The p tag MUST contain exactly one entry, the pubkey of the claim's subject.
 
@@ -48,7 +48,7 @@ Self-issued claims (issuer is the subject) is specifically allowed.
 
 ## Kind 1001: Refresh Claim Request
 
-A claim may change over time. This event allows a user to request the issuer submits an updated issue claim event for the same subject and claim_type.
+A claim may change over time. This event allows a user to request the issuer submit an updated issue claim event for the same subject and claim_type.
 
 ```json
 {
@@ -70,7 +70,7 @@ A relay MAY choose to ignore this event if original event does not contain "is_m
 Design Notes
 ------------
 
-### Why treat issue claim events as parameterized replaceable event (NIP-33)?
+### Why treat issue claim events as a parameterized replaceable event (NIP-33)?
 
 The intended use for claims is to enable clients to display the latest claim information for a user and for relays to take different actions on an incoming event based on claims.  Treating issue claim events as parameterized replaceable events allows any consumer to get the only latest issue claim event for a user by setting a subscription filter specifying the kind, issuer, the subject as the p tag, and a limit of 1.
 
@@ -79,19 +79,19 @@ The intended use for claims is to enable clients to display the latest claim inf
 It's optional, and not technically necessary, but is a practical consideration. 
 
 - If adhered to, prevents clients from sending refresh claim request events that are useless, reducing "garbage" events relays have to handle
-- Alows users acting as issuers to periodically send new issue claim events, updating claims for individual users "on demand" only when necessary
+- Allows users acting as issuers to periodically send new issue claim events, updating claims for individual users "on demand" only when necessary
 
 ### App-specific data tags instead of content?
 
 I considered allowing claim data to be stored in the event tags after reading this [discussion of another NIP](https://github.com/nostr-protocol/nostr/issues/20#issuecomment-913027389). 
-Simple data directly in event tags instead of content may be useful for owners of relays to communicate with each other about pubkeys acting badly (from purely a network point of view). Given throughput and stability is important fo relays, reading single values from an event's tags seems faster and safer than parsing a object from content.
+Simple data directly in event tags instead of content may be useful for owners of relays to communicate with each other about pubkeys acting badly (from purely a network point of view). Given throughput and stability is important for relays, reading single values from an event's tags seems faster and safer than parsing an object from content.
 Still unsure if this should be allowed.
 
 Motivation
 ----------
-As a protocol, Nostr is application agnostic, easy to implement, and censorhip resistant. While current apps built on Nostr focus on messaging (Twitter, Telegram, etc.) I envision Nostr being the underlying protocol of other social media apps as well (Instagram, LinkedIn, Tinder, etc.). 
+As a protocol, Nostr is application agnostic, easy to implement, and censorship resistant. While current apps built on Nostr focus on messaging (Twitter, Telegram, etc.) I envision Nostr being the underlying protocol of other social media apps as well (Instagram, LinkedIn, Tinder, etc.). 
 
-Apps that create new relationships between strangers need more user profile information that Nostr currently supports, but how do we do that will still being application agnostic, easy to implement, and censorship resistant?
+Apps that create new relationships between strangers need more user profile information that Nostr currently supports, but how do we do that while still being application agnostic, easy to implement, and censorship resistant?
 
 This NIP attempts to accomplish this by:
 - re-using existing structures from standard Nostr events as much possible
@@ -106,20 +106,20 @@ Potential Use Cases
 
 ### Profile Metadata
 
-A common use case today is linking a Notr pubkey with other social accounts (e.g. [nostr.directory](https://github.com/pseudozach/nostr.directory)). Apps can act as issuers, sending a Issue Claim event with other account specific claim data (Twitter handle, number of followers, proof link to Twitter message with Nostr pubkey, etc). Clients subscribed to Issue Claim events can then display other social account links provided by multiple issuers in a user's profile page. Ideally, issuers would use the same claim_type when the properties are the same, so client code doesn't have to be re-written.
+A common use case today is linking a Nostr pubkey with other social accounts (e.g. [nostr.directory](https://github.com/pseudozach/nostr.directory)). Apps can act as issuers, sending an Issue Claim event with other account specific claim data (Twitter handle, number of followers, proof link to Twitter message with Nostr pubkey, etc). Clients subscribed to Issue Claim events can then display other social account links provided by multiple issuers in a user's profile page. Ideally, issuers would use the same claim_type when the properties are the same, so client code doesn't have to be re-written.
 
 ### Community Pins / Badges
 
-Because any user can act as a issuer, this NIP makes it easy for a community manager to reward their members with pins / badges. For example, the owner of the Damus client could issue a claim with a badge to their users who have made a donation.
+Because any user can act as an issuer, this NIP makes it easy for a community manager to reward their members with pins / badges. For example, the owner of the Damus client could issue a claim with a badge to their users who have made a donation.
 
 ### Pukey Behavior
 
-While claims can be associated with the owner of the pubkey, claims can be made against the pubkey itself based on its usage. The first use case that comes to mind is the owner of a relay communicating that a pubkey is actly badly, allowing other relay others to take appropriate actions on that pubkey's events. 
+While claims can be associated with the owner of the pubkey, claims can be made against the pubkey itself based on its usage. The first use case that comes to mind is the owner of a relay communicating that a pubkey is acting badly, allowing other relay others to take appropriate actions on that pubkey's events. 
 
 About Privacy
 -------------
 
-While additional profile information is needed for apps that create new relationships between stranger, as soon as we start associating information with a person via their pubkey, there are privacy concerns. 
+While additional profile information is needed for apps that create new relationships between strangers, as soon as we start associating information with a person via their pubkey, there are privacy concerns. 
 
 - What happens when an issuer makes a claim about me that is untrue?
 - What happens when an issuer makes a claim about me that is true, but I don't want public?
@@ -127,16 +127,16 @@ While additional profile information is needed for apps that create new relation
 
 ### Untrue Claims
 
-This NIP uses the term "claim" instead of "credential" or "attribute" to emphasize that the issuer is making a claim, which can be true or untrue. In an censorship resistant application, any person can make any claim about someone else, without their permission, regardless of if it is as a regular Nostr message or as a issue claim event. The issue for this NIP is, does the channel incorrectly convey legitimacy to the claims, or does the display of an issued claim on a client's profile page convey more legitimacy than a message? It probably does.
+This NIP uses the term "claim" instead of "credential" or "attribute" to emphasize that the issuer is making a claim, which can be true or untrue. In an censorship resistant application, any person can make any claim about someone else, without their permission, regardless of if it is as a regular Nostr message or as an issue claim event. The issue for this NIP is, does the channel incorrectly convey legitimacy to the claims, or does the display of an issued claim on a client's profile page convey more legitimacy than a message? It probably does.
 
-An immediate solution is to blacklist that issuer's pubkey, a configuration setting that already exists in some Notr relays. An alternate solution is for the wrong users to sent their own Issue Claim event against the pukey of the issuer, and use heuristics to automatically blacklist or hide event from bad issuers.
+An immediate solution is to blacklist that issuer's pubkey, a configuration setting that already exists in some Notr relays. An alternate solution is for the wronged users to send their own Issue Claim event against the pukey of the issuer, and use heuristics to automatically blacklist or hide events from bad issuers.
 
 ### True Claims that Shouldn't be Public
 
-If an issuer is acting in good faith, once informed, the issue claim event can be deleted [NIP-09](https://github.com/nostr-protocol/nips/blob/master/09.md). However, the same issue exists as Tweets that are taken down, there is no guarantee that it hasn't already been copied, or in Nostr's case, that a relay will respect the deletion event. A client may have to verify the relay properly supports event deletion before sending a issue claim event to that relay.
+If an issuer is acting in good faith, once informed, the issue claim event can be deleted [NIP-09](https://github.com/nostr-protocol/nips/blob/master/09.md). However, the same issue exists as Tweets that are taken down, there is no guarantee that it hasn't already been copied, or in Nostr's case, that a relay will respect the deletion event. A client may have to verify the relay properly supports event deletion before sending an issue claim event to that relay.
 
 ### Correlation of Identity
-Doxing is an issue. If claims against my pubkey include membership in "Women in Tech", "Atlantic Falcons Fan", and "Austism Support Network", something searching for my real identity knows to look to a woman in Atlanta, likely working for one of the thirteen big tech firms in Atlanta, likely in a photo with wearing Falcons merch, and has an autistic child. That's dangerous.
+Doxing is an issue. If claims against my pubkey include membership in "Women in Tech", "Atlanta Falcons Fan", and "Autism Support Network", something searching for my real identity knows to look to a woman in Atlanta, likely working for one of the thirteen big tech firms in Atlanta, likely in a photo with wearing Falcons merch, and has an autistic child. That's dangerous.
 
 It takes user education, but one nice thing about Nostr though, it's trivial for a person to create multiple pubkeys, and no single login / wallet. Claims about the same person, but spread across multiple unrelated pubkeys greatly reduces the risk of doxing.