# WebAssembly Registry (Warg) This document introduces the registry project's scope and design proposed by the Bytecode Alliance SIG Registries group, commonly known as ***WebAssembly Registry (Warg)***. ## Process SIG Registeries meetings are held weekly. To attend, please [join the Google group](https://groups.google.com/g/ba-sig-registries) for the calendar invite. The calendar invite provides instructions for adding to the agenda. See [past meeting notes](https://github.com/bytecodealliance/meetings/tree/main/sig-registries). Design process [phases](phases.md). ## Design Decisions #### WebAssembly binary packages *Warg* is primarily designed for publishing and fetching WebAssembly binary packages, both core modules as well as components and component interfaces. #### From development to deployment Both libraries and interfaces published for software developers as well as deployment artifacts can be published to *Warg* registries. #### Federation of registries Anyone can run their own registry and import (and optionally mirror) packages from other registries. Creating your own private or public registry allows you to implement your own policies for publishing packages, define access controls, and secure network traffic. #### Verifiable logs Package releases are published to immutable logs signed by their maintainers. Clients, third-party monitors, and importing registries can cryptographically verify a registry's state and history of state changes to detect a compromised or malicious registry. #### Content hosting optionality *Warg* primarily interacts with package release logs with content hashes. The registry itself or other services, such as blob stores and OCI registries, can host package contents. ## Scope for the Specification and Reference Implementation Anything that involves client-to-registry, monitor-to-registry, or registry-to-registry interaction needs to be clearly defined in the [Warg Specification](specification.md). The reference implementation prioritizes a minimal design that is usable but not necessarily highly scalable or full-featured. This encourages other [Warg Specification](specification.md) compliant implementations to be developed for more extensive requirements.