Strata

We replaced ads with useful work. Idle browser GPUs become a distributed transcription network, slicing podcasts into tasks for ~$0.04/audio-hour. The web gives compute back.

Comment

Inspiration

Imagine you could skip Spotify ads without having to subscribe to Spotify Premium, Spotify still gets paid without having to sell your data for revenue, and Clavicular gets all his 3h+ livestreams transcribed thanks to YOUR Spotify listening hours? Media companies and content creators nowadays are paying $$ for cloud services just to transcribe hours of video, audio, or livestream footage when their perfect solution is just walking around with spare compute for much less. The cheapest cloud transcription tier costs creators about $1.20 per audio-hour. A weekly podcast can run a few hundred dollars a month just to be searchable. Meanwhile, every laptop and phone in the room, literally anywhere you go (when unused) has a GPU sitting idle behind a Chrome tab.

The Distributive Compute Protocol (DCP) already routes work into those tabs. Reading published case studies of creating local computing networks as cloud replacements, the Stratosphere protocol is a layer built on top of existing DCP infrastructure that helps perfectly connect 3 entities in the demand-supply flow for a specific, yet surprisingly very contemporary, untapped market- transcription, specifically automated transcription for media studios, content creators, and content farms. Three parties: a creator (or fan of theirs who runs a clipping farm) who needs transcripts for spamming Instagram reels with 100x clips a day, a site owner (or web platform service, whether a streaming platform, e-newspaper, blog etc. who has visitors), and a tab that has a few seconds of unused GPU. DCP routes the work and in-browser sandbox clients; Stratosphere protocol writes the contracts and handles scheduling (either public network or private computing groups); handles scheduling for each use case; and also settles the books, directly from transcriptor and transcriptee. Meanwhile, the users of the website, web service, etc., are the worker nodes within the Stratosphere, happy to opt in for idle compute on their favourite media site over predatory advertisements that just feed on your sold data.

What Strata Is

Strata, a DCP node-powered transcription service, runs heavy transcription processes by distributing the load into chunks running on the browser of idle computers. A creator drops audio or video into the dashboard following a straightforward registration and onboarding flow. Strata writes a Forecast (job) row, atomically charges the client wallet via Prisma updateMany so the row can never be double-charged, and stamps castedAt. A one-second polling scheduler picks up any cast forecast, decodes the audio with ffmpeg, chunks into 30-second windows (Whisper's input dimension), and submits one DCP job per cast. The job ships as compute.for(slices, whisperWorkFunction) with three required modules declared via job.requires:

  • onnxruntime-dcp/dcp-wasm.js
  • whisper-tiny-encoder-q/module.js
  • whisper-tiny-decoder-past-q/module.js

Browser tabs at dcp.work claim slices, run inference under WebGPU when the device has it, fall back to WASM-SIMD otherwise, and post results back through DCP's scheduler. Each completed slice fires an onResult callback in lib.mjs that decodes the tokenizer output, writes the slice and attestation rows, increments the budget cycle counter, and publishes a Server-Sent Events frame. The catchment view fills column-by-column in the order timestamps return. When all slices land, Strata writes a Catchment bundle and a Settlement row that splits the gross 80% to the distributor and 20% to the platform.

The business model

The triple-entity model is the Stratosphere protocol implemented by Strata. The two-party ad model (reader pays attention, advertiser buys eyeballs, creator gets pennies) is a bad trade. Strata's three-party model:

  1. Client (creator, media company) | pays USD per audio-hour to run transcription jobs (Forecasts in the Stratosphere)
  2. Distributor (business site, web platform | earns 80% of every sealed forecast their visitor compute helped seal
  3. Platform (Strata) | keeps 20% to cover scheduler, settlement, and trust scoring

Visitors to the Distributor's service pay nothing and consent only to running compute they wouldn't otherwise use. Although it is up to the Distributor whether or not they choose to run the opt-in Stratosphere Client on top of traditional ad marketing, given that Strata does not probe into any Distributor layers aside from managing the Stratosphere built on top of the DCP runtimes, market reputation and ethical association shapes whether opt-in users are "potential missed premium tier customers" vs. "gained additional revenue from free site visitors" vs. "volunteer revenue source/opt-in support", depending on the nature of your business.

How we built Strata

Real DCP, public marketplace

Strata's dispatch script in the demo version calls dcp-client against https://scheduler.distributed.computer. We submit without setting job.computeGroups, which lands the job on the public marketplace where any DCP worker can claim slices. We considered private groups gated by joinKey / joinSecret and chose against it for the demo, due to limitations specified in the Challenges section. Group routing is the next step (more below).

A 9-minute podcast chunks to 18 windows. On one warm worker tab, the first slice returns at ~25 seconds (ONNX module load), then subsequent slices land every 3 to 5 seconds.

Sync between distributor and client

Distributor surfaces (the Slopify music-app, in our build) post heartbeats to POST /api/worker/heartbeat endpoint with a stable nodeKey persisted in localStorage. The client dashboard polls /api/worker/active and renders a "live network" indicator. The distributor dashboard reads the same source and pulses the trust panel row matching the worker that just delivered. Both views agree on one WorkerNode table because that's the contract: Strata is the ledger, both sides read from it. The same shape will carry the per-distributor settlement feed in the next iteration.

Challenges we ran into

DCP compute groups, and how we adapted

DCP supports private compute groups gated by joinKey / joinSecret according to the public documentation That's the right production shape for a distributor whose visitor pool is scoped to its own site, and what we originally built Strata around, following a full fleshed out business protocol, but Hackathon scope has Hackathon limitations.

Specifically: provisioning per-distributor keystores in hackathon time was not within scope, and the public "marketplace" (BearHacks computing group) was enough to demonstrate the routing and Whisper performance effectively, albeit with some workarounds to simulate the "allocation" of client jobs to distributor "networks" (public BearHacks network for actual worker nodes isntead of a private DCP scoped to distributor platform users, and writing to a shared database instead for syncing the slices and jobs). To preserve the concept of distributor-scoped routing for the demo, we used Cloudflare tunnels to expose Strata across our demo machines on the BearHacks network, and we treated the WorkerNode table as a stand-in compute-group registry. Each distributor surface heartbeats a stable nodeKey into that table, the dashboards render only nodes inside the declared group label, with the trust panel reads from there. The optic matches a real compute-group routing pass. The underlying transport is still the public DCP marketplace.

Accomplishments

  • Whisper-tiny inference running live in browser tabs on BearHacks venue Wi-Fi. End-to-end (upload, chunk, dispatch, claim, infer, write, seal) ran during the team build, testing, and demo time. That it works and finished Forecasts (transcription jobs) within good runtime on shared conference Wi-Fi, basically.
  • A real DCP integration with an additional scheduling layer and external database.
  • A schema that mirrors the business model. Attestations are one-to-one with slices. Settlements are anchored to the receiving distributor's active slot. The data model is the contract.

Built With

Share this project:

Updates