vela

Governance

Governance.

How the protocol is decided, maintained, and protected from capture. Open spec, open reference implementation, public RFC process, no single-vendor lock-in. Honest about where governance is today and where it goes.

Apache-2.0
reference impl
MIT dual-license
CC-BY-4.0
spec text
free to fork
3
reducer impls
byte-identical
RFC
process
open issues, public PRs

The protocol is open.

The wire format, the canonical-JSON serialization, the signing scheme (ed25519-canonical-json-v1), the reducer semantics, and the event schema live in /spec. They are versioned with RFC 2119 conformance language. A new implementation is conformant iff its byte-output matches the reference reducer on the published test corpus.

Three reference reducers, byte-identical.

Rust (vela-reducer), Python (vela_reducer.py), TypeScript (vela_reducer.mjs). Each can replay the canonical event log to byte-identical state. Anyone worried about implementation lock-in can run a fourth reducer and verify against the test corpus in twenty minutes.

Local-first by design.

Every signed event carries its actor's public key. Every reducer can replay the canonical state from a folder of events with no network. The hub at vela-hub.fly.dev is a mirror, not the source of truth. If the canonical hub disappears tomorrow, anyone with the event log can stand up another one with vela registry mirror.

Licensing.

The reference implementation, spec, and reducer test corpus are dual-licensed Apache-2.0 / MIT — pick whichever fits your downstream license. Documentation (this site) is CC-BY-4.0. Patent grants are explicit in the Apache license.

Files: LICENSE · LICENSE-MIT · LICENSE-APACHE.

Compatibility promises.

Two version axes, kept distinct on every page that exposes them:

Protocol version
Currently v1. Embedded in every signed event as the "v" field. Breaking changes increment the major. Hubs MAY accept multiple versions and MUST advertise supported versions in /.well-known/vela.
Binary version
Currently v0.103.0. Implementation-level semantic versioning of the Rust workspace. Independent of protocol version. A binary at v0.49 may still implement protocol v1.

RFC process.

Protocol changes go through a public RFC opened as a GitHub issue with the rfc label. Each RFC has a motivation, a proposed change, a backwards-compatibility analysis, and a kill criterion (when do we revert this if it doesn't land). RFCs sit in discussion for a minimum of 14 days before merge. Implementation must precede or accompany merge — no design-only RFCs.

Open RFCs: github.com/vela-science/vela/issues?label=rfc.

Capture defenses.

Three structural defenses against single-vendor or single-funder capture:

Portable signed events
Ed25519 signatures travel with events. A finding signed for one hub verifies on every conformant hub. There is no central key authority that gates participation.
Replaceable reducers
Three independent reducer implementations (Rust + Python + TypeScript), byte-identical and checked in CI on every push. A fourth or fifth can be written in any language. The reference reducer is dual-licensed Apache-2.0 / MIT.
Mirrorable hubs
The hub stores signed manifests pointing at content-addressed frontier files. Mirroring is a no-op for authenticity. Anyone can run their own hub against the same protocol.

The defense isn't "we promise to stay open." It is that closing wouldn't accomplish anything: every event is portable, every reducer is replaceable, every hub is mirrorable. /faq walks the capture-attack scenarios in detail.

Stewardship — honest where this is today.

Vela is currently maintained by one founder. Every signature on the live hub is signed with a key under that founder's control. This is named openly because a protocol claiming to be open governance shouldn't pretend otherwise.

The intended path is transfer to a long-term steward (foundation, consortium, or absorption into an existing open-science institution) once the protocol is in use by independent reviewers and frontiers. The structural defenses above mean that transfer can happen at any time without breaking conformant clients.

Open call: second steward.

RFC-001 · published 2026-05-02 · status: open · deadline: rolling. A protocol with one signing key is not yet a protocol. Vela invites a second steward — an institution or named individual — to hold a co-equal signing role on the canonical hub. This is the prerequisite for foundation handoff and for any adoption argument downstream.

Criteria for a candidate second steward:

Institutional standing
A research institute, university lab, scientific foundation, or open-science organization with public charter and at least 3 years' continuous operation. 501(c)(3) preferred (so the entity can hold the DOI prefix without commercial encumbrance).
Domain credibility
A track record in cumulative-science infrastructure (preprints, registries, shared archives, replication networks). Open-science publications a plus, not required.
Governance posture
Willingness to publish a co-stewardship MOU, hold a designated key, and participate in protocol RFC merges. No equity, no exclusivity, no platform fee.
Operational capacity
One named human committing 0.1–0.25 FTE to frontier curation, signature review, and quarterly governance check-ins. Reviewer stipend negotiable.
Persistence custody
The second steward — not the founder — registers the CrossRef or DataCite DOI prefix that resolves vela: URIs, and signs the deposit MOU with at least one dark archive (Software Heritage for the event log, CLOCKSS or Portico for journal-pinned manifests). This is the precondition for any journal accepting vela: as a primary reference.

Inquiries: will.blair0708@gmail.com with subject RFC-001 second steward. Responses public unless requested otherwise. The first qualified candidate to engage in good faith gets the conversation before any second.

Hub operations and continuity.

The canonical hub at vela-hub.fly.dev is run by the founder today. This is named openly because a hub claiming to host long-lived scientific citations cannot pretend its operational picture is institutional when it isn't yet.

Hosting
Fly.io (Hobby tier through 2026-Q3, Scale tier from 2026-Q4 once the second steward holds the billing relationship). Region iad primary, sjc warm standby.
DNS
vela-hub.fly.dev is a Fly subdomain and survives founder unavailability. The vela.science apex is registered through Cloudflare with a 5-year prepayment; renewal contact is published in /.well-known/security.txt.
Backup
The full event log is git-mirrored to github.com/vela-science/vela on every signed publish. Reconstructing the hub from a clean machine takes one vela registry pull --full against any conformant mirror.
Mirroring
Any third party can run vela registry mirror <vfr_id> --from vela-hub.fly.dev --to <your-hub> to operate an independent mirror. Two such mirrors plus the canonical hub satisfy the §13 hub-equivocation cross-check threshold.
Handoff
On second-steward acceptance (RFC-001 above), DNS, hosting, and the canonical hub key transfer to the steward via a documented runbook in {REPO_URL}/blob/main/HANDOFF.md. The runbook is testable today — a third party with the founder's permission can dry-run the full transfer in a staging environment.
Failure mode
If the hub disappears tomorrow without notice: the event log on GitHub is the source of truth; any conformant reducer reconstructs the canonical state in minutes; the vela: URI scheme can be re-resolved by any new hub with the same vfr_id. Citations remain verifiable; only the read-side resolver path needs replacement.

Conformance registry.

Any reducer implementation that reproduces byte-identical state on every fixture in /reducer-fixtures.tar.gz earns a conformance badge and a public registry entry. The registry is a public manifest signed by the protocol editor; entries are removed only on a regression against a future fixture.

Current entries:

vela-reducer
Rust · reference · canonical conformance witness · current at v0.55.0
vela_reducer.py
Python · stdlib-only · auditable in one sitting · source
vela_reducer.mjs
TypeScript · ESM module · runs in browser + node · source

Submit a new implementation: open a PR adding your reducer to the conformance suite with passing fixtures. The registry is the answer to "how do I know there isn't a single-vendor lock-in?" — not a promise, but a public list of independent implementations that have demonstrably reduced the same event log to the same hash.

Code of conduct + security.

Code of Conduct adapted from the Contributor Covenant. Security disclosures via repo security policy — please don't open public issues for vulnerabilities; use the policy's private reporting channel.

Contributing.

Pull requests welcome. Bug reports on existing primitives go straight to issues. Protocol-level changes go through the RFC process above. Reviewer-in-residence applications (you want to curate a frontier) — open a GitHub discussion under the frontier category.