Revert "rename "parameterized replaceable event" to "addressable event""

01.md

@@ -78,8 +78,8 @@ This NIP defines 3 standard tags that can be used across all event kinds with th
 - The `e` tag, used to refer to an event: `["e", <32-bytes lowercase hex of the id of another event>, <recommended relay URL, optional>]`
 - The `p` tag, used to refer to another user: `["p", <32-bytes lowercase hex of a pubkey>, <recommended relay URL, optional>]`
 - The `a` tag, used to refer to a (maybe parameterized) replaceable event
-    - for an addressable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]`
-    - for a normal replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:, <recommended relay URL, optional>]`
+    - for a parameterized replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]`
+    - for a non-parameterized replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:, <recommended relay URL, optional>]`
 
 As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": ["5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"]}` filter.
 

15.md

@@ -301,7 +301,7 @@ This event leverages naddr to enable comprehensive customization and sharing of
 Bids are simply events of kind `1021` with a `content` field specifying the amount, in the currency of the auction. Bids must reference an auction.
 
 > [!NOTE]
-> Auctions can be edited as many times as desired (they are "addressable events") by the author - even after the start_date, but they cannot be edited after they have received the first bid! This is enforced by the fact that bids reference the event ID of the auction (rather than the product UUID), which changes with every new version of the auctioned product. So a bid is always attached to one "version". Editing the auction after a bid would result in the new product losing the bid!
+> Auctions can be edited as many times as desired (they are "parameterized replaceable events") by the author - even after the start_date, but they cannot be edited after they have received the first bid! This is enforced by the fact that bids reference the event ID of the auction (rather than the product UUID), which changes with every new version of the auctioned product. So a bid is always attached to one "version". Editing the auction after a bid would result in the new product losing the bid!
 
 ### Event `1022`: Bid confirmation
 

19.md

@@ -43,7 +43,7 @@ These possible standardized `TLV` types are indicated here:
   - depends on the bech32 prefix:
     - for `nprofile` it will be the 32 bytes of the profile public key
     - for `nevent` it will be the 32 bytes of the event id
-    - for `naddr`, it is the identifier (the `"d"` tag) of the event being referenced. For normal replaceable events use an empty string.
+    - for `naddr`, it is the identifier (the `"d"` tag) of the event being referenced. For non-parameterized replaceable events, use an empty string.
 - `1`: `relay`
   - for `nprofile`, `nevent` and `naddr`, _optionally_, a relay in which the entity (profile or event) is more likely to be found, encoded as ascii
   - this may be included multiple times

23.md

@@ -6,7 +6,7 @@ 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` (a _parameterized replaceable 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.
 
 "Social" clients that deal primarily with `kind:1` notes should not be expected to implement this NIP.
 

29.md

@@ -16,7 +16,7 @@ Normally a group will originally belong to one specific relay, but the community
 
 ## Relay-generated events
 
-Relays are supposed to generate the events that describe group metadata and group admins. These are _addressable_ events signed by the relay keypair directly, with the group _id_ as the `d` tag.
+Relays are supposed to generate the events that describe group metadata and group admins. These are parameterized replaceable events signed by the relay keypair directly, with the group _id_ as the `d` tag.
 
 ## Group identifier
 

33.md

@@ -6,4 +6,4 @@ Parameterized Replaceable Events
 
 `final` `mandatory`
 
-Renamed to "Addressable events" and moved to [NIP-01](01.md).
+Moved to [NIP-01](01.md).

38.md

@@ -13,7 +13,7 @@ This NIP enables a way for users to share live statuses such as what music they
 
 ## Live Statuses
 
-A special event with `kind:30315` "User Status" is defined as an *optionally expiring* _addressable event_, where the `d` tag represents the status type:
+A special event with `kind:30315` "User Status" is defined as an *optionally expiring* _parameterized replaceable event_, where the `d` tag represents the status type:
 
 For example:
 

51.md

@@ -16,7 +16,7 @@ When new items are added to an existing list, clients SHOULD append them to the
 
 ## Standard lists
 
-Standard lists use normal replaceable events, meaning users may only have a single list of each kind. They have special meaning and clients may rely on them to augment a user's profile or browsing experience.
+Standard lists use non-parameterized replaceable events, meaning users may only have a single list of each kind. They have special meaning and clients may rely on them to augment a user's profile or browsing experience.
 
 For example, _mute list_ can contain the public keys of spammers and bad actors users don't want to see in their feeds or receive annoying notifications from.
 

52.md

@@ -6,7 +6,7 @@ Calendar Events
 
 `draft` `optional`
 
-This specification defines calendar events representing an occurrence at a specific moment or between moments. These calendar events are _addressable_ and deletable per [NIP-09](09.md).
+This specification defines calendar events representing an occurrence at a specific moment or between moments. These calendar events are _parameterized replaceable_ and deletable per [NIP-09](09.md).
 
 Unlike the term `calendar event` specific to this NIP, the term `event` is used broadly in all the NIPs to describe any Nostr event. The distinction is being made here to discern between the two terms.
 

53.md

@@ -12,7 +12,7 @@ Service providers want to offer live activities to the Nostr network in such a w
 
 ### Live Event
 
-A special event with `kind:30311` "Live Event" is defined as an _addressable event_ of public `p` tags. Each `p` tag SHOULD have a **displayable** marker name for the current role (e.g. `Host`, `Speaker`, `Participant`) of the user in the event and the relay information MAY be empty. This event will be constantly updated as participants join and leave the activity.
+A special event with `kind:30311` "Live Event" is defined as a _parameterized replaceable event_ of public `p` tags. Each `p` tag SHOULD have a **displayable** marker name for the current role (e.g. `Host`, `Speaker`, `Participant`) of the user in the event and the relay information MAY be empty. This event will be constantly updated as participants join and leave the activity.
 
 For example:
 

54.md

@@ -6,7 +6,7 @@ Wiki
 
 `draft` `optional`
 
-This NIP defines `kind:30818` (an _addressable event_) for descriptions (or encyclopedia entries) of particular subjects, and it's expected that multiple people will write articles about the exact same subjects, with either small variations or completely independent content.
+This NIP defines `kind:30818` (a _parameterized replaceable event_) for descriptions (or encyclopedia entries) of particular subjects, and it's expected that multiple people will write articles about the exact same subjects, with either small variations or completely independent content.
 
 Articles are identified by lowercase, normalized ascii `d` tags.
 

57.md

@@ -36,7 +36,7 @@ A `zap request` is an event of kind `9734` that is _not_ published to relays, bu
 In addition, the event MAY include the following tags:
 
 - `e` is an optional hex-encoded event id. Clients MUST include this if zapping an event rather than a person.
-- `a` is an optional event coordinate that allows tipping addressable events such as NIP-23 long-form notes.
+- `a` is an optional event coordinate that allows tipping parameterized replaceable events such as NIP-23 long-form notes.
 
 Example:
 

58.md

@@ -9,7 +9,7 @@ Badges
 Three special events are used to define, award and display badges in
 user profiles:
 
-1. A "Badge Definition" event is defined as an addressable event with kind `30009` having a `d` tag with a value that uniquely identifies the badge (e.g. `bravery`) published by the badge issuer. Badge definitions can be updated.
+1. A "Badge Definition" event is defined as a parameterized replaceable event with kind `30009` having a `d` tag with a value that uniquely identifies the badge (e.g. `bravery`) published by the badge issuer. Badge definitions can be updated.
 
 2. A "Badge Award" event is a kind `8` event with a single `a` tag referencing a "Badge Definition" event and one or more `p` tags, one for each pubkey the badge issuer wishes to award. Awarded badges are immutable and non-transferrable.
 

71.md

@@ -6,7 +6,7 @@ Video Events
 
 `draft` `optional`
 
-This specification defines video events representing a dedicated post of externally hosted content. These video events are _addressable_ and delete-requestable per [NIP-09](09.md).
+This specification defines video events representing a dedicated post of externally hosted content. These video events are _parameterized replaceable_ and delete requestable per [NIP-09](09.md).
 
 Unlike a `kind 1` event with a video attached, Video Events are meant to contain all additional metadata concerning the subject media and to be surfaced in video-specific clients rather than general micro-blogging clients. The thought is for events of this kind to be referenced in a Netflix, YouTube, or TikTok like nostr client where the video itself is at the center of the experience.
 

75.md

@@ -54,11 +54,11 @@ The following tags are OPTIONAL.
 }
 ```
 
-The goal MAY include an `r` or `a` tag linking to a URL or addressable event.
+The goal MAY include an `r` or `a` tag linking to a URL or parameterized replaceable event.
 
 The goal MAY include multiple beneficiary pubkeys by specifying [`zap` tags](57.md#appendix-g-zap-tag-on-other-events).
 
-Addressable events can link to a goal by using a `goal` tag specifying the event id and an optional relay hint.
+Parameterized replaceable events can link to a goal by using a `goal` tag specifying the event id and an optional relay hint.
 
 ```jsonc
 {

78.md

@@ -12,7 +12,7 @@ Even though interoperability is great, some apps do not want or do not need inte
 
 ## Nostr event
 
-This NIP specifies the use of event kind `30078` (an _addressable_ event) with a `d` tag containing some reference to the app name and context -- or any other arbitrary string. `content` and other `tags` can be anything or in any format.
+This NIP specifies the use of event kind `30078` (parameterized replaceable event) with a `d` tag containing some reference to the app name and context -- or any other arbitrary string. `content` and other `tags` can be anything or in any format.
 
 ## Some use cases
 

99.md

@@ -6,7 +6,7 @@ Classified Listings
 
 `draft` `optional`
 
-This NIP defines `kind:30402`: an addressable event to describe classified listings that list any arbitrary product, service, or other thing for sale or offer and includes enough structured metadata to make them useful.
+This NIP defines `kind:30402`: a parameterized replaceable event to describe classified listings that list any arbitrary product, service, or other thing for sale or offer and includes enough structured metadata to make them useful.
 
 The category of classifieds includes a very broad range of physical goods, services, work opportunities, rentals, free giveaways, personals, etc. and is distinct from the more strictly structured marketplaces defined in [NIP-15](15.md) that often sell many units of specific products through very specific channels.