diff --git a/CHANGELOG.md b/CHANGELOG.md new file mode 100644 index 0000000..c5b9c65 --- /dev/null +++ b/CHANGELOG.md @@ -0,0 +1,55 @@ +# Changelog + +Notable changes to OpenHosting are documented here. The project follows +[Semantic Versioning](https://semver.org/). + +## [Unreleased] + +## [0.6.0] — 2026-08-27 + +### Added + +- Agent-native commerce discovery, bounded purchase grants, idempotent native + checkout, ACP 2026-04-17 checkout sessions, and exact USDC settlement through + x402 v2. +- Asset-aware money handling with six-decimal USDC support, network and asset + allowlists, durable settlement records, and metered-service compatibility. +- Knowledgebase-grounded support reply drafts, automatic ticket triage, + guarded tier-1 resolution, and a read-only customer assistant with ticket + escalation. +- OAuth-secured remote MCP transport with per-tool scopes and discovery + metadata. +- S3-compatible ticket attachment storage with presigned access and local + storage fallback. +- System-aware dark mode with an explicit light, dark, or system preference. +- Billing lifecycle integration coverage and a reusable provisioning-driver + certification harness. +- Detailed codebase, operator, extension, AI-support, agent-commerce, and + contributor documentation. + +### Changed + +- Expanded the root README's agent-commerce positioning and made the autonomous + commerce roadmap its final section. +- Reframed future automation around policy-governed autonomy: normal low-risk + operations complete machine-to-machine, while people manage policy and + exceptions. +- Defined phased delivery and production-readiness criteria for autonomous + account creation, treasury, purchasing, service management, recovery, and + multi-agent governance. + +### Upgrade notes + +- This release contains database migrations for AI extensions, attachment + storage, AI support, remote MCP/OAuth, USDC money fields, and agent commerce. + Apply migrations before starting the new application version; the supported + installer and container entrypoint do this automatically. +- Anthropic, S3-compatible storage, remote MCP, ACP, and x402 remain optional + and require operator configuration before use. +- USDC is seeded disabled. Verify the network, official asset identifier, + facilitator, and receiving wallet on testnet before enabling mainnet + settlement. +- No intentionally breaking REST, CLI, or human-checkout changes are included. + +[Unreleased]: https://github.com/solomon2773/openhosting/compare/v0.6.0...HEAD +[0.6.0]: https://github.com/solomon2773/openhosting/compare/v0.5.1...v0.6.0 diff --git a/README.md b/README.md index 27231ca..486d82b 100644 --- a/README.md +++ b/README.md @@ -35,6 +35,9 @@ in one self-hosted application. - [Deployment](#deployment) - [Development conventions](#development-conventions) - [Documentation](#documentation) +- [Contributing](#contributing) +- [License](#license) +- [Roadmap](#roadmap) ## What is OpenHosting? @@ -744,3 +747,164 @@ are intended to be narrowly scoped. ## License [MIT](LICENSE) — free for personal and commercial use. + +## Roadmap + +OpenHosting's long-term goal is a hosting business that can serve both humans +and software agents with minimal human involvement. An authorized agent should +be able to discover a product, establish an account, prove control of its +identity, obtain a quote, pay, receive infrastructure, manage its lifecycle, +and resolve routine failures without opening a browser or waiting for an +operator. Humans define policy and handle exceptions; they should not have to +approve every normal action. + +The detailed and independently updateable roadmap is also available in +[docs/roadmap.md](docs/roadmap.md). Ordering may change as protocols and legal +requirements mature, but the safety properties below are release gates rather +than optional follow-up work. + +### The autonomous customer journey + +| Stage | Target machine-to-machine behavior | Human involvement | +|---|---|---| +| Discover | Read products, capacity, price, settlement assets, regions, and policy requirements from a versioned catalog | None | +| Enroll | Register an agent principal, prove control of a public key or workload identity, and establish a policy-bounded account | Only when operator policy requires identity review | +| Purchase | Reserve capacity, receive an authoritative quote, pay with delegated fiat or self-funded USDC, and create an idempotent order | Only for a policy exception or high-risk order | +| Provision | Track the workflow to completion and receive credentials encrypted to the agent's registered key | Only after retries and automated remediation are exhausted | +| Operate | Renew, resize, reinstall, rotate credentials, manage backups and DNS, inspect usage, and request support through API or MCP | Exception queue only | +| Exit or recover | Cancel, export data, receive eligible refunds, rotate a lost key, or transfer control under a predeclared recovery policy | Disputes and contested ownership only | + +### Phase A — commerce foundation (shipped in v0.6) + +- Machine-readable catalog and discovery documents. +- Scoped agent grants with product, currency, expiry, per-order, and cumulative + spending limits. +- Idempotent native checkout, ACP checkout sessions, and exact USDC settlement + through x402 v2. +- Durable settlement records, metered billing, provisioning workflows, audit + trails, remote MCP, and tool-level OAuth scopes. +- AI-assisted support with confidence gates and a human escalation path. + +This phase deliberately requires an existing customer to create the agent +grant. It proves delegated purchasing before OpenHosting removes the +pre-existing human account requirement. + +### Phase B — autonomous identity and account creation (target: v0.7) + +- Introduce a first-class agent principal and an enrollment API that does not + require email, password, browser cookies, or a pre-existing human login. +- Authenticate enrollment with a signed nonce and registered public key. + Support adapters for OAuth client credentials and workload identities, with + optional [W3C DID](https://www.w3.org/TR/did/) and + [SPIFFE](https://spiffe.io/docs/latest/spiffe/concepts/) verification rather + than hard-coding one identity vendor. +- Allow anonymous or pseudonymous accounts when the operator's product, + jurisdiction, network, and risk policy permits them. Collect identity data + only when a configured provider or legal rule requires it. +- Attach an operator-defined capability profile at enrollment: allowed + products, regions, networks, concurrent services, rate limits, maximum + exposure, and account lifetime. +- Build proof-of-control key rotation, multiple active keys, revocation, + recovery guardians, ownership transfer, and inactivity succession. Losing a + workload must not permanently strand the account or let a new workload seize + it. +- Add progressive trust levels so a new anonymous principal begins with low + limits and earns more capacity through successful payment and service + history without manual review of every order. + +### Phase C — autonomous treasury and purchasing (target: v0.8) + +- Add signed, expiring quotes and capacity reservations so an agent knows the + exact price and availability before authorizing payment. +- Support self-funded wallets, prepaid balances, delegated fiat instruments, + and operator-issued credits through one asset-aware ledger. Private keys + always remain outside OpenHosting. +- Add standing budget policies for renewals, usage bursts, and emergency + remediation. A policy decision replaces per-purchase approval while retaining + hard ceilings and an emergency stop. +- Model authorization, settlement finality, expiration, underpayment, + overpayment, refunds, chargebacks, and blockchain reorganization explicitly. + Refunds return through a verified route instead of accepting an arbitrary + address supplied after payment. +- Connect checkout, payment, provisioning, and notification through durable + workflow state and an outbox so crashes can be replayed without duplicated + charges or servers. +- Publish signed lifecycle events and webhooks for quote, payment, invoice, + service, usage, and policy changes. Agents should react to state changes + instead of polling every endpoint. + +### Phase D — autonomous service management (target: v0.9) + +- Expose the complete safe service lifecycle through REST and MCP: renew, + upgrade, downgrade, resize, reinstall, restart, cancel, snapshot, restore, + rotate credentials, manage DNS, and inspect usage. +- Deliver initial and rotated secrets encrypted to the registered agent key or + an operator-configured secret manager. Secrets must never be copied into a + model prompt, audit record, or webhook payload. +- Add balance forecasting, renewal simulation, automatic top-up requests, + budget-aware scaling, and graceful downgrade or shutdown policies before + funds run out. +- Turn provisioning certification into continuous provider health scoring, + automatic failover, bounded retry, and diagnosed escalation. +- Let the support agent gather logs, run approved diagnostics, apply reversible + remediations, and escalate a complete case when confidence or policy blocks + further action. +- Give agents portable receipts, invoices, usage evidence, and service export + data so they can reconcile every decision and leave without operator help. + +### Phase E — multi-agent operations and governance (v1.0 candidate) + +- Support attenuated delegation: an account agent can create a narrower, + short-lived capability for a purchasing, operations, or support sub-agent, + but can never delegate more authority than it owns. +- Add organizations, machine roles, approval policies, quorum controls, and + treasury separation for teams of agents managing shared infrastructure. +- Build a policy simulator and dry-run mode that explains whether an action + would be allowed, its maximum cost, and which rule would block it before any + real payment or provisioning occurs. +- Add pluggable compliance, sanctions, tax, fraud, and provider-acceptable-use + checks. These controls should return structured requirements that an agent + can satisfy automatically when possible and route only genuine exceptions + to a person. +- Add privacy-preserving reputation and optional verifiable attestations for + payment history, abuse history, and workload ownership without making a + public identity mandatory. +- Provide operator kill switches, per-agent quarantine, transaction tracing, + tamper-evident audit exports, and incident replay. + +### Additional roadmap tracks + +- **Reliability without an operator:** high availability, queue visibility, + automated database backups, restore drills, disaster recovery, and safe + upgrade/rollback workflows. +- **Agent-friendly infrastructure:** DNS, object storage, backup, GPU, network, + and secrets-manager drivers with the same certification contract as server + providers. +- **Economic observability:** per-agent margin, settlement cost, usage forecast, + failed-purchase reasons, support cost, and autonomy-rate dashboards. +- **Protocol conformance:** executable ACP, x402, MCP, OAuth, identity, and event + compatibility suites so integrations do not drift as standards evolve. +- **Federated discovery:** signed provider capability documents and portable + service offers so an agent can compare OpenHosting installations without a + proprietary marketplace. +- **Autonomy evaluations:** adversarial simulations for overspending, prompt + injection, replay, compromised keys, provider failure, payment reorgs, and + runaway remediation before higher autonomy levels can be enabled. + +### Definition of done for autonomous accounts + +Anonymous autonomous accounts will be considered production-ready only when: + +1. A clean machine client can discover OpenHosting, create a bounded account, + pay with USDC, provision a service, and retrieve encrypted access without a + human or browser. +2. The same account can renew, resize, recover a key, request support, and + cancel through documented APIs with idempotent retries. +3. Concurrent agents cannot exceed account, order, product, or treasury limits, + even during retries, worker crashes, or partial payment failures. +4. Every decision, delegation, payment, and lifecycle transition is attributable + to a principal and exportable without exposing secrets. +5. Operators can choose where human review is mandatory, but the default + low-risk path completes automatically and sends exceptions to one queue. +6. Recovery, refunds, suspension, and safe shutdown work even when the original + agent runtime is permanently unavailable. diff --git a/docs/roadmap.md b/docs/roadmap.md index db2a1c4..a9848c4 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -1,100 +1,174 @@ -# Roadmap — the AI era - -OpenHosting's direction: become the first hosting-billing platform built *for* -the agent economy — where AI assistants can run the business, AI agents can be -customers, and AI does the support work — all on open standards (MCP, ACP, -x402) with scoped-permission safety, bring-your-own model keys, and -human-in-the-loop defaults. - -**Foundations already shipped:** [AI support](guides/ai-support.md) — staff-reviewed -reply drafts, ticket classification, confidence-gated tier-1 resolution, and a -read-only customer assistant, all on your own API key — the [MCP server](mcp.md) (21 tools), the -scoped [REST API](api/rest-api.md), an [OAuth2 provider](api/oauth.md), -[usage-metered billing](guides/metered-billing.md), the -[delegated agent-commerce APIs](guides/agent-commerce.md), the -[knowledgebase](guides/knowledgebase.md), the -[fraud pipeline](guides/fraud.md), and the idempotent -[billing cron](billing/automation.md). - -Interested in any of these? Comment on the tracking issues or open a -[discussion](https://github.com/solomon2773/openhosting/discussions) — -contributions and design feedback shape the ordering. - -## Phase 1 — "AI runs your support" (in progress, v0.6) - -1. **AI support agent** — knowledgebase-grounded answers to tickets. - **Shipped:** auto-drafted replies for staff review and auto-triage - (department/priority) on ticket creation, on a bring-your-own Anthropic key - with per-feature toggles — see [AI support](guides/ai-support.md). - **Shipped:** optional auto-resolve for tier-1 questions behind source, - priority, race, and confidence gates. **Still to come:** additional providers. - Industry benchmarks put AI-first - support at 60–80% deflection at a fraction of human cost — for - ticket-heavy, thin-margin hosting businesses this is the single biggest - cost lever. -2. **Customer-facing assistant — shipped** — a scoped chat in the client area - grounded in the knowledgebase *plus the customer's own services and invoices* - (read-only), with an "escalate to ticket" handoff and per-account rate limit. -3. **MCP v2: remote & trusted — shipped** — streamable-HTTP transport secured by the - built-in OAuth provider so hosted AI clients connect without a local - install; per-key *tool-level* scoping in the admin UI; and discovery - metadata ready for registry submission. **Still to come:** publication in - the external MCP Registry. -4. **`llms.txt` + AI-readable docs** — so AI assistants answer OpenHosting - questions accurately. - -## Phase 2 — "AI agents as customers" (v0.7+) - -5. **Agent checkout API — shipped** — a first-class machine purchase flow: - machine-readable catalog feed, idempotent order placement, delegated - purchase tokens with spend caps and product allow-lists, full audit trail. - The fraud pipeline gains an "agent buyer" lane instead of treating all - automation as abuse. -6. **Agentic Commerce Protocol (ACP) — beta shipped** — a versioned - 2026-04-17 checkout-session surface through Stripe Shared Payment Tokens, - backed by the same delegated limits and order engine. -7. **x402 machine payments — shipped** — an x402 v2 gateway accepting USDC - per-use payments (HTTP 402 flow); pairs with metered billing for true - pay-per-request / pay-per-hour infrastructure resale. -8. **Admin copilot** — a chat panel inside the admin that uses OpenHosting's - own MCP tools internally ("who's likely to churn this month?", "draft a - quote for X", "why did this provisioning job fail?") with confirmation on - every write action. - -## Phase 3 — "AI in the engine room" (later) - -9. **Revenue & risk intelligence** — churn-risk scoring, usage-anomaly - detection, LLM-written weekly business summaries; the fraud review queue - gains AI case summaries explaining *why* an order was flagged. -10. **AI migration assistant** — LLM-assisted schema mapping to import from - *any* panel export (CSV/SQL), beyond the built-in WHMCS/Paymenter - importers. -11. **Provisioning auto-remediation** — when a driver call fails, an agent - reads the audit log, retries with corrected parameters, or files a - diagnosed ticket for the operator. -12. **GPU / AI-infra reseller pack** — hourly and GPU-metered billing - presets plus token-usage metering, targeting the fastest-growing hosting - segment: AI compute resale. -13. **Anonymous autonomous account creation** — let an agent establish and - operate a pseudonymous account without a pre-existing human login. This is - intentionally a future capability, after delegated checkout is proven: it - requires durable agent identity, recovery and ownership rules, abuse and - fraud controls, jurisdiction-aware compliance, and tightly bounded payment - authority before an account can provision infrastructure safely. - -## Principles (constant across all phases) - -- **BYO keys, no lock-in** — operators plug in their own model provider; - every AI feature degrades gracefully to manual. -- **Scoped-permission safety** — AI capability is bounded by API-key and - tool scopes, never by trust. -- **Human-in-the-loop by default** — automatic actions are opt-in, with - thresholds and a full audit trail. -- **Open standards over proprietary** — MCP, ACP, x402. - ---- - -*This roadmap reflects market direction as of mid-2026 (MCP mainstream in -enterprise AI stacks; the Agentic Commerce Protocol live across major -platforms; machine-payment volume growing rapidly). Ordering may shift with -user demand — tell us what you need first.* +# Roadmap — autonomous hosting commerce + +OpenHosting's direction is to become the open hosting-billing platform where AI +agents can be customers as well as operators. The normal path should be fully +machine-to-machine: discover, enroll, quote, pay, provision, operate, renew, and +exit. People define the rules and handle genuine exceptions instead of acting +as mandatory intermediaries. + +The public summary, end-to-end customer journey, and production-readiness gates +are the final section of the [root README](../README.md#roadmap). This document +tracks delivery order and concrete outputs. + +## Shipped foundation — v0.6 + +- Knowledgebase-grounded support drafts, triage, confidence-gated tier-1 + resolution, and a read-only customer assistant. +- Remote MCP over streamable HTTP, OAuth protection, and per-tool scopes. +- Machine-readable commerce discovery and catalog endpoints. +- Delegated agent grants with expiry, product and currency allowlists, + per-order limits, cumulative budgets, audit records, and revocation. +- Idempotent native checkout and ACP 2026-04-17 checkout sessions. +- Exact USDC settlement through x402 v2, durable settlement records, and + asset-aware metered billing. +- S3-compatible support attachments, provisioning-driver certification, + billing integration tests, and container CI. + +The v0.6 agent flow is intentionally delegated: an existing customer creates a +grant for an agent. The next phases remove that prerequisite without weakening +the limits already enforced by checkout. + +## v0.7 — autonomous identity and account creation + +### Deliverables + +1. Add agent principals and accounts that do not require an email address, + password, browser session, or pre-existing human owner. +2. Add a challenge-response enrollment API that binds the account to a public + key. Treat OAuth client credentials, workload identity, W3C DID, and SPIFFE + as adapters to one internal principal model. +3. Add operator enrollment policies for product, region, payment network, + rate, service-count, exposure, and account-lifetime limits. +4. Allow pseudonymous enrollment for eligible policies. Request identity or + compliance evidence only when a configured rule requires it. +5. Add progressive trust tiers driven by successful settlements, account age, + disputes, abuse signals, and service history. +6. Add multiple keys, proof-of-control rotation, immediate revocation, recovery + guardians, ownership transfer, and inactivity succession. +7. Add encrypted secret delivery so account and service credentials can be + recovered without appearing in model context or application logs. + +### Exit criteria + +- A clean client can enroll, authenticate, rotate a key, and close or recover + its account using documented machine interfaces. +- A new principal receives the exact policy selected by the operator and + cannot expand it by changing identity adapters. +- Losing one runtime or key does not strand the account, while a third party + cannot claim it through recovery alone. + +## v0.8 — autonomous treasury and purchasing + +### Deliverables + +1. Add signed, expiring quotes and capacity reservations. +2. Unify prepaid balance, self-funded USDC, delegated fiat, credits, refunds, + and adjustments in an asset-aware treasury view. +3. Add standing policies for renewal, usage bursts, scaling, and remediation so + a human approval is not required inside an already approved envelope. +4. Model pending and final settlement, authorization expiry, underpayment, + overpayment, refunds, chargebacks, and blockchain reorganization. +5. Refund only through verified payment routes and record the complete link + between quote, authorization, settlement, invoice, order, and service. +6. Coordinate purchase and provisioning through durable workflow state and an + outbox, with idempotent replay after crashes. +7. Publish authenticated lifecycle events and webhooks so agents can subscribe + instead of polling. + +### Exit criteria + +- Enrollment through usable infrastructure completes without a browser or + operator on the low-risk path. +- Retries and concurrent workers cannot create duplicate charges, duplicate + infrastructure, or spend beyond policy. +- Failed and expired purchases converge to a documented state with a safe + retry, refund, or exception path. + +## v0.9 — autonomous service management + +### Deliverables + +1. Expose renew, resize, upgrade, downgrade, reinstall, restart, cancel, + snapshot, restore, credential rotation, DNS, and usage through REST and MCP. +2. Integrate external secret managers and public-key-encrypted credential + envelopes. +3. Add balance and usage forecasting, automatic top-up requests, budget-aware + scaling, and configurable graceful shutdown before funds run out. +4. Continuously score provider health using the certification harness and add + bounded retry, failover, rollback, and diagnosed escalation. +5. Allow the support agent to gather approved diagnostics and run reversible + remediations before creating an exception case. +6. Export portable receipts, invoices, usage evidence, backups, DNS records, + and service configuration. + +### Exit criteria + +- A service can run through purchase, renewal, modification, incident, and + cancellation without routine staff action. +- Secrets never enter prompts, webhooks, audit metadata, or plaintext recovery + records. +- Automation stops safely and explains the blocking policy when confidence, + budget, provider health, or compliance requirements are not satisfied. + +## v1.0 candidate — multi-agent operations and governance + +### Deliverables + +1. Add attenuated capability delegation for purchasing, operations, finance, + and support sub-agents. +2. Add organizations, machine roles, quorum policies, treasury separation, and + time-bounded emergency access. +3. Add a dry-run policy simulator that reports cost, permissions, expected + state transitions, and blocking rules before execution. +4. Add pluggable tax, sanctions, fraud, provider acceptable-use, and + jurisdiction policies with structured machine-remediable requirements. +5. Add optional privacy-preserving reputation and verifiable attestations. +6. Add agent quarantine, global and scoped kill switches, tamper-evident audit + exports, and incident replay. +7. Add executable protocol conformance and autonomy evaluations covering + replay, overspending, prompt injection, compromised keys, partial failures, + payment reorganization, and runaway remediation. + +### Exit criteria + +- Delegates cannot mint broader authority than their parent and every action is + attributable through the complete delegation chain. +- Operators can explain, simulate, stop, and replay autonomous actions without + directly managing each normal transaction. +- The production-readiness definition in the + [README](../README.md#definition-of-done-for-autonomous-accounts) is met. + +## Parallel roadmap tracks + +- **Admin copilot:** explain revenue, churn, provisioning, support, and risk; + draft bounded actions; execute only through the same policy engine as other + agents. +- **Revenue and risk intelligence:** anomaly detection, churn scoring, weekly + business summaries, and explainable fraud cases. +- **AI migration assistant:** schema mapping for arbitrary panel exports beyond + the built-in WHMCS and Paymenter importers. +- **GPU and AI infrastructure:** hourly GPU presets, token and accelerator + metering, capacity discovery, and reservation-aware quotes. +- **Reliability:** high availability, queue operations, backup verification, + disaster recovery, and safe upgrade/rollback automation. +- **Federation:** signed provider capability documents and portable offers for + cross-installation discovery without a proprietary marketplace. +- **Model choice:** additional AI providers and local-model support while + retaining bring-your-own keys and graceful manual fallback. + +## Principles + +- **Policy-governed autonomy:** routine low-risk actions complete automatically; + humans receive structured exceptions, not a request to approve everything. +- **Least authority:** every credential, grant, tool, and delegation is scoped, + expiring, revocable, and auditable. +- **No secret in model context:** private keys, passwords, recovery material, + and payment credentials stay in dedicated security boundaries. +- **Open standards and replaceable adapters:** ACP, x402, MCP, OAuth, W3C DID, + SPIFFE, and interoperable events are adapters around stable domain services. +- **Safe replay:** all money and infrastructure mutations are idempotent and + recoverable after partial failure. +- **Privacy by design:** pseudonymous operation remains possible where policy + allows; collect evidence only for a stated requirement. +- **Portable exit:** an autonomous customer can reconcile, export, cancel, and + recover funds or data without vendor lock-in. diff --git a/package-lock.json b/package-lock.json index 0f4f6e1..a4adf86 100644 --- a/package-lock.json +++ b/package-lock.json @@ -1,12 +1,12 @@ { "name": "openhosting", - "version": "0.5.1", + "version": "0.6.0", "lockfileVersion": 3, "requires": true, "packages": { "": { "name": "openhosting", - "version": "0.5.1", + "version": "0.6.0", "dependencies": { "@anthropic-ai/sdk": "^0.115.0", "@aws-sdk/client-s3": "^3.1119.0", diff --git a/package.json b/package.json index 5b41816..c31887a 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "openhosting", - "version": "0.5.1", + "version": "0.6.0", "private": true, "description": "Open-source billing and client management platform for hosting providers. Next.js + PostgreSQL.", "scripts": {