timmy-home/kimi-research-queue.md

Kimi Deep Research Queue

Budget: ~97 tokens remaining (2 used: Architecture + Implementation reports)

Priority: highest-leverage research that unblocks multiple issues

NOTE: Reports #1+#2 covered L402, Nostr identity, cost estimation extensively

Redirecting those slots to gaps that remain

BATCH 1 — Fire Now (3 prompts)

Research 1: L402 Implementation Blueprint

Maps to: token-gated-economy #40, #46, the-matrix #9

Provide a complete implementation blueprint for L402 (formerly LSAT) protocol 
gating AI inference APIs with Bitcoin Lightning micropayments.

I need PRODUCTION CODE, not theory. My stack: Node.js/Express backend on Replit, 
LNbits for wallet management, Three.js frontend.

Cover with code examples:
1. Server middleware: Express middleware returning HTTP 402 with BOLT11 invoice + 
   macaroon in WWW-Authenticate header. Show exact header format.
2. Macaroon minting: How to create macaroons with caveats encoding job_id, model, 
   estimated_tokens, refund_policy, expiry. Libraries: js-macaroon or macaroons.js.
3. Client flow: Browser/agent pays invoice, gets preimage, retries with 
   Authorization: L402 <macaroon>:<preimage>. Show fetch() code.
4. Session mode: Using macaroon caveats to gate a session (multiple requests) 
   rather than single request. Session balance tracking.
5. LNbits integration: Using LNbits API (v1, not deprecated v0) for invoice 
   creation, payment verification, webhook on settlement.
6. Existing open-source implementations: aperture (Lightning Labs), L402 middleware 
   packages, any Node.js libraries.
7. Security: Replay prevention, macaroon attenuation, preimage verification.

Focus on what I can ship in a weekend with LNbits + Express + existing npm packages.

Research 2: Nostr-Native Identity for AI Agent Economy

Maps to: token-gated-economy #44, dashboard #245 (stream adapters)

Design a pseudonymous identity system for an AI compute marketplace using Nostr 
and Lightning, with NO KYC and NO custodial accounts.

My platform: Users pay Lightning invoices to interact with AI agents. I need to 
know who repeat customers are (for credits, reputation, trust tiers) without 
requiring email/password/KYC.

Cover with implementation details:
1. Nostr npub as identity anchor: How users authenticate with NIP-07 browser 
   extension (nos2x, Alby). Login flow: sign challenge → verify signature → 
   create session.
2. Lightning node pubkey as identity: Can the payer's node pubkey be extracted 
   from a settled HTLC? What does LND's SubscribeInvoices reveal about payers?
3. Trust tiers from payment history: Building reputation from cumulative payment 
   volume without storing PII. Tier thresholds in sats.
4. NIP-98 HTTP Auth: Using Nostr events as HTTP authentication tokens. How does 
   this compare/integrate with L402?
5. Decentralized reputation: Stacker News model, Web of Trust via Lightning 
   channels, NIP-32 labels for reputation.
6. BIP-322 message signing: Proving Bitcoin address ownership without spending.
7. Existing implementations: How RoboSats, Stacker News, and Nostr marketplaces 
   handle pseudonymous identity. What works, what doesn't.
8. Integration pattern: User has Nostr key + Lightning wallet. They sign in with 
   Nostr, pay with Lightning. How to link the two identities cryptographically.

I want users identified by their keys, not their names. Sovereignty first.

Research 3: Lightning Refund Engineering

Maps to: token-gated-economy #46 (session mode), Kimi report Section 3.1

Engineer an automated Lightning Network refund system for honest-accounting AI 
compute. Users pay estimated cost upfront, actual cost is measured, overpayment 
is refunded automatically.

My stack: LNbits on Replit, Node.js backend, jobs take 5-60 seconds.

Cover with code and state machines:
1. Refund via keysend vs refund invoice: LNbits keysend API (push payment without 
   invoice from recipient) vs generating a refund invoice the user must pay. 
   Tradeoffs in UX, privacy, and implementation complexity.
2. The problem: Lightning payers are anonymous. When a user pays an invoice, can 
   I identify them for refund? What does LNbits/LND reveal? If not, how do I 
   deliver refunds?
3. Refund-by-preimage pattern: User proves they paid original invoice by presenting 
   preimage. Platform verifies SHA256(preimage) == payment_hash. Then what? 
   Options: a) user provides their own invoice for refund amount, b) keysend to 
   their node, c) credit balance.
4. State machine: job lifecycle states (created → invoiced → paid → executing → 
   metering → completed → refund_eligible → refund_claimed/expired). Exact state 
   transitions with LNbits webhook triggers.
5. Minimum refund thresholds: When is a refund too small to bother? Dust limits, 
   routing fee overhead, UX friction. Suggest thresholds.
6. Abandoned refunds: User never claims. Timeout policy. Where do unclaimed 
   sats go?
7. Concrete LNbits API calls: Exact endpoints for creating invoices, checking 
   payment status, issuing keysend, with request/response examples.

I need a working state machine I can implement, not a theoretical framework.

BATCH 2 — Fire After Batch 1 Returns (2 prompts)

Research 4: AI Inference Cost Estimation & Calibration

Maps to: Kimi report Section 1.2, token-gated-economy core pricing

Build a cost estimation model for AI inference that supports honest accounting 
(estimate upfront, measure actual, refund difference).

My setup: Multiple model backends (local qwen3:30b via Ollama, cloud APIs as 
fallback). Jobs are text-in/text-out chat completions.

Cover with formulas and algorithms:
1. Token prediction: Given an input prompt, how to estimate output token count 
   BEFORE generation. Approaches: historical averages by prompt type, input 
   length correlation, complexity heuristics.
2. Cost-per-token by model: How to benchmark and maintain a rate card. Include 
   local inference cost (GPU-seconds/token amortized over hardware cost) vs 
   cloud API cost (direct pricing).
3. The 90th percentile estimate: Why estimate at P90 not mean. How to calibrate 
   the percentile over time with a feedback loop. Exponential moving average of 
   estimate accuracy.
4. Confidence scoring: Output a 0-100 confidence with each estimate. Low 
   confidence = high variance jobs (creative writing, chain-of-thought). High 
   confidence = predictable jobs (classification, extraction).
5. Real-world data: What do OpenAI/Anthropic/Together.ai charge per token? What's 
   the typical estimate-to-actual ratio for chat completions?
6. Edge cases: Long context window costs, chain-of-thought reasoning explosion, 
   tool-use loops, retry costs. How to bound worst-case.
7. Concrete implementation: Python/JS class that takes (model_id, input_tokens, 
   job_type) and returns (estimated_cost_sats, confidence, p50_cost, p90_cost).

I need a formula I can code, not a survey paper.

Research 5: Sovereign Lightning Node Operations for AI Platforms

Maps to: token-gated-economy #41 (auto-sweep), #19 (LNbits API), the-matrix #51

Operational guide for running Lightning infrastructure for an AI payment platform, 
focused on sovereignty and automation.

Current setup: LNbits instance, considering LND directly. Single VPS deployment.
Goal: Handle 100-1000 micropayments/day (50-15000 sats each).

Cover with operational procedures:
1. LNbits vs raw LND: When to graduate from LNbits to running LND directly. 
   What LNbits abstracts vs what you lose. Can they coexist?
2. Channel management automation: Scripts/tools for auto-opening channels with 
   well-connected nodes, rebalancing, fee adjustment. Existing tools: Balance 
   of Satoshis (bos), charge-lnd, rebalance-lnd.
3. Inbound liquidity: How to get inbound capacity for receiving payments. LSPs 
   (Lightning Service Providers), liquidity ads, channel leasing. Costs and 
   tradeoffs.
4. Hot wallet security: Auto-sweep excess to cold storage (on-chain). Threshold 
   management. Multi-sig for cold storage.
5. Monitoring and alerting: What to monitor (channel balance, pending HTLCs, 
   force closes, fee rates). Prometheus exporters, Grafana dashboards. 
   Existing: lndmon, thunderhub.
6. Backup and recovery: SCB (Static Channel Backups), seed phrase management, 
   disaster recovery procedure.
7. Scaling from 1 node: When to add a second node. Geographic distribution. 
   Load balancing incoming payments across nodes.
8. Cost model: What does it cost to run Lightning infra for this volume? 
   Channel opening fees, rebalancing costs, VPS costs.

Operational focus — I want runbooks, not architecture diagrams.

TRACKING

• Research 1: L402 — NOT STARTED
• Research 2: Nostr Identity — NOT STARTED
• Research 3: Refund Engineering — NOT STARTED
• Research 4: Cost Estimation — NOT STARTED
• Research 5: Lightning Node Ops — NOT STARTED