docs(plans): private-apps-on-Lit framework + Lambda-parity gateway plan#446
Closed
clawdbot-glitch003 wants to merge 2 commits into
Closed
docs(plans): private-apps-on-Lit framework + Lambda-parity gateway plan#446clawdbot-glitch003 wants to merge 2 commits into
clawdbot-glitch003 wants to merge 2 commits into
Conversation
Add two design plans: - private-apps-backend.md: a "backend-as-Lit-Actions" framework (in-action runtime + CLI + client SDK + optional relay) for building private apps with encrypted-at-rest Postgres, decrypted only inside the TEE. - chipotle-lambda-parity.md: prioritized gateway work (per-key spend cap, rate/concurrency limits, origin allowlist, public-key type) to make a usage key safe to embed in a frontend, with blast-radius parity to a public Lambda. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…mbda-parity Add an "Architecture: where state lives & the zero-latency path" section grounded in the existing hot path (BlockchainCache, Stripe SWR caches, async fire-and-forget charge). Introduces P0.0 (hasSpendingRules on-chain bit fetched in the canExecuteAction multicall) as the zero-latency gate, splits storage across on-chain flag / lit-payments DB rules+usage / in-process per-node counters, and records resolved decisions: rolling spend window, SWR rule cache, DB-backed durable per-key spend, multicall flag fetch, and rule-write-before-flag-flip ordering. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
clawdbot-glitch003
pushed a commit
that referenced
this pull request
Jun 17, 2026
Brings the two design plans from PR #446 into this branch so they ship with the lambda-parity implementation they describe, and #446 can be closed. - plans/chipotle-lambda-parity.md — prioritized gateway work (this PR implements P0.0/P0.1/P0.2/P1) for per-key blast-radius parity with a public Lambda URL. - plans/private-apps-backend.md — the backend-as-Lit-Actions framework these gateway controls unlock (relay becomes optional). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
|
closing - moved plan to #477 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds two design plans (docs only — no code changes).
plans/private-apps-backend.mdproposes a "backend-as-Lit-Actions" framework — an in-action runtime, CLI, client SDK, and optional relay — for building private apps where Postgres row contents are encrypted at rest and decrypted only inside the TEE, with plaintext index columns for querying.plans/chipotle-lambda-parity.mdlays out the prioritized Chipotle gateway work (per-key spend cap with auto-disable, per-key/per-IP rate + concurrency limits, origin allowlist, and a public-key type) needed to make a usage key safe to embed directly in a frontend, with blast-radius parity to a public AWS Lambda URL. Together they argue the relay becomes optional once the gateway controls land, since confidentiality is already TEE/CID-gated and only spend/availability needs bounding. Both are grounded in the existingexamples/dark-pool/encrypted-Postgres pattern and the currentlit-api-serverguard/billing code.🤖 Generated with Claude Code