Introduction

Understand what OMSS Core is, why it exists, and how it fits into the broader OMSS ecosystem.

OMSS Core is the official TypeScript runtime for building OMSS-compliant backends. At a high level, it allows developers to easily create their own OMSS backend, by providing a structured runtime with extension points for plugins, hooks, providers, resolvers, and extractors. It is designed to be minimal, flexible, and extensible, so that backend authors can focus on their specific domain/provider logic without having to reinvent the core runtime.

That design is deliberate. OMSS Core does not try to do everything (i.e. HTTP, caching, authentication etc.). Instead, it acts as a stable center for an ecosystem of plugins and feature modules.

What the core owns

The runtime, shared state, orchestration, and feature coordination.

What the core avoids

HTTP transport, caching policy, auth strategy, and provider-specific business logic.

Why the core is minimal

Creating a streaming backend has many moving parts, but also things that stay the same over different implementations. OMSS Core takes the otherwise repeating code and centralizes it into a single runtime. That means backend authors can focus on writing providers and resolvers for their specific media sources, while plugins allow them to add cross-cutting capabilities like transport, caching, and authentication.

How OMSS Core fits into OMSS

The broader OMSS project defines a standard way for media backends to expose sources through a unified API. OMSS Core sits one layer beneath that API surface. The specification describes what an OMSS-compatible backend should present to clients; the core helps backend authors build those systems in a consistent and extensible way.

That means the core is implementation-oriented, but its value is conceptual as much as technical. It gives the ecosystem a shared runtime vocabulary: plugins, hooks, providers, resolvers, extractors, and source services all have clear places in the system.

Why not put everything (providers, resolvers and transport) directly in the server?

Putting every capability directly into the server would make the system easier to start but harder to evolve. The current design accepts a little more structure up front so features can be swapped, extended, or isolated later. As an example with OMSS Core you can create an instance and reexport it, so that you have one place where you register all the providers, resolvers, and extractors. Then you can create other applications that use the same instance (for example a HTTP server and a CLI tool) without having to duplicate the provider logic.

Why not make plugins optional and bake in defaults?

A heavily opinionated default stack can speed up adoption, but it also makes the runtime less neutral. OMSS Core favors composability so official and community plugins can coexist without the core having to choose one deployment style.