Tracked: morrowind agent (py/cfg), skills/, training-data/, research/, notes/, specs/, test-results/, metrics/, heartbeat/, briefings/, memories/, skins/, hooks/, decisions.md, OPERATIONS.md, SOUL.md Excluded: screenshots, PNGs, binaries, sessions, databases, secrets, audio cache, timmy-config/ and timmy-telemetry/ (separate repos)
173 lines
8.8 KiB
Markdown
173 lines
8.8 KiB
Markdown
# 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
|