Skip to content

Roadmap

iiiris is growing from a best-in-class IIIF Image API server into a complete, single-stack IIIF platform — covering the key IIIF APIs in one performant, easy-to-operate Go binary. The Image API is the grounding core; everything else orients around it.

This is the stable, reader-facing roadmap. The design rationale behind it (options weighed, decisions made) lives in the brief; as each capability ships it graduates to its own implementation brief → spec.

Where iiiris stands today

IIIF API Status
Image API 3.0 / 2.x (Level 2) ✅ shipped
Authorization Flow API 2.0 (+ Auth 1.0 dual-advertisement) ✅ shipped
Presentation API 3.0 / 2.1 (serve + auto-derive, bundled viewer) ✅ shipped v0.6.0 — author/edit (1c) planned
Content State API 1.0 planned — Phase 2
Content Search API 2.0 planned — Phase 3
Change Discovery API 1.0 planned — Phase 4
Presentation API 4.0 (release candidate upstream) planned — 2.0 era, experimental flag

Guiding principles

These constrain every phase:

  • Stateless where possible, stateful only where unavoidable. The Image API owns no canonical data — it resolves an identifier and derives output on demand. That posture is preserved wherever the IIIF data model allows (Presentation serve + derive, Content State). State is accepted only where an API is inherently stateful (a search index, an annotation store).
  • One binary, capabilities toggle via config. iiiris stays a single iiirisd binary. Each capability is a subsystem enabled by configuration, not a separate deployable. Operators scale by running the same binary in different role configurations.
  • Zero-config stays load-bearing. ./bin/iiirisd with no flags, file, or env vars keeps serving on :8080. No new capability may require configuration to keep the default image-server path alive. Every stateful capability ships off by default.
  • Coherent, role-oriented config. Each capability's configuration groups under one coherent section, ships off by default, and adds no orphan flags — config stays navigable as the platform grows.
  • Honesty gate. No advertised feature the server won't actually serve; advertisement and enforcement come from one source (as the Image API's Supported* slices already do).
  • Conformance-gated in CI. Each new API gets a conformance check, modelled on the project-local iiif-auth-conformance harness.
  • Performance-competitive. Hot paths carry a benchmark posture; parity or better is a release gate.
  • Reuse before invention. Caches, sources, hooks, and the admin UI are extended before new infrastructure is built. Persistence technology for each stateful capability is decided in that capability's own brief.

Phases

Sequencing follows the IIIF data-model dependencies. Each phase ships independently and is useful on its own.

Phase 0 — Harden the core (in flight)

Pre-1.0 stabilisation of the Image + Auth core: performance parity, IIIF conformance, the Windows release pipeline, operational polish.

Phase 1 — Presentation API 3.0 (gates 1.0)

The document model that describes and structures objects — manifests, collections, canvases, ranges, annotation pages.

  • 1a. Serve / proxy manifests and collections — resolve a Presentation identifier to a backing source and serve it, as the Image API resolves image identifiers today. Stateless.
  • 1b. Auto-derive manifests on the fly from a directory of images (or a hook-supplied descriptor), wiring in the server's own Image API services per canvas. Stateless. "Point iiiris at a folder, get a valid manifest and a working viewer."
  • 1c. Author / edit manifests via write APIs / admin UI, persisted to a manifest store. Stateful, off by default. Lands in 1.x with Phase 3's stateful work.

🎯 1.0 — the first platform milestone

1.0 ships when Phase 1 serve + auto-derive (1a + 1b) and a working bundled viewer land alongside the hardened Image + Auth core. A 1.0 deployment is credibly "more than an image server" — point it at a folder and get a manifest and a viewer. Manifest author/edit (1c) is not part of the 1.0 gate.

1.0 checklist

Gates for the 1.0 tag (the contract above, made concrete):

  • [x] Image API 3.0 + 2.x, Level 2 — shipped.
  • [x] Authorization Flow API 2.0 (+ Auth 1.0 dual-advertisement) — shipped.
  • [x] Performance parity with Cantaloupe — win-or-tie on every measured cell (see briefs/CANTALOUPE_PARITY.md); held as a release gate, not a one-time check.
  • [x] Presentation API serve + auto-derive (Phase 1a + 1b) — shipped v0.6.0. Contract: specs/presentation.md.
  • [x] Bundled viewer at /view/{id} — shipped v0.6.0 (self-hosted Mirador default + Universal Viewer).
  • [ ] Windows release pipeline — pre-built Windows artefacts published on each release (the EC2-orchestrated builder; today gated behind RUN_WINDOWS=1). The main remaining engineering gate; see briefs/WINDOWS_EC2_RUNNER.md.
  • [x] IIIF conformance posture — decided: accept the allow_failure Image-API validator stage for 1.0. Its 3 failures are upstream iiif-validator issues (pinned at v1.0.5, unmaintained since 2019), not iiiris defects: two are validator crashes (baseurl_redirect, and size_noup — the latter while iiiris correctly rejects an upscale without ^), and one (info_json) is the validator demanding a byte-for-byte id where iiiris emits the canonical service URL per IIIF Image API § 5.3. Blocking on an unmaintained validator is an indefinite wait for non-iiiris bugs. Rationale + per-test detail: iiif-compliance.md.

Not gating 1.0 (deliberately deferred): manifest author/edit (1c, Phase 3); Content State / Content Search / Change Discovery (Phases 2–4); and the operational nice-to-haves (EV/OV MSI code-signing, Helm chart, published macOS binary, installer GUI checkbox) tracked in deployment.md "What's not yet shipped" — that list is the single source of truth for deferred work; this checklist only enumerates 1.0 gates.

Phase 2 — Content State API 1.0

Encode and share a specific view (a region of a canvas, a set of canvases) as a portable link / payload. Mostly client-facing; the server offers initialization/resolution endpoints referencing Presentation resources. Largely stateless. Sequenced early as a low-cost, high-visibility win once Presentation exists.

Phase 3 — Annotation store + Content Search API 2.0

The unavoidable stateful work, taken together because Search needs content to search.

  • 3a. Annotation server — a W3C Web Annotation store/endpoint, the substrate Content Search indexes and Presentation annotation pages reference. Stateful, off by default. Designed as a first-class destination for machine-generated annotations (OCR/HTR output, bulk ingest) — the shape AI-era demand takes on a IIIF server.
  • 3b. Content Search API 2.0 — the search HTTP surface plus an index. Embedded default + pluggable: an embedded index so a single node works when enabled, with a pluggable interface for external engines at scale (mirroring the cache-backend pattern). Off by default.

Manifest author/edit (1c) lands in this window, sharing the same "stateful store, off by default" shape.

Phase 4 — Change Discovery API 1.0

An Activity Streams feed so aggregators can harvest what changed. Last, because it announces lifecycle events for the resources earlier phases introduce. Reuses the persistence the stateful capabilities established.

Beyond 1.0 — the 2.0 era

Themes committed for the era after 1.0, alongside Phases 2–4. The 2.0 milestone itself is deliberately undefined until 1.0 ships and Presentation 4.0 finalises upstream; each item graduates to its own implementation brief. (Rationale and the July 2026 landscape review behind these live in briefs/ROADMAP.md.)

  • Presentation API 4.0 (Canvas → Container with 2D Canvas, audio Timeline, 3D Scene). Implemented against the upstream release candidate, shipped behind an experimental config flag, off by default, in the existing multi-version dispatch alongside 2.1 + 3.0.
  • A/V and 3D: describe, don't process. iiiris models A/V and 3D resources in (derived) manifests and serves their bytes statically — range requests, no transcoding; libvips stays the only media dependency. Technical metadata (e.g. duration) arrives via the existing descriptor layering (sidecar/hook), not a new probe dependency. Includes a 3D pilot: derive a Scene manifest from a folder containing glTF.
  • AVIF output format — additive SupportedFormats entry; broad browser support at roughly half JPEG's bytes. (JPEG XL: tracked, not planned, until browser support moves.)
  • AI-ready annotations — Phase 3's store and search are designed for machine-generated content: bulk HTR/OCR ingest as Web Annotations, hook-driven auto-annotation; semantic/vector search is an open question for the Content Search brief.
  • Georeferencing passthrough — navPlace / Georeference extension properties flow through descriptor layering into derived manifests.
  • Ingest with format migration — the ingest tool converts sources to performant formats (HTJ2K / pyramidal TIFF), not just registers them.
  • Ecosystem presence — listing on the iiif.io image-servers page, published conformance and benchmark results.
  • Benchmark posture — add IIPImage (the raw-performance leader) to the comparative bench alongside Cantaloupe; parity-or-better means parity with the fastest peer.

Platform glue

"A IIIF platform" is more than the API surface. These thread through the phases above:

  • Bundled viewer. OpenSeadragon stays for the image-only / admin case. For Presentation, iiiris bundles both Mirador and Universal Viewer behind a viewer-agnostic embedding, selectable per deployment / per manifest. Lands with Phase 1 and is part of the 1.0 gate.
  • Ingest tooling. Point iiiris at source images and have it prepare derivatives, manifests, and search-index entries — the operational thread that ties the APIs together. Matures across phases.
  • Annotation server. Both an API substrate and a platform capability (Phase 3a).

Out of scope

  • Service-family decomposition into separate deployables — iiiris stays one binary; capabilities toggle via config.
  • Serverless/Lambda packaging — that pole of the market is well served (serverless-iiif); iiiris competes on the zero-config binary and container. Revisit only on operator demand.
  • A/V transcoding or 3D processing — iiiris describes these media in manifests and serves their bytes; it does not process them.
  • Non-key / experimental IIIF specs beyond those named here (the four phased APIs and the 2.0-era items above) — considered only after these ship.
  • Becoming a full DAMS / repository. iiiris is a IIIF platform, not a collection-management system; cataloguing, rights, and workflow belong to upstream systems that feed it.