Querying the reputation miners for reputation states

Assuming I am using the dapp (and maybe the developer portal), wondering where I can get each of the variables needed to query for a user’s reputation state?

1 Like

You can get the reputationState with the getReputationRootHash method:

We made this easier for users in colonyJS with the getReputation method:

1 Like

If you are not using colonyJS and the getReputation method, you will need to get the reputationState (ie, reputationHash) using the getReputationRootHash method mentioned above, and you will need the colonyAddress, skillId and userAddress.

The developer portal dashboard shows your reputation on the “Account” page using the colony address of the developers colony and the skillId of the root domain for the developers colony.

1 Like

The skillId of the root domain is not displayed anywhere in the dApp or the developer portal but you can get the skillId for any domain using the getDomain method:

1 Like

I’m trying the approach in mainnet with the following script:

const { getNetworkClient } = require('@colony/colony-js-client');
const { open } = require('@colony/purser-software');
(async () => {
  const wallet = await open({
    privateKey: "0x0000000000000000000000000000000000000000000000000000000000000001",
  const networkClient = await getNetworkClient('mainnet', wallet);
  const repHash = await networkClient.getReputationRootHash.call();
  console.log('repHash:', repHash);
})().then(() => process.exit()).catch(error => console.error(error));

The script returns 0xdf32626d1f933a177f6a9431ff085b96561cc5da7240baccc4ef3897646f5553 as current root hash.

Using that root hash i’m querying my account as follows:


=> {"message":"Requested reputation does not exist or invalid request"}


1 Like

I’ve done the same thing a month ago with another root hash, and it worked well:


1 Like

Hi @johba, Daniel from the smart contracts team here. We’re taking a look and will let you know what we find :slight_smile:

Hey @johba, do you remember when you queried the reputation hash 0x09bcd7ba43000d19b2609ad8f0dff41b63b20e8dd223a172e0f476bb16ca30a9? I ask because when I look at the “current” reputation state (see here) it shows that hash as the most recent, which seems incorrect.

yeah, it is from Oct 30., here a screenshot from slack:

1 Like

Thanks! Looking at Etherscan, the hashes are continuing to be updated (see the last event here), so it might be something with the miner’s local storage, since the hashes the day before and after your problematic hash are also not working.

Here’s the transaction which set the working hash (on Oct 19, as it happens).

Perhaps unsurprisingly, the hash from the day before (Oct 18) also works, while the one from the day after (Oct 20) does not.

If I had to guess, I’d say something went wonky with the miner’s local state on Oct 20th, since it seems not to have kept track of reputation changes since then (although it continues to submit new reputation hashes, which appear to be correct since the number of reputation leaves continues to increase). I’ll talk to my colleague who wrote most of the reputation miner and see if he has any insight.

I’m the colleague @krono referred to in the above.

The queries you were trying to do work now, but the underlying issue has not been fixed. I hope to have this properly fixed later this week (perhaps as early as tomorrow…), and will update once I’ve done so. If you’re interested in how we got here, read on…

The reputation miner and the oracle used to be the same process, but out of a sense of caution I refactored the code so that two instances could be run, where the oracle (with ports exposed to the internet) did not have the private key for the miner in memory (required to automatically update the reputation state and eventually challenge incorrect updates). It seems that during that process I didn’t quite separate ‘updating the reputation state’ and ‘submitting new reputation states’ correctly, and so the oracle has not been successfully following new updates.

For now, I’ve manually copied across the database the oracle uses from the one the miner uses, but this will once again become out of date once the next reputation cycle completes.

1 Like

cool, thx for the explanation @area :pray:

once the fix is deployed, will all reputation be included? or will we need to re-run some of the payouts that we did since October 20th in the team?

All reputation will be included. As far as I can tell, the miner has been operating correctly, it’s just that the oracle hasn’t been following the updates.

1 Like

cool, i visualized the reputation distribution in the team, and compared our previous gdocs-based reputation calculation with the colony reputation that we are recording since a month or 2. they match pretty well:

want to see more details? join #00_leap_dao on slack.

1 Like

Glad to see that. I would not expect an exact match, unless you are taking reputation decay into account with your local accounting?

no decay, rather we were doing a simple sliding window over last 3 month. thanks again for all the help in this thread :bowing_man:

1 Like

I am now hopeful the issue around the oracle following the miner has now been resolved. Sorry it took it long - we were caught short (my fault) by the Istanbul hard fork which delayed this work.

1 Like