I’ve built a live-runner capability and put the container in Swarm - Ethereum’s decentralised storage layer - rather than Docker Hub, served through a real OCI registry. I’d like a few Orchestrators to try pulling it, because it has only ever been pulled by me, on my own network.
Two separate asks, and the first is much smaller than the second.
Ask 1: does it pull?
podman pull registry.hobcroft.org/transcoding-with-captions:latest
docker works identically. No --tls-verify=false, no editing daemon.json - real hostname, real certificate. Pin it if you’d rather not trust the transport:
podman pull registry.hobcroft.org/transcoding-with-captions@sha256:c5b5c1236f824fd38357ead9053ec1f0b1ebbb7ebdd76cc965826940b63ec3dc
There’s a script that pulls it, starts it, checks /health and prints a block you can paste back: deploy/test-pull.sh in the repo below. A failure is more useful to me than a success - I have exactly one data point and it’s from my own LAN.
Fair warning: it’s 5 GB and my uplink is 25 Mbit. So it’s one command and about five minutes of your attention, but half an hour of waiting - and it’s shared with anyone else pulling at the same time. That’s the honest number.
Which leads to the interesting part.
The bit that might actually be useful to you / to Livepeer Network
The image lives in Swarm. My registry is one gateway to it, not the source of it.
That’s different from a normal registry in a way that matters for BYOC specifically. With Docker Hub or a self-hosted registry, whoever publishes an image pays for every byte anyone pulls, and their bandwidth is a ceiling for the entire network. Here it isn’t: run your own registry against your own bee node (golang source here) and the content comes from Swarm’s storer nodes in parallel, bounded by your download speed. My box isn’t in the path at all.
And there’s a coherence argument I think is worth making
We ask people to run Orchestrators because compute shouldn’t depend on one company. Then we hand them capabilities out of Docker Hub, GHCR or GCR - three companies’ - and the whole decentralisation argument quietly stops at the container boundary.
That gap gets wider with BYOC, not narrower, because BYOC makes the container itself the unit of capability. If capability images live in a hosted registry then that registry is a single point of failure for the network’s functionality, a single point of censorship for what capabilities may exist, and a rate limit somebody else sets. None of those are hypothetical: Docker Hub already rate-limits anonymous pulls, and registries have removed images before.
Swarm is a closer fit than the alternatives for a reason that isn’t ideology. It settles on Ethereum, it’s paid for with a token you hold in the same wallet you already use for the protocol, and storage is prepaid with postage rather than rented from an account with a company. An Orchestrator can pay for capability distribution with the same Ethereum key it uses to earn fees, and no third party is involved in either. That’s the same shape as Livepeer itself: permissionless participation, on-chain settlement, no account with anybody.
I’m not claiming Swarm is the only answer - IPFS with pinning, or Arweave, would each remove some of this. But they need a second identity and a second relationship, and Swarm doesn’t - it uses the same one that Livepeer (and Ethereum, and Arbitrum) does.
So there are two routes:
- Through my registry - one command, no setup, slow, and dependent on my home internet.
- Your own - needs about an hour, a Bee node, and a small amount of xDAI and BZZ. Then it’s fast and depends on nobody.
I’ve written the second one up as an agent skill, because the fiddly part isn’t the registry, it’s funding a Bee node - and a Livepeer Orchestrator is unusually well placed to do that, since fund.ethswarm.org swaps straight from Arbitrum, where you already hold ETH for the protocol. One transaction, with an asset you already have, into a network that settles on the same chain you already settle on.
The skill is at skills/swarm-registry-for-orchestrators/ in the repo, but you don’t need Radicle to read it. It’s also in Swarm, which felt like the right place for it:
# from any browser or curl, via a public gateway
curl -O https://download.gateway.ethswarm.org/bzz/67b8f6cf47342a60551a95c9438066fc43f1bd6e9e798b4096b2e76919c217de/
# or, once you have your own Bee, from the network directly - no gateway involved
curl http://localhost:1633/bzz/67b8f6cf47342a60551a95c9438066fc43f1bd6e9e798b4096b2e76919c217de/
Drop it in ~/.claude/skills/ and ask your agent to set it up. It documents the things that cost me time rather than the things that are in the README - chiefly that --swap-enable is off by default and an empty chequebook is still a 73x speedup over none.
Ask 2: does the capability work, and would you run it at Devcon?
transcoding-with-captions/whisper - one live A/V stream in, transcoded renditions and live captions out, from the same session. The stream is decoded once and feeds both the encoder ladder and speech-to-text, so captions cost far less than running transcription separately. "captions": false serves a plain transcoding customer at plain transcoding cost.
whisper large-v3-turbo and tiny are baked in. No translation models ship with it - translation works, but which models are worth putting in front of an audience isn’t a judgement this image should make for you. Mount a directory at MT_MODEL_ROOT and they light up.
Tested end to end on x86 against a mainnet Orchestrator (go-livepeer 0.9.1, -useLiveRunners, static registration, no orchSecret): 720p30 in, 360p and 144p out, English captions, paid in ETH on Arbitrum. Every frame published, nothing dropped.
Why I’m asking now: I’d like to use this at Devcon 8 in Mumbai, for live captions on talks. There’s a Devcon Improvement Proposal published here. What it needs is Orchestrators willing to run it - ideally two or three independently, so no single machine is the reason subtitles stop mid-talk. A GPU operator willing to spend an hour is the single most useful thing anyone can offer; it has only ever run on CPU, and what I can’t tell you today is how many concurrent sessions one card serves, which is exactly the number an Orchestrator needs.
What I’d like back
- “it pulled” / “it didn’t, here’s the error” - this one most of all
- “I ran it on a GPU and got N sessions”
- “here’s why serving images from Swarm is a bad idea” - genuinely, better now than in November
Source, Unlicense: rad clone rad:zVjqknCK5c7TWDqeVaTuAKWmHgxZ
Registry: registry.hobcroft.org · Swarm feed owner 0x8dd1d034615FC3D652a6E63c2777788d75517912