Skip to main content

How to Contribute

Contributions are welcome. This page is the orientation; the CONTRIBUTING.md in the code repository is the authoritative and complete version, and is the one to follow when actually opening a PR.

Where help is most useful​

  • DID method implementations — additional DID method resolvers
  • Framework integrations — middleware for additional AI agent frameworks
  • Documentation — tutorials, guides, and examples

Beyond those, bug reports with a minimal reproduction, and improvements to the example apps, are always useful.

Improving these docs​

This site is open source too, in its own repository: helixid/helix-wiki.

Every page has an "Edit this page" link at the bottom. It opens the source file on GitHub, where you can edit in the browser and open a pull request — no clone, no local setup. For a typo, a broken link, or a sentence that is wrong, that is the entire workflow.

For anything larger — a new page, or restructuring a section:

git clone https://github.com/helixid/helix-wiki.git
cd helix-wiki
npm install
npm start

Pages are Markdown; you do not need to know React or Docusaurus to write one. npm run build is the check to run before opening a pull request — broken internal links fail the build, so a green build means every cross-reference resolves.

If you spot something wrong but would rather not fix it yourself, open an issue — that is genuinely useful on its own. Details and conventions are in the repository's CONTRIBUTING.md.

Security issues do not go through this process

Do not open a public issue or PR for a vulnerability. See Reporting a Vulnerability.

Before you start​

For anything beyond a small fix, open an issue or a GitHub Discussion first. HelixID has a written constitution and an append-only decision log, and a change that cuts across an existing decision is much easier to agree on before the code is written than after.

Development setup​

Prerequisites and bootstrap:

pnpm install
pnpm build

This is a pnpm workspace — pnpm, not npm. Internal dependencies are linked with workspace:*, and phantom dependencies are deliberately impossible. See Design Decisions.

Configure .env from .env.example before running anything that needs the API. The default runtime is SQLite plus an in-memory cache plus did:web, with no external infrastructure. Full variable list: Environment & Configuration.

set -a; source .env; set +a
pnpm --filter @helixid/api dev

Running tests​

pnpm test

End-to-end tests live in the e2e/ package. Hedera testnet writes are gated behind HEDERA_E2E_TESTNET, which must stay false in standard CI.

The demo apps have their own test suites — for instance, the consent demo's regression test asserts on consent-prompt counts:

pnpm --filter @helixid/example-e2e-consent-demo test

Repository layout​

See Project Structure for the full tree and which workspace owns what.

The rule that matters most for contributors: helix-core owns everything cryptographic. Adapters and integrations must not hand-roll VP canonicalization, base58/base64url encoding, Ed25519 signing, or verification semantics.

Licensing of contributions​

HelixID is Apache License 2.0 — chosen for enterprise compatibility, explicit patent protection, and no copyleft friction for proprietary AI agent integrations. Contributions are accepted under the same license, and commits must be signed off under the DCO.

Community​

A Code of Conduct applies to all project spaces; it is in the repository as CODE_OF_CONDUCT.md.

Next​

Coding Standards & PR Process