Skip to content

Latest commit

 

History

History
262 lines (181 loc) · 12.9 KB

File metadata and controls

262 lines (181 loc) · 12.9 KB

MPP Roadmap

Vision: First Elixir implementation of the Machine Payments Protocol — HTTP 402 payment middleware that turns any Phoenix API into an agent-billable service. No accounts, no API keys. Payment is authentication.

Completed work: See CHANGELOG.md for finished tasks.

Spec: tempoxyz/mpp-specs | Reference impl: tempoxyz/mpp-rs


Current Focus

Protocol completeness + client SDK (2026-04-19) — Prioritizing Phases 9-12 (protocol utilities, sessions, MCP, client SDK) over new payment methods (Phases 13-15, 16). Proxy/gateway scoped out to separate mpp_proxy package. Task 41 (Tempo SessionReceipt), Task 33b (HTTP client transport), and Task 43 (onchain + onchain_tempo dep bump) landed 2026-04-19. Cross-SDK gap pass on 2026-04-19 added Tasks 36-42. Next high-Eff: Task 32b (MCP server transport), Task 35 (dedup), Task 37 (Accept-Payment), Task 33c (Req plugin).

Philosophy reminder: This is a library, not an app. Explicit credentials, no global config, no ENV fallback. Per-route pricing via Plug opts. Stateless HMAC-bound challenges.

Focus phase: 9 — Protocol Utilities (5 of 13 done · 0 in progress)

Last shipped: Task 58 — Public API @doc + missing @spec pass on 2026-06-12

Up next: Task 57 — Unit tests for MultiProvider and ConCacheStore [D:2/B:5/U:6 → Eff:2.75] 🎯


Phase 1: Core Protocol ✅

8 tasks complete (v0.1.0). Challenge, Credential, Receipt, Headers, Errors, Charge intent, Method behaviour, Plug middleware.

9 tasks. See CHANGELOG.md.


Phase 2: Stripe Payment Method ✅

2 tasks complete (v0.1.0). Stripe SPT verification + integration tests against Stripe test API.

3 tasks. See CHANGELOG.md.


Phase 3: Descripex + Local Discovery ✅

2 tasks complete (v0.2.0). api() annotations on all public functions, MPP.describe/0-2, and mix mpp.manifest for local discovery/manifest generation.

Task Status Notes
Task 11 🎁 descripex · Descripex annotations [D:3/B:7/U:8 → Eff:2.5?] 🎯
Task 12 🎁 descripex · mix mpp.manifest [D:2/B:6/U:7 → Eff:3.25?] 🎯
Task 42 [P] 🎁 discovery · OpenAPI discovery document generation [D:4/B:7/U:8 → Eff:1.88?] 🚀

Phase 4: Tempo Payment Method ✅

8 tasks complete (v0.2.0). Hash + transaction credential paths, fee payer co-signing, optimistic broadcast, dedup store, ConCacheStore, integration tests against Moderato testnet, ox/tempo cross-validation.

5 tasks. See CHANGELOG.md.


Phase 5: EVM Payment Method ✅

Task Status Notes
Task 14 🎁 evm · Generic EVM method [D:6/B:7/U:6 → Eff:1.08?] 📋
Task 38 [P] 🎁 evm · EVM credentialTypes backfill [D:3/B:5/U:6 → Eff:1.83?] 🚀

Phase 6: Multi-Method Challenges ✅

1 task complete (v0.2.0). Multiple payment methods per endpoint with per-method pricing and credential routing.

1 task. See CHANGELOG.md.


Phase 7: Hex Publish ✅

v0.1.0 published to Hex (2026-03-25). v0.2.0 published (2026-03-28). v0.3.0 published (2026-04-03). v0.4.0 published (2026-04-18) — Phase 9 utilities (BodyDigest, Amount, JCS, Verifier, multi-challenge), Phase 10 session error types, Phase 11 MCP types, Phase 12 PaymentProvider behaviour.

1 task. See CHANGELOG.md.


Phase 8: Developer Experience

2 tasks. See CHANGELOG.md.


Phase 9: Protocol Utilities

Cross-SDK gap analysis (2026-04-04) identified missing protocol features in mppx and mpp-rs that our library lacks. These are small, independent modules — all [P] parallelizable.

Task Status Notes
Task 24 🎁 utilities · Multi-challenge parsing [D:3/B:7/U:7 → Eff:2.33?] 🎯
Task 25 🎁 utilities · Body digest [D:2/B:6/U:5 → Eff:2.75?] 🎯
Task 26 🎁 utilities · Amount and decimals helpers [D:2/B:6/U:6 → Eff:3.0?] 🎯
Task 27 [P] 🎁 utilities · Expiration and DID helpers [D:2/B:4/U:5 → Eff:2.25?] 🎯
Task 34 🎁 utilities · Verifier extraction + JCS [D:4/B:9/U:10 → Eff:2.38?] 🎯
Task 35 [P] 🎁 utilities · Generic dedup at Plug level [D:3/B:7/U:7 → Eff:2.33?] 🎯
Task 37 [P] 🎁 utilities · Accept-Payment header support [D:3/B:6/U:7 → Eff:2.17?] 🎯
Task 45 🎁 utilities · Tier-2 pinned-field verification [D:4/B:8/U:7 → Eff:1.88] 🚀
Task 46 🎁 utilities · Tempo + session hardening audit vs. latest reference impls [D:5/B:8/U:7 → Eff:1.5] 🚀
Task 53 🎁 utilities · Payment event hooks (server-side observability surface) [D:3/B:5/U:6 → Eff:1.83] 🚀
Task 56 [P] 🎁 utilities · GitHub Actions CI workflow [D:3/B:7/U:7 → Eff:2.33] 🎯
Task 57 [P] 🎁 utilities · Unit tests for MultiProvider and ConCacheStore [D:2/B:5/U:6 → Eff:2.75] 🎯
Task 58 🎁 utilities · 📝 Public API @doc + missing @spec pass [D:3/B:4/U:4 → Eff:1.33] 📋

Phase 10: Session Support

The session intent is the second major intent type (alongside charge). It enables streaming/metered payments via payment channels — clients open a channel with a deposit, present signed vouchers for ongoing access, and either party can close. Both mppx and mpp-rs have full session support.

Task Status Notes
Task 28 🎁 session · Session error types [D:2/B:5/U:7 → Eff:3.0?] 🎯
Task 29 🎁 session · Session intent schema [D:4/B:7/U:8 → Eff:1.88?] 🚀
Task 41 🎁 session · Tempo SessionReceipt [D:2/B:5/U:6 → Eff:2.75?] 🎯
Task 30 🎁 session · Channel state and voucher types [D:5/B:6/U:7 → Eff:1.3?] 📋
Task 31 🎁 session · Session credential actions [D:5/B:6/U:6 → Eff:1.2?] 📋
Task 50 🎁 session · Tempo subscriptions [D:6/B:6/U:5 → Eff:0.92] ⚠️

Phase 11: MCP Transport

MCP (Model Context Protocol) support enables payments over JSON-RPC — critical for AI agent economy. Independent of sessions, can be built in parallel with Phase 10. Types alone are not enough here; both reference SDKs also expose concrete server/client MCP integration points.

Task Status Notes
Task 32 🎁 mcp · MCP types and constants [D:2/B:7/U:8 → Eff:3.75?] 🎯
Task 32b 🎁 mcp · MCP server transport [D:3/B:7/U:8 → Eff:2.5?] 🎯

Phase 12: Client SDK

Currently we're server-only — MPP.Plug lets you charge for endpoints, but there's no way to make MPP-authenticated requests as a client. This phase adds the client-side SDK foundation plus built-in providers so the package is usable out of the box. mppx has Mppx.create() + Fetch.from() + built-in methods, mpp-rs has PaymentProvider + PaymentExt plus concrete providers.

Task Status Notes
Task 33a 🎁 client-sdk · Client PaymentProvider behaviour [D:3/B:8/U:9 → Eff:2.83?] 🎯
Task 33b 🎁 client-sdk · HTTP client transport [D:3/B:7/U:8 → Eff:2.5?] 🎯
Task 33c 🎁 client-sdk · Payment-aware Req plugin [D:4/B:8/U:8 → Eff:2.0?] 🎯
Task 33d 🎁 client-sdk · MCP client transport [D:3/B:6/U:7 → Eff:2.17?] 🎯
Task 33e 🎁 client-sdk · Built-in charge providers [D:6/B:8/U:9 → Eff:1.42?] 📋
Task 47 🎁 client-sdk · Client challenge ordering hook [D:2/B:4/U:5 → Eff:2.25] 🎯

Phase 13: Lightning Payment Method

Lightning has two specs: charge (one-time BOLT11 invoice) and session (prepaid streaming with deposit/topUp/close). Verification is simple: SHA256(preimage) == payment_hash. Neither mppx nor mpp-rs implement Lightning — we'd be first movers. Lightning session (Task 20) depends on session infrastructure from Phase 10.

Specs: refs/mpp-specs/specs/methods/lightning/draft-lightning-charge-00.md, draft-lightning-session-00.md

Task Status Notes
Task 19 🎁 lightning · Lightning charge method [D:5/B:7/U:7 → Eff:1.4?] 📋
Task 20 🎁 lightning · Lightning session method [D:8/B:5/U:4 → Eff:0.56?] ⚠️

Phase 14: Solana Payment Method

Solana supports two modes: pull (client signs tx, server broadcasts — default) and push (client broadcasts, sends confirmed signature). Supports native SOL and SPL tokens, fee payer option, and payment splits (up to 8 recipients). Similar pattern to Tempo's on-chain verification. Neither mppx nor mpp-rs implement Solana.

Spec: refs/mpp-specs/specs/methods/solana/draft-solana-charge-00.md

Task Status Notes
Task 21 🎁 solana · Solana charge method [D:6/B:6/U:5 → Eff:0.92?] ⚠️

Phase 15: Card Payment Method

Card is the most complex method — uses JWE-encrypted network tokens with RSA-OAEP-256 + AES-256-GCM. Requires "Client Enabler" (token provisioning) and "Server Enabler" (decryption + processing) intermediaries. Least aligned with machine-to-machine payments. Neither mppx nor mpp-rs implement Card. Defer until ecosystem demand.

Spec: refs/mpp-specs/specs/methods/card/draft-card-charge-00.md

Task Status Notes
Task 22 🎁 card · Card charge method [D:8/B:5/U:4 → Eff:0.56?] ⚠️

Phase 16: Additional Payment Methods

Methods with spec support but limited ecosystem pull. Deferred until demand or partnership surfaces.

Task Status Notes
Task 36 🎁 additional-methods · Stellar charge method [D:7/B:5/U:6 → Eff:0.79?] ⚠️
Task 39 🎁 additional-methods · EVM Permit2 credential path [D:7/B:7/U:7 → Eff:1.0?] 📋
Task 40 🎁 additional-methods · EVM EIP-3009 authorization credential [D:6/B:5/U:5 → Eff:0.83?] ⚠️
Task 51 🎁 additional-methods · Hedera charge method [D:6/B:4/U:4 → Eff:0.67] ⚠️

Deferred

Items identified in cross-SDK gap analysis but not worth phasing yet:

  • SSE support — Server-Sent Events for streaming payments (payment-receipt + payment-need-voucher events). Canonical session transport in mpp-rs and mppx (not optional). Blocked on Tasks 30-31; escalate priority when Phase 10 work begins. [D:4/B:6/U:6 → Eff:1.5]
  • Store backends — Redis adapter, file store. ConCache + behaviour is sufficient for now. [D:3/B:3/U:3 → Eff:1.0]
  • HTML/UI — Browser payment helper UI and hosted-form config (mostly mppx-specific). Not relevant for library. [D:5/B:3/U:2 → Eff:0.5]

Separate Package: mpp_proxy

Proxy/gateway functionality scoped out to a standalone mpp_proxy hex package (not part of this library). Both mppx and mpp-rs ship proxy as core modules — but the proxy is a product (payment gateway), not a library feature. Separate package keeps mpp focused on protocol correctness while mpp_proxy targets the "wrap any API → monetize it" use case. See mpp_proxy repo for roadmap once created.


References

Resource What
ZenHive/mpp This repo — Elixir MPP implementation
MPP Spec IETF draft — core protocol, intents, methods
mpp-rs Rust reference implementation (Tower/Axum)
x402 Docs Coinbase-backed on-chain payment protocol
Stripe MPP Blog Stripe's agent commerce vision
api_cache Phase 7 First consumer — Tasks 47-51