Until now, genes lived in local projects. v0.4 changes that. Genes can now travel across developers through a cloud registry, and the Arena goes global.
Why a Cloud Registry?
Local gene development proved the concept: you can write, compile, test, and rank genes on a single machine. But isolated excellence is not evolution. For genes to compete, propagate, and improve, they need to be discoverable by other developers and executable in shared environments.
We evaluated three architectures for the cloud layer:
- Custom API server (Express/Fastify on a VPS) — full control, but requires managing infrastructure, authentication, database migrations, and scaling. For a solo developer, this is a maintenance burden that competes with protocol development.
- Firebase — excellent real-time capabilities, but its proprietary query language and vendor lock-in conflict with our multi-Binding philosophy. A protocol that preaches portability shouldn't depend on a single cloud provider's SDK.
- Supabase (PostgreSQL + PostgREST + Auth) — open-source core, standard SQL, Row-Level Security for fine-grained access control, and a generous free tier. The REST API is auto-generated from the schema, so adding a new table immediately exposes new endpoints.
We chose Supabase. The deciding factor was RLS: instead of writing authorization logic in application code (where bugs are common and auditing is hard), we express access rules as SQL policies that PostgreSQL enforces at the database level. Every query, regardless of which client sends it, passes through the same security checks.
New Commands
rotifer login # OAuth via PKCE (GitHub / GitLab)
rotifer logout # clear cloud credentials
rotifer publish <gene-name> # upload gene (phenotype + WASM) to cloud registry
rotifer search [query] # browse and search published genes
rotifer install <gene-ref> # download a gene from the cloud
rotifer arena submit --cloud # compete in the global Arena
rotifer arena list --cloud # view global Arena rankings
rotifer arena watch --cloud # real-time ranking updates (polling)
Architecture
The Cloud Binding is backed by Supabase with PostgreSQL and Row-Level Security:
- REST API — gene CRUD, Arena submissions, and ranking queries
- OAuth (PKCE) — secure authentication via GitHub or GitLab, no client secrets needed
- Auto-profile creation — DB trigger creates developer profiles on first login
-
.cloud-manifest.json— links local gene directories to their cloud counterparts
The Global Arena
The local Arena (introduced in v0.1) ranks genes on a single machine. The global Arena ranks genes across all developers. When you run rotifer arena submit --cloud, your gene's phenotype and WASM binary are uploaded, executed in a standardized environment, and ranked against every other gene in the same domain.
This creates genuine selection pressure. A gene that performs well locally might rank poorly when evaluated against alternatives from other developers. The fitness score F(g) is computed identically for all contestants — same fuel budget, same timeout, same input corpus — so rankings reflect real capability differences, not environmental advantages.
Endpoint-Agnostic Design
The CLI supports custom Cloud Binding endpoints via --endpoint flag or ~/.rotifer/cloud.json config. This enables multiple deployments — the official global endpoint, self-hosted instances, or regional mirrors.
This design decision reflects a core protocol principle: no single entity should control gene distribution. The official endpoint at cloud.rotifer.dev is convenient, but any organization can deploy their own Cloud Binding using the same Supabase schema. Enterprise teams can run private registries. Regional communities can run localized mirrors. The protocol doesn't care where the genes come from — content-addressable identity (from v0.2) ensures integrity regardless of the source.
Fixes
- OAuth switched from implicit flow to PKCE for secure token exchange
-
rotifer publishnow saves.cloud-manifest.jsonfor Arena linkage - Graceful error messages for auth-required commands (was showing raw stack traces)
By the Numbers
- 91 → 114 tests (23 new cloud tests)
- 31 files changed, +2,214 lines
OAuth PKCE: Why Not Implicit Flow?
The initial v0.4 prototype used OAuth implicit flow — simpler to implement, but fundamentally insecure for CLI applications. Implicit flow exposes access tokens in URL fragments, which appear in browser history, server logs, and referrer headers. For a CLI that stores tokens locally and sends them to cloud APIs, this was unacceptable.
PKCE (Proof Key for Code Exchange) solves this by generating a one-time code verifier that never leaves the client. The authorization server only issues tokens to the client that can prove possession of the original verifier. No client secret is needed — critical for an open-source CLI where embedding secrets is impossible.
The implementation opens a temporary localhost HTTP server, redirects the user to the OAuth provider, receives the callback with the authorization code, exchanges it for tokens using the PKCE verifier, and shuts down the server. The entire flow completes in under 5 seconds.
Looking Ahead
v0.4 transformed Rotifer from a local development tool into a connected ecosystem. The cloud registry enabled gene sharing, the global Arena created selection pressure across developers, and the endpoint-agnostic design ensured no single entity controls the ecosystem. The next step was adding trust signals — reputation scores that help developers choose between competing genes — which arrived in v0.5.
Get Started
npm install -g @rotifer/playground
rotifer login
rotifer publish my-gene
Top comments (0)