laantungir/routstr_protocol
1
0
Fork 0
mirror of https://github.com/Routstr/protocol.git synced 2026-08-08 23:34:42 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: update authentication and usage details

Browse Source 
- RIP-01: Add Basic Usage section explaining sk- keys and Cashu tokens
- RIP-03: Update Ephemeral Authentication to match RIP-01
This commit is contained in:
Shroominic
2026-01-05 13:41:48 +01:00
parent 9009a804b0
commit e946468141
2 changed files with 13 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
RIP-01.md
+10 -2
View File
@@ -2,12 +2,20 @@
Defines the HTTP proxy interface forwarding OpenAI-compatible API requests, with per-request micropayment handling via Cashu tokens.
## Basic Usage
Routstr provides an OpenAI-compatible API interface. Basic LLM requests are made using standard `POST` requests to `/v1/chat/completions` (or other supported endpoints) with a JSON body containing the model parameters.
Authentication and payment are handled via the `Authorization` header. The "api-key" provided in the header can be one of two things:
1. **A Temporary Balance Key (`sk-...`)**: A standard API key linked to a pre-funded temporary wallet/balance on the server.
2. **A Cashu Token (`cashuA...`)**: A raw Cashu eCash token. The server will redeem this token to create an ephemeral session or account.
## Endpoints
### 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.
Forward proxied requests to the upstream service like local vLLM, OpenAI, Anthropic, etc.
### GET /v1/info
RIP-03.md
+3 -2
View File
@@ -14,9 +14,10 @@ Routstr clients MUST maintain high fidelity with the OpenAI API specification to
## 2. Ephemeral Authentication (Cashu-as-Key)
Authentication and funding are unified into a single bearer-asset mechanism, preserving complete privacy through a "Rolling Identity" model.
Authentication and funding are unified into a single mechanism. The client passes either a temporary balance key (`sk-...`) or a Cashu token (`cashuA...`) in the `Authorization` header.
For the full specification of authentication methods and token types, refer to **[RIP-01: Authorization](RIP-01.md#authorization)**.
- **Cashu Token as API Key**: The client passes a valid Cashu token (containing monetary value) in the standard API key field (e.g., `Authorization: Bearer <cashu_token>`).
- **Implicit Session**: The provider accepts this token as both payment and a temporary identity. The token's secret effectively acts as the account identifier for the duration of the operation.
- **Privacy by Default**:
- Upon request completion, the provider deducts the cost.