Simplify push notifications, put more burden on the push server

Author: Jon Staab

9a.md

@@ -19,26 +19,23 @@ All other tags MUST be encrypted and placed in the event's `content` field:
 
 - `relay` - the normalized url of the relay the event was sent to
 - `filter` - a nostr filter for matching events (may appear multiple times)
-- `server` - a URL indicating a push server to forward events to
-- `vapid_endpoint` - a VAPID push notification endpoint (web push only)
-- `vapid_p256dh` - a VAPID p256dh key (web push only)
-- `vapid_auth` - a VAPID auth key (web push only)
-- `fcm_token` - a Firebase Cloud Messaging token (android only)
-- `apns_token` - an APNs token (ios only)
-- `ios_bundle_identifier` - a iOS app bundle identifier (ios only)
-- `silent` - whether silent push notifications should be used
+- `callback` - a URL indicating a callback url to forward events to
 
 If a relay does not intend to fulfill the subscription, it SHOULD respond with an `OK` message with `false` as the result and a human-readable message.
 
-When a relay receives a new event, it SHOULD match it against all current registrations and forward the event to authorized users by sending an HTTP `POST` request to the `server` URL with `Content-Type: application/json`. The payload should be as follows:
+Because client developers are expected to be running their own push server, any other features such as registration of device tokens, notification cancellation, or client status should be implemented directly between the client and the push server.
+
+When a relay receives a new event, it SHOULD match it against all current registrations and forward the event to authorized users by sending a `POST` request to the `callback` URL with `Content-Type: application/json`. The payload should be as follows:
 
 ```typescript
 {
+  relay: string       // The normalized url of the relay sending the notification
   event: Event        // The signed nostr event
-  config: string[][]  // The private tags provided by the user to the relay
 }
 ```
 
-If a relay receives a `kind 30390` event not p-tagged to itself, it SHOULD NOT store it. If a relay receives a `kind 30390` event whose `relay` tag does not match the relay's own URL, the relay SHOULD discard it. However, special purpose relays MAY choose to implement this behavior on behalf of other relays that do not support this NIP.
+If the `callback` URL responds with a `404` status code, the relay SHOULD delete the subscription. Relays MAY delete subscriptions at their discretion (e.g. due to expiration, inactivity, callback `500` errors, etc).
 
-Relays SHOULD delete subscription events after 30 days. Clients MAY re-publish subscription events periodically if they wish to continue receiving push notifications. Clients MAY delete subscription events as specified in [NIP 09](09.md).
+If a relay receives a request for `kind 30390`, it should respond only with the current user's subscription events (based on [NIP 42](42.md) AUTH). Clients MAY wish to sync subscription events periodically if they wish to ensure they continue receiving push notifications. Clients MAY delete subscription events as specified in [NIP 09](09.md), or they may delete subscriptions with the push server directly, relying on `callback` error responses to clean up relay subscriptions.
+
+If a relay receives a `kind 30390` event not p-tagged to itself, it SHOULD NOT store it. If a relay receives a `kind 30390` event whose `relay` tag does not match the relay's own URL, the relay SHOULD discard it. However, special purpose relays MAY choose to implement this behavior on behalf of other relays that do not support this NIP.