Integrate recoverable native purchases, registered rentals and explicit payment consent

This commit is contained in:
archipelago
2026-10-06 22:44:06 -04:00
parent e4eae71314
commit 49703d7e88
63 changed files with 8028 additions and 134 deletions
+53 -2
View File
@@ -180,10 +180,12 @@ Seven registered-media tests and three route/stream tests passed in
`/tmp/archy-registration-rental-batch-tests.log`; its overall result was 1,834
passed, one failed legacy missing-file expectation, and five existing skips.
All 383 captured source/build/fixture hashes remained unchanged. The expectation
was corrected separately and awaits the next full run. Do not describe that batch
was corrected separately; the later full run passed 1,848 tests, zero failures
and five existing skips with all 385 captured hashes unchanged. Do not describe that earlier batch
as a clean combined suite or live playback acceptance.
The subsequent, not-yet-tested performance refinement persists the already
The subsequent performance refinement, qualified in the later clean 1,848-test
backend run, persists the already
verified snapshot's signed hash and inode/device/ctime/size attestation during
registration. Ordinary first-open/range requests reuse it. A missing cache streams
the original signed hash under a per-registration lock; buyer leases use separate
@@ -197,3 +199,52 @@ picker/consent bridge, app receipt consumption, and player reconnect/expiry UI a
being connected next. Their source is not yet deployed; app registration and
publication flags remain disabled pending complete qualification. No real payment,
announcement, media publication or node deployment was performed by this work.
## Applied native caller and terminal recovery — 7 October UTC
The next source batch now connects the dashboard Cloud picker, exact producer
signature, owner-session/CSRF RPC, shared snapshot reservation budget and Backstage
receipt consumption. It is local and uncommitted; the deployed b52214f7 backend
candidate does not contain these caller changes. Registration/publication flags
remain disabled.
An interrupted operation can now be resolved under its original operation lock:
return and verify its completed receipt, or durably retire an expired incomplete
request. Retirement is node-signed against the entire original intent. It prevents
late preparation and cannot replace a completed receipt. App pending lookup and
retirement consumption authenticate the current producer/project owner and pinned
installation; an expired unknown intent cannot silently become a fresh one.
Backstage retains signatures/receipts across lost replies and offers explicit
resume/resolve actions. Completed media remains available without the Cloud source.
Focused qualification: PostgreSQL registration/retirement and migrations plus
HTTP identity routes passed 54 tests in two suites; app caller passed seven tests;
dashboard native bridge passed six tests. App frontend typecheck passed. Logs:
`/tmp/indeehub-terminal-registration-focused.log`,
`/tmp/indeehub-terminal-registration-client-rerun.log`,
`/tmp/archy-native-registration-bridge-tests.log`, and
`/tmp/indeehub-terminal-registration-typecheck.log`.
The first client test command found zero tests because the new file was outside
the repository include pattern; it was moved to `tests/backstage-registration.test.ts`
and the rerun passed. No zero-test run is counted as qualification.
The backend all-source noEmit check reports two unchanged legacy test-mock errors:
missing Subscription.flashId and User.libraryItems. Its production-config noEmit
check passed; the all-source failure remains recorded separately. Combined new Rust primitive/RPC/caller tests and
real native registration/rental acceptance remain pending. No new payment,
announcement, media publication or deployment was performed by this batch.
The connected app rental player passed eight mounted-Vue lifecycle/status tests
and frontend typecheck. Opening the dialog creates no purchase or media request;
video uses preload=none and does not autoplay. Native response generations reject
late close/reopen or changed-offer results. The actual playing event starts a
read-only status(handle) request and non-overlapping five-second checks; pause,
ended, error and close stop polling. Only the server expires_at is displayed;
null never starts a local rental clock. A status error retains the original
purchase handle and offers recovery without another payment. Logs:
`/tmp/indeehub-rental-player-status-tests.log` and
`/tmp/indeehub-rental-player-status-typecheck.log`.
Host broker and Rust proxy/caller qualification are tracked separately; these app
tests do not claim a live paid-stream acceptance.
+89
View File
@@ -646,3 +646,92 @@ on-chain amount matches the backend. These checks do not establish complete
durable recovery for every payment method. Full purchase integration and live
acceptance remain open; Framework dashboard verification still needs normal TOTP.
No new real payment was made.
## Next integrated caller batch — qualification in progress
The owner Cloud purchase RPC, registered video rental RPC and FIPS seller routes
are now connected to the durable purchase journal. Fresh spending requires the
original operation UUID, envelope hash and exact wallet debit returned for owner
confirmation. Reopening a title checks its existing operation first. Cancellation
must obtain the seller's unspent acknowledgement before a replacement quote.
External Lightning QR invoices expose authoritative lifecycle state; a local timer
alone cannot authorize another payment method.
The native IndeeHub rental broker and player are now implemented in source. The
browser receives a session-bound local playback handle, not the seller receipt
capability. Handle creation/status do not start the viewing period; the actual
video GET does. The app uses `preload="none"` and no autoplay. Closing or changing
content invalidates asynchronous UI results, and status polling cannot initiate
a purchase. Native origin, app lifecycle and HTTP/HTTPS route review are ongoing.
This is **not deployed or accepted**. The combined Rust source is undergoing its
isolated compile/test run. Focused registration tests passed 54 backend, seven
app caller and six host bridge tests; the app rental player passed eight mounted
lifecycle/status cases and frontend typecheck. Host rental tests initially passed
five cases before cancellation/status additions and further independent review;
final host qualification remains pending. Two preexisting backend test/mock type
omissions remain recorded separately from the passing production typecheck.
The original Framework paid-file recovery, real Yaya↔Framework/dev method-switch
acceptance, app image deployment, complete published-title playback and physical
companion checks remain open. No new real payment or public announcement was made.
### Integrated purchase qualification and seller policy correction
The integrated caller, immutable offers, durable acceptance/cancellation, fee-plan
execution, retained Cloud delivery and registered rental plumbing are now in the
candidate source. These are not yet accepted as a live payment flow. The first
combined compile failed before tests; subsequent isolated runs reported 1,884
passed/3 failed/5 ignored, then 1,886 passed/1 failed/5 ignored. The latter run
verified all 406 captured source inputs unchanged. Logs are retained at
`/tmp/archy-purchase-integrated-backend-rerun.log` and
`/tmp/archy-purchase-integrated-backend-final.log`.
The remaining caller test exposed missing explicit mint acceptance in its seller
fixture. Production review also found that a configured default mint could be
quoted without checking the seller's redemption allowlist. The candidate now
checks network and mint policy before new offers/acceptance and before reporting
an unresolved accepted operation ready for fresh buyer spending. Wallet policy
changes cannot remove a mint or switch networks while an accepted seller
liability remains unresolved. Acceptance and policy updates use the same wallet
then purchase lock order. Settlement and cancellation release that policy pin;
already-settled receipts remain recoverable after policy changes. No generic
redemption allowlist bypass was added. New tests cover these transitions and the
original lost acceptance/settlement sequence; this correction awaits the next
isolated run.
Confirmation responses additionally carry the original saved offer's Cashu
network and mint for display. They are not derived from later wallet settings.
No new real payments were made for these checks.
Remaining protocol work is explicit: authenticated server-owned creation and
cancellation of external Lightning invoices across browser-state loss; durable
on-chain address/dispatch/transaction recovery; and explicit rental renewal only
after seller-authoritative expiry evidence. Existing paid receipts and ambiguous
legacy attempts must retain recovery access. A local timeout, missing browser
record or clock expiry must never authorize a second payment.
Qualification update: the corrected combined isolated backend run passed **1,889
tests, zero failures, five existing skips**. Compilation took 4m22s; isolated
execution took 14.60s. All 406 captured inputs remained unchanged. Evidence:
`/tmp/archy-purchase-policy-backend-tests.log` and
`/tmp/archy-purchase-policy-green-provenance.json`. This includes the complete
caller lost-acceptance/lost-settlement regression, seller policy transitions,
immutable-content first-use integrity, and explicit application license metadata.
Production build, deployment and live payment acceptance are separate gates.
### Integrated native purchase dashboard qualification — 7 October
The matching dashboard passed 1,375 tests across 170 files, the actual project
TypeScript check, and its production build with 500 source/build inputs unchanged.
Twenty-one local browser cases passed at 320, 390 and 1440px, including long mint
URLs, Cashu network labels, busy/error states and reachable mobile actions. These
are local fixtures, not live payment acceptance. The earlier full-suite loading
notice timeout is retained in its log; its unchanged-timeout focused rerun and
the subsequent complete suite passed.
The deployable UI and evidence are preserved under
`~/.local/state/archipelago/release-qualification/ui-purchase-6fd81faf0d05/`.
Its index SHA256 is `6fd81faf0d057b1c689610ebfbd04193071e282d85e27ec07b34f927525be1f5`.
It requires the matching purchase backend and is not yet deployed. The prior
qualified backend and dashboard remain live on dev, Yaya and Framework.