Hello, My Flaggy fellows fighting abuse on the Steem blockchain!
Repository
https://github.com/anthonyadavisii/steemflagrewards
We try our best to be and equal opportunity flag reward service. That means we try our best to reward meaningful tracking / downvoting of abuse from lil stake to BIG stake.
We want to encourage everyone while optimizing the Steem Power. To be good stewards of our bot's delegated SP, we must make smart decision.
Our greatest shortfall is decisive support in terms of Steem Power. We are very thankful for the delegators of our existing 14k SP but we could use a lot more help to reward as many legitimate flags as possible. We make a difference everyday with the stake allotted and desire to do more. If you are frustrated seeing the prevalent abuses on the platform, this is YOUR fight.
We may reach a point in which we give priority to delegating flaggers to be fair. I like to consider us a team so believe it is critical that we support or bot which, in turn, supports one another.
By delegating to the SFR bot, we invest not only in the health of the platform but also in own our stake. That's the way it should be. We'll discuss that more but let's get back to the topic of dust.
What is the challenge in regard to dust downvotes?
The minimum payout threshold. You can see the code for yourself on Github.
#define STEEM_MIN_PAYOUT_SBD (asset(20,SBD_SYMBOL))
Simply put, if your comment or post is not worth 0.02 SBD or above, no payout for you!
Rewards Nazi don't play!
The goal is for every @steemflagrewards bot comment to exceed minimum payout of 0.02 SBD. This allows the SFR account to grow via curation rewards. This is especially important with the occurrence of retaliatory flags from abusers.
It is ideal to be well above this threshold in that case. Even so, we have given near dust voters a little bit of wiggle room to accomodate fluctuating vote values. Below is the code we use to evaluate dust. Note that this value will be moved to the config file in future updates to facilitate ease of adjusting.
if stm.rshares_to_sbd(abs(int(v['rshares']))) < 0.0195:
dust = True
This modified the approve function to bypass upvoting the mentions below the threshold. It's still tracked for the regular 8 Flagger beneficiary reward posts. Still yet, I wanted to do more for these brave dust flaggers as I value them especially in numbers. You never know when it could be a dust vote that brings an abuse post below payout so they matter.
What did I do about that?
Our reports are currently set up to rewards quantity of flags. It doesn't matter if you are a 10,000 SP flagger or a 500 SP flagger. Rather, we use the number of abuse posts the user has reviewed and flagged for beneficiary weight.
I figured we are able to make up for the lack of votes on dust flags by giving an extra count for the beneficiary posts. It's far from perfect especially considering the variability of @steemflagrewards post payouts. Still yet, I hope it will encourage lower SP users to participate in community moderation.
It took me a bit of finessing the Structured Query Language code but I finally figured it out. The code is below. I'd be happy to provide a copy of our sqlite DB if anybody believes they can improve it. I am always open to suggestions and how I can learn from other coders on the platform.
benlist = []
flags = []
#queries flags exceeding minimum payout
payoutflags = cursor.execute(
'SELECT flagger FROM steemflagrewards WHERE included == 0 AND flagger IN flaggers')
for q in payoutflags.fetchall():
flags.append(str(q).split('\'')[1])#extracts username from tuple
#queries flags below dust threshold
dustflags = cursor.execute(
'SELECT flagger FROM steemflagrewards WHERE (included == 0 AND dust == 1) AND flagger IN flaggers')
for q in dustflags.fetchall():
flags.append(str(q).split('\'')[1])#extracts username from tuple
flaggers = set(flags)
for flagger in flaggers:
benlist.append({'account': flagger, 'weight': int(flags.count(flagger)/len(flags)*9500)})
benlist= sorted(benlist, key=lambda k: k['account'],reverse=False)
We had been running from a couple of sophisticated queries created by @flugschwein. Problem was that I was having a hard time understanding them. It makes sense to offload the logic to our Python interpreter which I am more capable of adjusting. I have acquired a bit of SQL knowledge in my professional career but it's pretty basic. It is obvious that, if I will be committing my time and energy to maintaining the bot, need to make it as easy as possible. Trying to understand nested SELECT statements makes my head spin a little.
me_irl
This is the one we were using for the flagger posts previously:
'''SELECT flagger, COUNT(*) * 95 * 10 / (SELECT COUNT(*) FROM steemflagrewards WHERE included == 0 AND
flagger IN flaggers) FROM steemflagrewards WHERE flagger in flaggers AND included == 0 GROUP BY flagger ORDER
BY flagger;''')
This is the query I had attempted for the dust votes and then divide by 2 to get the actual beneficiary weight. It seemed to have worked but with a margin of error. The new code is a bit more slim and the last post checks out with the dust beneficiary rewards.
For example, see the following for beneficiary rewards on this post
@noblebot, our friendly neighborhood dust flagger coded by @reazuliqbal, sent 6 flags, whereas @freebornangel, a more heavy hitting flagger above the min. payout value, sent 9 flags. As you can see, @noblebot's beneficiary weight is greater by 483 so this means that they will get a bigger slice of the pie on the flagger post which is nice.
This tends to be my silver lining go-to meme
You never know when that dust downvote will be the proverbial straw that breaks the camel's back. It is my belief that Steem as a community will benefit supporting these flagger posts. For example, they aid in the development of flag support bots such as this.. Hope you will take this as food for thought if you are not already a supporter.
