# 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