Merge 20f2eb37f7 into 7dec812f99

nip22: fix example type for external URL (#2011 )
NIP-24: Fix heading levels (#2009 )
2025-08-12 14:41:59 +02:00 · 2025-08-11 17:26:05 -04:00 · 2025-08-11 19:37:53 +09:00 · 2025-08-11 19:35:36 +09:00 · 2025-05-19 21:03:38 -07:00 · 2025-05-19 20:37:13 -07:00
4 changed files with 390 additions and 13 deletions
--- a/21.md
+++ b/21.md
@ -21,7 +21,7 @@ The identifiers that come after are expected to be the same as those defined in

 ### Linking HTML pages to Nostr entities

-`<link>` tags with `rel="alternate"` can be used to associate webpages to Nostr events, in cases where the same content is served via the two mediums (for example, a web server that exposes Markdown articles both as HTML pages and as `kind:30023' events served under itself as a relay or through some other relay). For example:
+`<link>` tags with `rel="alternate"` can be used to associate webpages to Nostr events, in cases where the same content is served via the two mediums (for example, a web server that exposes Markdown articles both as HTML pages and as `kind:30023` events served under itself as a relay or through some other relay). For example:

 ```
 <head>
--- a/22.md
+++ b/22.md
@ -143,13 +143,13 @@ A comment on a website's url looks like this:
  "tags": [
    // referencing the root url
    ["I", "https://abc.com/articles/1"],
-    // the root "kind": for an url, the kind is its domain
-    ["K", "https://abc.com"],
+    // the root "kind": for an url
+    ["K", "web"],

    // the parent reference (same as root for top-level comments)
    ["i", "https://abc.com/articles/1"],
-    // the parent "kind": for an url, the kind is its domain
-    ["k", "https://abc.com"]
+    // the parent "kind": for an url
+    ["k", "web"]
  ]
  // other fields
 }
--- a/24.md
+++ b/24.md
@ -8,8 +8,7 @@ Extra metadata fields and tags

 This NIP keeps track of extra optional fields that can added to events which are not defined anywhere else but have become _de facto_ standards and other minor implementation possibilities that do not deserve their own NIP and do not have a place in other NIPs.

-kind 0
-======
+### kind 0

 These are extra fields not specified in NIP-01 that may be present in the stringified JSON of metadata events:

@ -19,24 +18,22 @@ These are extra fields not specified in NIP-01 that may be present in the string
  - `bot`: a boolean to clarify that the content is entirely or partially the result of automation, such as with chatbots or newsfeeds.
  - `birthday`: an object representing the author's birth date. The format is { "year": number, "month": number, "day": number }. Each field MAY be omitted.

-### Deprecated fields
+#### Deprecated fields

 These are fields that should be ignored or removed when found in the wild:

  - `displayName`: use `display_name` instead.
  - `username`: use `name` instead.

-kind 3
-======
+### kind 3

 These are extra fields not specified in NIP-02 that may be present in the stringified JSON of follow events:

-### Deprecated fields
+#### Deprecated fields

  - `{<relay-url>: {"read": <true|false>, "write": <true|false>}, ...}`: an object of relays used by a user to read/write. [NIP-65](65.md) should be used instead.

-tags
-====
+### tags

 These tags may be present in multiple event kinds. Whenever a different meaning is not specified by some more specific NIP, they have the following meanings:

--- a/agents.md
+++ b/agents.md
@ -0,0 +1,380 @@
+# NIP-YYY: Standardized LLM/AI Agent Communication Protocol
+
+**Abstract:** This NIP proposes a standardized protocol for Large Language Model (LLM) and AI Agent communication on the Nostr network. It aims to build on and replace many aspects of [NIP-90](./90.md) by providing a more comprehensive and robust specification without the extra bloat. This proposal standardizes communication patterns, LLM parameter exchange, context and state management, service discovery, and secure payment/job contract mechanisms. The goal is to foster a vibrant, interoperable ecosystem of user-agent and agent-agent interactions and transactions.
+
+**Replaces:** [NIP-90](./90.md), specifically kinds [5000](https://github.com/nostr-protocol/data-vending-machines/blob/master/kinds/5000.md)-[5250](https://github.com/nostr-protocol/data-vending-machines/blob/master/kinds/5250.md) content generation services, in general.
+
+**Kind:** `ZZZZ` - *TBD*.
+
+## Terminology
+
+For clarity and consistency, this NIP defines the following terms:
+
+*   **AI (Agent):** A Nostr `pubkey` (typically an automated agent, service, or bot) offering LLM text, multi-modal generation, or other AI-powered services.
+    *   *Why:* Identifies the service provider on Nostr.
+*   **Client:** A Nostr `pubkey` (user or another service) requesting services from an AI Agent.
+    *   *Why:* Identifies the service requestor on Nostr.
+*   **Task Request:** A Nostr event of `kind ZZZZ` sent by a Client to an AI Agent, initiating an AI task.
+    *   *Why:* Standardizes how AI tasks are requested on Nostr.
+*   **Task Result:** A Nostr event of `kind ZZZZ` sent by an AI Agent in response to a Task Request, containing the output or an error.
+    *   *Why:* Standardizes how AI task results are delivered on Nostr.
+*   **Agent Card:** A JSON metadata file, hosted at a publicly accessible URL, describing an AI Agent's capabilities, supported NIPs, interaction protocols, pricing, authentication requirements, and example usage.
+    *   *Why:* Enables discovery, interoperability, and clear communication of an agent's services.
+*   **Context:** Information shared between Client and AI Agent necessary for task completion, including past interactions, session state, and specific instructions, messages, prompts, and/or other data.
+    *   *Why:* Essential for coherent, relevant, and contextually appropriate AI responses, especially in multi-turn conversations.
+*   **Session:** A series of related interactions between a Client and an AI Agent, identified by a unique Session ID.
+    *   *Why:* Enables stateful conversations and efficient context management.
+
+## Motivation
+
+The Nostr protocol's decentralized nature is well-suited for creating open marketplaces of services, including those powered by LLMs and AI. [NIP-90](./90.md) provided an initial generic framework for "data vending machines (DVMs)," but specific standardization for common LLM/AI agent interaction patterns and language model parameters is needed. Current approaches lack clarity and consistency in:
+
+*   Standardized representation of LLM tasks and parameters.
+*   Efficient context and state management for multi-turn conversations.
+*   Discoverability and advertisement of AI agent capabilities.
+*   Secure and reliable payment and job contract mechanisms.
+*   Consistent error handling and communication.
+
+This NIP addresses these gaps by:
+*   Defining a dedicated Nostr `kind` for LLM/AI requests and responses.
+*   Standardizing tag usage for prompts, parameters, session management, payments, and results.
+*   Introducing "Agent Cards" for service discovery and capability description.
+*   Emphasizing secure payment mechanisms using Lightning Network BOLT11 invoices.
+*   Providing guidelines for robust error handling, security, and privacy.
+
+By standardizing these elements, this NIP aims to benefit both users seeking AI assistance and AI agents offering services, fostering innovation and growth within the Nostr AI ecosystem.
+
+## Event Structure
+
+This NIP defines a single event `kind: ZZZZ` for both Client requests and AI Agent responses. The direction and nature of the message are determined by the presence of specific tags and the relationship between the `pubkey` of the event and the referenced `p` tags.
+
+### Common Tags (for Requests and Results)
+
+*   `["p", "<agent_pubkey>"]`: The `pubkey` of the AI Agent. REQUIRED in requests. Agents MAY include this in results, echoing the request.
+*   `["p", "<client_pubkey>"]`: The `pubkey` of the Client. OPTIONAL in requests (agent can infer from event `pubkey`). REQUIRED in results directed to a specific client.
+*   `["e", "<request_event_id>"]`: In a Task Result, this tag MUST be present and reference the `id` of the corresponding Task Request event.
+*   `["t", "<session_id>"]`: A unique identifier (RECOMMENDED: UUID v4) for a conversation or session. Allows the agent to maintain state across multiple events. Clients SHOULD generate this ID for the first request in a session and reuse it for subsequent requests in that session.
+    *   *Rationale:* Replaces sending entire context in every event, enabling efficient stateful interactions.
+*   `["nip_version", "YYYYMMDD"]`: Version of this NIP specification the event adheres to (e.g., "20250520"). Allows for future upgrades.
+
+### Task Request Tags (Client to Agent)
+
+In addition to Common Tags, a Task Request event MUST include:
+
+*   `["request", "<json_string>"]`: A JSON string detailing the task. The structure of this JSON object SHOULD align with common API standards (e.g., OpenAI's `/chat/completions` format) to promote interoperability.
+    *   **RECOMMENDED JSON Structure:**
+        ```json
+        {
+          "model": "string", // Optional: Requested model identifier (agent specific)
+          "messages": [ // REQUIRED: Conversation history or prompt
+            {"role": "user" | "assistant" | "system", "content": "string | object"}
+            // For multi-modal: "content": [{"type": "text", "text": "..."}, {"type": "image_url", "image_url": {"url": "data:image/png;base64,..." | "http://..."}}]
+          ],
+          "response_format": { // Optional: Desired output format
+            "type": "text" | "json_object" // etc.
+          },
+          "parameters": { // Optional: LLM parameters
+            "temperature": 0.7,
+            "max_tokens": 512,
+            // Other common or agent-specific parameters
+          },
+          "tools": [ // Optional: Tools the agent may use
+            // Tool definitions
+          ]
+        }
+        ```
+    *   *Note:* `parameters` here are distinct from the top-level Nostr event tags like `#temperature`. This allows for namespacing and rich parameter structures. Agent Cards (see below) define supported models, parameters, and tools.
+*   `["output_format", "<mime_type>"]`: OPTIONAL. Specifies the desired MIME type of the primary output (e.g., `text/markdown`, `application/json`, `image/png`). This can also be specified within the `request` JSON's `response_format` field. If both are present, the one in the `request` JSON is preferred.
+*   `["contract", "<json_string_or_url>"]`: OPTIONAL. A JSON string or a URL pointing to a JSON file describing the job contract (scope, deliverables, explicit payment terms beyond simple invoice).
+    *   **Example Contract JSON:**
+        ```json
+        {
+          "scope": "Summarize the provided text into 5 bullet points.",
+          "deliverables": ["Markdown formatted summary."],
+          "payment_amount_sats": 1000,
+          "settlement_terms": "Payment upon successful delivery and acceptance (if applicable).",
+          "dispute_resolution": "See agent's policy at <url>."
+        }
+        ```
+*   `["bolt11", "<ln_invoice>"]`: OPTIONAL. A BOLT11 Lightning invoice for pre-payment if the agent requires it.
+
+### Task Result Tags (Agent to Client)
+
+In addition to Common Tags (especially `e` and `p` pointing to client), a Task Result event MUST include one of the following:
+
+*   `["result", "<json_string>"]`: A JSON string containing the successful result from the AI Agent.
+    *   **RECOMMENDED JSON Structure (aligning with OpenAI):**
+        ```json
+        {
+          "id": "string", // Agent-generated ID for this completion
+          "object": "chat.completion", // or other relevant object type
+          "created": 1677652288, // Unix timestamp
+          "model": "string", // Model used for the completion
+          "choices": [
+            {
+              "index": 0,
+              "message": {"role": "assistant", "content": "string | object"},
+              "finish_reason": "stop" | "length" | "tool_calls"
+            }
+          ],
+          "usage": { // Optional: Token usage
+            "prompt_tokens": 56,
+            "completion_tokens": 31,
+            "total_tokens": 87
+          }
+          // Other result fields like tool_calls
+        }
+        ```
+    *   The actual `content` (e.g., text, image data if not in JSON) MAY be in the Nostr event's `content` field if appropriate, or referenced if large. The `result` JSON should clarify where to find the primary output.
+*   `["error", "<json_string>"]`: A JSON string describing an error if the task could not be completed.
+    *   **RECOMMENDED JSON Structure:**
+        ```json
+        {
+          "code": "string", // Standardized error code (see Error Handling section)
+          "message": "string", // Human-readable error message
+          "details": {} // Optional: Additional error-specific details
+        }
+        ```
+
+And MAY include:
+
+*   `["bolt11", "<ln_invoice>"]`: OPTIONAL. If payment is due post-service, the agent includes a BOLT11 invoice.
+*   `["cost", "<json_string>"]`: OPTIONAL. A JSON string detailing the cost breakdown of the service provided.
+    *   **RECOMMENDED JSON Structure:**
+        ```json
+        {
+          "input_tokens": 120,
+          "output_tokens": 350,
+          "price_sats": 500,
+          "currency": "sats", // Default "sats", could be other if specified in Agent Card
+          "breakdown": [
+            {"item": "model_usage", "cost_sats": 450},
+            {"item": "tool_xyz", "cost_sats": 50}
+          ]
+        }
+        ```
+
+## Agent Cards
+
+To facilitate discovery and interoperability, AI Agents SHOULD publish an "Agent Card." This is a JSON file hosted at a publicly accessible URL, linked from the agent's [NIP-05](./05.md) identifier or a dedicated [NIP-89](./89.md)-style announcement (e.g., kind `3ZZZZ`, where `ZZZZ` is the NIP kind). Agent Cards offer a much more detailed and reliable way to describe an agent's details, parameters, and custom properties, without the need to perpetually broadcast [NIP-89](./89.md) announcements.
+
+Agent Cards MUST be versioned (e.g., using a `version` field or SemVer in the URL). Clients SHOULD cache Agent Cards but periodically refresh them.
+
+**Agent Card JSON Structure (Example):**
+
+```json
+{
+  "nip_yyy_version": "20250520", // Version of this NIP it adheres to
+  "agent_card_version": "1.1.0", // Version of this card
+  "name": "My Awesome AI Assistant",
+  "pubkey": "<agent_nostr_pubkey>",
+  "description": "Provides text summarization and translation services.",
+  "capabilities": {
+    "tasks": [
+      {"type": "summarization", "description": "Summarizes text up to 5000 words."},
+      {"type": "translation", "description": "Translates between EN, ES, FR."}
+    ],
+    "supported_models": ["gpt-3.5-turbo-instruct", "custom-summarizer-v2"],
+    "supported_input_formats": ["text/plain", "text/markdown"],
+    "supported_output_formats": ["text/plain", "text/markdown", "application/json"],
+    "max_context_tokens": 4096,
+    "context_refresh_strategy": "summarize_last_5_turns" // e.g.
+  },
+  "interaction_protocols": [ // How to interact (beyond this NIP, if any)
+    {"type": "nostr_nip_yyy", "kind": "ZZZZ"},
+    {"type": "http_api", "endpoint_url": "https://api.exampleagent.com/v1", "docs_url": "..."}
+  ],
+  "llm_parameters_schema": { // JSON schema or link to one for supported `request.parameters`
+    "$ref": "https://api.exampleagent.com/v1/params_schema.json"
+  },
+  "pricing": {
+    "default_currency": "sats",
+    "models": [
+      {
+        "id": "gpt-3.5-turbo-instruct",
+        "input_cost_per_1k_tokens": 10,
+        "output_cost_per_1k_tokens": 30
+      }
+    ],
+    "payment_methods_accepted": ["bolt11_prepaid", "bolt11_postpaid", "escrow_hodl_optional"],
+    "escrow_details": { // If escrow is supported
+      "preferred_escrow_providers": ["<mostro_pubkey>", "https://escrow.service/api"],
+      "min_escrow_value_sats": 5000
+    }
+  },
+  "authentication": { // How the agent authenticates clients if needed
+    "type": "none" // or "nip98", etc.
+  },
+  "rate_limits": {
+    "anonymous_requests_per_hour": 10,
+    "authenticated_requests_per_hour": 100,
+  },
+  "terms_of_service_url": "https://exampleagent.com/tos",
+  "privacy_policy_url": "https://exampleagent.com/privacy",
+  "example_request": { // A full Nostr event example for this agent
+    "kind": "ZZZZ",
+    "pubkey": "<client_pubkey>",
+    "created_at": 0,
+    "tags": [
+      ["p", "<agent_nostr_pubkey>"],
+      ["request", "{\"messages\":[{\"role\":\"user\",\"content\":\"Summarize this...\"}], \"model\":\"custom-summarizer-v2\"}"]
+    ],
+    "content": "This is the text to summarize...",
+    "id": "...",
+    "sig": "..."
+  }
+}
+```
+
+*Frameworks like Open Agentic Schema Framework (OASF) or Agents JSON can provide further inspiration for Agent Card structures.*
+
+## LLM/AI Parameter Standardization
+
+*   Parameters specific to LLM calls (e.g., temperature, max_tokens, top_p) SHOULD be included within the `["request", "<json_string>"]` tag's JSON payload, under a `parameters` key.
+*   Agent Cards MUST define or link to a schema (e.g., JSON Schema) for the `parameters` they accept, including data types, ranges, and default values.
+*   Agents SHOULD adopt common parameter names where functionality aligns (e.g., `temperature`, `max_tokens`).
+*   Naming conventions for proprietary model files/identifiers (e.g., `Llama-3-8b-Instruct-Q4_K_M.gguf`) can be useful for clients but are agent-specific and should be listed in the Agent Card.
+
+## Context and State Management
+
+*   The `["t", "<session_id>"]` tag is CRUCIAL for managing state across multiple interactions. Clients are responsible for generating and reusing session IDs.
+*   AI Agents are responsible for storing and retrieving context based on the `session_id`. This may involve in-memory storage, external databases, or even storing encrypted context in Nostr events (if small enough and privacy-preserving).
+*   Agent Cards MAY specify their context window limits (e.g., `max_context_tokens`) and context refresh strategies (e.g., "truncate FIFO," "summarize conversation every N turns").
+*   Clients SHOULD be mindful of agent context limits and manage the information sent accordingly.
+
+## Payment, Job Contracts, and Escrow
+
+*   **Direct Payment:**
+    *   Pre-payment: Client includes a `["bolt11", "<invoice>"]` in the Task Request.
+    *   Post-payment: Agent includes a `["bolt11", "<invoice>"]` in the Task Result.
+    *   The `["cost", "<json_string>"]` tag in the Task Result provides transparency.
+*   **Job Contracts:** The `["contract", "<json_string_or_url>"]` tag allows for defining scope, deliverables, and payment terms beyond a simple invoice.
+*   **Lightning Network Escrow:** For higher-value or trust-sensitive tasks, escrow is STRONGLY RECOMMENDED.
+    *   Agents supporting escrow SHOULD specify this in their Agent Card, including preferred escrow mechanisms (e.g., HODL invoices, PTLCs) and potentially trusted escrow service providers (e.g., Mostro - `https://mostro.network/`).
+    *   The job contract (`["contract"]` tag) can specify escrow terms, including the escrow agent's `pubkey` and fees.
+    *   The escrow process might involve a 2-of-3 multisig or interaction with an escrow service via Nostr messages. (Detailed escrow NIPs may be referenced here in the future).
+*   **Reputation Systems:** While this NIP doesn't define a specific reputation system, agents and clients are encouraged to participate in emerging Nostr-based reputation protocols. Agent Cards MAY link to reputation profiles. Verifiable behavior logs (e.g., publishing anonymized success/failure rates) can build trust.
+*   **Payment Splitting:** For tasks involving multiple agents, the primary agent coordinating the task is responsible for handling payments to sub-agents. The main contract may specify this.
+
+## Discovery of AI Agents
+
+*   **Agent Cards:** As described above, linked from [NIP-05](./05.md) or a dedicated [NIP-89](./89.md) announcement.
+*   **[NIP-89](./89.md) Application Handlers:** Agents SHOULD advertise their support for this NIP (`kind ZZZZ`) via [NIP-89](./89.md), allowing clients to discover them.
+*   **Dedicated Announcement Kind:** A kind like `3ZZZZ` (e.g., `37001` if `ZZZZ` is `7001`) can be used for agents to announce their Agent Card URL and key capabilities using standardized tags (e.g., `["capability", "text_summarization"]`, `["capability", "image_generation"]`).
+*   **Searchable Tags:** Using standardized tags in these announcements facilitates client-side searching and filtering.
+*   **Directories:** Services like Nostrbook MAY be leveraged to list AI agents and their Agent Cards.
+
+## Error Handling
+
+AI Agents MUST use the `["error", "<json_string>"]` tag in their Task Result event if a task fails. The JSON string SHOULD contain:
+
+*   `code`: A standardized error code.
+*   `message`: A human-readable error message.
+*   `details`: OPTIONAL. An object with additional information specific to the error.
+
+**Standard Error Codes (Inspired by HTTP, but extensible):**
+
+*   `BAD_REQUEST` (400 equivalent): Malformed request, invalid JSON, missing required fields.
+*   `UNAUTHORIZED` (401 equivalent): Authentication failed or required but not provided.
+*   `PAYMENT_REQUIRED` (402 equivalent): Payment is required to process the request.
+*   `FORBIDDEN` (403 equivalent): Client is not allowed to access this resource/perform this action.
+*   `NOT_FOUND` (404 equivalent): Requested model or resource not found.
+*   `RATE_LIMIT_EXCEEDED` (429 equivalent): Client has sent too many requests.
+*   `AGENT_ERROR` (500 equivalent): An unexpected error occurred on the agent's side.
+*   `MODEL_ERROR`: The underlying LLM or AI model reported an error.
+*   `SERVICE_UNAVAILABLE` (503 equivalent): The agent is temporarily overloaded or down for maintenance.
+*   `TIMEOUT`: The request timed out.
+*   `INSUFFICIENT_FUNDS`: For pre-paid services, if payment was insufficient.
+*   `CONTENT_TOO_LARGE`: Input content exceeds agent's limits.
+*   `INVALID_PARAMETER`: A specified parameter in the request is invalid or unsupported.
+
+## Security Considerations
+
+*   **Authentication:** Agents MAY require client authentication (e.g., [NIP-98](./98.md)) for certain operations or to access higher rate limits. This SHOULD be specified in the Agent Card.
+*   **Input Validation & Sanitization:** Agents SHOULD validate and sanitize all inputs from clients to prevent prompt injection, denial-of-service, and other attacks.
+*   **Output Sanitization:** Agents SHOULD sanitize outputs to prevent the generation of malicious content or exposure of sensitive information.
+*   **Resource Limits:** Agents SHOULD implement resource limits (CPU, memory, time) for processing requests to prevent abuse.
+*   **Rate Limiting:** Agents SHOULD implement rate limiting based on `pubkey`, IP address (if applicable), or other factors. Details MAY be in the Agent Card.
+*   **Encryption:** For sensitive data, communication SHOULD utilize end-to-end encryption (e.g., [NIP-04](./04.md)/[NIP-17](./17.md)/[NIP-44](./44.md) between client and agent for the content of `request` and `result` tags if not already encrypted within the payload).
+*   **Permissions:** Agents that can perform actions (e.g., call tools, interact with other services) SHOULD operate under the principle of least privilege.
+*   **Client-Side Caution:** Clients SHOULD be cautious when interacting with unknown or untrusted AI Agents. Verify Agent Cards and look for community trust signals.
+*   **Session Security:** Session IDs (`t` tag) are not inherently secret. Do not embed sensitive capability-granting tokens directly in them. Use established authentication methods for sensitive operations within a session.
+
+## Privacy Considerations
+
+*   **Data Minimization:** Agents SHOULD only request and store data necessary for providing the service.
+*   **Transparency:** Agents SHOULD clearly state their data handling practices in their privacy policy, linked from the Agent Card.
+*   **Data Deletion:** Clients SHOULD have a way to request deletion of their data, and agents SHOULD comply as per their privacy policy.
+*   **Anonymization/Pseudonymization:** Agents SHOULD consider anonymizing or pseudonymizing data used for logging or analytics.
+
+## Removed Features (from [NIP-90](./90.md) context)
+
+*   **Job Chaining:** Removed to simplify the protocol. Complex workflows can be orchestrated by clients by making sequential requests, linked by standard tags, `session_id`s, and timestamps.
+*   **Bid System:** Removed. Pricing is made explicit via Agent Cards and the `cost` tag, or negotiated through contracts. This reduces complexity and latency. Simple overpayments MAY be used to incentivize agents to complete tasks during high demand.
+
+## Extensibility
+
+This NIP is designed to be extensible:
+*   New tags can be proposed for future needs.
+*   The JSON structures within `request`, `result`, `error`, `contract`, and `cost` tags can evolve, ideally with backward compatibility or clear versioning in Agent Cards.
+*   Agent Cards themselves are versioned and can be extended with new fields.
+
+## Example Flow (Summarization Task)
+
+1.  **Client Discovers Agent:** Client finds an agent supporting `kind ZZZZ` via [NIP-89](./89.md) or a directory, and fetches its Agent Card.
+2.  **Client Constructs Request:**
+    ```json
+    // Nostr Event
+    {
+      "kind": "ZZZZ",
+      "pubkey": "<client_pubkey>",
+      "created_at": 1678886400,
+      "tags": [
+        ["p", "<agent_pubkey>"],
+        ["t", "session-uuid-123"],
+        ["request", "{\"messages\":[{\"role\":\"user\",\"content\":\"Please summarize this article for me.\"}], \"model\":\"text-davinci-003\", \"parameters\":{\"max_tokens\":150}}"],
+        ["output_format", "text/markdown"],
+        ["nip_version", "20250520"]
+      ],
+      "content": "Nostr is a simple, open protocol that enables global, decentralized, and censorship-resistant social media. ... (long article text) ...",
+      "id": "<request_event_id>",
+      "sig": "..."
+    }
+    ```
+3.  **Agent Processes and Responds:**
+    ```json
+    // Nostr Event
+    {
+      "kind": "ZZZZ",
+      "pubkey": "<agent_pubkey>",
+      "created_at": 1678886405,
+      "tags": [
+        ["p", "<client_pubkey>"],
+        ["e", "<request_event_id>"],
+        ["t", "session-uuid-123"],
+        ["result", "{\"id\":\"comp-xyz\",\"object\":\"text_completion\",\"created\":1678886405,\"model\":\"text-davinci-003\",\"choices\":[{\"text\":\"Nostr is a simple, open protocol for decentralized social media.\",\"index\":0,\"finish_reason\":\"length\"}],\"usage\":{\"prompt_tokens\":500,\"completion_tokens\":150,\"total_tokens\":650}}"],
+        ["cost", "{\"input_tokens\":500,\"output_tokens\":150,\"price_sats\":65,\"currency\":\"sats\"}"],
+        ["nip_version", "20250520"]
+      ],
+      "content": "", // Result is in the 'result' tag
+      "id": "<result_event_id>",
+      "sig": "..."
+    }
+    ```
+
+## References
+
+*   [NIP-01](./01.md): Basic protocol flow
+*   [NIP-04](./04.md): Encrypted Direct Message
+*   [NIP-05](./05.md): Mapping Nostr keys to DNS-based internet identifiers
+*   [NIP-17](./17.md): Encrypted Direct Messages v2
+*   [NIP-44](./44.md): Encrypted Direct Messages v3
+*   [NIP-89](./89.md): Recommended Application Handlers
+*   [NIP-90](./90.md): Data Vending Machines
+*   [NIP-98](./98.md): HTTP Auth
+*   [Agent Protocol (LangChain)](https://github.com/langchain-ai/agent-protocol)
+*   [Open Agentic Schema Framework (OASF)](https://github.com/agntcy/oasf)
+*   [Agents JSON](https://github.com/wild-card-ai/agents-json)
+*   [Mostro (Lightning Escrow)](https://github.com/MostroP2P)
+*   [OpenAI API Reference](https://platform.openai.com/docs/api-reference)
+*   [JSON Schema](https://json-schema.org/)
Author	SHA1	Message	Date
Rob	d0eb45e1e9	Merge `20f2eb37f7` into `7dec812f99`	2025-08-12 14:41:59 +02:00
Awiteb	7dec812f99	nip22: fix example type for external URL (#2011 )	2025-08-11 17:26:05 -04:00
Yoji Shidara	739f3c5263	NIP-24: Fix heading levels (#2009 )	2025-08-11 19:37:53 +09:00
Yoji Shidara	8830525250	NIP-21: Fix markup issue by closing backtick (#2008 )	2025-08-11 19:35:36 +09:00
landonMutch	20f2eb37f7	link improvements, replace kind5000-5250	2025-05-19 21:03:38 -07:00
landonMutch	f7767795fc	add links, other improvements, clarifications	2025-05-19 20:37:13 -07:00
landonMutch	aef171b8ac	init agent spec	2025-05-19 19:41:58 -07:00