From 554f3b2da0f720bdbf89c54d1a1fc3ed14ed88ec Mon Sep 17 00:00:00 2001 From: Grant Date: Wed, 17 Jun 2026 15:41:17 -0500 Subject: [PATCH] Sweep residual v0.1 staleness in API/ARCHITECTURE/README docs --- licensing-service/README.md | 2 +- licensing-service/docs/API.md | 2 +- licensing-service/docs/ARCHITECTURE.md | 11 +++++------ 3 files changed, 7 insertions(+), 8 deletions(-) diff --git a/licensing-service/README.md b/licensing-service/README.md index 3a107aa..540bc92 100644 --- a/licensing-service/README.md +++ b/licensing-service/README.md @@ -86,7 +86,7 @@ On first boot the server generates a fresh Ed25519 keypair and stores it in the ```bash curl -X POST http://localhost:8080/v1/admin/products \ - -H "Authorization: Bearer $LICENSING_ADMIN_API_KEY" \ + -H "Authorization: Bearer $KEYSAT_ADMIN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "slug": "my-app", diff --git a/licensing-service/docs/API.md b/licensing-service/docs/API.md index 5371dee..892c164 100644 --- a/licensing-service/docs/API.md +++ b/licensing-service/docs/API.md @@ -19,7 +19,7 @@ Service metadata including the Ed25519 public key. Useful for SDKs to fetch the ```json { "service": "keysat", - "version": "0.1.0", + "version": "0.2.0", "operator": "Acme Software", "public_key_pem": "-----BEGIN PUBLIC KEY-----\nMCow...\n-----END PUBLIC KEY-----\n", "key_algorithm": "ed25519", diff --git a/licensing-service/docs/ARCHITECTURE.md b/licensing-service/docs/ARCHITECTURE.md index ff34fe1..94aa096 100644 --- a/licensing-service/docs/ARCHITECTURE.md +++ b/licensing-service/docs/ARCHITECTURE.md @@ -33,7 +33,7 @@ LIC1 - - The payload is a fixed binary layout, not JSON, to keep keys short. Details in [`src/crypto/mod.rs`](../src/crypto/mod.rs). -Why base32 Crockford-style (no padding)? +Why base32 (RFC 4648, no padding)? - Uppercase only, unambiguous chars, easy to read aloud or type from a screen. - Slightly longer than base64 but less error-prone for humans copying keys. @@ -63,13 +63,12 @@ Who might attack this? 5. **Chargeback / dispute** (applicable to non-Bitcoin rails, but worth noting). Bitcoin payments are irreversible, so the normal fraud model that motivates software DRM mostly doesn't apply here. Most revocations will be: key leaked publicly, legitimate business decision, mistaken issuance. -## What's deliberately NOT in v0.1 +## Deliberately out of scope -- **Key rotation.** A single static signing key is fine for first launch. Rotation requires SDK multi-key support and a migration strategy; deferred. -- **Trial periods / demos.** This is a pure paid-license server. Trials are the developer's responsibility in-app. -- **Payment currencies other than BTC.** BTCPay supports Lightning, altcoins, and fiat; we only send BTC-denominated invoices. Adding Lightning is straightforward (BTCPay handles it transparently if the store has LN configured). +- **Key rotation.** A single static signing key is fine for now. Rotation requires SDK multi-key support and a migration strategy; deferred. - **Multi-tenant / SaaS mode.** This is a *single-operator* server by design. Running multiple logical operators on one instance is a different product. -- **Admin UI.** Everything is API-driven. Wrap it in whatever UI you like — or just use `curl`. + +(Trial/time-limited policies, multi-currency pricing, the optional Zaprite card rail, and the embedded admin UI all shipped after v0.1 and are no longer on this list.) ## Notes on Start9 dependencies