Module registry 

Registries (packaging slice 4a, #2274; track design/tracks/packaging.md §6.1–§6.2): the client bynk resolves { package, version } dependencies with, and the reference tooling for a static registry.

The Client opens the registry an organisation routes to — through a mirror, when one serves it — decides which key it trusts (a key pinned in [registries], else the one bynk.lock recorded, else trust on first use), follows the key-rotation chain from it, and from then on admits only index lines signed by a key on that chain and bound to the registry’s id and the package’s name. Archives are unpacked into staging and admitted to the store only when their tree checksum is the one the signed line names.

Modules

account

bynk login, bynk logout and bynk org (first-party registry R3.1, #2378): the client side of the account API the hosted registry serves beside its publish API (R3, #2363).

commands

The reference static registry and bynk add (packaging slice 4a, #2274, decisions H and I).

conformance

bynk registry conformance (first-party registry track R0, #2311): run the registry protocol’s observable behaviour against a registry URL, and report each check.

protocol

The registry protocol’s data (packaging slice 4a, #2274, decision D), as bynk uses it: the pure data and payloads live in bynk-registry-core (first-party registry R2, #2336, decision B), shared with the hosted registry’s wasm module; this module adds ed25519 signing and verification over ring (already in the build through rustls), and ConfigTrust, the signer walks with ring as their verifier.

publish

bynk publish and bynk yank (packaging slice 4c, #2287, decisions B and F): the client side of the publish API.

serve

bynk registry serve and bynk registry token (packaging slice 4c, #2287, decisions A, D and E): a reference server that puts the publish API in front of a static registry directory.