Lightning-Gated Public Resources

Lightning-Gated Public Resources#

draft optional

This NIP defines a minimal convention for publishing publicly discoverable resources that require a Lightning payment before a client presents or unlocks them.

Unlike encrypted premium-content systems, this protocol does not hide the resource. The resource URL and manifest MAY be publicly visible. Payment is an authorization and presentation mechanism.

Resource Manifest#

A Lightning-Gated Resource Manifest is an addressable event of kind 30469.

The event MUST contain a d tag:

["d", "<resource-id>"]

The event MAY contain:

["name", "<human-readable-name>"]
["url", "<public-resource-url>"]
["p", "<lightning-provider-pubkey>"]
["amount", "<millisatoshis>"]

The event is addressed as:

30469:<publisher-pubkey>:<resource-id>

Clients MUST verify the event signature before trusting the manifest.

Payment#

A client SHOULD use NIP-57 to request payment.

The zap request SHOULD reference the resource manifest:

["a", "30469:<publisher-pubkey>:<resource-id>"]

The zap request MUST identify the payment recipient and SHOULD include the requested amount.

The client pays the resulting Lightning invoice using its wallet.

Unlock#

After payment, the client SHOULD locate the corresponding NIP-57 zap receipt of kind 9735.

The receipt MUST be validated according to NIP-57.

The client MUST verify that:

• the receipt is validly signed;
• the receipt pubkey matches the Lightning provider's nostrPubkey;
• the receipt invoice matches the invoice issued for the request;
• the receipt recipient matches the manifest;
• the zap request references the manifest;
• the payment amount satisfies the manifest amount.

Only after successful validation SHOULD the client unlock or present the resource.

A wallet payment response alone is not a NIP-57 receipt.

Public Resources#

This protocol does not provide confidentiality.

A resource URL MAY be discovered by inspecting the event, source code, network traffic, or other public information.

Publishers SHOULD use this protocol where public discoverability is acceptable and the Lightning payment functions as a payment, presentation, conversion, or access mechanism.

Resource Directories#

A manifest MAY describe multiple resources using application-defined content.

For example:

{
  "version": 1,
  "resources": [
    {
      "name": "Example",
      "url": "https://example.com",
      "marker": "Active"
    }
  ]
}

Clients MUST treat manifest content and resource metadata as untrusted input.

Updating#

Publishers SHOULD update a resource by publishing a new event with the same d value.

Clients SHOULD use the newest valid event for the addressable identifier as defined by NIP-01.

Compatibility#

Clients that do not implement this NIP MAY ignore kind 30469.

This protocol builds on NIP-01, NIP-07, and NIP-57.

Implementation#

A reference implementation is available at:

https://prnstr.org

Discussion#

This is a draft proposal for discussion and experimentation.