Proposal to Create wasi-virt

This document is a proposal to create wasi-virt as a formal (Hosted) Project under the auspices of the TSC of the Bytecode Alliance, as specified in the TSC Charter.

Project Summary

WASI Virt is a project that provides many different adapters that are simply composed. Similar to the wasm-tools project, this project will be in a monorepository and contain many different implementations. Individual virtualization adapters may need to work in concert with others, e.g. a virtualized blobstore may use a virtualized filesystem.

A key feature of the proposed WebAssembly Component Model is virtualizability of components, see the link-time virtualization example. Virtualized components will aid the WebAssembly community in enhancing WebAssembly's key value propositions of embeddability and language neutrality.

Existing Resources

• wasi-vfs

Governance Summary

This project will begin with maintainers from the wasi-vfs project and additionally add maintainers of two other Bytecode Alliance projects, @peterhuene (cargo component) and @guybedford (jco). This representation from multiple organizations and language ecosystems will be a key component of this project.

Software Development Process

The project will meet the passing criteria for the OpenSSF best practices badge. Pull requests, issues, CI, and release management will be performed via GitHub.

Alignment with Bytecode Alliance Mission and Goals

Bytecode Alliance projects represent the mission and goals of the Bytecode Alliance itself.
We understand that as a Bytecode Alliance project, our project must adhere to the TSC Charter and other governing documents (such as the Security Policies and IP Policy).
As a Bytecode Alliance project, our project's source code and other pieces of intellectual property will be assigned to the Bytecode Alliance.

We understand and agree that:

• All code for this project must be under the Apache v2 License with the LLVM exception, unless an exception is required for compliance with existing licensing, and granted by the Bytecode Alliance's board of directors per IP Policy §4. If our code is not already licenses accordingly, we will take the necessary steps to correct this prior to becoming a Bytecode Alliance Project.
• We will comply with the Security Policies.
• Project name, trademarks, logos, wordmarks, and other intellectual property other than source code and documentation copyright is assigned to Bytecode Alliance per the IP Policy.
• Social media handles, GitHub repository access, and other relevant communication and coordination platforms will be overseen by Bytecode Alliance. Administrative/Owner permissions will be granted to the Bytecode Alliance for all such accounts.
• We will abide by the definition of a project as set forth in the TSC Charter.
• This project must remain under active development or maintenance, or it may be archived by the Bytecode Alliance.
• This project may be reviewed from time to time by the TSC, and project maintainers will assist with this review process.
• Project members will be able to participate in Bytecode Alliance governance, as specified in the TSC Charter and other governing documents.

Supporting Members

The following individuals support the creation of wasi-virt:

• Guy Bedford (Fastly)
• Bailey Hayes (Cosmonic)
• Peter Heune (Fastly)
• Yuta Saito (GoodNotes)

Proposal to Create a Component Model C#/.net project and tooling project

This document is a proposal to create two C#/.net repositories as a formal Hosted Project under the auspices of the TSC of the Bytecode Alliance, as specified in the TSC Charter.

Project Summary

Describe the project and its goals. Target 1-2 paragraphs.

The SIG Guest Languages Working Group desires two repositories to collaborate around tooling and shared C# modules to improve the ergonomics around C#/.net and Wasm CM + WASI Preview 2. Specifically creating a project that makes streamlines the process of creating components from C# and a library that will contain common types that are shared between generated components.

This also includes publishing a nuget package under the BytecodeAlliance name with the package name being: BytecodeAlliance.Runtime.InteropServices.Wit

The proposed repo for the shared modules will be: github.com/bytecodealliance/cm-dotnet

The proposed repo for the cli tooling will be: github.com/bytecodealliance/componetize-dotnet

Existing Resources

• https://github.com/bytecodealliance/wit-bindgen C# generator

Governance Summary

This project will be governed and maintained by SIG Guest Languages - C#/.net Subgroup. There are three chairs for this subgroup representing two different Bytecode Alliance member organizations and one individual contributor.

Software Development Process

1-3 paragraphs explaining how the project uses pull requests, issue maintenance, LGTM policy, release management, and security processes. Emphasize how code quality is ensured.

This project needs to be bootstrapped so there are no existing process today. During bootstrapping, this project will follow all hosted project requirements.

Alignment with Bytecode Alliance Mission and Goals

Bytecode Alliance projects represent the mission and goals of the Bytecode Alliance itself.
We understand that as a Bytecode Alliance project, our project must adhere to the TSC Charter and other governing documents (such as the Security Policies and IP Policy).
As a Bytecode Alliance project, our project's source code and other pieces of intellectual property will be assigned to the Bytecode Alliance.

We understand and agree that:

• All code for this project must be under the [Apache v2 License with the LLVM exception](https://github.com/PROJECT_LICENSE), unless an exception is required for compliance with existing licensing, and granted by the Bytecode Alliance's board of directors per [IP Policy](https://bytecodealliance.org/assets/ip-policy.pdf) §4. If our code is not already licenses accordingly, we will take the necessary steps to correct this prior to becoming a Bytecode Alliance Project.
  

• We will comply with the Security Policies.
• Project name, trademarks, logos, wordmarks, and other intellectual property other than source code and documentation copyright is assigned to Bytecode Alliance per the IP Policy.
• Social media handles, GitHub repository access, and other relevant communication and coordination platforms will be overseen by Bytecode Alliance. Administrative/Owner permissions will be granted to the Bytecode Alliance for all such accounts.
• We will abide by the definition of a project as set forth in the TSC Charter.
• This project must remain under active development or maintenance, or it may be archived by the Bytecode Alliance.
• This project may be reviewed from time to time by the TSC, and project maintainers will assist with this review process.
• Project members will be able to participate in Bytecode Alliance governance, as specified in the TSC Charter and other governing documents.

Supporting Members

The following individuals support the creation of Bytecode Alliance's C#/.net project:

• Timmy Silesmo (nor2)
• Scott Waye
• James Sturtevant (Microsoft)

Proposing the adoption of StarlingMonkey as a Bytecode Alliance hosted project.

Repository URL: https://github.com/bytecodealliance/StarlingMonkey

StarlingMonkey

StarlingMonkey is a component-native JavaScript runtime targeting WASIp2 or other sufficiently capable host environments. It's designed to be highly modular and is easily extensible with additional builtins.

StarlingMonkey is built on SpiderMonkey, the JS engine used by Firefox, and is thus highly spec compliant and extremely robust. Additionally, it includes an implementation of various web standards, such as the fetch API, WHATWG Streams, and a subset of the Web Crypto API.

StarlingMonkey is derived from Fastly's js-compute-runtime project, but has been significantly refactored and extended to be more modular and embeddable as part of an effort to integrate it into Fermyon's JS SDK for the Spin runtime.

(Note to observers: the StarlingMonkey repository is already in the Bytecode Alliance organization, but it's not yet an official Bytecode Alliance project. This was agreed on by the TSC a few months back, with this proposal being intended to formalize the status as a hosted project.)

Requirements

Alignment with the Bytecode Alliance Mission

I believe StarlingMonkey project aligns strongly with the Bytecode Alliance Mission by providing a robust toolchain for using JavaScript to develop WebAssembly Components.

StarlingMonkey is designed to be embeddable and extensible through hooks in its CMake based build system: it can be integrated into downstream projects and extended with additional builtins without changes to the code base itself. Additionally, all builtins are configurable and StarlingMonkey's host API is abstracted such that it can target other environments than WASIp2, meaning that the runtime can be tailored to the specific needs of downstream integrations.

One such integration is the existing ComponentizeJS project, through which it is easy to target arbitrary WIT interfaces using JavaScript without the need to compile custom runtimes.

Code Review

Description

Reviews by the members of the starlingmonkey-core team are required for all PRs, with a high code quality standard for all changes.

Code of Conduct

The project follows the Bytecode Alliance Code of Conduct.

Continuous Integration Testing

StarlingMonkey has a continuous testing setup consisting of multiple kinds of tests:

• End-to-end tests that fully provide their own code and are checked against expected output
• Integration tests using a JS harness and testing builtins such as assertions
• A harness for running a relevant subset of the Web Platform Tests suite, ensuring a high degree of spec conformance of the implementations of builtins.

Contributor Documentation

The repo contains a README file that provides an overview of the project and how to build and run it. An issue is on file to provide more technical and architectural documentation and expand on conbtributor facing docs.

Following the Bytecode Alliance Operational Principles

The StarlingMonkey project is committed to be interoperable with other projects and follows a standards-first approach: it targets WASIp2 and aims for high compliance with web standards wherever applicable.

Licensing Compatible with the Bytecode Alliance

Currently, the project uses the BA's default license, Apache-2.0 WITH LLVM-exception, for all code in the repository. There's an intent to import Rust code under the MPL-2.0 license, which is compatible with the Apache-2.0 license and used by the upstream SpiderMonkey project. The Bytecode Alliance's board of directors has already granted an exception for this as required by the BA's IP policy.

README

A README can be found at https://github.com/bytecodealliance/StarlingMonkey/blob/main/README.md

Upon acceptance of this application, a header indentifying StarlingMonkey as a Bytecode Alliance project will be added.

Release Process

StarlingMonkey itself doesn't have an automated release process yet, but one is available through the integration into the ComponentizeJS project. An issue is on file to automate the release process for StarlingMonkey itself.

Security Process

StarlingMonkey is fully run in a sandboxed environment and doesn't have access to the host system, so the attack surface is significantly reduced. Nevertheless, an issue is on file for defining a formal security process for the project.

Semantic Versioning

The project itself doesn't yet have any formal releases. Instead, ComponentizeJS and other downstream projects update the version used by depending on a specific commit hash. An issue is on file to implement semantic versioning for the project.

Secrets Management

The project doesn't handle any secrets at the moment. If and when that changes, it will use GitHub secrets for repository-wide secrets.

Supply Chain Security

StarlingMonkey has few upstream dependencies, with the most notable ones being SpiderMonkey and OpenSSL—both projects with a very high level of scrutiny.

In both cases, official release versions are used, with additional patches carried downstream where needed.

Sustainable Contributor Base

StarlingMonkey receives regular contributions from multiple developers working at multiple organizations, and has a core maintainer team with members of two different Bytecode Alliance member organizations.

Version Control

StarlingMonkey is already hosted in the Bytecode Alliance GitHub organization.

Recommendations

Changelog

The project will follow keepachangelog.com once it's feature-complete and 1.0 version is released.

Continuous Fuzzing

no fuzzing is currently performed. While it'll make sense to eventually change that, the fact that the runtime is fully sandboxed and doesn't have access to the host system significantly reduces the attack surface.

End-User Documentation

StarlingMonkey itself doesn't really contain end-user documentation, as it's intended to be embedded into other projects. However, the ComponentizeJS project provides a high-level overview of how to use the runtime.

Issue Triage Process

The project uses GitHub to track issues and manage pull requests. A GitHub project is used to track blockers for a 1.0 release.

Leverage the Bytecode Alliance RFC Process

StarlingMonkey does not leverage the RFC process yet, mostly due to being a new project, which is not feature-complete yet, but it's intended to do so as part of the stabilization process.

Production Use

Multiple organizations are already using StarlingMonkey in production, including Fastly and Fermyon as part of the JS SDKs for their platforms.

Public Project Meetings and Notes

Currently, no public meetings are taking place for StarlingMonkey, but the JS subgroup of SIG-guest-languages is used to discuss the project.

Sanitizers and Code Analysis

SpiderMonkey is fully running inside the WebAssembly sandbox, making the use of sanitizers less critical. However, the project is considering adding sanitizers to the build process to catch potential issues early.

Proposal to Create componentize-py

This document is a proposal to create componentize-py as a formal (Hosted) Project under the auspices of the TSC of the Bytecode Alliance, as specified in the TSC Charter.

Project Summary

componentize-py is a project to create components using the Python programming language, analogous to how jco componentize creates components using JavaScript. It currently resides at https://github.com/dicej/componentize-py/ and is published to PyPI at https://pypi.org/project/componentize-py/. In addition to supporting guest code written in pure Python, it supports native extensions written in C, C++, and other native languages via emulated dlopen/dlsym functions. We aim to make this tool the easiest, most efficient way to build components using Python.

This project has been developed with the advice and assistance of the members of the Python subgroup of the Guest Languages SIG, including @brettcannon, who currently maintains the CPython WASI port on which componentize-py is based.

Governance Summary

This project will begin with @dicej (Joel Dice, Fermyon) as the primary maintainer, with informal assistance from the Guest Languages SIG Python subgroup. By making this a hosted Bytecode Alliance project, we hope to attract additional contributors going forward.

Software Development Process

The project will meet the passing criteria for the OpenSSF best practices badge. Pull requests, issues, CI, and release management will be performed via GitHub.

Alignment with Bytecode Alliance Mission and Goals

Bytecode Alliance projects represent the mission and goals of the Bytecode Alliance itself.
We understand that as a Bytecode Alliance project, our project must adhere to the TSC Charter and other governing documents (such as the Security Policies and IP Policy).
As a Bytecode Alliance project, our project's source code and other pieces of intellectual property will be assigned to the Bytecode Alliance.

We understand and agree that:

• All code for this project must be under the Apache v2 License with the LLVM exception, unless an exception is required for compliance with existing licensing, and granted by the Bytecode Alliance's board of directors per IP Policy §4. If our code is not already licensed accordingly, we will take the necessary steps to correct this prior to becoming a Bytecode Alliance Project.
• We will comply with the Security Policies.
• Project name, trademarks, logos, wordmarks, and other intellectual property other than source code and documentation copyright is assigned to Bytecode Alliance per the IP Policy.
• Social media handles, GitHub repository access, and other relevant communication and coordination platforms will be overseen by Bytecode Alliance. Administrative/Owner permissions will be granted to the Bytecode Alliance for all such accounts.
• We will abide by the definition of a project as set forth in the TSC Charter.
• This project must remain under active development or maintenance, or it may be archived by the Bytecode Alliance.
• This project may be reviewed from time to time by the TSC, and project maintainers will assist with this review process.
• Project members will be able to participate in Bytecode Alliance governance, as specified in the TSC Charter and other governing documents.

Supporting Members

The following individuals support the creation of componentize-py:

• Joel Dice (Fermyon)
• Till Schneidereit (Fermyon)
• Kyle Brown (SingleStore)

Proposal to Create wac

This document is a proposal to create wac as a formal Hosted Project under the auspices of the TSC of the Bytecode Alliance, as specified in the TSC Charter.

Project Summary

wac is a tool for defining WebAssembly compositions from a formally defined language called WebAssembly Compositions.

It is a successor to the existing Bytecode Alliance tool wasm-compose.

The main justification for having wac as a stand-alone project compared to integrating it directly into wasm-tools is that it will have a direct build dependency on wasmtime to support the execution of arbitrarily-referenced "transform" plugins.

Existing Resources

• GitHub repository

Governance Summary

This project will begin with the current maintainers of the wac project and add additional maintainers from Bytecode Alliance member organizations over time; the representation of multiple organizations (and potentially within the Component Model proposal itself with respect to the language's design) will be an important aspect of this project.

Software Development Process

All code changes will be required to go through a pull request with at least one approval by a maintainer and passing all CI checks.

Code quality will be maintained through the CI process, including the eventual support for fuzzing the wac parser and encoder.

Releases will be performed similarly to existing BA repositories, where the creation of a tag will automate the publishing of the release to crates.io.

Alignment with Bytecode Alliance Mission and Goals

Bytecode Alliance projects represent the mission and goals of the Bytecode Alliance itself.
We understand that as a Bytecode Alliance project, our project must adhere to the TSC Charter and other governing documents (such as the Security Policies and IP Policy).
As a Bytecode Alliance project, our project's source code and other pieces of intellectual property will be assigned to the Bytecode Alliance.

We understand and agree that:

• All code for this project must be under the Apache v2 License with the LLVM exception, unless an exception is required for compliance with existing licensing, and granted by the Bytecode Alliance's board of directors per IP Policy §4. If our code is not already licenses accordingly, we will take the necessary steps to correct this prior to becoming a Bytecode Alliance Project.
• We will comply with the Security Policies.
• Project name, trademarks, logos, wordmarks, and other intellectual property other than source code and documentation copyright is assigned to Bytecode Alliance per the IP Policy.
• Social media handles, GitHub repository access, and other relevant communication and coordination platforms will be overseen by Bytecode Alliance. Administrative/Owner permissions will be granted to the Bytecode Alliance for all such accounts.
• We will abide by the definition of a project as set forth in the TSC Charter.
• This project must remain under active development or maintenance, or it may be archived by the Bytecode Alliance.
• This project may be reviewed from time to time by the TSC, and project maintainers will assist with this review process.
• Project members will be able to participate in Bytecode Alliance governance, as specified in the TSC Charter and other governing documents.

Supporting Members

The following individuals support the creation of wac:

• Brian Hardock (Fermyon)
• Danny Macovei (JAF Labs)
• L Pereira (Fastly)
• Luke Wagner (Fastly)
• Peter Huene (Fastly)
• Ryan Levick (Fermyon)
• Trevor Elliott (Fastly)

Proposing the adoption of wRPC as a Bytecode Alliance hosted project.

Repository URL: https://github.com/wrpc/wrpc

wRPC

wRPC is a component-native transport-agnostic RPC protocol and framework based on WIT.
It facilitates execution of arbitrary functionality defined in WIT over network or other means of communication.

Requirements

Alignment with the Bytecode Alliance Mission

I believe wRPC project aligns with the Bytecode Alliance Mission, it directly improves modularity of an existing Bytecode Alliance project, Wasmtime, by allowing a modular, out-of-tree plugin architecture (see bytecodealliance/wasmtime#8737 for the proposal in Wasmtime)

wRPC project itself is highly modular. For example, wrpc-transport crate provides the core transport abstractions, which are then implemented in e.g. wrpc-transport-nats. The intention is to further add wrpc-transport-ipc, wrpc-transport-quic etc.

wRPC officially supports the following platforms:

• x86-64, aarch64, riscv64 Linux
• x86-64, aarch64 Darwin
• x86-64 Windows
• aarch64 Android

Support for these platforms is continously tested on each pull request, the CI platform matrix can be seen here: https://github.com/wrpc/wrpc/blob/86d06a487f3ab3ad71c476c0038dbb759282388a/.github/workflows/wrpc.yml#L29-L64

Given the (potentially) networked use cases, wRPC protects e.g. from malicious peers by utilizing component model value definition encoding, defined at https://github.com/WebAssembly/component-model/blob/8ba643f3a17eced576d8d7d4b3f6c76b4e4347d7/design/mvp/Binary.md#-value-definitions, in which length of each dynamically-sized buffer is always known upfront and therefore the receiver peer can protect itself from e.g. buffer overflow attacks.

Code Review

Description

Code owner reviews are required, but currently there's only one code owner: @rvolosatovs, so his pull requests do not require review for merge. Once there are more active contributors to the project, that will change.

Example PR from an outside contributor: bytecodealliance/wrpc#108
CODEOWNERS: https://github.com/wrpc/wrpc/blob/86d06a487f3ab3ad71c476c0038dbb759282388a/.github/CODEOWNERS

Code of Conduct

A pull request for adding Bytecode Alliance CoC is open bytecodealliance/wrpc#104 and will be merged once the repository is approved for transfer

Continuous Integration Testing

wRPC, as a primarily Rust project, uses cargo audit, cargo clippy, cargo fmt and cargo nextest in CI, as well as builds the codebase for a variety of platforms and architectures on each pull request. cargo publish is run in dry-run mode for contained crates, but only failure in publishing of self-contained crates triggers a CI failure. cargo doc is built on each pull request and each merge to main branch triggers publishing the latest documentation to https://wrpc.github.io/wrpc/wrpc/index.html, which is occasionally verified manually.

wRPC contains Go code, which is tested using go test, however that is made part of the cargo test suite, meaning that go test is run as part of cargo test

wRPC contains a subtree-merged wit-bindgen source tree, which is heavily modified. wRPC uses the same test suite as wit-bindgen to test wit-bindgen-wrpc

Pull requests are merged using merge queue to ensure that CI is always being run on the latest HEAD state

Example PR bytecodealliance/wrpc#108
Example main CI run: https://github.com/wrpc/wrpc/actions/runs/9349494244

See https://github.com/wrpc/wrpc/tree/86d06a487f3ab3ad71c476c0038dbb759282388a/.github/workflows for current GitHub Actions setup

Contributor Documentation

Project contains a CONTRIBUTING.md at the root: https://github.com/wrpc/wrpc/blob/main/CONTRIBUTING.md

Following the Bytecode Alliance Operational Principles

wRPC project is committed to be interoperable with other projects and follows a standards-first approach. For example, the encoding format originating within wRPC was contributed to component model specification (and, eventually, modified using received feedback) to ensure standard compliance and consistency WebAssembly/component-model#336

Licensing Compatible with the Bytecode Alliance

The project uses "Apache-2.0 WITH LLVM-exception" license: https://github.com/wrpc/wrpc/blob/86d06a487f3ab3ad71c476c0038dbb759282388a/LICENSE

README

README can be found at https://github.com/wrpc/wrpc/blob/main/README.md

PR for indentifying as Bytecode Alliance project is open and will be merged once it's approved: bytecodealliance/wrpc#112

Release Process

Crate release automation is set up using GitHub Actions and cargo https://github.com/wrpc/wrpc/blob/c7bb1ebbd553c4557dbdb07f161435f168b98402/.github/workflows/wrpc.yml#L309-L350, however a token is not provisioned for CI due to logistical issues. Once the repository has been transferred to Bytecode Alliance, a CI user will be provisioned and used for releasing crates

Security Process

Project contains SECURITY.md https://github.com/wrpc/wrpc/blob/main/SECURITY.md

Dependabot is used for both security patches and regular dependency updates, however Dependabot PRs require all the same CI checks as other PRs and are always manually verified before merge

Semantic Versioning

The project strictly follows semantic versioning as defined at https://semver.org/.

Secrets Management

The project utilizes repository-wide GitHub secrets for e.g. Nix cache token and Cargo publish token

Supply Chain Security

Project uses cargo audit to vet dependencies on each pull request
TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)

Sustainable Contributor Base

Some examples:

• bytecodealliance/wrpc#108
• bytecodealliance/wrpc#55
• bytecodealliance/wrpc#54
• bytecodealliance/wrpc#28
• bytecodealliance/wrpc#13

Version Control

The project will be transferred once approved

Recommendations

Changelog

The project will follow keepachangelog.com once it's feature-complete and 1.0 version is released (tracked at https://github.com/orgs/wrpc/projects/1)

Continuous Fuzzing

no fuzzing is currently performed, but an issue is filed to do that bytecodealliance/wrpc#114

End-User Documentation

The project includes code examples for Go and Rust at https://github.com/wrpc/wrpc/tree/9de79f690b04ec30b3820449bbfe28261e36275e/examples

Most of the documentation from another Bytecode Alliance project - wit-bindgen is reused.

Rust API is documented on e.g. https://docs.rs/wrpc-transport/latest/wrpc_transport/
Go API is documented at https://pkg.go.dev/github.com/wrpc/wrpc/go

Issue Triage Process

The project uses GitHub to track issues and manage pull requests. GitHub projects, labels and milestones are also utilized to categorize and prioritize work.

Leverage the Bytecode Alliance RFC Process

wRPC does not leverage RFC process yet, mostly due to being a new project, which is not feature-complete yet, but once it is - Bytecode Alliance RFC process will be adopted

Production Use

The project includes ADOPTERS.md file in the root of the repository based on the one used in Wasmtime https://github.com/wrpc/wrpc/blob/2a758470c4bd3472f58e8c5b769a04a9a30a40da/ADOPTERS.md

Public Project Meetings and Notes

Currently, no public meetings are taking place for wRPC, but there is intention to setup such at regular cadence after approval as hosted project

Sanitizers and Code Analysis

The project does not use unsafe code and does not utilize such tools at this time, but an issue to run miri is CI is filed at bytecodealliance/wrpc#116

Code of Conduct document identifies that reports will be handled by this team but does not identify who makes it up. Is this handled by David Bryant who is identified as the Compliance Officer in the Whistleblower Policy or someone else?

This issue is a proposal to create the rust-oci-wasm crate as a formal hosted project under the auspices of the TSC of the Bytecode Alliance, as specified in the TSC Charter.

Project summary

Now that there has been general agreement on the spec for components in OCI artifacts, we needed to create some implementations that can be used to leverage the new types (such as wasm-pkg-tools). After consulting with various groups, the best home seems to be here in the BCA. This proposes that the https://github.com/thomastaylor312/rust-oci-wasm repo be transferred into the bytecodealliance org as a new project. This project will remain separate for some time as the contributors to this will span both active CNCF contributors and BCA contributors, so it will be easier to keep it separate for now for those who wouldn't be maintainers of wasm-pkg-tools. This doesn't preclude us from merging into that project in the future, but for now it would probably be best as a separate repo.

This is part of a cross community effort (special shout out to @jsturtevant) and was also discussed as part of SIG Registry on May 22: https://hackmd.io/9FXZK5TxSwSU-5mHNbFGBQ#May-22---SIG-Registries-meeting.

Additional resources

• OCI Wasm Spec
• https://github.com/thomastaylor312/rust-oci-wasm
• Discussion in CNCF Wasm WG (see May 28th meeting)
• Discussion in BCA SIG registry

Supporting members

The following individuals support the creation of this project:

• @thomastaylor312
• @calvinrp
• @jsturtevant

Please also note the general support of the members of the SIG registry and CNCF wasm working group

Proposal to Create a Component Model Go project

This document is a proposal to create a go monorepo as a formal Hosted Project under the auspices of the TSC of the Bytecode Alliance, as specified in the TSC Charter.

The proposed repo will be: github.com/bytecodealliance/cm-go

Project Summary

Describe the project and its goals. Target 1-2 paragraphs.

The SIG Guest Languages Working Group desires a repository to collaborate around tooling and shared go modules to improve the ergonomics around Go and Wasm CM + WASI Preview 2.

Repo: github.com/bytecodealliance/cm-go
The intention is to create a go vanity url: https://go.bytecodealliance.org/

This will allow for modules that we expect to be vendored easily like to upstream tinygo and big go. For example only: go.bytecodealliance.org/wasi/http

Existing Resources

The tooling around Go is nascent where most of the work is underway within POC in the TinyGo repository and other various projects that can be combined to improve go development with components. The idea is to join efforts across some of these into the go project.

• https://github.com/bytecodealliance/wit-bindgen go generator that relies on CGO
• https://github.com/ydnar/wasm-tools-go

Governance Summary

This project will be governed and maintained by SIG Guest Languages - Go Subgroup. There are two chairs for this subgroup representing two different Bytecode Alliance member organizations.

Software Development Process

1-3 paragraphs explaining how the project uses pull requests, issue maintenance, LGTM policy, release management, and security processes. Emphasize how code quality is ensured.

This project needs to be bootstrapped so there are no existing process today. During bootstrapping, this project will follow all hosted project requirements.

Alignment with Bytecode Alliance Mission and Goals

Bytecode Alliance projects represent the mission and goals of the Bytecode Alliance itself.
We understand that as a Bytecode Alliance project, our project must adhere to the TSC Charter and other governing documents (such as the Security Policies and IP Policy).
As a Bytecode Alliance project, our project's source code and other pieces of intellectual property will be assigned to the Bytecode Alliance.

We understand and agree that:

• All code for this project must be under the Apache v2 License with the LLVM exception, unless an exception is required for compliance with existing licensing, and granted by the Bytecode Alliance's board of directors per IP Policy §4. If our code is not already licenses accordingly, we will take the necessary steps to correct this prior to becoming a Bytecode Alliance Project.
• We will comply with the Security Policies.
• Project name, trademarks, logos, wordmarks, and other intellectual property other than source code and documentation copyright is assigned to Bytecode Alliance per the IP Policy.
• Social media handles, GitHub repository access, and other relevant communication and coordination platforms will be overseen by Bytecode Alliance. Administrative/Owner permissions will be granted to the Bytecode Alliance for all such accounts.
• We will abide by the definition of a project as set forth in the TSC Charter.
• This project must remain under active development or maintenance, or it may be archived by the Bytecode Alliance.
• This project may be reviewed from time to time by the TSC, and project maintainers will assist with this review process.
• Project members will be able to participate in Bytecode Alliance governance, as specified in the TSC Charter and other governing documents.

Supporting Members

The following individuals support the creation of Bytecode Alliance's go project:

• Randy Reddig (Fastly)
• Damian Gryski (Fastly)
• Jiaxiao Zhou (Mossaka) (Microsoft)
• Achille Roussel (Stealth Rocket)
• Bailey Hayes (Cosmonic)

Hey all, I'm working with the Rust project to shutter the long-defunct rustwasm github org and corresponding Wasm WG. Given we have BA members still actively maintaining a number of crates in the org, and we use a number of these in our projects, I wanted to open an issue here to propose adopting some of those crates in the BA. The full list of repositories can be found here. Based on maintainership, I was thinking the BA adopt the following crates:

• weedle - a WebIDL parser (particularly relevant for jco, WebGPU, WebUSB)
• walrus - a wasm transformation library

There are a number of other crates which seem generally useful, but haven't been updated in a minute. But perhaps we might want to adopt these in case they are still relevant?

• twiggy - a code size profiler
• wasm-tracing-allocator - a debugging allocator
• wee-alloc - a small, wasm-enabled allocator
• wasm-snip - replaces a wasm function's body with an unreachable

Process-wise, if the BA does not choose to adopt these crates, they will likely be marked as [archived] on GitHub as they have no other logical place to go. The flagship wasm-bindgen and wasm-pack crates should likely be adopted by their existing maintainers (non-BA afaik), and moved to a different org.

In terms of timing: any migration of crates is pending a decision from the Rust project to move forward with the deprecation of the Rust Wasm WG. I want to make clear that this is not a question about whether the BA wants the Rust Wasm WG to be shuttered, but about the steps that come after.

I'm keen to hear thoughts from the BA steering committee on this; I assume this should probably be raised at a future meeting? But I would in particular also want to hear from @alexcrichton and @fitzgen, who have worked on a number of these crates and are likely to have insights on whether they are relevant to the BA going forward.

Thanks!