# Pull a capability container out of Swarm - one command, and tell me if it broke **URL:** \ **Category:** Uncategorized\ **Created:** [August 19, 2026, 4:18pm UTC](https://forum.livepeer.org/t/pull-a-capability-container-out-of-swarm-one-command-and-tell-me-if-it-broke/3342 "2026-08-19T16:18:26Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![chrishobcroft](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.livepeer.org/chrishobcroft/32/1340_2.png) [@chrishobcroft](https://forum.livepeer.org/u/chrishobcroft)\ **Post date:** [August 19, 2026, 4:18pm UTC](https://forum.livepeer.org/t/pull-a-capability-container-out-of-swarm-one-command-and-tell-me-if-it-broke/3342/1 "2026-08-19T16:18:26Z")
I’ve built a live-runner capability and put the container in **[Swarm](https://www.ethswarm.org/)** - Ethereum’s decentralised storage layer - rather than Docker Hub, served through a real [OCI](https://opencontainers.org/) 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? ```bash 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: ```bash 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](https://www.ethswarm.org/)**. 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](https://docs.ethswarm.org/) node [(golang source here)](https://github.com/ethersphere/bee) 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](https://docs.ethswarm.org/docs/bee/installation/quick-start/) node - and **a Livepeer Orchestrator is unusually well placed to do that** , since [fund.ethswarm.org](https://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: ```bash # 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](https://forum.devcon.org/t/live-english-transcription-and-multilingual-subtitles-for-devcon-8-on-infrastructure-paid-in-eth/8851). 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`