replaceability using other tags.

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 an addressable or replaceable event
+- 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>]`
 
@@ -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 **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.
+- 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.
 
 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 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 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.
 
 ### 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 addressable/replaceable events for this due to the
+may be published. We have opted not to use parameterizable/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 addressable event.
+The status MAY include an `r`, `p`, `e` or `a` tag linking to a URL, profile, note, or parameterized replaceable 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 an _addressable event_ of `kind:31922`.
+The format uses a parameterized replaceable event 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 an _addressable event_ kind `31923`.
+The format uses a parameterized replaceable 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 an _addressable event_ kind `31925`.
+The format uses a parameterized replaceable 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,7 +13,8 @@ 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 an _addressable event_ with kind `30008` with a `d` tag with the value `profile_badges`.
+3. A "Profile Badges" event is defined as a parameterized replaceable event
+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

60.md

@@ -1,205 +0,0 @@
-# NIP-60
-## Cashu Wallet
-`draft` `optional`
-
-This NIP defines the operations of a cashu-based wallet.
-
-A cashu wallet is a wallet which information is stored in relays to make it accessible across applications.
-
-The purpose of this NIP is:
-* ease-of-use: new users immediately are able to receive funds without creating accounts with other services.
-* interoperability: users' wallets follows them across applications.
-
-This NIP doesn't deal with users' *receiving* money from someone else, it's just to keep state of the user's wallet.
-
-# High-level flow
-1. A user has a `kind:37375` event that represents a wallet.
-2. A user has `kind:7375` events that represent the unspent proofs of the wallet. -- The proofs are encrypted with the user's private key.
-3. A user has `kind:7376` events that represent the spending history of the wallet -- This history is for informational purposes only and is completely optional.
-
-## Wallet Event
-```jsonc
-{
-    "kind": 37375,
-    "content": nip44_encrypt([
-        [ "balance", "100", "sat" ],
-        [ "privkey", "hexkey" ] // explained in NIP-61
-    ]),
-    "tags": [
-        [ "d", "my-wallet" ],
-        [ "mint", "https://mint1" ],
-        [ "mint", "https://mint2" ],
-        [ "mint", "https://mint3" ],
-        [ "name", "my shitposting wallet" ],
-        [ "unit", "sat" ],
-        [ "description", "a wallet for my day-to-day shitposting" ],
-        [ "relay", "wss://relay1" ],
-        [ "relay", "wss://relay2" ],
-    ]
-}
-```
-
-The wallet event is a parameterized replaceable event `kind:37375`.
-
-Tags:
-* `d` - wallet ID.
-* `mint` - Mint(s) this wallet uses -- there MUST be one or more mint tags.
-* `relay` - Relays where the wallet and related events can be found. -- one ore more relays SHOULD be specified. If missing, clients should follow [[NIP-65]].
-* `unit` - Base unit of the wallet (e.g. "sat", "usd", etc).
-* `name` - Optional human-readable name for the wallet.
-* `description` - Optional human-readable description of the wallet.
-* `balance` - Optional best-effort balance of the wallet that can serve as a placeholder while an accurate balance is computed from fetching all unspent proofs.
-* `privkey` - Private key used to unlock P2PK ecash. MUST be stored encrypted in the `.content` field. **This is a different private key exclusively used for the wallet, not associated in any way to the user's nostr private key** -- This is only used when receiving funds from others, described in NIP-61.
-
-Any tag, other than the `d` tag, can be [[NIP-44]] encrypted into the `.content` field.
-
-### Deleting a wallet event
-Due to PRE being hard to delete, if a user wants to delete a wallet, they should empty the event and keep just the `d` identifier and add a `deleted` tag.
-
-## Token Event
-Token events are used to record the unspent proofs that come from the mint.
-
-There can be multiple `kind:7375` events for the same mint, and multiple proofs inside each `kind:7375` event.
-
-```jsonc
-{
-    "kind": 7375,
-    "content": nip44_encrypt({
-        "mint": "https://stablenut.umint.cash",
-        "proofs": [
-            {
-                "id": "005c2502034d4f12",
-                "amount": 1,
-                "secret": "z+zyxAVLRqN9lEjxuNPSyRJzEstbl69Jc1vtimvtkPg=",
-                "C": "0241d98a8197ef238a192d47edf191a9de78b657308937b4f7dd0aa53beae72c46"
-            }
-        ]
-    }),
-    "tags": [
-        [ "a", "37375:<pubkey>:my-wallet" ]
-    ]
-}
-```
-
-`.content` is a [[NIP-44]] encrypted payload storing the mint and the unencoded proofs.
-* `a` an optional tag linking the token to a specific wallet.
-
-### Spending proofs
-When one or more proofs of a token are spent, the token event should be [[NIP-09]]-deleted and, if some proofs are unspent from the same token event, a new token event should be created rolling over the unspent proofs and adding any change outputs to the new token event.
-
-## Spending History Event
-Clients SHOULD publish `kind:7376` events to create a transaction history when their balance changes.
-
-```jsonc
-{
-    "kind": 7376,
-    "content": nip44_encrypt([
-        [ "direction", "in" ], // in = received, out = sent
-        [ "amount", "1", "sat" ],
-        [ "e", "<event-id-of-spent-token>", "<relay-hint>", "created" ],
-    ]),
-    "tags": [
-        [ "a", "37375:<pubkey>:my-wallet" ],
-    ]
-}
-```
-
-* `direction` - The direction of the transaction; `in` for received funds, `out` for sent funds.
-* `a` - The wallet the transaction is related to.
-
-Clients MUST add `e` tags to create references of destroyed and created token events along with the marker of the meaning of the tag:
-* `created` - A new token event was created.
-* `destroyed` - A token event was destroyed.
-* `redeemed` - A [[NIP-61]] nutzap was redeemed.
-
-All tags can be [[NIP-44]] encrypted. Clients SHOULD leave `e` tags with a `redeemed` marker unencrypted.
-
-Multiple `e` tags can be added to a `kind:7376` event.
-
-# Flow
-A client that wants to check for user's wallets information starts by fetching `kind:10019` events from the user's relays, if no event is found, it should fall back to using the user's [[NIP-65]] relays.
-
-## Fetch wallet and token list
-From those relays, the client should fetch wallet and token events.
-
-`"kinds": [37375, 7375], "authors": ["<my-pubkey>"]`
-
-## Fetch proofs
-While the client is fetching (and perhaps validating) proofs it can use the optional `balance` tag of the wallet event to display a estimate of the balance of the wallet.
-
-## Spending token
-If Alice spends 4 sats from this token event
-```jsonconc
-{
-    "kind": 7375,
-    "id": "event-id-1",
-    "content": nip44_encrypt({
-        "mint": "https://stablenut.umint.cash",
-        "proofs": [
-            { "id": "1", "amount": 1 },
-            { "id": "2", "amount": 2 },
-            { "id": "3", "amount": 4 },
-            { "id": "4", "amount": 8 },
-        ]
-    }),
-    "tags": [
-        [ "a", "37375:<pubkey>:my-wallet" ]
-    ]
-}
-```
-
-Her client:
-* MUST roll over the unspent proofs:
-```jsonconc
-{
-    "kind": 7375,
-    "id": "event-id-2",
-    "content": nip44_encrypt({
-        "mint": "https://stablenut.umint.cash",
-        "proofs": [
-            { "id": "1", "amount": 1 },
-            { "id": "2", "amount": 2 },
-            { "id": "8", "amount": 8 },
-        ]
-    }),
-    "tags": [
-        [ "a", "37375:<pubkey>:my-wallet" ]
-    ]
-}
-```
-* MUST delete event `event-id-1`
-* SHOULD create a `kind:7376` event to record the spend
-```jsonconc
-{
-    "kind": 7376,
-    "content": nip44_encrypt([
-        [ "direction", "out" ],
-        [ "amount", "4", "sats" ],
-        [ "e", "<event-id-1>", "<relay-hint>", "destroyed" ],
-        [ "e", "<event-id-2>", "<relay-hint>", "created" ],
-    ]),
-    "tags": [
-        [ "a", "37375:<pubkey>:my-wallet" ],
-    ]
-}
-```
-
-## Redeeming a quote (optional)
-When creating a quote at a mint, an event can be used to keep the state of the quote ID, which will be used to check when the quote has been paid. These events should be created with an expiration tag [[NIP-40]] matching the expiration of the bolt11 received from the mint; this signals to relays when they can safely discard these events.
-
-Application developers are encouraged to use local state when possible and only publish this event when it makes sense in the context of their application.
-
-```jsonc
-{
-    "kind": 7374,
-    "content": nip44_encrypt("quote-id"),
-    "tags": [
-        [ "expiration", "<expiration-timestamp>" ],
-        [ "mint", "<mint-url>" ],
-        [ "a", "37375:<pubkey>:my-wallet" ]
-    ]
-}
-```
-
-## Appendix 1: Validating proofs
-Clients can optionally validate proofs to make sure they are not working from an old state; this logic is left up to particular implementations to decide when and why to do it, but if some proofs are checked and deemed to have been spent, the client should delete the token and roll over any unspent proof.

61.md

@@ -1,132 +0,0 @@
-# NIP-61:
-## Nut Zaps
-
-A Nut Zap is a P2PK cashu token where the payment itself is the receipt.
-
-# High-level flow
-Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.
-
-## Alice nutzaps Bob
-1. Alice fetches event `kind:10019` from Bob to see the mints Bob trusts.
-2. She mints a token at that mint (or swaps some tokens she already had in that mint) p2pk-locked to the pubkey Bob has listed in his `kind:10019`.
-3. She publishes a `kind:9321` event to the relays Bob indicated with the proofs she minted.
-
-## Bob receives the nutzap
-1. At some point, Bob's client fetches `kind:9321` events p-tagging him from his relays.
-2. Bob's client swaps the token into his wallet.
-
-# Nutzap informational event
-```jsonc
-{
-    "kind": 10019,
-    "tags": [
-        [ "relay", "wss://relay1" ],
-        [ "relay", "wss://relay2" ],
-        [ "mint", "https://mint1", "usd", "sat" ],
-        [ "mint", "https://mint2", "sat" ],
-        [ "pubkey", "<p2pk-pubkey>" ]
-    ]
-}
-```
-
-`kind:10019` is an event that is useful for others to know how to send money to the user.
-
-* `relay` - Relays where the user will be reading token events from. If a user wants to send money to the user, they should write to these relays.
-* `mint` - Mints the user is explicitly agreeing to use to receive funds on. Clients SHOULD not send money on mints not listed here or risk burning their money. Additional markers can be used to list the supported base units of the mint.
-* `pubkey` - Pubkey that SHOULD be used to P2PK-lock receiving nutzaps. If not present, clients SHOULD use the pubkey of the recipient. This is explained in Appendix 1.
-
-## Nutzap event
-Event `kind:9321` is a nutzap event published by the sender, p-tagging the recipient. The outputs are P2PK-locked to the pubkey the recipient indicated in their `kind:10019` event or to the recipient pubkey if the `kind:10019` event doesn't have a explicit pubkey.
-
-Clients MUST prefix the pubkey they p2pk-lock with `"02"` (for nostr<>cashu pubkey compatibility).
-
-```jsonc
-{
-    kind: 9321,
-    content: "Thanks for this great idea.",
-    pubkey: "sender-pubkey",
-    tags: [
-        [ "amount", "1" ],
-        [ "unit", "sat" ],
-        [ "proof", "{\"amount\":1,\"C\":\"02277c66191736eb72fce9d975d08e3191f8f96afb73ab1eec37e4465683066d3f\",\"id\":\"000a93d6f8a1d2c4\",\"secret\":\"[\\\"P2PK\\\",{\\\"nonce\\\":\\\"b00bdd0467b0090a25bdf2d2f0d45ac4e355c482c1418350f273a04fedaaee83\\\",\\\"data\\\":\\\"02eaee8939e3565e48cc62967e2fde9d8e2a4b3ec0081f29eceff5c64ef10ac1ed\\\"}]\"}" ],
-        [ "u", "https://stablenut.umint.cash", ],
-        [ "e", "<zapped-event-id>", "<relay-hint>" ],
-        [ "p", "e9fbced3a42dcf551486650cc752ab354347dd413b307484e4fd1818ab53f991" ], // recipient of nut zap
-    ]
-}
-```
-
-* `.content` is an optional comment for the nutzap
-* `amount` is a shorthand for the combined amount of all outputs. -- Clients SHOULD validate that the sum of the amounts in the outputs matches.
-* `unit` is the base unit of the amount.
-* `proof` is one ore more proofs p2pk-locked to the pubkey the recipient specified in their `kind:10019` event.
-* `u` is the mint the URL of the mint EXACTLY as specified by the recipient's `kind:10019`.
-* `e` zero or one event that is being nutzapped.
-* `p` exactly one pubkey, specifying the recipient of the nutzap.
-
-WIP: Clients SHOULD embed a DLEQ proof in the nutzap event to make it possible to verify nutzaps without talking to the mint.
-
-# Sending a nutzap
-
-* The sender fetches the recipient's `kind:10019`.
-* The sender mints/swaps ecash on one of the recipient's listed mints.
-* The sender p2pk locks to the recipient's specified pubkey in their
-
-# Receiving nutzaps
-
-Clients should REQ for nut zaps:
-* Filtering with `#u` for mints they expect to receive ecash from.
-  * this is to prevent even interacting with mints the user hasn't explicitly signaled.
-* Filtering with `since` of the most recent `kind:7376` event the same user has created.
-  * this can be used as a marker of the nut zaps that have already been swaped by the user -- clients might choose to use other kinds of markers, including internal state -- this is just a guidance of one possible approach.
-
-Clients MIGHT choose to use some kind of filtering (e.g. WoT) to ignore spam.
-
-`{ "kinds": [9321], "#p": "my-pubkey", "#u": [ "<mint-1>", "<mint-2>"], "since": <latest-created_at-of-kind-7376> }`.
-
-Upon receiving a new nut zap, the client should swap the tokens into a wallet the user controls, either a [[NIP-60]] wallet, their own LN wallet or anything else.
-
-## Updating nutzap-redemption history
-When claiming a token the client SHOULD create a `kind:7376` event and `e` tag the original nut zap event. This is to record that this token has already been claimed (and shouldn't be attempted again) and as signaling to the recipient that the ecash has been redeemed.
-
-Multiple `kind:9321` events can be tagged in the same `kind:7376` event.
-
-```jsonc
-{
-    "kind": 7376,
-    "content": nip44_encrypt([
-        [ "direction", "in" ], // in = received, out = sent
-        [ "amount", "1", "sat" ],
-        [ "e", "<7375-event-id>", "relay-hint", "created" ] // new token event that was created
-    ]),
-    "tags": [
-        [ "a", "37375:<pubkey>:my-wallet" ], // an optional wallet tag
-        [ "e", "<9321-event-id>", "relay-hint", "redeemed" ], // nutzap event that has been redeemed
-        [ "p", "sender-pubkey" ] // pubkey of the author of the 9321 event (nutzap sender)
-    ]
-}
-```
-
-Events that redeem a nutzap SHOULD be published to the sender's [[NIP-65]] relays.
-
-## Verifying a Cashu Zap
-* Clients SHOULD check that the receiving user has issued a `kind:10019` tagging the mint where the cashu has been minted.
-* Clients SHOULD check that the token is locked to the pubkey the user has listed in their `kind:10019`.
-
-## Final Considerations
-
-1. Clients SHOULD guide their users to use NUT-11 (P2PK) compatible-mints in their `kind:10019` event to avoid receiving nut zaps anyone can spend
-
-2. Clients SHOULD normalize and deduplicate mint URLs as described in NIP-65.
-
-3. A nut zap MUST be sent to a mint the recipient has listed in their `kind:10019` event or to the NIP-65 relays of the recipient, failure to do so may result in the recipient donating the tokens to the mint since the recipient might never see the event.
-
-## Appendix 1: Alternative P2PK pubkey
-Clients might not have access to the user's private key (i.e. NIP-07, NIP-46 signing) and, as such, the private key to sign cashu spends might not be available, which would make spending the P2PK incoming nutzaps impossible.
-
-For this scenarios clients can:
-
-* add a `pubkey` tag to the `kind:10019` (indicating which pubkey senders should P2PK to)
-* store the private key in the `kind:37375` event in the nip44-encrypted `content` field.
-
-This is to avoid depending on NIP-07/46 adaptations to sign cashu payloads.

71.md

@@ -16,7 +16,7 @@ There are two types of video events represented by different kinds: horizontal a
 
 #### Format
 
-The format uses an _addressable event_ kind `34235` for horizontal videos and `34236` for vertical videos.
+The format uses a parameterized replaceable 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 an _addressable event_ kind `34237`.
+The format uses a parameterized replaceable 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

73.md

@@ -6,29 +6,17 @@ External Content IDs
 
 `draft` `optional`
 
-There are certain established global content identifiers such as [Book ISBNs](https://en.wikipedia.org/wiki/ISBN), [Podcast GUIDs](https://podcastnamespace.org/tag/guid), and [Movie ISANs](https://en.wikipedia.org/wiki/International_Standard_Audiovisual_Number) that are useful to reference in nostr events so that clients can query all the events assosiated with these ids.
+There are certain established global content identifiers that would be useful to reference in nostr events so that clients can query all events assosiated with these ids.
 
+- Book [ISBNs](https://en.wikipedia.org/wiki/ISBN)
+- Podcast [GUIDs](https://podcastnamespace.org/tag/guid)
+- Movie [ISANs](https://en.wikipedia.org/wiki/International_Standard_Audiovisual_Number)
+
+Since the `i` tag is already used for similar references in kind-0 metadata events it makes sense to use it for these content ids as well.
 
-`i` tags are used for referencing these external content ids, with `k` tags representing the external content id kind so that clients can query all the events for a specific kind. 
 
 ## Supported IDs
 
-| Type | `i` tag | `k` tag |
-|- | - | - |
-| URLs | "`<URL, normalized, no fragment>`" | "`<scheme-host, normalized>`" |
-| Hashtags | "#`<topic, lowercase>`" | "#" |
-| Geohashes| "geo:`<geohash, lowercase>`" | "geo" |
-| Books | "isbn:`<id, without hyphens>`" | "isbn" |
-| Podcast Feeds | "podcast:guid:`<guid>`" | "podcast:guid" |
-| Podcast Episodes | "podcast:item:guid:`<guid>`" | "podcast:item:guid" |
-| Podcast Publishers | "podcast:publisher:guid:`<guid>`" | "podcast:publisher:guid" |
-| Movies | "isan:`<id, without version part>`" | "isan" |
-| Papers | "doi:`<id, lowercase>`" | "doi" |
-
----
-
-## Examples
-
 ### Books:
 
 - Book ISBN: `["i", "isbn:9780765382030"]` - https://isbnsearch.org/isbn/9780765382030

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 an addressable event with a `goal` tag, clients SHOULD tag the goal event id in the `e` tag of the zap request.
+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.
 
 ## Use cases
 

85.md

@@ -0,0 +1,15 @@
+NIP-85
+======
+
+Specific Tag Replaceableability
+-------------------------------
+
+`draft` `optional`
+
+This NIP establishes semantics similar to addressable events in the range `30000-39999`, but using different tags as the deduplication mechanism.
+
+Events in the range `40000-43999` are deemed to be replaceable by another event that contains the same `author`, the same `kind` and a duplicated `e` tag.
+
+Events in the range `44000-47999` are deemed to be replaceable by another event that contains the same `author`, the same `kind` and a duplicated `p` tag.
+
+Events in the range `48000-49999` are deemed to be replaceable by another event that contains the same `author`, the same `kind` and a duplicated `a` tag.

96.md

@@ -143,7 +143,7 @@ The upload response is a json object as follows:
   // and, optionally, all file metadata the server wants to make available
   //
   // nip94_event field is absent if unsuccessful upload
-  "nip94_event": {
+  "nip94_event2": {
     // Required tags: "url" and "ox"
     "tags": [
       // Can be same from /.well-known/nostr/nip96.json's "download_url" field

README.md

@@ -73,9 +73,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-57: Lightning Zaps](57.md)
 - [NIP-58: Badges](58.md)
 - [NIP-59: Gift Wrap](59.md)
-- [NIP-60: Cashu Wallet](60.md)
-- [NIP-61: Nutzaps](61.md)
-- [NIP-64: Chess (PGN)](64.md)
 - [NIP-64: Chess (PGN)](64.md)
 - [NIP-65: Relay List Metadata](65.md)
 - [NIP-70: Protected Events](70.md)
@@ -143,12 +140,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `5000`-`5999` | Job Request                     | [90](90.md)                            |
 | `6000`-`6999` | Job Result                      | [90](90.md)                            |
 | `7000`        | Job Feedback                    | [90](90.md)                            |
-| `7374`        | Reserved Cashu Wallet Tokens    | [60](60.md)                            |
-| `7375`        | Cashu Wallet Tokens             | [60](60.md)                            |
-| `7376`        | Cashu Wallet History            | [60](60.md)                            |
 | `9000`-`9030` | Group Control Events            | [29](29.md)                            |
 | `9041`        | Zap Goal                        | [75](75.md)                            |
-| `9321`        | Nutzap                          | [61](61.md)                            |
 | `9467`        | Tidal login                     | [Tidal-nostr]                          |
 | `9734`        | Zap Request                     | [57](57.md)                            |
 | `9735`        | Zap                             | [57](57.md)                            |
@@ -163,7 +156,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `10007`       | Search relays list              | [51](51.md)                            |
 | `10009`       | User groups                     | [51](51.md), [29](29.md)               |
 | `10015`       | Interests list                  | [51](51.md)                            |
-| `10019`       | Nutzap Mint Recommendation      | [61](61.md)                            |
 | `10030`       | User emoji list                 | [51](51.md)                            |
 | `10050`       | Relay list to receive DMs       | [51](51.md), [17](17.md)               |
 | `10063`       | User server list                | [Blossom][blossom]                     |
@@ -216,7 +208,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `34236`       | Short-form Portrait Video Event | [71](71.md)                            |
 | `34237`       | Video View Event                | [71](71.md)                            |
 | `34550`       | Community Definition            | [72](72.md)                            |
-| `37375`       | Cashu Wallet Event              | [60](60.md)                            |
 | `39000-9`     | Group metadata events           | [29](29.md)                            |
 
 [NUD: Custom Feeds]: https://wikifreedia.xyz/cip-01/