Interface Support Request: Network, SecurityCardManagement, SigningBoxInput, UserInfo.

[asnov]

Great work, guys!
Please, add support of the following interfaces from DeBot consortium:

• Network,
• SecurityCardManagement,
• SigningBoxInput,
• UserInfo.

Thank you!

[qwertys318]

All these interfaces have status "proposed" and not approved by "DeBot Interface Specifications (IS) Consortium" yet.
You can check their status there: https://github.com/tonlabs/DeBot-IS-consortium
So, we will add when status will be changed to "Accepted" and realized by ton-client-js debot engine.

[asnov]

On 13/05/2021 DevEx Weekly Zoom Call it was said that most of the SDK binding contest participants do maintain the debot modules inside SDK while it is unstable. And it was decided that all participants should maintain the debot modules inside SDK even they are unstable in the future.
If they can and should support these modules inside SDK, why can't you support them inside the DeBot browser?

[asnov]

I'm sorry, I suddenly pressed ctrl+enter to make a new line while editing but this posted my comment before I finished it.
Now my post is finished, please, read it again. Thank you!

[qwertys318]

Sorry, we just want to follow the rules of contest and be clear.
Okay. If you would like to compare with SDK-bindings, let's do it.
In this page you can download pdf file with SDK-bindings contest requirements. You can see vesting conditions:

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.

So requirements contents updating functionality and solving issues.

Now let's see SMV deBot Browser:
Page of contest
Vesting conditions:

The contestant should support the solution for twelve months to receive all vesting
distributions:
○ Major reported issues should be resolved within a reasonable timeframe - one
month maximum

So, there is not any conditions of implementing new functionality, only supporting existing.
But we are ready to implement new "Accepted" interfaces for free due to we like our deBrowser and Free TON in general.
Unstable features can be realized by community.

[asnov]

there is not any conditions of implementing new functionality, only supporting existing.

It is not like this.
You missed the point which goes just right after the sum of the prizes:
All rewards should be distributed in a form of 1 year Vesting depending on participants
supporting their repositories by responding to issues, implementing reasonable user
requests and fixing bugs.

So you should "implement reasonable user requests" to receive vesting. This means two things:

1. when you are writing:

we are ready to implement new "Accepted" interfaces for free

this is not "for free" - you're receiving vesting exactly for this.

2. Implementing all features, including unstable, could be considered as a "reasonable user request" as well.

[qwertys318]

Of course "implementing unstable features" cannot be "reasonable user request". That's ridiculous.
But it's okay, it's not too big problem for us. We see how you need it.
So, we will do it. If you already have some debots using those interfaces, we can finish it faster.

[asnov]

"implementing unstable features" cannot be "reasonable user request"

It's your point. My point is opposite but we do not need to argue. Thanks to Free TON, we can call a vote and get the community's point of view. Perhaps closer to the time of payment of the first vesting, we should do this.

[qwertys318]

Interface 'UserInfo' has realized.
You may check it in "Interfaces Demo Debot" in https://debrowser.extraton.io
Other 3 interfaces will be realized within a couple days.
Sorry for delay.

[qwertys318]

Interfaces 'Network' and 'SigningBoxInput' have realized.
You may check it in "Interfaces Demo Debot" in https://debrowser.extraton.io
The last interface 'SecurityCardManagement' will be realized ASAP.

[qwertys318]

Interface 'SecurityCardManagement' update.
Security card is required in process of implementation this interface.
So, we have ordered it and will continue when it's delivered.