NIP-??

Lightning Superchat

draft optional author: cjchua

• Lightning Superchat is akin to superchats on Youtube Livestreams, but done via lightning.
• This activity(Lightning Superchat) requires a service provider that actively manages the list of superchats and lightning payment requests.
• This NIP is designed to build off of NIP28.

Introducing 3 special events:

1. superchat service request: kind 1111 regular event with p tag referencing service provider, e tag referencing a kind40 channel. Clients register for a superchat service using this event.

{
  "kind": 1111,
  "pubkey": <kind40_creator>
  "tags": [
        ["p", <service_provider>, <relay_url>],
        ["e", <kind40_event_id>, <relay_url>],
    ],
}

2. superchats: kind 33333 parameterized replaceable event with d tag referencing the channel requesting the service. This event contains a dynamic list of active superchats.

{
  "kind": 33333,
  "pubkey": <service_provider>,
  "tags": [
        ["d", <kind40_event_id>],
        ["superchat", <amount_sat>, <created_timestamp>, <user_pubkey>, <content>],  // example
        ["superchat", "50", "1678443555", "bfd121a3.....4f063e7", "this is a superchat"],
    ],
}

3. An ephemeral event used for communication between the service provider and users. Below outlines the only 2 possible scenarios (for now)
   a. superchat request: kind 22222 event with a tag referencing superchats
   b. payment request: kind 22222 event with a tag referencing superchats and p tag referencing user

// Scenario 1: User making a `superchat request`
{
 "kind": 22222,
 "pubkey": <user>,
 "content": <amount_sat>,
 "tags": [
       ["a", "33333:<service_provider>:<kind40_event_id>", <relay_url>],
   ],
}

// Scenario 2: Service provider providing a `payment request`
{
  "kind": 22222,
  "pubkey": <service_provider>,
  "content": "optional comment",
  "tags": [
        ["a", "33333:<service_provider>:<kind40_event_id>", <relay_url>],
        ["p", <user>, <relay_url>],
        ["bolt11", "lnbc...."],
    ],
}

Implementation Guideline:

a. Service Provider

• Subscribe to superchat service request. Validate the provided kind40 event and that the requester is the channel creator
• Publish superchats and subscribe to superchat request
• Handle superchat request by replying with a payment request
• Once payment request is paid, update and publish superchats
• Service Provider could update superchats at will

b. Client

• Subscribe to superchats and display to the user. There may be more than one service provider offering this service. It is the client's prerogative to either default to a service provider, or provide more flexibility by allowing users to pick a service provider
• Send superchat request on user's request
• Handle payment request by presenting the bolt11 to the user

Notes:

1. Upon payment, service provider could publish a regular event that acts as a receipt for both the room creator and users. Clients could also use it as a signal that payment has been made and handle the UI accordingly. Excluded for now in favor of simplicity
2. Why not use Zaps? Avoiding the complexity of implementing a lnurl server and nip57/58
3. There is the problem of service provider discovery not addressed in this NIP. Hopefully this NIP will get the conversation around it going