AtPack: A Package Registry That Runs on AT Protocol (based on James M. Snell's original article)

This project takes its idea directly from the article "What If npm Ran on AT Protocol?" by James M. Snell (published June 21, 2026), available at <https://www.jasnell.me/posts/what-if-npm-ran-on-atproto>. All credit for the underlying design belongs to the original author. This prompt asks to actually build the thing he described: a real, working package registry that runs on the AT Protocol. Build a functioning package registry on the AT Protocol (the federated protocol behind Bluesky), plus the CLI a developer uses to publish and install from it. This is the real system, not a mock and not an in-browser simulation. It writes real lexicon-typed records to real Personal Data Servers (PDS), signs them with real Ed25519 DID keys, attaches real tarball blobs, ingests the real relay firehose, and resolves and installs real dependency trees. Where the source article names a genuine gap (split-key custody for individuals, full Sigstore-style build provenance), implement what is tractable today and mark the rest as a clearly documented follow-up, but do not stub out the core. In this model you publish in your own repo and registries discover you. The App View is a read-side aggregator, not an authority. Package data lives on the publisher's PDS, signed by their DID, under their control. DELIVERABLES: 1. Lexicon schemas: define the AtPack record types under a project-owned namespace such as `dev.atpack.*` (package, version, publish attestation, name claim, name grant, transfer). Lexicons are atproto's schema definition format (JSON files that describe the shape of each record). Ship them as versioned schema files. 2. `atpack` CLI (TypeScript/Node): `login` (OAuth to a PDS), `publish`, `install`, `resolve`, `attest`, `transfer`, `audit`, and `verify`. 3. App View service: subscribes to the relay firehose, indexes package records, issues name grants, and serves a resolution API. 4. Labeler service: a reference atproto labeler that publishes typed labels (security advisory, malware, deprecation, quality) consumed at install time. 5. A shared verification library used by both the CLI and the App View, so the trust rules are implemented once. 6. Deployment: runs against a real hosted or self-hosted PDS and the public relay, plus a `docker compose` stack for the isolated private-network mode (own PDS, own relay, own App View). HARD REQUIREMENTS: - Real atproto interop end to end. Records are written via `com.atproto.repo.putRecord`, blobs via `com.atproto.repo.uploadBlob`, and the App View consumes `com.atproto.sync.subscribeRepos`. No mocked protocol layer. - Real cryptography. Records are signed by the repo's actual DID signing key and every signature is verified against the DID document. No fake signatures. - Tarball integrity uses real Subresource Integrity `sha512` hashes, verified on install before any file is written to disk. - Identity is the DID; handles are display only and resolved via DNS/well-known. Package names are DID-scoped as `@handle/name`, so there is no global namespace and no name collisions. - Lockfiles pin DIDs, not handles. First install trusts the App View resolution plus attestation verification (trust on first use). Later installs verify against the lockfile; a changed DID fails the check and requires manual review. - Reproducible: `docker compose up` brings the private-network stack to a working state with no manual patching. The CLI installs from a real PDS. - Tested and CI-ready: unit tests for the verification library plus end-to-end integration tests that run against an ephemeral PDS and App View. CORE BEHAVIOR TO IMPLEMENT: 1. Publish flow: an individual publishes a package and version to their own PDS. An organization publishes via its own PDS while the individual developer writes a matching publish attestation in their own separate repo. Both records reference the same version and integrity hash and are independently verifiable. A version present in the org repo without a valid individual attestation is flagged. 2. Auditable name resolution: creating a name-to-DID mapping produces both a name claim (in the publisher's repo) and a name grant (in the App View's own repo, signed by the App View's DID). A mapping missing either half is distrusted by clients. Both records flow through the firehose and are publicly auditable. 3. Name transfer: transferring a package produces an old-owner transfer record, a new-owner claim, and an App View change record referencing both. Absence of the old owner's transfer record is surfaced as a strong warning and blocks silent takeover. 4. Composable trust via labelers: multiple independent labelers can attach typed labels to records or DIDs. Users configure which labelers they trust. Disagreement between labelers is preserved and shown, not collapsed. Revocation is checked at install time and flagged versions are refused unless explicitly overridden. 5. Server-side resolution: the CLI sends its dependency list and the App View resolves the full tree in a single pass against pre-cached firehose data, returning resolved DIDs, versions, CDN or blob tarball references, integrity hashes, and attestation and label status in one round trip. 6. Identity-to-source binding: the version record declares its authoritative source repository, signed by the publisher's DID. Where a Sigstore-style provenance attestation is available, verification confirms the declared source matches the attested build source and reports a mismatch. 7. Private packages: the isolated stack (own PDS, relay, App View, not connected to the public relay) uses the same lexicons and the same CLI. The private App View indexes both internal packages and the public firehose for public dependencies, so one client endpoint serves both worlds. SECURITY PROPERTIES TO PROVE: Ship an integration test suite where each of these is a passing, reproducible test with a clear verdict: - A forged version record in a compromised org PDS is detected because no matching individual attestation exists. - A name-resolution hijack (attacker DID with correctly signed records) is caught because the name grant is missing or does not match, even though every signature verifies. - Dependency confusion by name collision is structurally impossible because names are DID-scoped. - A silent ownership transfer is detected via the missing old-owner transfer record. - An identity-to-source mismatch (tarball built from a different repo than the signed record declares) is detected when provenance is present. The suite must also document, in plain language, what the system does NOT prove: signing proves who published, not that code is safe, not that a key holder is uncompromised; and hosted-PDS users still trust their provider's key custody until split-key support lands. DOCUMENTATION: - A README that gets a developer from zero to publishing and installing a real package against the private stack. - A short spec document covering the lexicons and the trust rules, plus a table comparing each property to how npm handles it today (composable trust, no single point of compromise, dependency-confusion resistance, transparent ownership, portable identity, auditable name resolution, identity-to-source binding). EXPLICIT NON-GOALS: - Not a drop-in replacement for the npm CLI or npmjs.com and not npm-registry wire-compatible. - No attempt to migrate the existing npm package corpus. - Split-key custody for individuals is documented as a designed follow-up, not implemented in the first shipment; hosted-PDS key custody is called out honestly. DEFINITION OF DONE: `docker compose up` brings up a working private AtPack network (PDS, relay, App View, labeler). A developer logs in with