---
# System prepended metadata

title: Introducing warg a WebAssembly ReGistry

---

# Introducing warg a WebAssembly ReGistry

The Bytecode Alliance has been hard at work defining an API and protocol for a **W**eb**A**ssembly **R**e**g**istry also known as **warg**. 

We just started, but we want this to be an open standard, built, and reviewed by the community, and its time to share our ideas!

## But why build a (yet another) registry?

Registries are a critical part of any software stack. They are the means for software  publish and share your code, but perhaps more importantly, pull your dependencies.

A modern application in today's world is made up of more lines of code from external dependencies than what is written in the application. 

This becomes more apparent with supply chain attacks on the rise. 



[TODO add supply chain attack stats]

Many registries have added methods for security like auditing, signing, and two-factor authentication, but often these have come after the fact - after a major CVE that left applications vulnerable and maintenance work (updating dependencies, rebuilding, and reshipping is churn for devs). 

Registries are an even more fundamental backbone of the software stack than most developers realize. They can dictate how applications are package, how they describe their contents for *what* is distributed, *who* can publish, and *how* applications are assembled.

There are very good reasons for why registries assemble so many fundamental aspects of the software stack. They are complex pieces of software with expensive ingress needs. This is why most successful registries require a software foundation to pay and maintain the integrity of the system.

For us, there is another fundamental key element. We are building a new standard, built on other open standards, that continues on the secure by design, capability based architecture of WebAssembly and the Component Model. Many existing registries are built around other protocols and package types that do not understand components. If we were to take a step back and design a new fundamental layer of the software stack, what would that look like?

Wapm?15:17
Luke asked about the reflect status in tinygo since he had a use case needing json deserialization/serialization.

 15:17
I think the status is that it's not great and undergoing heavy construction

Luke Wagner15:32
That matches what I heard also, so thanks for the confirmation and links. Sounds like someone on our team (dgryski) may end up trying to help move this forward before too long.



OCI?
supergloo
engineerd
NPM?
SIG-store?

## Component Model

The aspects of the component model that are relevant to Warg, are well, all of them.

[TODO]


## Ability to mirror

A company’s instance could mirror from the Bytecode Alliance registry,


## The Registry is based on Transparency

Registries Assert Package Contents
Diagram: Mapping of (registry, package, version) to digest

Registries Can Lie about Package Contents
Diagram: Prior diagram, where mapping has been changed to new digest

How can we know when they lie?
Picture: Panopticon

Using and Extending Transparency Data Structures
Title Card

Verifiable Log
Diagram

Verifiable Map
Diagram

Log-Backed Map
Diagram

Linked Log-Backed Map
Diagram

Package Logs
Diagram

Operator Logs
Diagram


## Summary

cert trans gives logs, this gives us a map, now we can talk about the state as one structure
Why Wasm? The answer has always been Security First.

## Goals

The Bytecode Alliance will stand up a canonical instance


And communities with specific components, can collaborate with the canonical instance.

This is a pre-security review design.


Supply imports

When you load it as a ES Module loader system
When you load a component as an ES Module

Put a URL in an import
as the module specifier
overridden by an import map

Look and feel like es module

With these DAGs
Top-level component will either bundle
or will have a URL

component then takes over how they are linked together

components would link themselves
separation of loading the code and instantation

longer term story 

expose Web API's as built-in modules as ES Modules
import objects from the module system

Then with component model could use those es modules.

polyfill story there that we could use all the way through.






TUF general-purpose




WebAssembly has new and better approaches to security, and we want to use these new approaches 