Nip88: Adding dtag, typos

- A kind 37001 dtag is referenced in the 7003 description, but was missing in the example

-A etag is referenced in the  kind 7001 description but an a tag was referenced in the example

88.md

@@ -0,0 +1,171 @@
+NIP-88
+======
+
+Recurring Subscriptions
+-----------------------
+
+`draft` `optional`
+
+This NIP defines a way for a pubkey to create recurring subscription payments to another pubkey.
+
+Actors in this flow:
+* Recipient: A pubkey that receives recurring payments
+* Subscriber: A pubkey that sends recurring payments
+* Payment verifier: An optional pubkey recipients can designate to verify payments on their behalf
+
+# Kinds
+`kind:37001` - Tier Event -- Optionally published by recipients
+`kind:7001` - Subscribe Event -- Published by subscribers
+`kind:7002` - Unsubscribe Event -- Published by subscribers
+`kind:7003` - Subscription Payment Receipt -- Published by payment-verifier-pubkey
+
+## `kind:37001`: Tier Event
+A pubkey that wants to provide others the ability to subscribe to them can create "tiers". These tiers might provide certain benefits to the supporters who subscribe to these.
+
+```js
+{
+    "kind": 37001,
+    "content": "<description of the tier>",
+    "tags": [
+        [ "title", "..." ],
+        [ "image", "..." ],
+
+        // Perks
+        [ "perk", "<description>" ],
+        [ "perk", "<description>" ],
+
+        // Amount possibilities
+        [ "amount", "<amount-in-base-unit>", "currency", "<monthly>" ],
+        [ "amount", "<amount-in-base-unit>", "currency", "<quarterly>" ],
+
+        // Zap-splits
+        [ "zap", "<recipient-pubkey>", "relay-url", "19" ], // 95%
+        [ "zap", "", "relay-url", "1" ], // 5%
+
+        // Relay and payment-verification
+        [ "r", "wss://my-subscribers-only-relay.com" ],
+        [ "p", "<payment-verifier-pubkey>" ],
+
+        // A unique identifier
+        [ "d", "<random-id>" ],
+    ]
+}
+```
+
+`.content`: description of what subscribers can expect.
+Tag `title` is an optional title for the tier.
+Tag `image` is an optional image for the tier.
+Zero or more `perk` tags specify the benefits of the tier; these can be rendered as a list of benefits to the user in addition to the content.
+One or more `amount` tags specify the payment required for this tier and its cadence.
+    * The first argument should be the stringified amount in cents or msats, and the second argument the currency
+    * The third argument SHOULD be one of `daily`, `monthly`, `yearly`
+One or more `amount` tags MUST exist.
+Zero or more `zap` tags can exist as defined in NIP-57.
+
+A `zap` tag with no pubkey indicates that the client can include any pubkey in the `kind:7001` event (and in the resulting recurring zaps). This way, users can offer a "referral" fee to other clients.
+
+An `r` tag can be included to specify a relay where clients can find special content for this tier.
+
+Zero or more `p` tags can be included to specify a pubkey that is trusted by the tier creator to verify payments on their behalf.
+
+#### Examples
+* `[ "amount", "100", "usd", "daily" ]`, $1.00 a day.
+* `[ "amount", "1000000", "msats", "daily" ]`, 1000000 millisats a day.
+
+## Subscribe Event
+
+```js
+{
+    "kind": 7001,
+    "content": "<optional-message>",
+    "tags": [
+        [ "p", "<recipient-pubkey>" ],
+        [ "e", "<supporting-tier-event-id>" ],
+        [ "event", "<stringied-event-subscribed-to>" ],
+        [ "amount", "<amount-in-base-unit>", "<currency>", "<cadence>" ],
+
+        // Zap-splits
+        [ "zap", "<recipient-pubkey>", "19" ], // 95%
+        [ "zap", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52", "1" ], // 5% to client developer where subscription was created
+    ]
+}
+```
+
+When a user wants to subscribe to support a user they create a `kind:7001` event.
+
+* `.content` is an optional message the supporter can write.
+* The `p` tag MUST tag the pubkey being supported.
+* The `e` tag is optional; it should point to a `kind:37001` support tier event. There MUST be exactly 0 or 1 `e` tag.
+* The `event` tag is optional; subscribers can opt to keep the version of the event they subscribed to. There MUST be exactly 0 or 1 `event` tag.
+* The `amount` tag specifies what the supporters is committing to pay to the supported pubkey and the cadence. MUST be equal to one of the amounts specified in the
+`kind:37001` event if one is tagged. There MUST be exactly 1 `amount` tag.
+
+The `kind:7001` event can be created without an `e` tag so that users can create recurring support events without the pubkey receiving the support having explicitly created a support tier.
+
+### Zap splits
+`kind:7001` events can include zap splits as defined in NIP-57. Zap splits MUST be copied by clients as they exist in the `kind:37001` event being subscribed to. When an event has a `zap` tag with no pubkey, clients can discard it, or add the client developer's pubkey, or any other user they wish to receive a share of recurring subscriptions.
+
+## Paying
+The supporting user should create a zap `p`-tagging the receiver and e-tagging the `kind:7001`. There MUST be a single `p` and a single `e` tag in the zap request.
+
+```js
+{
+    "kind": 9734,
+    "content": "",
+    "tags": [
+        [ "p", "<recipient-pubkey>" ],
+        [ "e", "<kind-7001-event-id>" ]
+    ]
+}
+```
+
+Clients supporting this NIP can check for zaps e-tagging the `kind:7001` event to find the pubkeys that have a valid, paid subscriptions at each different period.
+
+The same `kind:7001` is re-zapped on a regular basis per the cadence specified in the event.
+
+## Stopping a subscription
+A user who wants to signal they are no longer subscribed can publish a `kind:7002` event tagging the `kind:7001` they are stopping and `p`-tagging the pubkey they are no longer subscribed to.
+
+```js
+{
+    "kind": 7002,
+    "content": "<optional-message>",
+    "tags": [
+        [ "p", "<recipient-pubkey>" ],
+        [ "e", "<kind-7001-event-id>" ],
+    ]
+}
+```
+
+## Subscription Payment Receipt
+When a subscription payment is made and a `payment-verifier-pubkey` is set on the `kind:37001` this pubkey publishes `kind:7003` events tagging the `kind:7001` event that was paid and `p`-tagging the pubkey that received the payment.
+
+```js
+{
+    "kind": 7003,
+    "content": "<optional-message>",
+    "tags": [
+        [ "p", "<recipient-pubkey>" ],
+        [ "P", "<subscriber-pubkey>" ],
+        [ "e", "<kind-7001-event-id>" ],
+        [ "valid", "<from-timestamp>", "<to-timestamp>" ]
+        [ "tier", "kind:37001-d-tag" ]
+    ]
+}
+```
+
+`p` is the pubkey that received the payment.
+`P` is the pubkey that made the payment.
+`e` is the `kind:7001` event that was paid.
+`valid` is the period for which the payment is valid.
+`tier` is the d-tag of the `kind:37001` that this subscription is for.
+
+# Appendix 0: Verifying Payment
+The following conditions must be met to verify a payment:
+
+* Time between zap receipts should be equal or less than the cadence specified in the `kind:7001` event.
+* Amount of the zap receipt should be equal or greater than the amount specified in the `kind:7001` event. For currencies not directly supported by the zap spec, clients should do a best effort conversion to the currency specified in the `kind:7001` event at the time of zap receipt.
+* Zap-receipts should include a zap request `e`-tagging the `kind:7001` event. Zap-receipts might not include a signature (for NWC-automated payments where the subscriber is not present to sign the zap request).
+* Validations specified in [NIP-57](https://github.com/nostr-protocol/nips/blob/master/57.md).
+
+If `kind:7003` events are published by the payment-verifier-pubkey, clients can use these to verify payments more simply.

93.md

@@ -1,57 +0,0 @@
-NIP-93
-======
-
-Alternative URLs
-----------------
-
-Whenever there is a URL linked to in an event, alternative versions of that same URL can be given as `alturl` tags in that same event. For example:
-
-```json
-{
-  "kind": 1,
-  "content": "I just painted this: https://www.foundmyself.com/gallery/albums/userpics/55231/qs170gzrh0by7w0ftxaas76tx2r7vb.jpg",
-  "tags": [
-    [
-      "alturl",
-      "https://www.foundmyself.com/gallery/albums/userpics/55231/qs170gzrh0by7w0ftxaas76tx2r7vb.jpg",
-      "http://images5.fanpop.com/image/photos/31600000/The-Starry-Night-by-Vincent-van-Gogh-1889-fine-art-31674050-2560-2027.jpg",
-      "https://www.paintingmania.com/arts/vincent-van-gogh/large/starry-night-6_2843.jpg?version=09.12.13"
-    ]
-  ],
-  ...
-}
-```
-
-The second element in the tag is the original URL that is in the content, the remaining elements are alternative sources for the same content.
-
-Alternative URLs do not have to contain exactly the same content, byte-for-byte.
-
-## Fixing other people's events
-
-When someone else publishes an event containing URLs, other people can reference it in an event that adds alternative URLs for them, thus preventing the original event from losing its meaning once its referenced URL becomes inaccessible.
-
-For example, in response to an event
-
-```json
-{
-  "id": "ad777844308977e54867c64aa0a425e15f29618105080c8c33c5a00e9198a076",
-  "kind": 1,
-  "content": "I just painted this: https://wallpapercave.com/wp/wp5960277.jpg",
-  ...
-}
-```
-
-Other people (or the same person) could publish events of kind `4001` like this:
-
-```json
-{
-  "kind": 4001,
-  "tags": [
-    ["alt", "alternative image for event ad77..."],
-    ["e", "ad777844308977e54867c64aa0a425e15f29618105080c8c33c5a00e9198a076"],
-    ["alturl", "https://wallpapercave.com/wp/wp5960277.jpg", "https://wallpapercave.com/wp/wp5960312.jpg"]
-  ]
-}
-```
-
-Then clients, when finding out that the original URL of the event is no longer available, could try to load an alternative from one of the `kind:4001` events that reference the original one. They should prioritize replacements from the original author and then use some kind of heuristics to prevent misleading replacements (only load `kind:4001` events from trustworthy friends or friends of the original author, for example).

README.md

@@ -99,11 +99,12 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `1971`        | Problem Tracker            | [nostrocket-1971][nostrocket-1971] |
 | `1984`        | Reporting                  | [56](56.md)                        |
 | `1985`        | Label                      | [32](32.md)                        |
-| `4001`        | URL Alternative            | [93](93.md)                        |
 | `4550`        | Community Post Approval    | [72](72.md)                        |
 | `5000`-`5999` | Job Request                | [90](90.md)                        |
 | `6000`-`6999` | Job Result                 | [90](90.md)                        |
 | `7000`        | Job Feedback               | [90](90.md)                        |
+| `7001`        | Subscription Start         | [88](88.md)                        |
+| `7002`        | Subscription Stop          | [88](88.md)                        |
 | `9041`        | Zap Goal                   | [75](75.md)                        |
 | `9734`        | Zap Request                | [57](57.md)                        |
 | `9735`        | Zap                        | [57](57.md)                        |
@@ -149,6 +150,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `31989`       | Handler recommendation     | [89](89.md)                        |
 | `31990`       | Handler information        | [89](89.md)                        |
 | `34550`       | Community Definition       | [72](72.md)                        |
+| `37001`      | Subscription Tier           | [88](88.md)                        |
 
 [nostrocket-1971]: https://github.com/nostrocket/NIPS/blob/main/Problems.md