BOS Component Attestation Registry Funding Proposal
Date: 01/07/2024
Prepared by Cory Dickson, Seth Feibus, AJ Beckner
Organization: Archetype
1. Summary
Project Description:
The NEAR BOS & Open Web stack offer promises for a more modular development paradigm for decentralized applications (dApps). With permissionless publishing, the NEAR Social VM, and the existing BOS component toolchain; developers can more resourcefully build and collaborate on dApp interfaces that leverage the unique properties of the NEAR Social DB. With easy forking and strong dogfooding from the NEAR ecosystem, the number of developers and components has grown - to a point where additional considerations and infrastructure are now warranted namely package management.
As the ecosystem grows, this will serve a crucial role in the developer experience and security of dApps. Archetype proposes to solve these issues, in accordance with its efforts to secure the software supply chain, by building and deploying an initial component of its planned package management infrastructure - a metadata and attestation registry for BOS. It will provide superior ergonomics & rich metadata, along with arbitrary attestations to increase trust throughout the stack.
Funding Requested: $7,000
Implementation Timeline: Two months, January - Feb 2024
2. Background
Problem Statement:
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:
The main goal of the project is to introduce a system that preserves context around type definitions and props when developing for the NEAR SocialDB. This takes the form of an attestation registry with the purpose of improving trust and ergonomics within the BOS developer experience. Completion of this work will be the first foray into exploring the solution space around package management.
3. Project Description
Scope:
To accomplish the above, the team will be developing a registry contract on NEAR, that contains the type definitions of various BOS components as well as relevant props. These definitions will be stored in a JSON object who’s IPFS hash will be used as a reference on-chain. The mapping will contain a concatenated hash of the publishing key of the author and the name of the BOS component. From there, versioning will be supported to make updates to this particular reference with a new IPFS content hash. Below you will find the scope of the contract’s functionality.
Integrations
-
bos-workspace -
hyperfiles
In order to leverage registry capabilities in existing developer workflows, Archetype will write integrations for popular libraries including bos-workspace. With enhanced context on imported/referenced components, developers will get improved type introspection as well as preservation of props. With arbitrary attestations and metadata from the registry, the integration will hook into existing constructs and scripts within bos-workspace, thus providing context to module imports that utilize data.json when uploading data to the SocialDB. Support will also be provided for build and deployment scripts/commands. For example, an optional flag that can be used to publish metadata content hashes to the registry.
The following is a list pertaining to the new capabilities enabled and piloted after contract deployment.
-
Initial efforts for Curation layer, i.e decentralized discovery, indexing, sorting, and filtering:
-
An sdk to surface schemas such as category tagging, dependency graphs, various search filters
-
Different publishing rights through SocialDB, allowing orgs to share and release packages under the same namespace
-
Semantic linking of BOS components, i.e. Widgets that can work together/interface (share props) cleanly with one another throughout version updates.
Key Stakeholders: Everything, BOS Workspace, Hyperfiles
4. Budget
-
Total Cost: $7,000 - - the full estimate of the project cost has not yet calculated this is exclusively for the month of Feb. The project is being developed actively along with BuildDAO.
-
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:
- Phase 1 will have the contracts deployed to testnet by end of January
- Phase 2 goals are to have touch points and integrations completed along with the initial semantics defined for component discovery
- Milestones:
- Phase 1 End of Jan 31st - contract deployment
- Phase 2 End of Feb - Pull requests for integrations for
bos-workspace
6. Evaluation and Measurement
Success Criteria:
For the initial work surrounding the smart contracts below list the features to be completed
-
As a component author, I am able to publish an IPFS hash for a new BOS component
-
As a component author, I am able to update an IPFS hash for an existing BOS component
-
As a component consumer, I should be able to retrieve the IPFS content for a particular BOS component
Monitoring and Evaluation
Archetype will be working closely with BuildDAO as well as maintainers for bos-workspace to determine the github issues necessary to complete the integration step. Regularly (weekly) design meetings will be had to ensure project status is on track but also to iterate on the metadata layer corresponding potential future work
7. Risks and Mitigation Strategies
-
Risks: Community buy-in surrounding schemas as well as potential additional work as it pertains to new policies to be supported in the NEAR SocialDB contract.
-
Mitigation: By working out in the open we hope to drive adoption of some of the standards outlined after this set of design work. Furthermore, by leveraging existing work around NEAR social, the team will engage in an open channel with the previous maintainers to see what features can be supported in the upstream project or our own fork.
8. Conclusion
Summary
This is the first step necessary to introduce a new paradigm of software development. We’re targeting a variety of verticals and use cases across different industries (including outside of the crypto space), but with the general interest in distributing access to the modes and methods of sovereignty - through a couple of key areas, starting with a secure software supply chain.
Consumers of the metadata can vary widely. At the highest level, we’re looking to provide context - to arbitrary decision makers, contracts and protocols, execution environments, CI/CD pipelines, test suites and toolchains, infrastructure providers, security researchers etc. We believe this is a great first step in order to facilitate knowledge graphing and opening up data/documentation to the community.
9. Appendix
For our whitepaper pertaining to the GTR, please visit: archetype.computer
10. Contact Information
- Name: Cory Dickson
- Title: Chief Architect, Archetype
- Email: cory@archetype.computer