The Sovereign Supply Chain

“Trust is not assumed; it is proven.”

Every modern language ships a package manager. npm, cargo, pip, go get---they all follow the same blueprint: a centralized registry, a username and password, and a trust by default contract that says “install this code and hope it doesn’t destroy your system.”

Janus rejects this blueprint entirely. Hinge, the Janus package manager, is not a convenience layer on top of a corporate registry. It is a cryptographic trust engine built on the same doctrines that define the language itself: Syntactic Honesty, Revealed Complexity, and Mechanism over Policy.

This document explains why.

1. The Problem with Centralized Registries

The software supply chain is broken. Not theoretically---demonstrably.

left-pad (2016): A single developer unpublished an 11-line string-padding function from npm. Thousands of builds broke worldwide---including React, Babel, and the entire Node.js ecosystem. One person, one decision, one registry. Total systemic failure.

SolarWinds (2020): Attackers compromised the build system of a widely-trusted vendor. Malicious code was signed, distributed, and installed by 18,000 organizations including the US Treasury and Department of Homeland Security. The centralized trust model didn’t just fail---it was weaponized.

Dependency Confusion (2021): Researchers discovered that internal package names could be hijacked on public registries. By publishing packages with names matching private dependencies, attackers could inject malicious code into enterprise build pipelines automatically. The registries couldn’t distinguish intent from intrusion.

Typosquatting: Packages named crossenv instead of cross-env, coffescript instead of coffeescript---malicious code hiding behind spelling mistakes. npm’s response? Reactive takedowns, after the damage is done.

The pattern is always the same: a centralized registry is a single throat to choke. Governments can compel takedowns. Corporations can revoke access. Attackers need only compromise one server, one account, one build system.

npm install runs arbitrary code on your machine with no verification, no capability constraints, no proof that the code does what it claims. You are trusting strangers with root access to your build pipeline.

We will not build on that foundation.

2. The Garden Wall Doctrine

In Janus, a library is not a “bag of code.” It is a Capsule---an atomic unit of distribution containing three indivisible elements:

Source: The logic itself (structs, functions, modules).
Proof: Test certificates generated by the Janus compiler. Not self-reported coverage badges. Not “works on my machine.” The compiler signs a cryptographic attestation that the tests passed and the code compiles.
Contract: A capability manifest declaring exactly what the package touches. Filesystem? Network? Cryptographic operations? It is written in the manifest, visible to every consumer before installation.

The Blue Checkmark of Code: hinge rejects any publish attempt that does not include a valid Proof Certificate generated by the compiler itself. You cannot lie about your tests. The compiler is the witness.

This is the Garden Wall. The wall is high. But the garden inside is pristine.

You do not enter the Sovereign Bazaar by claiming your code works. You enter by proving it.

3. Cryptographic Sovereignty

In the centralized model, your identity is a username and password stored on someone else’s server. Your “ownership” of a package is a database row that an administrator can edit.

Hinge does not use usernames. Hinge does not use passwords.

Your Ed25519 keypair IS your identity. Every package author has a Decentralized Identifier (DID)---a cryptographic identity that no registry, corporation, or government can revoke. You hold your keys. You are sovereign.

Content Addressing: Every package is addressed by its BLAKE3 hash. If even one bit of the source changes, the Content Identifier (CID) changes. There is no ambiguity about what you installed---the hash is the truth.
Non-Repudiable Signatures: When you publish a package, you sign it with your private key. That signature is permanent. You cannot deny authorship. The ecosystem cannot forge it.
Post-Quantum Readiness: Hinge supports Dilithium3 hybrid signatures alongside Ed25519. Supply chains must survive the next 30 years. When quantum computers break classical cryptography, packages signed with Dilithium3 remain intact.

There is no “forgot my password” flow. There is no “account recovery.” Your identity is a mathematical fact, not a database entry. This is the cost of sovereignty. We pay it gladly.

4. Federation Over Centralization

If there is no central registry, who decides what to trust?

Chapters.

A Chapter is a group of three or more humans who vouch for each other’s work. Not a corporation. Not a foundation. A small group of real people with real reputations.

N-of-M Governance: No single person can admit or remove a Chapter member. Decisions require threshold consensus.
Cross-Witnessing: Chapters verify each other’s packages. When Chapter A publishes a cryptographic library, Chapter B can independently review and attest to its quality. The attestation is signed and public.
Trust as a Graph: Trust is not a hierarchy with a root certificate authority. It is a graph, computed via shortest-path traversal. The more independent paths of attestation lead to a package, the more trustworthy it is.

This is how trust works in the physical world. You trust your doctor because multiple independent sources---your friend, the medical board, the hospital, your own experience---converge on the same conclusion. Hinge formalizes this intuition into mathematics.

5. The Reputation Formula

Trust is not binary. It is a continuous value, computed from observable behavior:

reputation = 0.4 * accuracy + 0.2 * frequency + 0.2 * cross_verify + 0.2 * tenure

Accuracy (40%): The percentage of a Chapter’s attestations that were not later found to be malicious or incorrect. This is the dominant signal. One malicious attestation can destroy a reputation.
Frequency (20%): Active participation in the ecosystem. Chapters that review and attest regularly are more trustworthy than dormant ones.
Cross-Verification (20%): How often other Chapters independently confirm your attestations. Agreement from independent sources is the strongest signal of truth.
Tenure (20%): Time-based trust building, capped at 12 months to full weight. New Chapters are not distrusted---they are unproven. Time separates the committed from the tourists.

Catastrophic Drop: A single confirmed malicious attestation triggers a reputation drop exceeding 0.3. This generates an ecosystem-wide alert. You cannot recover from betrayal by waiting it out.

Low-Confidence Flagging: Attestations from Chapters with a reputation score below 0.4 are visibly marked as low-confidence. Consumers see the warning before they decide to trust.

This is Mechanism over Policy. We do not write rules about who is “allowed” to publish. We build a mathematical system where trustworthy behavior is rewarded and malicious behavior is self-punishing.

6. Transparency Without Authority

Every publish, every attestation, every revocation is recorded in a Merkle tree---a transparency ledger that anyone can verify independently.

DID-Signed Checkpoints: Periodic snapshots of the ledger state, signed by multiple Chapters. Anyone can verify that the ledger has not been tampered with.
Revocation Certificates: When a vulnerability is discovered, the author (or a trusted Chapter) can issue a revocation. Revocations come in two severities: advisory (warn consumers) and critical (hard block installation).
No Silent Removals: No administrator can quietly delete a package. Revocations are public, signed, timestamped, and auditable. The ledger remembers everything.

The transparency ledger is the shared truth. It is not a database controlled by a company with a terms-of-service agreement that changes quarterly. It is a cryptographic structure that anyone can independently verify.

7. The DMP Transport Layer

How do packages travel from author to consumer if there is no central server?

Through the Distributed Message Protocol (DMP).

Topic Namespace: Package announcements are published to structured topics: $HINGE/{chapter_did}/{package_name}/announce
Gossip Propagation: Announcements spread peer-to-peer. No single server distributes packages. No single point of failure controls distribution.
Offline-Capable: Your local cache and lockfile are sufficient to build. Network connectivity is a convenience, not a requirement.

The protocol is the registry. Not a website. Not a corporation. A protocol that anyone can implement, anyone can participate in, and no one can shut down.

8. One Binary Philosophy

“We rival bun by being one tool.”

We do not ship separate binaries for separate concerns. The janus binary is the compiler, the runner, the tester, AND the package manager:

janus init --- Create a new project with a janus.kdl manifest.
janus build --- Compile your code.
janus test --- Verify your code and generate proof certificates.
janus pkg publish --- Seal the Capsule and announce it to the network.

No separate hinge binary to install. No version mismatches between your compiler and your package manager. No additional attack surface from a second toolchain.

Tooling consolidation is not a convenience---it is a security decision. Every additional binary in your toolchain is an additional vector for supply chain attacks. One binary. One trust boundary.

9. Why Build From Scratch?

The obvious question: “Why not use cargo? npm? pip? IPFS?”

“Why not just use cargo/npm/pip?” --- Because they assume a trusted centralized authority. Their entire security model depends on a single organization maintaining a registry with integrity. That assumption has been violated repeatedly. We will not build our sovereignty on someone else’s foundation.

“Why not use IPFS?” --- Content addressing alone does not prove authorship. IPFS can tell you what a file contains. It cannot tell you who made it, whether it was tested, or what it touches on your system. We need all four properties.

“Why post-quantum cryptography?” --- Because supply chains must survive the next 30 years. A package signed today with only Ed25519 may be forgeable in 2040. Dilithium3 hybrid signatures ensure that the cryptographic foundation outlives the hardware generation that created it. This is Strategic Pragmatism applied to cryptography.

“Why reputation mathematics?” --- Because access control lists do not scale. The internet has proven that centralized “approved publisher” lists become political, bureaucratic, and ultimately compromised. Mathematical trust based on observable behavior scales to millions of participants without a governing body.

“Why self-contained Capsules?” --- Because the Libertaria SDK needs these primitives. Hinge is not just a package manager for Janus---it is a prototype for sovereign software distribution in a world where centralized trust is a liability.

10. The Vision

A world where janus pkg install crypto means:

The package is content-addressed. You can verify it is the exact code the author intended. Not a modified version. Not a compromised mirror. The hash is the truth.
The author is cryptographically identified. You know who made it. Not a username on a website---a mathematical identity bound to a keypair that no one else holds.
The package was witnessed by multiple independent Chapters. You know that others---real people with real reputations---have reviewed it and staked their standing on its quality.
The package includes proof certificates. You know it works. Not because the author said so, but because the compiler attested to it.
The package’s capability manifest tells you exactly what it touches. Filesystem access? Network sockets? Nothing? You know before you install. No surprises. No hidden effects.

No centralized authority. No corporate gatekeepers. No single point of failure.

The garden grows because the wall is high---and everyone who enters proved they belong.

Related Reading:

The Manifesto --- Why Janus Exists
The Bedrock --- Foundational Principles
Strategic Pragmatism --- Tactical vs. Strategic Design