RFP: ICRC-16 Compatible Rust Cargo Component for the Internet Computer
Overview
Status: Open
Project Type: Cooperative - Multiple workers can submit work, and the bounty is shared.
Time Commitment: Estimated <1 week
Experience Level: Beginner to Intermediate
Size: Possible < USD 5,000 via Grant, 60,000 Event Utility Working Group Tokens/hr.
Proposing Group: The Events Utility Working Group
Description
In the rapidly emerging sector of decentralized applications, standardization of data exchange formats is crucial for interoperability and efficient communication between canisters on the DFINITY Internet Computer. The ICRC-16 EnhancedValue standard proposes a Candid-Compatible interface for a flexible, standardized exchange of unstructured data.
Our goal is to create a Rust cargo component that fully implements the ICRC-16 EnhancedValue standard, ensuring compatibility and functionality in a Rust project environment. This component should provide developers with the necessary tools to seamlessly integrate and manipulate ICRC-16 data types.
Project Deliverables
This Rust cargo component should provide:
Data Types:
Define all necessary Rust data types corresponding to the ICRC-16 EnhancedValue Candid variants.
Conversion Functions:
Implement helper functions that facilitate the conversion between ICRC-16 variants and native Rust types.
Interface Methods:
Provide implementation for the interaction of these data types with the Internet Computer, including serialization and deserialization to/from Candid.
Size Calculation:
Provide implementation for the estimation of the size of an object in bytes.
Acceptance Criteria
The deliverable must:
Fully support all variants outlined in the ICRC-16 standardâs Candid definition.
Include comprehensive documentation detailing usage and integration processes.
Provide a robust suite of unit tests demonstrating the correctness of the implementations and conversion functions.
Be published on a public repository under an open-source license (preferably MIT or similar).
Offer examples demonstrating practical implementations of the component in sample Rust projects.
The creation of this Rust cargo component is a step towards enhancing the ecosystemâs capability to manage and utilize unstructured data effectively, following the ICRC-16 standard. We invite capable Rust developers to contribute to this effort, paving the way for more standardized and cohesive data handling within the Internet Computerâs diverse and expanding application landscape. This component will be a key input into the rust client for ICRC-72 and a such the Event Utility WG is offering 60,000 tokens / hour spent on the item given an agreed upon estimate. We would recommend this project be granted a DFINITY public grant as well, although it my not be a full $5,000 grant.
We have already tools generating Java proxy classes from Candid IDL files. Currently we also generate Motoko types from existing Java classes. Let me investigate how we can use same libraries to generate Rust artifacts from IDL. This would simplify any future Candid integrations. Let me also see if we can use some AI to generate documentation.
The Event Utility has one value proposition of creating a way for canisters to communicate with other canisters that are interested in its activities without that canister having to know about the other canisters and/or, in some cases(like an indexing service), those canisters needing to know the schema of the incoming message. Since inter-canister communication on the IC is generally candid unless youâre specifically trying to exclude significant portions of the ecosystem, we currently have the data payloads using standard candid, specifically, ICRC-16-defined candid.
So there will be recommendations for how to use CBOR, but generally, you need to keep in mind that if you use it you are significantly limiting the interoperability of your platform on the IC. (This may be fine in a closed loop icrc-72 implementation, but shouldnât be the case for open internet services).
@DunkanMcLoud is currently investigating bringing his previous component up to the latest version which would help accomplish this RFP. Thanks, DunkanMcLoud!
I have delved deeper into the topic to assess the effort required to improve the existing library: candy-rs.
Based on my analysis, adding a couple of additional types and test cases would suffice to create a type system for Rust developers. This task appears straightforward and could be completed in a few evenings, likely taking less time than going through the grant application process.
One point that remains unclear to me is the byte size estimation, which currently differs between the existing Rust and Motoko libraries. This discrepancy is highlighted in the following integration test: size.test.ts.
To achieve a more thorough implementation, I need advice and a code review from a more experienced canister developer, particularly for properly implementing byte size estimation or deciding whether to leave it as is. I am also uncertain about the specific use cases for this functionality, so I am requesting suggestions from such a developer for modelling in an additional integration test.
I am willing to work on this library without submitting an extra grant application since it is my previous project and the scope of changes seems manageable. If anyone is already working on this task, I encourage them to pay special attention to the last point mentioned.
Weâd love to have you on the call Wednesday to discuss your proposal(I expect unanimous agreement). Since it is smaller, we can just do the WG tokens which may be used to seed the team allocation of a future DAO, but are pretty much just internet cool points at the moment.
Iâve made a mistake when claimed that byte size estimation is not ok in previous version, seems it was done right, I just forgot about it
I will add a couple of test cases and hope to complete current iteration of development this week
