The meeting discussed the authorization protocol, what schemes should be developed, their directions and for what audience they are. They also touched on the burning topic of not quite perfect voting yet.
About the development of an authorization mechanism
Ivan Kotelnikov mentioned that there is already a solution from TON Labs in open source, which allows to give a person a token and then check and authorize it using a public key in a certain way. But based on this decision, you can think of something else.
Pavel P also spoke about another universal proposal, in which the key is split locally into 3 parts on the client. “For example, a person makes a Google login and actually signs the operation — this is what the user experience (UX) looks like. We already have people who integrate such a scheme. All in all, this is a very good UX. It can be changed, improved, made more secure by linking it to a multisig, but in general, this kind of story can be modeled a lot”.
Ivan is also confident that the community will have enough ideas for alternative solutions. The task in the contest is simply to describe and design the authorization.
Pavel P agrees that there is no problem to make authorization schemes, but in his opinion, it is necessary to calculate that different audiences have their own needs: “For some, recovery is important, for some security, for some convenience. The more authorization schemes are developed and available out of the box, the more will be used”.
Mitja, on the other hand, expressed the opposite point of view that he does not see much sense in holding this contest, because he believes that everyone can do authorization himself: “For example, we have an initial authorization scheme, we will develop it later. Take it, use it. The partners have a scheme — take it and use it. Anyway, everything is done under the use case”.
Pavel P suggested to write the scheme more broadly, and there can be three directions of focus:
The last point should definitely be. Combinations are possible. At the same time, just indicate that the scheme can be for different user cases, who it should be more focused on, for what type of people (audience).
Pavel P also suggested a mini experiment. If you go to the “Passwords” tab in your iPhone and click on security recommendations, you can find out how many accounts and passwords have been compromised, i.e. they can be purchased on the market. “What I mean,” explains Pavel P, “That this login-password system must die and only authorization via the blockchain should work in the future. Well, of course, if you do not trust Google, which can disable something, because it violated some policy — it is not clear whose and it is not clear where”.
Ivan summed up all the statements to a common denominator: “It is necessary to add a jury list, remove the specifics of a smart contract and ask in the requirements to specify the target audience and use case for which such a design is being developed, add recovery and convenience”.
Free TON Voting System: How to Be?
The burning topic of voting continues to excite minds. And this is not surprising, when there are so many shortcomings and understatements, it is urgently necessary to come to a common denominator, so as not to step on the same rake every time.Anazarov79, for example, noted that it is always necessary to set a list of the jury in a smart contract, and it is those who judge.
Then a discussion began about the distribution of prizes under the conditions of 50+1.
If 50+1 and reject, will the submission participate in further consideration? Still, reject means that one of the judges considered that the conditions were not met, which means, in theory, all other votes are leveled.
Also, the question of abstain (abstention from voting) was once again raised. Aleksandr Hramcov wonders what to do in such a case, for example, when there were 4 voters, while one refused to vote because he was affiliated with a participant, the other two rejected — and this is not enough to reject the submission? That is, in fact, the affiliated person must still consider the submission.
For example, Mitja is sure that the people on the jury simply cannot be without an opinion (this is a question on abstain), because they must be qualified from the beginning. And there is no point in changing smart contracts for this.
Anazarov79 believes that when making any assessment, the judges are obliged to justify them and leave comments. But abstain may well affect the final result.
Alex Novikov suggests stricter criteria: count only those submissions for which more than half voted, excluding abstain and reject. Ivan approved the idea, but these changes will be appropriate with a large prize pool: “We currently have a contest system not flexible enough to introduce manual vote counting”.
Boris Ivanovsky recalled the importance of the fact that the judges should not have a big difference of opinion, because any contest has its own rules, and they must be followed by all participants who submitted applications.
Marina offered to vote and decide whether everything remains as it is written in the smart contract (if 50+1 reject among those who voted, then the submission is automatically rejected), or it should be changed to Alexey’s proposal — if the submission receives 50+1 pros, then it participates in the prize distribution pool. As a result — the majority for the first option — leave everything as it is.
Should there be a Rejection?
Boris noted that the terms of the contest are also the criteria that affect the assessment. And since all conditions must be satisfied, then there must not be many of them.
Marina agreed that everything must be clearly stated within the contest and all the points of the conditions must be met, and if only one is not met, the submission is rejected. This is a good help for the judges.
Pavel P, as a person who often participated in judging, noted that writing criteria is a great idea: “We have, relatively speaking, mandatory and optional ones. But the fact is that even the mandatory criteria are sometimes formulated broadly enough, this was deliberately done precisely in order to leave people a field for creativity. Therefore, you can write separately the rejection criteria, which the submission can be rejected. This would greatly simplify the work of judges”.
Alex Novikov found an imperfection in this: «We use both Russian and English, but these are not formulas, so the text can have several interpretations.»
After the vote, it was postulated that in this contest it is necessary to prescribe clear terms for the reject.
Natural Selection in the Jury
Ivan, taking the opportunity, announced that there will be a chain of contests on smart contracts: “They aim to educate developers on how to write smart contracts better, and also give them some springboard for creativity to play with. That is, it will be some written piece of code on the basis of which it will be proposed to add something, write, expand, etc. As a result, I suggest adding people with the best solutions to the global judging of smart contracts”.
All voted in favor of such experiments.