SFR Update: Role Based Access Control and Exclusionary Blacklist

I have returned dear flag brethren. It is time for us to continue our crusade against the wily blockchain bandits. It is time to raise our flags

Some may have wondered where I have been with SFR development as I have been somewhat MIA. I'm gearing up to bring things into full swing and have a few updates this round. This update does not focus on our token but we are nearing the final phase of developing the system. I appreciate everybody's patience with me while I adjust to the changes in my life and find the appropriate balace for Steem.

SFR Project Updates

1. AdmiralBot - New Avatar, New App

One day, I noticed that our good pal, the Admiral, was failing to authenticate to Discord. I realized that the application was tied to a former SFR dev contributor who has since deleted their Discord. I had to take action. Ended up recreating the application but didn't stop there. I also put a fresh spin on his avatar image with my glorious patented lens flare technique. _{Ok, it's not patented. I lied.}

Admiral: Arrgh Matey. This isn't even my final form.

I thought the design looked pretty dope but I can imaging further variations in the future. Also, wouldn't be a bad idea to invent a backstory or lore behind the Admiral character.

2. Role Based Access Control

What is RBAC?

Role-based access control (RBAC) restricts network access based on a person's role within an organization and has become one of the main methods for advanced access control.

Source

This was put in place to ensure only users with authorized roles are able to issue certain bot commands. This includes our beneficiary_heal function. This is used to create a 100% benficiary comment for any SFR users that experience flags in retaliation. I was working on a more automated process but this is what we have now. When a SFR mention has been zeroed beyond the ability to counter, we invoke the heal comment. This can then be voted with less reward shares required to reach the minimum payout threshold. This has been helpful in the past to cause abusers to waste their voting power. Just another trick up our sleeves if you will.

Initially, there was a bit of a ordeal with this implementation as we could not figure out why the bot was not recognizing mods and admins. Turns out that I had made an assumption about how Discord works. I had incorrectly thought that right-clicking and selecting "Copy ID" on a mentioned user role would obtain the identifier for that role. It was actually the message ID that I was getting.

The result is my pairings of IDs to roles was completely incorrect except for the founder role. We were scratching our heads for a few moments and even elicited the notorious eye-roll emoji from Hive account@reazuliqbal.

Legend has it that this same emoji has power to cause people to leave discord DM groups.

After fumbling around a bit with the function, I realized my error and finally got it fixed. RBAC is now in full force.

3. Exclusionary Blacklist

This was put in place as a protection mechanism to block approvals from anonymous flag accounts. SFR has a few regular adversaries such as Hive account@atempt and we have suspected this person would create alts for the purposes of gaming SFR votes. This function protects us by adding the user to a database table and performing a check when we batch approve follow on flags.

In addition to this, I have added a watchlist function but that is yet to be tested. What I envision we can do with that is create a separate webhook to keep us aware of operations of these accounts. This will improve overall situational awareness. Expect that to come in the next update.

4. Token testing

I have created the function to distribute our tokens to our users upon post payout. This will occur roughly at a 24 hour interval but may vary slightly. The reason for this is I will be integrating a check into our regular approval function which will track the time since Hive account@sfr-treasury or Hive account@sfr-token-issue has last posted. If the time exceeds 24 hours, the next distribution cycle will kick off. This will eliminate the need to run a separate bot and process to maintain. (Currrently, we have 4 separate Python processes for SFR)

This next phase will involve testing SFR token transfers on the Steem Engine testnet which will generate a post. We have recently added the parent_created column to our database which was necessary so we should be ready to rock and roll.

I hope that is enough to hold you over until we get the token system rolling. Another idea that I am entertaining is created a Flag Radio program. I think we have a lot juicy drama day by day that could make for an interesting program. It'll be like a soap opera for abuse fighters. 😉

With that, I will close this out and switch gears to token testing. Have a great week!

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