Provider catalogue
Every provider in omnifs answers exactly three operations: lookup-child, list-children, and read-file. Those map directly to ls and cat at any path the provider exposes. The wire protocol does not change between providers. If you know how to read a file, you already know how to use every provider in this catalogue.
How providers work
Section titled “How providers work”A provider is a WASM component (wasm32-wasip2) that implements the omnifs:provider@1.0.0 WIT interface. The host runtime loads it at mount time. The provider never opens its own socket and never touches credentials directly: the host holds credentials and gates every external callout through an explicit capability. Adding a new provider does not require recompiling the runtime.
The host maintains a capacity-bounded cache, invalidated by upstream events rather than TTLs. Inodes are stable across upstream renames, so tools that track paths (watchers, tail -f, agent loops) do not lose their footing when a resource moves.
Reading a provider page
Section titled “Reading a provider page”Each provider page is structured the same way:
- Mount: the
omnifs.tomlstanza that registers the provider under a mount point. - Path schemes: every path the provider exposes, annotated with whether it responds to
ls,cat, or both. - Config: the fields that go in the mount stanza, with types and required/optional status.
- Examples: runnable commands against real paths, with the output you should see.
The same ls and cat verbs work everywhere. The only thing that changes is the path prefix.
Live providers
Section titled “Live providers”Five providers are available today.
| Provider | Mount prefix | What it exposes |
|---|---|---|
| GitHub | /github | Repos, issues, PRs, CI runs |
| Docker | /docker | Containers, compose projects, system info |
| arXiv | /arxiv | Papers, metadata, category feeds, search |
| Linear | /linear | Teams, issues, priorities, assignees |
| DNS | /dns | A, AAAA, MX, NS, TXT and other record types; reverse lookups; per-query resolver selection |
Quick sample across all five, from a single shell:
# GitHub: list open issues in a repols /omnifs/github/ollama/ollama/_issues/_open
# Docker: check a container's statecat /omnifs/docker/containers/by-name/postgres/state
# arXiv: read paper metadatacat /omnifs/arxiv/papers/1706.03762/metadata.json | jq .title
# Linear: list open issues for a teamls /omnifs/linear/teams/ENG/issues/_open
# DNS: look up MX recordscat /omnifs/dns/example.com/MXWork in progress
Section titled “Work in progress”Thirteen providers are under active development. None are ready to use. They are listed here so you can track progress or contribute.
| Provider | Mount prefix | Notes |
|---|---|---|
| Hugging Face | /hf | Models, datasets, spaces |
| Kubernetes | /k8s | Pods, namespaces, per-context |
| Postgres | /pg | Tables as directories, rows as files |
| Slack | /slack | Channels, threads, latest messages |
| Redis | /redis | Keys projected as files |
| S3 | /s3 | Buckets and object trees |
| Stripe | /stripe | Customers, charges, subscriptions |
| Cloudflare | /cloudflare | Zones, DNS, Workers |
| Vercel | /vercel | Projects, deployments |
| OCI | /oci | Container image layers |
| MCP | /mcp | MCP server tools, resources, and prompts as files |
| Spotify | /spotify | Playlists, tracks, playback state |
| Discord | /discord | Guilds, channels, messages |
Adding a provider
Section titled “Adding a provider”Providers are self-contained WASM components. If a service you care about is missing, you can write a provider for it without touching the omnifs runtime. See Build a provider for the WIT interface, the component scaffolding, and how to register a local build in omnifs.toml.
Pull requests are open. The five live providers are the best reference implementations.