Plugin registry platform

What shipped

The registry used to be a single static plugins/registry.json in the website repo — every new plugin or version meant a maintainer PR. Since Tabularis v0.16.0, plugin discovery runs through the hosted Tabularium registry instead; the static file survives only as a legacy source merged into the catalogue automatically.

Instead of adapting an existing marketplace (Open VSX and a Gitea package-registry fork were the candidates), a purpose-built registry was written: TabularisDB/tabularium — self-hostable, with the official instance at registry.tabularis.dev.

Delivered, matching the original goals:

• OAuth-based ownership. Authors sign in with GitHub, GitLab, or any Gitea/Forgejo instance (Codeberg included) and claim a plugin slug. Ownership is verified against the linked repository.
• Linked-repo publishing. New releases on the linked repo are picked up automatically via webhooks — no website PR, no maintainer in the loop. The .tabularium manifest is resolved from the release assets.
• Hybrid storage. The registry is a catalog + trust layer, not a CDN — binaries keep living in the author's Releases. On install, Tabularis verifies the registry's JWS signature and the download's SHA-256.
• Download analytics. Per-plugin, per-version, per-platform counts.
• Manifest validation at publish time. Schema-validated; invalid manifests are rejected (HTTP 422). CI can pre-validate via POST /api/manifest/validate.
• Client install unchanged. The registry changed how plugins are discovered and resolved; the install path stayed put.

Themes and other kinds slot into the same pipeline via kind: in the manifest — the kind system is admin-configurable per instance.

Docs

• Publish a plugin: docs.tabularium.wiki/publishing
• Manifest reference: docs.tabularium.wiki/manifest
• Self-host your own instance: docs.tabularium.wiki/deploy (point Tabularis at it via tabulariumRegistryUrl)