Revise the mechanism that detects whether someone is human or not to accommodate for percentages not changing very much (e.g. 9/10 answered wrong and 1 then answered correctly)

[forgetso]

This is basically a recency problem in which increased weight should be assigned to more recent captcha interactions.

In future, the isHuman method could perhaps be stored as a separate contract. The logic of this contract would simply need to fit an interface, with the contract account being passed into Protocol during dapp registration. The dapp would then be free to implement their own logic for the isHuman function or subscribe to some other contract that implemented the interface.

e.g the contracts would be

• Protocol
• Dapp
• DappChecker

The Dapp registers with Protocol, passing the DappChecker account as the checker_contract.

    pub struct Dapp {
        status: GovernanceStatus,
        balance: Balance,
        owner: AccountId,
        min_difficulty: u16,
        client_origin: Hash,
        checker_contract: AccountId // New
    }

checker_contract complies with some interface by implementing each of the functions:

        pub fn dapp_operator_is_human_user(
            &self,
            user: AccountId,
            threshold: u8,
        ) -> Result<bool, Error> {}

        pub fn dapp_operator_last_correct_captcha(
            &self,
            user: AccountId,
        ) -> Result<LastCorrectCaptcha, Error> {}

[forgetso]

Question: Should a log approximation be used? https://planetmath.org/approximationofthelogfunction