Registry and Package Management Funding Proposal
Date: 02/09/2024
Prepared by Cory Dickson, Seth Feibus, AJ Beckner
Organization: Archetype
1. Summary
Project Description:
This proposal extends the line of work that the archetype team has undertaken as it pertains to the BOS component registry. There are several additional touchpoints that involve bos-workspace and near.sdk to further improve the developer experience.
Funding Requested: $15,000
Implementation Timeline: Mar - Apr 2024
2. Background
Problem Statement:
See our previous proposal:
“
There is a lack of tools available to make BOS components discoverable. Furthermore this project aims to allow developers to create an ecosystem in which context can be shared across different implementations of similar sets of features.Weak code introspection to BOS component given a particular address
Lack of explicit “type” declaration of valid props on a BOS component
Lack of dependency tracking of components that reference other components
Lack of provenance of component source code between local and on-chain components
Lack of trust metrics for components imported from other accounts (and associated dependencies)
Objective:
After the completion of the initial attestation registry contract, the next goal for this endeavor is to leverage the technology to support specific claims and schemas associated with BOS types and their dependencies.
3. Project Description
Scope:
- Package management alpha
- Package publishing, versioning, dependency registration
- Package locks, including locking of dependency versions
- Package imports, dependency resolution, installation
- Access Control (early version of teams, delegation)
- Authors will be able to manage & assign publishing rights to project maintainers or contributors
- Improved typescript support:
- Publishing: Bos developers will now be able preserve type definitions for their components and dependencies, with configurable auto-publishing of types when releasing components through bos-workspace projects using typescript.
- Import: Then, when developers install those components for use as a dependency in their project, Imported components with associated types can (through the use of a library) automatically display associated type definitions, thus making them available for the typescript compiler, language server, and tooling such as linters, IntelliSense, etc.
- Integrations:
- SDKs, libraries, everything, bos-workspace
- GUI:
- Visualization of dependency graphs
- Introspection into dependencies, dependents, types, authors, attestations, arbitrary metadata
- Namespace & resolvers
The main objective of this project is to define a set of schemas that can be leveraged to allow users to specify blockheights for subcomponents and retrieve them accordingly from NEAR socialDB. In addition to this, types that have been generated using a typescript schema will also be posted to the registry. The team will continue to iterate through ideas as it pertains to allowing developers different ways they can enforce commitments to dependencies through attestations. There will now be support for multiple accounts to be able to publish on behalf of an author’s component to allow different release criteria. Potluck will also be another partner to continue publishing data on voter behalf.
Furthermore for each of these projects we will be exploring different front-end options to allow devs an easy way to construct these schemas on the fly and post to the registry.
Key Stakeholders: Everything, BOS Workspace, NEAR.sdk, Potluck
4. Budget
- Total Cost: $15,000 - - this is a continuation of the BuildDAO relationship in which Archetype improves the developer experience of several parts of the toolchain
- Funding Request: All funds will be used to support the team that will be developing the system and participating in design meetings with relevant stakeholders.
5. Implementation Plan
- Timeline:
- This encapsulates all of the work for the Archetype team to focus on the various projects related to BuildDAO for the month of March and into April
- Milestones:
- End of March - Schemas and real data published on mainnet for dependency management
6. Evaluation and Measurement
Success Criteria:
Each of the points outlined above has two main components. One, a schema recognized by maintainers for both bos-workspace and NEAR SDKs, with a relevant PR in each repo to support the construction of these abstractions. And the second, actually publishing the data to the registry. We will have integration tests that support each of the examples above. As for the front-end we hope to converge on either an existing system using Everything or our own bespoke solution that incorporates examples above.
Monitoring and Evaluation
The team will be posting updates to NEAR builders and continuing to discuss these endeavors with relevant stakeholders in the respective Telegram groups.
7. Risks and Mitigation Strategies
- Risks: The biggest risk is that these schemas do not gain adoption and this rendering them not as useful as intended.
- Mitigation: By deeply embedding these regimes into various projects / developer toolchains we hope to gain adoption by the wider NEAR community.
8. Conclusion
Summary
While this proposal includes new features/improvements that have an integration associated with them, it also includes the standard work associated with maintaining the existing NEAR attestation registry. All of these will allow us to improve the existing contract by making certain abstractions first-class and enshrined into the contract logic. This will facilitate our ability to improve our pipeline to deploying into mainnet and handling state migration as the team continues to roll out releases.
9. Appendix
Github repo: archetype-org/attestation-registry
10. Contact Information
- Name: Cory Dickson
- Title: Chief Architect, Archetype
- Email: cory@archetype.computer