tulpa compute calls, media apps, third-party providers · 07_compute_marketplace/APP_INTEGRATION_NODES.md

Nodes in Our Apps — tulpa compute calls, media apps & third-party providers

Date: 2026-09-06 · Answers: "Consider using nodes in our apps and systems — when people call for compute on the tulpa platform and affiliated media apps that integrate with third-party compute providers such as Local Media Studio."

Status: implemented. qmarket/ (running today) IS this pattern — the demo literally has tulpa buying a render from Local Media Studio.

1. Three node tiers — which apps get what

Tier	Who	Runs	Cost/complexity
Light (RPC client)	most apps — tulpa, doof, tradez frontends	nothing on-box; HTTPS calls to the gateway (qmarket)	minutes
Gateway-embedded	apps with backend logic (hub, qalarc.ai API)	`qmarket.py` pattern (or import its functions) — talks to loopd + chain	hours
Full node / provider	compute sellers (Local Media Studio, minirig)	Qalnet full node + provider adapter (attests jobs, settles on-chain)	Phase 1

The insight: apps don't need nodes to PARTICIPATE — they need the gateway. Only providers and validators need chain presence. That keeps every qalarc app integration to an HTTP call, while the chain still underwrites every escrow and receipt.

2. The tulpa compute-call flow (as demonstrated today)

tulpa app ──POST /jobs {buyer:"tulpa-app", provider:"local-media-studio",
                         kind:"render", spec:{frames:240}}──► qmarket :8824
   │ 1. ESCROW   hold ~115% of estimate from tulpa's credit account (loopd → qal_credit on-chain later)
   │ 2. DISPATCH provider adapter executes (ffmpeg/GPU render at Local Media Studio)
   │ 3. ATTEST   provider returns metrics {frames, gpu_seconds, bytes}
   │ 4. SETTLE   actual = metered × price; release difference; 10% fee; provider EARNINGS accrue
   │ 5. PROVENANCE output hash anchored on Qalnet (tx + object id)
   ◄── response: job receipt {cost, metrics, output_path, anchor:{tx, sha256}}
tulpa app verifies the output anytime: qalpipe verify <output>  → PASS (against the chain)

What the app developer writes: one POST and one verify call. Everything between is the system's problem, not theirs.

3. Third-party provider onboarding (Local Media Studio pattern)

A provider is three things: an adapter, an identity, an account.

Adapter — a function (today: in-process; Phase 1: standalone binary calling the provider's own API) translating a job spec into their workload + returning attested metrics. The LMS adapter: {frames} → render → {frames, gpu_seconds, bytes}.
Identity — Qal ID device DID + can-run-jobs accreditation (Hierarchies); revocable in ~2s if their box goes rogue.
Account — a credit account that EARNINGS flow into (AU$1:1 redeemable). This is the pitch to third parties: "plug in your idle machines, get paid in dollars-that-redeem, with receipts your customers can verify."

Trust ladder over time: invited (now) → accredited → staked (G-QALS slashable) → open registration (post-VASP). See P2P_COMPUTE_MARKET.md §4.

4. Where the nodes actually live (Phase 1 topology)

            ┌─── Tailscale mesh ───────────────────────────────┐
superlocal ─┤ validator#1 + qmarket gateway + loopd + MinIO    │
minirig ────┤ validator#2 + PROVIDER NODE (inference, GPU)     │   apps (tulpa etc.)
bb-mini ────┤ validator#3 + witness                           │   reach the gateway
cloud VM ───┤ validator#4 + public RPC gateway (auth'd)        │   over HTTPS/Tailscale
LMS ────────┤ PROVIDER NODE (render) — full node, attests jobs │
            └──────────────────────────────────────────────────┘

5. What each affiliated media app gets from a single integration

App	Compute calls	What Qals adds
tulpa	renders, voice/video synthesis	pay-per-job from prepaid credit; provenance on every artefact ("this avatar render, by this provider, unmodified")
doof.ing	memes/generative	gasless micro-jobs (Qal Pass), receipt-NFT-ready outputs
tradez	signal inference	auditable signal provenance for clients
endispute	doc processing	evidence-grade receipts (the premium product)
qalarc.ai	client LLM work	per-client metering + margin visibility + provenance certificates

6. Roadmap

Now (done): gateway pattern + two-party sale + provenance — paper money, mock adapters.
Weeks: real adapters (ollama on 8060S, LMS's real API), loopd wired into hub metering, provider earnings view in Qal Wallet prototype.
Phase 1: publish qal_credit on-chain; providers get on-chain accounts; ComputeJob objects replace paper receipts; provider stakes.
Phase 2: external providers self-serve via the accreditation flow; earnings redeem to AUD (licensed path); 402 endpoint so outside agents can buy tulpa/LMS compute.

← P2P Compute MarketIdentity & AI →