||Hours||Rate / Hr.||Period|
For the WRAP-IOU portion, Polywrap DAO to mint the tokens at delivery (approximately July), based on actual hours worked. WRAP-IOU should go to this wallet:
Discussion period: Thu May 12 to Mon May 16, 2022 (3 Business Days)
Voting period: Tue May 17 to Thu May 19, 2022
PWV is a polyglot development shop with expertise in code architecture. Previously, we have contributed technical research and code architecting services to Polywrap, in the form of research documents, architecture plans, and implementation proposals and details. We have also contributed code to several major features, including recipe cookbooks and toolchain versioning.
PWV is looking to expand their engagement with Polywrap in order to undertake bigger projects within reasonable timeframes. Some of those larger projects are presented below, as well as a general backlog of issues that we are interested in working on, including documentation and contributing to the Technical Council.
Polywrap markets itself as a cross-platform, cross-linguistic tool. We believe that implementing a second client in another language would benefit the project greatly in these early stages. We have created a proposal concerning this, which we estimate will take roughly 200–240 hours to implement effectively. At this time, we believe the imperative should be to create a Python client, and to use Wasmer as the underlying WASM runtime.
With multiple clients comes the risk of implementation drift (cf. monorepo#32). To combat this, Polywrap needs a suite of tests and known I/O pairs that can be used to effectively validate feature parity between different client implementations (in addition to benchmarking, and other interesting measurable client properties). This test harness would include scaffolding code, updates to the clients (to facilitate testing), as well as a library of recipes (cf. technical-council#3) with known, expected outputs, and we estimate it will take roughly 240–300 hours to complete (against the two expected clients).
Given the composable nature of wrappers, it should seem common and obvious to need to include certain other wrappers as “dependencies” during wrapper development. However, when shipping those wrappers, there is currently no way to bundle them together, directly. This project would cover the inclusion of a new codegen step to insert the WASM bytecode of dependencies directly into the dependent wrapper, so that they can be packaged and run together; though, we intend to start with the “easier” project types first — applications & plugins — before getting to the “harder” one — WASM modules. We estimate that this would take roughly 160–200 hours to complete.
Depending on how quickly this goes, there may be potential to upgrade this project to cover an entire MVP of the (client-side) dependency locking feature.
- Document how to add metadata to a wrapper / interface
- Document how to query metadata of a wrapper / interface
- URI resolver documentation - Redirects
- URI resolver documentation - ENS resolver
- URI resolver documentation - IPFS resolver
- URI resolver documentation - FS resolver
- Additional documentation (as time permits)
- Contributing to the Technical Council, especially as relating to the multi-client and dependency locking standards and specifications