complete renaming to "addressable" events.

as noticed by @bezysoftware at https://github.com/nostr-protocol/nips/pull/1437#issuecomment-2380626514.

I don't know how so many of these instances were left from the original PR at following ca3c52e3e7.

01.md

@@ -77,7 +77,7 @@ 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
+- The `a` tag, used to refer to an addressable or 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>]`
 
@@ -95,7 +95,7 @@ And also a convention for kind ranges that allow for easier experimentation and
 - for kind `n` such that `1000 <= n < 10000 || 4 <= n < 45 || n == 1 || n == 2`, events are **regular**, which means they're all expected to be stored by relays.
 - for kind `n` such that `10000 <= n < 20000 || n == 0 || n == 3`, events are **replaceable**, which means that, for each combination of `pubkey` and `kind`, only the latest event MUST be stored by relays, older versions MAY be discarded.
 - for kind `n` such that `20000 <= n < 30000`, events are **ephemeral**, which means they are not expected to be stored by relays.
-- for kind `n` such that `30000 <= n < 40000`, events are **parameterized replaceable**, which means that, for each combination of `pubkey`, `kind` and the `d` tag's first value, only the latest event MUST be stored by relays, older versions MAY be discarded.
+- for kind `n` such that `30000 <= n < 40000`, events are **addressable** by their `kind`, `pubkey` and `d` tag value -- which means that, for each combination of `kind`, `pubkey` and the `d` tag value, only the latest event MUST be stored by relays, older versions MAY be discarded.
 
 In case of replaceable events with the same timestamp, the event with the lowest id (first in lexical order) should be retained, and the other discarded.
 

23.md

@@ -31,7 +31,7 @@ Other metadata fields can be added as tags to the event as necessary. Here we st
 
 ### Editability
 
-These articles are meant to be editable, so they should make use of the parameterized replaceability feature and include a `d` tag with an identifier for the article. Clients should take care to only publish and read these events from relays that implement that. If they don't do that they should also take care to hide old versions of the same article they may receive.
+These articles are meant to be editable, so they should include a `d` tag with an identifier for the article. Clients should take care to only publish and read these events from relays that implement that. If they don't do that they should also take care to hide old versions of the same article they may receive.
 
 ### Linking
 

32.md

@@ -8,7 +8,7 @@ Labeling
 
 This NIP defines two new indexable tags to label events and a new event kind (`kind:1985`) to attach those labels to existing events. This supports several use cases, including distributed moderation, collection management, license assignment, and content classification.
 
-New Tags: 
+New Tags:
 
 - `L` denotes a label namespace
 - `l` denotes a label
@@ -146,7 +146,7 @@ Other Notes
 -----------
 
 When using this NIP to bulk-label many targets at once, events may be requested for deletion using [NIP-09](09.md) and a replacement
-may be published. We have opted not to use parameterizable/replaceable events for this due to the
+may be published. We have opted not to use addressable/replaceable events for this due to the
 complexity in coming up with a standard `d` tag. In order to avoid ambiguity when querying,
 publishers SHOULD limit labeling events to a single namespace.
 

38.md

@@ -46,7 +46,7 @@ Two common status types are defined: `general` and `music`. `general` represent
 
 Any other status types can be used but they are not defined by this NIP.
 
-The status MAY include an `r`, `p`, `e` or `a` tag linking to a URL, profile, note, or parameterized replaceable event.
+The status MAY include an `r`, `p`, `e` or `a` tag linking to a URL, profile, note, or addressable event.
 
 The `content` MAY include emoji(s), or [NIP-30](30.md) custom emoji(s). If the `content` is an empty string then the client should clear the status.
 

52.md

@@ -20,7 +20,7 @@ This kind of calendar event starts on a date and ends before a different date in
 
 #### Format
 
-The format uses a parameterized replaceable event kind `31922`.
+The format uses an _addressable event_ of `kind:31922`.
 
 The `.content` of these events should be a detailed description of the calendar event. It is required but can be an empty string.
 
@@ -79,7 +79,7 @@ This kind of calendar event spans between a start time and end time.
 
 #### Format
 
-The format uses a parameterized replaceable event kind `31923`.
+The format uses an _addressable event_ kind `31923`.
 
 The `.content` of these events should be a detailed description of the calendar event. It is required but can be an empty string.
 
@@ -193,7 +193,7 @@ The RSVP MAY tag the author of the calendar event it is in response to using a `
 
 ### Format
 
-The format uses a parameterized replaceable event kind `31925`.
+The format uses an _addressable event_ kind `31925`.
 
 The `.content` of these events is optional and should be a free-form note that adds more context to this calendar event response.
 

58.md

@@ -13,8 +13,7 @@ user profiles:
 
 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.
 
-3. A "Profile Badges" event is defined as a parameterized replaceable event
+3. A "Profile Badges" event is defined as an _addressable event_ with kind `30008` with a `d` tag with the value `profile_badges`.
-with kind `30008` with a `d` tag with the value `profile_badges`.
 Profile badges contain an ordered list of pairs of `a` and `e` tags referencing a `Badge Definition` and a `Badge Award` for each badge to be displayed.
 
 ### Badge Definition event

71.md

@@ -16,7 +16,7 @@ There are two types of video events represented by different kinds: horizontal a
 
 #### Format
 
-The format uses a parameterized replaceable event kind `34235` for horizontal videos and `34236` for vertical videos.
+The format uses an _addressable event_ kind `34235` for horizontal videos and `34236` for vertical videos.
 
 The `.content` of these events is a summary or description on the video content.
 
@@ -91,14 +91,14 @@ A video event view is a response to a video event to track a user's view or prog
 
 ### Format
 
-The format uses a parameterized replaceable event kind `34237`.
+The format uses an _addressable event_ kind `34237`.
 
 The `.content` of these events is optional and could be a free-form note that acts like a bookmark for the user.
 
 The list of tags are as follows:
 * `a` (required) reference tag to kind `34235` or `34236` video event being viewed
 * `d` (required) same as `a` reference tag value
-* `viewed` (optional, repeated) timestamp of the user's start time in seconds, timestamp of the user's end time in seconds 
+* `viewed` (optional, repeated) timestamp of the user's start time in seconds, timestamp of the user's end time in seconds
 
 
 ```json

75.md

@@ -77,7 +77,7 @@ Clients MAY display funding goals on user profiles.
 
 When zapping a goal event, clients MUST include the relays in the `relays` tag of the goal event in the zap request `relays` tag.
 
-When zapping a parameterized replaceable event with a `goal` tag, clients SHOULD tag the goal event id in the `e` tag of the zap request.
+When zapping an addressable event with a `goal` tag, clients SHOULD tag the goal event id in the `e` tag of the zap request.
 
 ## Use cases