update RIPs

RIP-01.md

@@ -1,25 +1,52 @@
 # RIP-01: OpenAI-API Proxy with Cashu Payments
 
+[x] - Implement HTTP proxy interface for OpenAI-compatible API requests
+
+- [x] Integrate per-request micropayment handling via Cashu tokens
+- [x] Support endpoints:
+  - [x] POST /v1/{path:path} (proxy to upstream AI service)
+  - [x] GET /v1/wallet (get Cashu token balance and API key)
+  - [x] POST /v1/wallet/topup (top up wallet with Cashu token)
+  - [x] POST /v1/wallet/refund (refund remaining balance as Cashu token)
+- [x] Authorization via Bearer API key or Cashu token
+- [x] API key and Cashu token validation and redemption
+- [x] Token-based pricing for chat/completions with MODEL_BASED_PRICING
+- [x] SSE and JSON cost reporting in responses
+- [ ] Tor hidden service deployment support
+- [ ] Admin dashboard for monitoring and settings
+
 Defines the HTTP proxy interface forwarding OpenAI-compatible API requests, with per-request micropayment handling via Cashu tokens.
 
 ## Endpoints
 
-### POST /{path:path}
+### POST /v1/{path:path} e.g. /v1/chat/completions
 
 Forward proxied requests to the upstream AI service at `UPSTREAM_BASE_URL`.
+This is usually your llamacpp or vllm server.
+
+### GET /v1/wallet
+
+Get the balance of the Cashu token and the associated API key.
+
+### POST /v1/wallet/topup
+
+Top up the balance of that temporary wallet with another Cashu token.
+
+### POST /v1/wallet/refund
+
+Recieve the full amount of the remaining balance as a Cashu token.
 
 #### Authorization
 
 - Header: `Authorization: Bearer <api-key>` or `Bearer <cashu-token>`
 - API keys: prefixed `sk-`, validated against stored hashed keys.
-- Cashu tokens: prefixed `cashu`, redeemed via Cashu L3 mint.
+- Cashu tokens: prefixed `cashu`, redeemed via Cashu mint.
 
 #### Payment Flow
 
-1. **Validation**: Verify bearer key and ensure balance ≥ `COST_PER_REQUEST` msats.
-2. **Charge Base**: Deduct `COST_PER_REQUEST` from user balance; record request count.
-3. **Forward**: Send request upstream, applying `UPSTREAM_API_KEY` override if set.
-4. **Token-Based Pricing (Optional)**: For chat/completions when `MODEL_BASED_PRICING`=true:
+1. **Balance**: The cashu token is redeemed and the balance is credited internally (allows reuse of the same token for multiple requests).
+2. **Api-Key**: Each balance has an associated API key that allowes for top-ups.
+3. **Token based pricing**: For chat/completions when `MODEL_BASED_PRICING`=true:
    - Parse upstream `usage.prompt_tokens` and `usage.completion_tokens`.
    - Compute `input_msats` = prompt_tokens/1000 × model.prompt_price.
    - Compute `output_msats` = completion_tokens/1000 × model.completion_price.
@@ -38,8 +65,12 @@ Forward proxied requests to the upstream AI service at `UPSTREAM_BASE_URL`.
 - `502 Bad Gateway`: Upstream service unavailable.
 - `500 Internal Server Error`: Unexpected errors.
 
-## Configuration
+## Tor Routing
 
-- `COST_PER_REQUEST`: Base cost in msats (env `COST_PER_REQUEST`).
-- `MODEL_BASED_PRICING`: Enable token pricing (env `MODEL_BASED_PRICING`).
-- `COST_PER_1K_INPUT_TOKENS` & `COST_PER_1K_OUTPUT_TOKENS`: Fallback pricing if `models.json` not present.
+Every node can be deployed as a Tor hidden service.
+
+## Multi model support
+
+Each node can serve multiple models.
+These models are defined in the root `/` endpoint.
+Including node information and pricing.

RIP-02.md

@@ -1,5 +1,7 @@
 # RIP-02: Node Listing
 
+- [ ] Create PR to the Nostr repo to add a new Kind 40500 event
+
 Nodes announce their presence and capabilities via a Nostr event for client discovery.
 
 **Kind**: 40500
@@ -12,10 +14,7 @@ Nodes announce their presence and capabilities via a Nostr event for client disc
     ["d", "<node-id>"],       // Unique node identifier
     ["p", "<operator-pubkey>"],
     ["url", "https://..."],    // Inference endpoint
-    ["model", "<model-id>"],   // Repeatable
-    ["price", "<msats>"],      // mSAT per request
-    ["region", "<ISO-region>"],
-    ["latency_ms", "<avg-ms>"]
+    ["onion", "<tor-onion-address>"], // Tor hidden service endpoint
   ],
   "content": "Human-readable description"
 }

RIP-03.md

@@ -1,9 +1,31 @@
+# TODO
+
+- [x] 100% local frontend (no backend)
+- [x] UI components: search bar, filters panel, model card (description, models, price)
+- [x] Include chat application, discovery interface, landing page, and documentation
+- [x] Support Nostr-based login
+- [x] Cashu wallet integration
+- [ ] Filter nodes by supported models, region, price range, social proximity, and average rating
+- [ ] Allow users to publish personal node information and interact with nodes
+- [ ] List active nodes from Nostr Kind 40500
+- [ ] Subscribe to Nostr Kind 40500 & 31555 events
+- [ ] Maintain in-memory index and update on new events
+- [ ] Render node list with applied filters
+- [ ] Real-time UI updates on new events
+
 # RIP-03: Frontend Discovery
 
-Defines the web or app interface for browsing and filtering available inference nodes based on social network and evolving evals.
+This document defines a fully client-side, 100% local web or app interface for node discovery, chat, and interaction. There is no backend: all logic and data flow run in the user's browser or device. The frontend includes a chat application, discovery interface, landing page, and documentation. Authentication and filtering leverage Nostr for login and social graph-based filtering. Users can publish their own node information or interact with available nodes directly from the interface.
 
 ## Features
 
+- 100% local frontend: no backend, all data and logic run on the client.
+- Includes:
+  - Chat application
+  - Discovery interface
+  - Landing page
+  - Documentation
+- Nostr-based login and filtering (social graph proximity)
 - List active nodes from Nostr Kind 40500.
 - Filter by:
   - Supported model(s)
@@ -11,6 +33,7 @@ Defines the web or app interface for browsing and filtering available inference
   - Price range
   - Social network proximity (follow graph)
   - Average rating (from evals)
+- Publish personal node information or interact with nodes
 - Future: Toggle eval visibility once RIP-04 is live.
 
 ## UI Components

RIP-04.md

@@ -1,25 +1,56 @@
+# TODO
+
+- [ ] Implement independent evaluation (eval) services for LLM providers
+- [ ] Scan Nostr for all advertised providers
+- [ ] Run anonymized, randomized, proxied evaluation jobs
+- [ ] Prevent providers from detecting evals (randomization, proxying, ephemeral keys)
+- [ ] Publish benchmark reports for each provider (Kind 31555)
+- [ ] Support free and paid report tiers (monetization)
+- [ ] Measure and report quality, latency, and cost metrics
+- [ ] Use ephemeral Nostr keys per eval
+- [ ] Publish standard rating tags: d (node-id), rating (quality, latency, value), content (notes)
+- [ ] Batch multiple evaluations in one event
+- [ ] Limit eval jobs to ≤5% of overall requests
+- [ ] Provide objective, third-party benchmarks for provider comparison and ranking
+
 # RIP-04: Evaluations & Quality Control
 
-Specifies how clients anonymize and randomize evaluation submissions to mimic normal inference requests.
+Specifies how independent evaluation (eval) services scan Nostr for all advertised LLM providers, run anonymized and randomized evals, and publish benchmark reports for each provider.
 
 ## Goals
 
 - Prevent provider bias by making evals indistinguishable from real inference calls.
 - Collect unbiased metrics on quality, latency, and cost.
+- Establish eval services as the primary source of trust and ranking in the marketplace.
+
+## Eval Service Model
+
+- Evals are separate, continuously running services that monitor Nostr for all LLM providers advertising their capabilities.
+- For each discovered provider, the eval service runs anonymized, randomized, and proxied evaluation jobs to ensure providers cannot distinguish eval requests from normal user traffic.
+- Evals are designed to prevent providers from treating evals differently than real users, using strategies such as randomization, proxying, and ephemeral keys.
+- After running evals, the service publishes a report for each provider, containing benchmark scores and detailed metrics.
+
+## Report Tiers & Monetization
+
+- There are multiple tiers of reports:
+  - **Free Report:** All providers receive a basic report at no cost, summarizing essential metrics.
+  - **Paid Reports:** Providers can pay the eval service (in sats) to receive more advanced, detailed reports. These paid reports offer deeper insights, improve user trust, and help the provider rank higher in the marketplace.
+- Eval services are a monetizable component of the ecosystem, earning fees for advanced reporting and acting as a trusted third party.
 
 ## Eval Flow
 
-1. Client selects a subset of providers based on discovery.
-2. For each eval job:
+1. Eval service scans Nostr for all advertised providers.
+2. For each provider:
    - Generate randomized inference parameters.
-   - Send inference request randomized with proxy.
+   - Send anonymized, proxied inference requests.
    - Measure latency, output quality against ground truth.
 3. Assemble eval result and prepare Nostr event:
    - Use new random ephemeral Nostr key per eval.
    - Publish Kind 31555 with standard rating tags:
      - `d`: provider node-id
      - `rating` categories: `quality`, `latency`, `value`
-   - No direct link to client's main pubkey.
+   - No direct link to eval service's main pubkey.
+4. Publish report (free or paid tier) with benchmark scores.
 
 ## Tags
 
@@ -30,15 +61,21 @@ Specifies how clients anonymize and randomize evaluation submissions to mimic no
   - `value`: cost vs performance
 - `content`: optional detailed notes
 
-## Anonymity
+## Anonymity & Randomization
 
 - Ephemeral keys rotated per session.
 - Randomized send times & intervals.
+- All requests are proxied and randomized to prevent provider detection.
 
 ## Aggregation
 
-- Clients can batch multiple evaluations in one event by repeating `rating` tags.
+- Eval services can batch multiple evaluations in one event by repeating `rating` tags.
 
 ## Frequency
 
 - Limit eval jobs to ≤5% of overall requests to avoid load spikes.
+
+## Trust & Benchmarking
+
+- Eval services are the source of trust in the marketplace, providing objective, third-party benchmarks.
+- Each report results in a set of benchmark scores, enabling transparent provider comparison and ranking.

RIP-05.md

@@ -1,39 +1,79 @@
-# RIP-05: Smart Clients & Token Management
+# TODO
 
-Defines client-side behavior for automated token cycling, proxy/Tor usage, and provider optimization.
+- [ ] Develop multi-language SDKs (Python, TypeScript/JavaScript, Go, Rust, etc.)
+- [ ] Implement full-stack components: client, server, discovery, evaluation server, chat API
+- [ ] Provide unified interfaces for Cashu wallet management, API key rotation, proxy/anonymity
+- [ ] Expose high-level abstractions in SDKs (token management, API key rotation, provider selection, proxy/Tor integration, secure flows)
+- [ ] Smart clients: automated token cycling/top-up, per-request API key rotation, proxy/Tor circuit selection
+- [ ] Dynamic provider discovery and scoring (price, latency, rating, reliability)
+- [ ] Pluggable architecture for custom scoring, proxy, or wallet backends
+- [ ] Reference implementations for server, discovery, and evaluation endpoints in each language
+- [ ] Standardized APIs for provider registration, health, and metrics
+- [ ] Modular evaluation server for benchmarking and rating providers
+- [ ] Chat API reference implementations (real-time and batch)
+- [ ] Built-in proxy and Tor routing in all SDKs and clients
+- [ ] Automated rotation of API keys and tokens
+- [ ] Rate limiting and circuit rotation to prevent fingerprinting
+- [ ] Define core protocol interfaces and data models in each language
+- [ ] Maintain open-source SDKs and reference servers
+- [ ] Ensure feature parity and cross-language test suites
+- [ ] Document integration patterns and privacy best practices
 
-## Responsibilities
+# RIP-05: SDKs & Smart Clients
 
-- Maintain local Cashu wallet and balance.
-- Auto-redeem and split tokens into per-request msat units.
-- Route inference requests through proxies or Tor to obfuscate origin.
-- Continuously monitor discovery for better providers (price, latency, rating).
+This RIP proposes a comprehensive suite of SDKs and Smart Client libraries across multiple programming languages, enabling seamless integration with the protocol and ensuring robust privacy, payment, and provider management.
 
-## Workflow
+## Scope
 
-1. **Initialization**
-   - Load master wallet token.
-   - Pre-split tokens into request-sized shards.
-2. **Request Execution**
-   - Select provider based on weighted metrics (price, latency, rating).
-   - Choose random proxy or Tor circuit.
-   - Attach one token shard as payment credential.
-   - Send inference request off-chain.
-3. **Monitoring**
-   - Track per-provider performance over time.
-   - On token exhaustion, auto-top-up from wallet.
-   - Adjust provider weights for future selection.
+- Multi-language SDKs: Python, TypeScript/JavaScript, Go, Rust, and others as needed.
+- Full-stack implementations for:
+  - Client
+  - Server
+  - Discovery
+  - Evaluation Server
+  - Chat API
+- Unified interfaces for Cashu wallet management, API key rotation, and proxy/anonymity features.
 
-## Metrics & Adaptation
+## Components
 
-- Dynamic scoring: lower price & latency, higher rating favored.
-- Decay older measurements; prioritize recent data.
+### 1. SDKs
 
-## Security & Privacy
+- Provide idiomatic libraries in each language for all protocol operations.
+- Expose high-level abstractions for:
+  - Token management (Cashu wallets)
+  - API key rotation
+  - Provider selection and scoring
+  - Proxy/Tor integration for request anonymization
+  - Secure, stateless request/response flows
 
-- Rotate Tor circuits per request.
-- Limit request rate per provider to avoid fingerprinting.
+### 2. Smart Clients
+
+- Automated token cycling and top-up from Cashu wallets.
+- Per-request API key rotation and proxy/Tor circuit selection.
+- Dynamic provider discovery and scoring (price, latency, rating, reliability).
+- Pluggable architecture for custom scoring, proxy, or wallet backends.
+
+### 3. Server & Discovery
+
+- Reference implementations for server, discovery, and evaluation endpoints in each supported language.
+- Standardized APIs for provider registration, health, and metrics reporting.
+
+### 4. Evaluation Server & Chat API
+
+- Modular evaluation server for benchmarking and rating providers.
+- Chat API reference implementations for real-time and batch inference.
+
+## Privacy & Security
+
+- Built-in support for proxy and Tor routing in all SDKs and clients.
+- Automated rotation of API keys and tokens to minimize linkability.
+- Rate limiting and circuit rotation to prevent fingerprinting.
+
+## Implementation Plan
+
+- Define core protocol interfaces and data models in each language.
+- Develop and maintain open-source SDKs and reference servers.
+- Ensure feature parity and cross-language test suites.
+- Document integration patterns and privacy best practices.
 
 ---
-
-_End of RIP specs._