This is something that I had dealt with a couple weeks or so ago but haven't had the time to properly document. One of my responsibilities 'round here is to maintain our Flag Approval Discord bot and I'm used to restarting it every now and again. The is likely due to our bot's reliance on a somewhat antiquated version of the @rapptz Discord.Py API Wrapper with the metadata as follows:

Metadata-Version: 2.1
Name: discord.py
Version: 1.0.0a1584+g1da6962
Summary: A python wrapper for the Discord API
Home-page: https://github.com/Rapptz/discord.py

---

Unfortunately, this was not just a routine bot restart. Something was wrong. Seriously wrong...

        We would go through the motions as usual. Log in, plug in the environmental variables, and run the Python script... but the bot would be lucky to stay online for an hour or so before crashing. After some digging, I came across the following article which seemed to be the exact same circumstances that we found ourselves.

Reacting with emotes causes bot to crash

The recommended fix was simple enough, right?

Oh, if only things were that simple...

     Remember when I said our bot is reliant on the older version of the API wrapper. This means that upgrade would be a no-go unless we could resolve the compatibility issues. I tried crossing that bridge before and I was not able to make everything jive. This was back when we migrated to @themarkymark's host and I had attempted getting the bot to work with the latest which I would chalk up as a failure.

    The emojis were indeed rising up against SFR. All it took was one of those animated bois to come up and our bot was brought to it's knees. Of all the challenges we face, would be mighty ironic for us to be taken out by a emoji.

BOLO! Prime suspects are a Blue Hedgehog and an Rotating Coin! Considered armed and dangerous!
_{The funny thing is I did not intend to have the ::rip:: emoji visible which is apt for this situation whether our bot facing the existential crisis of its time.}

Anyways, I Decided a Bit of Creative Problem Solving Was in Order

     Essentially, I isolated the emoji fix from the updated Rapptz wrapper, downloaded a dependent script, and patched the animated emoji references. It was a "quick and dirty" fix but it got the job done.

We were back in business!

I'm sure the token manipulators were thrilled that we would continue to be a thorn in their side. /s

     The next step was updating our Github. Note, we are working from a different branch and not entirely sure if we should start a new repo for the token system or just merge and forget the previous version existed. I don't know but, in the spirit of open source, maybe it is good to keep those major versions distinct. Perhaps, some wouldn't desire the Steem-Engine dependency. Maybe some want instant gratification with comment upvotes and follow-on flags. Whatever floats your boat. 🛥️

     Unfortunately, much work had been done in the interim from the last commit so things were not exactly meticulously tracked. The delegation tracking was a noteworthy achievement as it saves a lot of time and less utilization of public RPC nodes is a good thing but I also made adjustments to our ROI and max token dispersal per flag to help us keep up.

• Pull Request 1

• Pull Request 2

     On the Return on Investment change, I suppose a ToS (Terms of Service) would be in order for those sort of things. I can either find a tech writer up to the task or allocate some time to spin something up. Let's just say the ROI is fluid and subject to needs of the chain. Yes, I know we try to be decentralized and all but sometimes judgment calls are needed and that's what was done.

     Right now, I think it's important to pay more distinct users for more eyes on the chain to improve situational awareness. One user even if they are a whale unfortunately has only one set of eyes. Imagine if you would in a hypothetical universe where @blocktrades was an SFR user and we did not institute a max payout on flags. We could potentially be paying out a single one of his flags for at least a month are our current SP level.

     Even if we gained additional capability to remove rewards, we would likely lose the coverage that attention provided by multiple humans working in tandem to locate spam, plag., bid bot misuse and other forms of token manipulation that occur on chain. I asked our admins if it was a good idea to institute a cap and they concurred.

     The current cap is the same as the bots full upvote value in SBD (About 0.85 per flag). This will hopefully lend to payments being diversified among multiple sets of eyes and keep lower tier stakeholders motivated to continue providing valuable coverage.

     With that, I'll close this update knowing that I have plenty more that needs to be done. Maybe dig up our SPS proposal draft. I've been considering strategy for a successful campaign and @howo did offer to help out with the proofread. The admins have been doing an excellent job in spite of my more sporadic activity here as of late and hope we together, not just SFR but the broader Steem community that we serve would see fit that they should be rewarded for that time.

     That's all I got for now. Hope everybody is enjoying their holiday time and doing something to make it meaningful.

And cue the SFR project ad. Thanks for checking out my post!

---

Would you like to delegate to the Steem Flag Rewards project and promote decentralized moderation?

_{It's much more fashionable than self-voting.}

Here are some handy delegation links!

50 SP 100 SP 500 SP 1000 SP

Also, here is my SteemAuto fanbase link if you believe what I do adds value to the chain consistently and would like to support it likewise.