Free TON

Contest Proposal: Bindings for TON Client Library

Contest Proposal: Bindings for TON Client Library

Short description

Implement TON Client library bindings for any language of participant’s choice.

Dates

October Xth, 2020, the beginning of day UTC - November Yth, 2020, the end of day UTC

Motivation

TON adoption depends on the ecosystem of DApps, which doesn’t exist yet. We need to provide a set of libraries, tools, and materials for developers to build TON Dapps on any language, platform, and architecture.

The contest is focused on the TON-SDK (especially TON Client) library bindings for different languages, which is the foundation for developers to build DApps.

We expect each participant of the contest to get a deeper understanding of SDK internals and technical concepts behind TON.

Task

  1. Create TON Client library bindings for your language of choice. These bindings should provide an API for all SDK Library methods
  2. Write either unit tests or example code which illustrate the usage of the interface you’ve implemented

Submission format and requirements

  • Work should be submitted to the GitHub repository. The participant may use any GitHub account he/she wants to publish the repository
  • To make the evaluation process faster, include a README file with instructions to install dependencies (if any) and compile/run tests/examples
  • Submissions with failing builds/tests/samples will be rejected
  • Submission should use v1.0.0 Core SDK release

Evaluation criteria

Considering the following criteria set, the submission score increase:

  • API coverage completeness

  • Test coverage completeness:

    • amount of methods covered
    • “negative” tests
    • async request tested
    • tests on method execution correctness when called from one/different client contexts
  • Internal SDK errors are handled using error handling approaches. Error codes and messages are consistent with SDK errors.

  • It is possible to solve the following routines using participants’ submission code:

    • keypair derivation from TON Surf mnemonic
    • contract deployment
    • message / transaction sending
    • fee estimation
    • graphql queries execution
  • Asynchronous API (request with callback) binding implementation

  • Available via the appropriate package manager (e. g. pip for python or npm for js)

Considering the following criteria set, the submission score decrease:

  • Not implemented SDK methods
  • Binding mistakes causing SDK errors
  • Memleaks
  • Incomplete test coverage or tests inexistence
  • No instructions for running tests/examples
  • Bad code readability
  • Core Implementation inconsistency

Notes

Don’t implement core logic. You should use the Core SDK dynamic library (v1.0.0) to create your bindings.

The Jury

  • Strong technical background is a must.
  • There should not be less than 5 jurors

Contest Rewards

The reward for TOP-3 among all participants:

  1. :gem: 100’000
  2. :gem: 75’000
  3. :gem: 50’000

The reward for TOP-3 among participants of given language:

  1. :gem: 50’000
  2. :gem: 25’000
  3. :gem: 10’000

30% of this amount will be paid as a contest reward immediately after voting ends.
Another 70% of this amount will be vested over a 12-month period with the monthly distribution.

Prize Evaluation Example

Python binding submission took 2nd place among all participants and his solution is the best among all Python submissions. It will receive :gem: 75’000 + :gem: 50’000 = :gem: 125’000

Reward Distribution

  • Winners receive 30% of their rewards when contest results are evaluated.
  • Another 70% will be vested over a 12-month period with the monthly payouts.
  • To receive all 12 distributions, the solution should be supported for 1 year
    • The binding should be updated (in a reasonable timeframe) according to the main library changes
    • Major GitHub Issues should resolve within a reasonable timeframe
  • The first vesting payout is paid one month after the end of the contest
  • The first vesting payout :gem: 100
  • Payouts increase exponentially over a month

Exponential Vesting Distribution

As an incentive to support the winning solution during the whole vesting period, payouts increase exponentially each month.

Use this to play with parameters


Voting: 1-10 / reject / abstain
  • Each of the initial Free TON jurors can vote on your submission. Jurors whose team(s) intend to participate in this contest by providing submissions lose their right to vote in this contest.
  • Each juror will vote by rating each submission on a scale of 0 to 10 or can choose to reject it if it does not meet requirements, or they can choose to abstain from voting if they feel unqualified to judge.
  • Jurors will provide feedback on your submissions.
  • Duplicate, sub-par, incomplete or inappropriate submissions will be rejected.
Jury Rewards: 5%

An amount equal to 5% of the sum total of all total tokens actually awarded to winners of this contest will be divided equally between all jurors who vote and provide feedback. Both voting and feedback are mandatory in order to collect this reward.

Procedural requirements
  • All submissions must be accessible for the jury to open and view, so please double-check your submission. If the submission is inaccessible or does not fit the criteria described, the submission may be rejected by jurors.
  • Contestants must submit their work before the closing of the filing of submissions. If not submitted on time, the submission will not count.

Disclaimer

Anyone can participate, but Free TON cannot distribute tokens to US citizens or US entities.

23 Likes

Very good idea! Highly appricate this contest!

3 Likes

Can Bitbucket account be used instead of GitHub (I don’t like their politic)?

1 Like

No. We will stick to GitHub, because it’s defacto standard in Open Source community

1 Like

:rocket: :rocket: :rocket: :rocket: :rocket: :rocket: :rocket: :rocket: :rocket:

1 Like

Good idea. It will encourage people to get familiar with or better at SDK usage.

2 Likes

You can ask technical questions on SDK here

3 Likes

I participated in the Airdrop contest. Spent 2 days.
I participated in the Brand masters contest. Spent 2 weeks.
I read about DePool contests and talk with Validator contest participants.

This contest is harder! Need increase reward.

First
Look at rewards for other contests.

Airdrop 30, 29, 28, …
Brand masters 20, 18, 16, …
DevOps tools 30, 29, 28, …
Wiki 40, 20, 10, …

Second
Think about code support. If the SDK is updated or developers start use library,
the author will have to update the library. Library without support do not needed.

I propose to up reward to 70k, 55k and 40k for TOP-3 on one language.

3 Likes

I like idea, but I think need increase rewards as it will take much more time than DePool contest or Validator contest

3 Likes

Contest Proposal Updates:

  • Start Date rescheduled to September, 21st
  • Increased rewards
  • Introduced Exponential Vesting Distribution (sample vesting schedule attached to the proposal)
  • Minor formatting and readability updates

Enjoy :slight_smile:

2 Likes

The contest dates and reward structure will be updated soon. Detailed announce is in SDK chat, any feedback is welcome

Everyone, the original proposal has been edited and adjusted based on the feedback that was provided. Please see the redacted version here:

Contest Proposal: Bindings for TONOS Client Library

Short description

Implement TONOS Client library bindings for any language of participant’s choice.

Contest dates

October 28th, 2020 - November 18th, 2020 end of day by timestamp in your location. There will be a 24-hour countdown clock on the last day of possible contest submission entry.

Voting cycle:

21 days

Motivation

TON adoption depends on the ecosystem of DApps, which don’t exist yet. We need to provide a set of libraries, tools, and materials for developers to build TON Dapps on any language, platform, and/or architecture.

The contest is focused on the TON-SDK library bindings for different languages, which is the foundation for developers to build DApps.

We expect each participant of the contest to get a deeper understanding of SDK internals and technical concepts behind TON.

Task

  1. Create TON SDK binding for your language of choice. This binding should provide an API for all TON SDK asynchronous JSON Interface methods listed in the docs/modules.md file of the TON-SDK master branch.
  2. Write either unit tests or example code that illustrates the usage of the interface you’ve implemented

Submission format and requirements

  • Submission must use the v1 TON-SDK release
  • Work should be submitted to the GitHub repository. The participant may use any GitHub account they want to publish the repository
  • Include a README file with instructions to install dependencies (if any) and compile/run tests/examples
  • Submissions with failing builds/tests/samples will be rejected
  • Submissions without tests or usage samples will be rejected

Evaluation criteria

Considering the following criteria set, the submission score increases:

  • API coverage completeness
  • Inline documentation in your code
  • Test coverage completeness:
    • amount of methods covered
    • “negative” tests
  • Internal SDK errors are handled using error handling approaches. Error codes and messages are consistent with SDK errors.
  • It is possible to solve the following routines using participants’ submission code:
    • TON Surf mnemonic generation and keypair derivation from it
    • contract deployment
    • contract call
    • message decoding
    • run get methods, including Solidity and Fifth get methods, such as elector contract get methods
    • emulate transaction locally
    • subscription for data events
    • intermediate events of process_message logging
    • graphql queries execution
  • Available via the appropriate package manager (e. g. pip for python or npm for js)

Considering the following criteria set, the submission score decreases:

  • Not implemented SDK methods
  • Binding mistakes causing SDK errors
  • Memleaks
  • Incomplete test coverage
  • No instructions for running tests/examples
  • Bad code readability

Notes

Don’t implement core logic. You should use the TON-SDK library (v1.0) to create your bindings.

Jury

  • The juror must have a solid understanding of the described technology to provide a score and feedback. If not, the juror should choose to “Abstain”.

Voting:

  • The juror must have a solid understanding of the described technology to provide a score and feedback. If not, the juror should choose to “Abstain”.
  • Jurors or whose team(s) intend to participate in this contest by providing submissions lose their right to vote in this contest.
  • Each juror will vote by rating each submission on a scale of 1 to 10 or can choose to reject it if it does not meet requirements or vote “Abstain” if they feel unqualified to judge.
  • Jurors must provide feedback on submissions or lose their reward.
  • The Jury will reject duplicate, sub-par, incomplete, or inappropriate submissions.
  • The number of days for jury voting is hereby set at 21 day.

Contest Rewards

The reward for TOP-3 among all participants:

  1. :gem: 100’000
  2. :gem: 75’000
  3. :gem: 50’000

The reward for TOP-3 among participants of given language:

  1. :gem: 50’000
  2. :gem: 25’000
  3. :gem: 10’000

Reward Distribution

  • Winners receive 30% of their rewards when contest results are evaluated.
  • Another 70% will be vested in equal parts over a 12-month period with monthly payouts.
  • To receive all 12 distributions, the solution should be supported for 1 year
    • The binding should be updated within a reasonable timeframe - 1 month maximum, and according to main library changes.
    • Major GitHub Issues should be resolved within a reasonable timeframe - 1 month maximum.

Jury Rewards:

An amount equal to 5% of the total sum of all total tokens awarded to contest winners will be distributed among jurors who vote and provide feedback. This percentage will be awarded on the following basis:

  • The percentage of tokens awarded to the jury will be distributed based on the number of votes each juror casts. For example, if one juror votes 50 times and another juror votes 5 times, the juror who votes 50 times will get 10 times more tokens than the juror who votes 5 times.
  • Feedback is mandatory to collect any rewards.
  • In this particular contest the contestants have a vesting period for their reward distributions. The jurors do not. Jurors will receive their rewards upon completion of the contest in one lump sum, i.e., no vesting period, and as a part of the cumulative 100% reward figure regardless of the long term outcome.

Procedural requirements:

Accessibility. All submissions must be accessible for the jury to open and view, so please double-check your submission. If the submission is inaccessible or does not fit the criteria described, jurors may reject the submission.

Timing. Contestants must submit their work before the closing of the filing of applications. If not submitted on time, the submission will not count.

Contact. Each submission must have an identifiable contact that can be matched with your description. If you have not provided a forum description for discussion, then your application should contain links to your online persona, for example, a Telegram ID (preferred) or other direct contact information that can confirm that the submitted work is yours. In the absence of confirmation by the contestant of the authorship of the submitted work, the submission may be rejected.

Multiple submissions.

  • Each contestant has the right to provide several submissions if they are all different from one another. If they are too similar, or in any way appear to be partially the same work done twice, or if they appear to be one whole body of work divided into parts to create the illusion of several submissions, jurors have the right to reject such submissions.
  • If the contestant wants to make an additional submission to replace a previously published submission, the contestant must inform the jury about this fact and indicate which submission is the one to be judged. In this case, only the indicated work will count. If the contestant fails to indicate which submission to judge, only the first submission that is uploaded by timestamp will count. The Jury will reject all others.

Disclaimer

Anyone can participate, but Free TON cannot distribute tokens to US citizens or US entities.

6 Likes

I am going to participate in this contest!

In this post I’ll briefly describe my work.

The work consists of two independent implementations in different programming languages: Lua and Clojure.

Being created with specific practical goals in mind, they both are quite generic and suitable for any purpose TON OS SDK is applicable for.

I kindly invite everyone interested to find out more by reading docs and reviewing the code on Github!

Tag 1.1.0 is to be the subject for assessment.

Alongside with tests, there are growing set of usage examples (in the main branch).

For any question or help, anyone is welcome to contact me via Telegram (@sergemedvedev).

4 Likes

Bindings for TONOS Client Library

Dear community, rsquad brings you ton-client-ts — TON-SDK bindings for the web and node.js.

Telegram — @inyellowbus
Repository — https://github.com/RSquad/ton-client-ts
Contest branch — https://github.com/RSquad/ton-client-ts/tree/contest

Why TypeScript?

From our point of view, the main idea of decentralization and blockchain as a whole implies the total domination of serverless applications. Users want to remain anonymous and not transfer any information to third parties. Therefore, we believe that the most valuable bindings for SDK are bindings in languages for implementing interfaces, moreover graphical ones.

Of course, the majority of languages that solve such problems are large, but JS is gaining popularity every day as an interface language and occupies a leading position. It has long been used by not only websites, but also cross-platform mobile and desktop applications. In turn, TS is tacitly the standard for writing applications transpiled in JS. Many popular frameworks use it out of the box.

While developing applications using TON, we were faced with the fact that while implementing our interfaces we cannot use all the power and beauty of the typescript, therefore we decided to write bindings

Brief overview

• The library is fully typed
• Complete generated in-code documentation
• All binding units are covered with tests
• All functionality of TON-SDK v1.1.2 is fully supported
• The bindings interface is identical to the interface of the root library, nothing has been changed
• All calls are asynchronous
• Easy installation via platform-dependent npm packages

About implementation

In our implementation, we have kept the naming and functionality of the root library as much as possible. It is really important to have a unified interface for interaction and unified documentation with the root library, since the task is to write bindings, which in essence implies the complete preservation of the library interface and possible add-ons, but excludes changing the interface without the possibility of calling signatures similar to the root library. Therefore, we did not resort to the mandatory wrappers for creating GraphQL queries and other things without preserving the ability to use exactly the same interface as in the root library.

Of course, we understand that a number of root library decisions may seem controversial. The main idea that we adhered to — do not change, but add. In this implementation of bindings, not only the full interface of the root library is preserved, but also supplemented with a number of new functions and opportunities to expand the functionality of the library. In other words — use
with an interface that is completely identical to the root library, or use our add-ons / implement your own.

About cross-platform

While developing the library, we faced a cross-platform problem. It is not enough just to write a good kernel, you need to support different platforms — both web and node.js on different operating systems, and also do not forget that both TS and bare JS can be used.

Therefore, a monorepo was created using yarm workspaces and lerna.

The main packages at the moment
• core — the core of the library with general binding functionality
• node — a package defining the correct binary depending on the OS and exporting the library class for node.js
• web — a package that starts a web-worker with wasm and exports a library class for the web

Each of the above packages is built and published as scoped npm module @ ton-client-ts

Such a system allowed us to avoid creating a bunch of repositories with our own dependencies, reducing the time for support and publishing the solution, and also solved a lot of problems with testing and versioning. Now there is no need to worry about the correctness of package versions, and builds, tests and version updates are launched with a simple command

About interesting solutions

A module generator has been implemented. The generator receives the api from the TON-SDK client and collects from them a ready-made package of modules conveniently arranged in directories, links them together and generates in-code documentation in a matter of seconds. All you need to update the TON-SDK modules to the new version is to run the generation script.

About additional features

At rsquad, we have been developing interfaces for over a year that are somehow related to Free TON. We solved a lot of similar problems and suffered from dubbing in different projects. Therefore, we have already added a number of utilities, such as getting an account balance, to make such a case as simple and compact as possible without learning GraphQL and writing our own utilities.

In the future, we will gradually expand modules and publish our ups and downs to make your development even easier.

Best regards, rsquad

2 Likes

I want also to present my submission in .NET: https://github.com/vcvetkovs/TonSdk

1 Like

Good,interesting idea.

Is this contest still active? Tags and dates in posts are misleading. And what’s a current deadline?

You can found dates in this post here: Contest Proposal: Bindings for TON Client Library
or on gov.freeton.org under DevEx sub-governance

1 Like