NIP-800: Define BDD Payload Execution Protocol (because 800 and BDD are a match made in alphanumeric heaven)

800.md

@@ -0,0 +1,135 @@
+NIP-800
+=======
+
+BDD Payload Execution Protocol
+------------------------------
+
+`draft` `optional`
+
+This NIP defines `kind:800` and `kind:801`: a standardized protocol for relays to handle and execute Behavior-Driven Development (BDD) payloads. The protocol enables developers to send structured BDD test cases as Nostr events and provides a framework for relays to execute, validate, and return the results.
+
+---
+
+#### **Motivation**
+The need for BDD payloads arises from the desire to integrate automated testing into the Nostr ecosystem. This enables developers to leverage relays for distributed and immutable BDD test case execution, reducing reliance on centralized CI/CD systems and providing auditable on-chain results.
+
+---
+
+#### **Specification**
+
+##### 1. **Event Structure**
+A BDD payload is a specialized Nostr event (`kind` value: `800`). The payload must conform to the following structure:
+
+```json
+```json
+{
+  "id": "<event_id>",
+  "pubkey": "<developer_pubkey>",
+  "created_at": <timestamp>,
+  "kind": 800,
+  "tags": [
+    ["test-suite", "<suite_name>"],
+    ["test-feature", "<feature_name>"],
+    ["test-scenario", "<scenario_name>"],
+    ["test-description", "<description>"],
+    ["expected-result", "<expected_result>"]
+  ],
+  "content": {
+    "feature": "<feature_description>",
+    "background": {
+      "given": "<background_given_clause>"
+    },
+    "scenario": {
+      "name": "<scenario_name>",
+      "steps": [
+        {"given": "<given_clause>"},
+        {"when": "<when_clause>"},
+        {"then": "<then_clause>"}
+      ]
+    }
+  },
+  "sig": "<signature>"
+}
+```
+
+---
+
+##### 2. **Tags**
+
+- **`test-suite`**: The name of the test suite.
+- **`test-feature`**: The name of the feature being tested.
+- **`test-scenario`**: A specific scenario name within the feature.
+- **`test-description`**: A detailed description of the test case.
+- **`expected-result`**: The expected outcome for validation.
+
+---
+
+##### 3. **BDD Payload Content**
+The `content` field must include the following keywords:
+- **`feature`**: A high-level description of the feature under test.
+- **`background`**: Contains shared setup steps or context that applies to multiple scenarios (uses the **`given`** keyword).
+- **`scenario`**: Describes a specific scenario to be tested. It includes:
+  - **`name`**: The name of the scenario.
+  - **`steps`**: A list of BDD steps using the **`given`**, **`when`**, and **`then`** keywords.
+
+---
+
+##### 4. **Relay Execution**
+Relays supporting NIP-800 must:
+1. Validate the event structure and signature.
+2. Parse the `content` to extract the BDD elements: **feature**, **background**, and **scenario**.
+3. Execute the BDD test using a sandboxed runtime environment, applying the `background` steps before running the `scenario` steps.
+4. Return the results as a new Nostr event (`kind: 801`).
+
+---
+
+##### 5. **Result Event Structure**
+The results of a BDD test are published as a new event (`kind: 801`) by the relay:
+
+```json
+{
+  "id": "<result_event_id>",
+  "pubkey": "<relay_pubkey>",
+  "created_at": <timestamp>,
+  "kind": 801,
+  "tags": [
+    ["test-suite", "<suite_name>"],
+    ["test-feature", "<feature_name>"],
+    ["test-scenario", "<scenario_name>"],
+    ["status", "<pass|fail>"],
+    ["error", "<error_message_if_any>"]
+  ],
+  "content": {
+    "execution-log": "<log_of_steps>",
+    "result": "<result_output>"
+  },
+  "sig": "<signature>"
+}
+```
+
+---
+
+##### 6. **Status Tag**
+- **`status`**: Indicates whether the test passed or failed.
+- **`error`**: Contains an error message if the test failed.
+
+---
+
+#### **Use Cases**
+- Decentralized CI/CD for Nostr apps and protocols.
+- Immutable record of test executions.
+- Enabling collaborative debugging via shared test scenarios.
+
+---
+
+#### **Security Considerations**
+- Relays must execute tests in a sandboxed environment to prevent malicious code execution.
+- Event sizes must be limited to prevent denial-of-service attacks.
+- Results must be cryptographically signed by the relay for authenticity.
+
+---
+
+#### **Future Extensions**
+- Support for additional test formats (e.g., unit tests).
+- Integration with popular test frameworks.
+- Mechanisms for incentivizing relays to execute tests (e.g., Lightning payments).