Live data means talking to the outside world: streaming platforms, chat services, score feeds, APIs of every shape. No team can build and maintain an integration for each of them. The only way to scale is to let others build them.
That raises an uncomfortable question. Would you run a stranger’s code inside your live show?
The problem with ordinary plugins
In most applications a plugin is code that runs with the same rights as the application itself. It can read files, open network connections, use as much memory and time as it likes, and crash the host on its way out.
That is acceptable in a text editor. In a live show, one badly written plugin can freeze the program on air, and you cannot ask the audience to wait.
WebAssembly: a sandbox by design
Muxivo Studio provider plugins run as WebAssembly.
WebAssembly is a compact, portable format for code that runs inside a sandbox. A plugin cannot touch anything the host has not explicitly handed to it. No files, no network and no access to the rest of the application unless the host grants it, and each grant is narrow.
In practice:
- A plugin asks; the host decides. To fetch data or perform an action on a service, the plugin requests it through the host, which applies the permissions, accounts and limits.
- Execution is bounded. A plugin gets limited time and memory. If it hangs or misbehaves, it is stopped, and the show carries on.
- Packages are versioned. You know exactly which version of a plugin a project uses, and updating it is an explicit step.
Accounts and keys stay in the application’s own Integrations settings, on your machine. A plugin uses an account through the host; it never needs to hold your credentials itself.
One rule for everyone
There is a rule behind the platform that matters more than any single feature: the plugins we ship use exactly the same public contracts as everyone else.
There is no private back door for our own integrations, no behaviour switched on by a plugin’s name. If one of our plugins needs a capability, that capability is added to the platform for all plugins. That keeps the contracts honest, and it means a third-party plugin can do anything ours can.
Plugins are also connection-agnostic. A chat widget does not care whether messages come from one platform or another; it consumes a common shape, and the plugin’s job is to deliver that shape.
Processing, including AI
Plugins do not only bring data in. They can also process it, as steps in the data flow described in the previous chapter:
- Transformers turn data into a new shape, such as reformatting a message or computing a value.
- Filters decide what passes, what is rejected and what needs a human to review it before it reaches the screen.
- Services do heavier work, including AI. A step can send chat messages to a compatible AI service to summarise them, translate them, or flag the ones that should not go on air.
The same rules apply. A processing step declares what it needs, the host grants it, and the result goes on to the widget in the schema it expects.
Building your own
For developers there is a public author kit: the contracts, documentation and examples needed to build a provider or processing plugin without access to Muxivo Studio’s source code. That is the point of public contracts: everything a plugin author needs is on the outside.
Where things stand
This chapter brings the devlog up to date.
Since the seam that started it all, Muxivo Studio has grown into a GPU compositor with layers and effects, a first step into 3D, overlays on their own channels, outputs to screens, software and the network, an audio engine built as a signal graph, graphics fed by live data, and a plugin platform that is safe by design.
It is still in rehearsal. Some parts are on set, some are being rehearsed, and some are still in the script. Next come the things a product needs before opening night: licensing, the public website you are reading, documentation, an MCP server so AI agents can operate a show, and the visual data flow.
The show is getting closer. Thanks for following along.