Rust Lite Client Instead of tonlibjson

[liketurbo]

Summary

Add a native lite client to tonlib-rs

Context

The lite client is a library used for interaction with the lite server. Currently, tonlib-rs utilizes tonlibjson from the main repository, incurring compilation and complexity costs.

References

• Rust SDK for The Open Network
• Main TON monorepo
• ADNL protocol implementation in Rust

Estimate suggested reward

TBD

[hacker-volodya]

Recently we've continued tonstack/adnl-rs and tonstack/lite-client libraries development. We plan to rewrite it to async traits and publish stable release soon.

Features list:

adnl-rs

• Implement ADNL according to its specification (done)
• Cover with unit tests (done)
• Support async/await (current implementation supports only synchronous operations)

lite-client

• Implement lite_api.tl functions and types (done)
• Cover with integration tests (test communication with public liteservers) (done)
• Implement small low-level cli to manually interact with liteservers (prototype is done, improvements needed)
• Support async/await
• Add docs and examples
• Publish on crates.io

[liketurbo]

@hacker-volodya tbh, I don't think it's a good idea to have a separate crate for the lite client. Dapp developers would be forced to use both tonstack/lite-client and ston-fi/tonlib-rs and the latter already comes with the tonlibjson library, which can't be opted out, resulting your binary ending up with two lite server clients.

Besides, there already exists a great adnl client from tonlabs with good support, tonlabs/ever-adnl, upon which a lite client can be built relatively easily and integrated into ston-fi/tonlib-rs.

[hacker-volodya]

I don't think it's a good idea to have a separate crate for the lite client

It would be great for lite-client lib to support both tonlib-rs and everscale libs, allowing people to choose libraries which are most appropriate for their cases. So, separate crate is a good option.

Dapp developers would be forced to use both tonstack/lite-client and ston-fi/tonlib-rs and the latter already comes with the tonlibjson library, which can't be opted out, resulting your binary ending up with two lite server clients.

If I understand correctly, the goal is to replace tonlibjson. To do this, you have to adjust tonlib-rs code anyway. So, what's the difference between integrating code directly in tonlib-rs vs. making dependency on a separate crate?

Besides, there already exists a great adnl client from tonlabs with good support, tonlabs/ever-adnl

I don't think that it has "good support". Using git blame on client.rs, for example, shows that latest manual commits were in 2021. AFAIK, modern networking library is broxus/everscale-network, which doesn't support client-server ADNL.

[liketurbo]

If I understand correctly, the goal is to replace tonlibjson. To do this, you have to adjust tonlib-rs code anyway. So, what's the difference between integrating code directly in tonlib-rs vs. making dependency on a separate crate?

Sorry, I misunderstood you. In that case, either one will do ... although, I personally prefer the option of development within ston-fi/tonlib-rs.

Regardless, we need to open an issue and coordinate with the maintainer before we proceed with what's better 😊