Awarded: ICDevs.org Bounty #47 - Candy Library - Rust - $4,000

Developers Bounties
1

Candy Library - Rust - #47

Current Status: Discussion

  • Discussion (01/09/2023)
  • Ratification: (01/09/2023)
  • Open for application: (01/09/2023)
  • Assigned
  • In Review
  • Closed

Official Link

Bounty Details

  • Bounty Amount: $4,000 USD of ICP.
  • ICDevs.org Bounty Acceleration: For each 1 ICP sent to 239ae124bf63b521baf9bdd6051652fae0c16178027ec9b2b093346bad280752, ICDevs.org will add .25 ICP to this issue and .75 ICP to fund other ICDevs.org initiatives.
  • Project Type: Individual
  • Opened: 01/09/2023
  • Time Commitment: Weeks
  • Project Type: Library
  • Experience Type: Intermediate - Motoko; Intermediate - Rust; Intermediate - JS;

Description

Candy Library provides an extensible set of types for the basic motoko types.

You will create a rust implementation of the various candid types. Since some libraries return Candy types it can be helpful to have these types available in rust.

Create a cargo package that allows rust developers to add the candy types to their projects.

Duplicate the functionality in the Candy library: GitHub - icdevsorg/candy_library: Library for Converting Types and Creating Workable Motoko Collections

This bounty gives the opportunity to

  • learn about Rust
  • learn about Candy Library

To apply for this bounty you should:

  • Include links to previous work writing tutorials and any other open-source contributions(ie. your github).
  • Include a brief overview of how you will complete the task. This can include things like which dependencies you will use, how you will make it self-contained, the sacrifices you would have to make to achieve that, or how you will make it simple. Anything that can convince us you are taking a thoughtful and expert approach to this design.
  • Give an estimated timeline on completing the task.
  • Post your application text to the Bounty Thread

Selection Process

The ICDevs.org developer’s advisors will propose a vote to award the bounty and the Developer Advisors will vote.

Bounty Completion

Please keep your ongoing code in a public repository(fork or branch is ok). Please provide regular (at least weekly) updates. Code commits count as updates if you link to your branch/fork from the bounty thread. We just need to be able to see that you are making progress.

The balance of the bounty will be paid out at completion.

Once you have finished, please alert the dev forum thread that you have completed work and where we can find that work. We will review and award the bounty reward if the terms have been met. If there is any coordination work(like a pull request) or additional documentation needed we will inform you of what is needed before we can award the reward.

Bounty Abandonment and Re-awarding

If you cease work on the bounty for a prolonged(at the Developer Advisory Board’s discretion) or if the quality of work degrades to the point that we think someone else should be working on the bounty we may re-award it. We will be transparent about this and try to work with you to push through and complete the project, but sometimes, it may be necessary to move on or to augment your contribution with another resource which would result in a split bounty.

Funding

The bounty was generously funded by the DFINITY Foundation. If you would like to turbocharge this bounty you can seed additional donations of ICP to 239ae124bf63b521baf9bdd6051652fae0c16178027ec9b2b093346bad280752. ICDevs will match the bounty $40:1 ICP for the first 50 ICP out of the DFINITY grant and then 0.25:1ICDevs.org Bounty Acceleration All donations will be tax deductible for US Citizens and Corporations. If you send a donation and need a donation receipt, please email the hash of your donation transaction, physical address, and name to donations@icdevs.org. More information about how you can contribute can be found at our donations page.

FYI: General Bounty Process

Discussion

The draft bounty is posted to the DFINITY developer’s forum for discussion

Ratification: (01/09/2023)

The developer advisor’s board will propose a bounty be ratified and a vote will take place to ratify the bounty. Until a bounty is ratified by the Dev it hasn’t been officially adopted. Please take this into consideration if you are considering starting early.

Open for application

Developers can submit applications to the Dev Forum post. The council will consider these as they come in and propose a vote to award the bounty to one of the applicants. If you would like to apply anonymously you can send an email to austin at icdevs dot org or sending a PM on the dev forum.

Assigned

A developer is currently working on this bounty, you are free to contribute, but any splitting of the award will need to be discussed with the currently assigned developer.

In Review

The Dev Council is reviewing the submission

Awarded

The award has been given and the bounty is closed.

Other ICDevs.org Bounties

3 Likes
2

Hi @skilesare ,

I would really like to work on this task. Previously I participated in this icdevs’ bounty and mentioned my background in that thread. Briefly, I spent some amount of time to become familiar with Rust since I am mainly a Java developer. Now I would like to build something useful.

I have created a repo with initial blocks created (stable and unstable types, some functions)
GitHub - IT-Union-DAO/candy-rs: Candy library implementation in Rust

I guess I have grasped the idea of candy library, but i believe your feedback is required for creating good tests and docs, which cover the main purpose of this task. For instance, which cases you see for use this library. Should we simulate something like inter-canister blob transfer? Are there any apps today which require or utilize such approach?

3

Awesome. I’ve submitted you to the board and I expect it to be accepted.

@icme, @aiv, @quint, @mparikh, please vote :slight_smile:

4

I voted to approve, good luck Dunkan!

5

Hi @skilesare
Could you please share libraries which currently return candy types? These references would be helpful to design a nice api.

6

@skilesare There is an implementation detail that I am currently struggling with, and it relates to the sizing of Candy values. I have not yet fully understood which environment these sizings belong to, whether it is WASM or Rust/Motoko. The sizes of these values are used in chunking workspaces and data zones. While working on Motoko workspace chunking, I noticed that the library relies on the sizes of Candy (Unshared) values. However, in the Rust library, we do not need Unshared values at all. My main problem at the moment is to understand where sizes fit into the whole logic of the project since I do not understand whether 2 libraries should produce the same output?

In other words, where Motoko getValueSize functions come from?

7

Good point…this function may be less relevant in rust…but I’d think there were standard sizes or Lagos one could use.

For motoko I got them by asking around and understanding how variants work. I do t think o cover all edge cases (ie variants get bigger when you get past. 256).

Perhaps a rust expert could weigh in. The purpose here is to split a workspace into enough addresses chunk arrays that it fits into a sub 2 MB message. It is an artifact of the current network limitations.

9

Hi @skilesare

I guess the job is completed for this particular moment of time. Please review repository and published crate.
https://crates.io/crates/ic_candy

Perhaps, further improvements can arise due to the difference of value size calculation. Please review jest integration tests (for size and workspace) in example folder of repository