Meeting Details Date: Feb 21, 2024 Venue: Zoom call Time: 1 PM EST / 10 AM PST Host: Calvin Prewitt Attendees: Topics Meeting Notes

For Monitors & Registries: Warg-Registry HTTP Header For all API endpoints, if the Warg-Registry header is present in the request, the response will be as if the registry at the domain name specified in the header value was the one responding. The response will include the same Warg-Registry header and value if the server is responding as that registry. If the response header is omitted, the client should assume that the server ignored the request header. POST /v1/verify/checkpoint Request body is the signed timestamped checkpoint envelope to be verified. The Warg-Registry specifies the domain name of the registry checkpoint that is being verified. Response is success status code or error status code with an error messsage.

Federation is one of the few outstanding protocol features not implemented. Effort is underway to update the docs with targeted use cases. To highlight two use cases: Registry packages that import packages published to other registries; Registry mirrors; This proposed implementation can be thought of as a composition of three new features: Proxying on behalf of another registry;

Background Monitors in Certificate Transparency "watch logs and check that they behave correctly". They verify things that may be impossible or impractical for every client to verify for themselves. Introduction In Package Transparency, monitors watch different logs and check different things than in Certificate Transparency but abstractly fill an analagous role. In the protocol as discussed to this point, monitors are expected to verify two distinct things: That the log and the map in a checkpoint are consistent with each other (i.e. that applying every update in the log produces the map); That no fork attack has occurred or that if there is one we are using a checkpoint on the "correct" branch of the log history;

Motivations Privacy of network activity; Availability through mirroring, caching and replication; Data locality by having the registry API and content local within a datacenter or network; Access control policies for private registries; A team wants to use components from the registry in their deployed service, but does not want to depend on availability from any upstream registry in their deploy process. They want a registry that implements a "read-through cache", attempting to sync from upstream on each fetch but serving the latest cached log if that fails. To enable this use case, the registry protocol needs to support mirroring individual package logs from an upstream registry into a local registry. Intended Use Cases As there will not be a single, central registry, these potential patterns may emerge from federation capabilties.

Meeting Details Date: Jun 15, 2023 Venue: Zoom call Time: 2 PM EST / 11 AM PST Host: Calvin Prewitt Attendees: Topics Meeting Notes

This document introduces the registry project's scope and design proposed by the Bytecode Alliance SIG Registries group, commonly known as WebAssembly Registry (WARG). 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