Yes, you can do that, but those post may actually use bid bots.
I plan on creating lists within this blog that will update automatically and sub sort by category, for example life, crypto, introduceyourself, etc.
Later, some of this might move to an off site server to create a richer user experience, with the links bringing them right back to Steemit.
Sounds good.
I have a feeling that the up and coming (where is it?!) communities will 'guard' against posts voted by Bid-bots.
There will need to be either a list of Bots, or the communities will be closed - I guess managing a Bot list might be easier.
Then you've got the issue of Pay for vote services, where someone has delegated their SP to MB or SS, etc.
What I was doing here - section 3, was taking a look at Transfers, and anyone receiving a delegation payout was part of the 'other bots'.
And then you've got the behind the scenes vote buying - probably the trickiest of the lot to solve.
Early days though!
Yes, these are all valid concerns and I am aware of all of them. Each of them will need to be addressed via community feedback as much as anything.
Systematic voting from repeat accounts is easy to spot and can be indicated.
Delegations from or too a bot will probably not be considered since it in no way changes the voting on the particular post that is being judged worthy or not of being on the nobidbot list. We will need to judge the post, not the author.
Vote buying via off site communications will be all but impossible to address fully, (yet patterns do develop) but if they make a transfer via ANY wallet with the post url in the memo, it will be seen.
I do of course have a list of all bots that I update routinely.
I am using steemSQL to do all the queries so that i do not strain the blockchain. I do all the programming in SteemJ.
Are you interested in providing any programming input?
Yes I agree. This was related to a user transferring to SS or MB and receiving a vote back from a 'normal' account, my previous sentence wasn't so clear. :)
I use SteemSQL for my work, but have no SteemJ experience.
Possible, but very unlikely, as it is a high risk that it'll be downvoted out of the tag. It's one thing when they do it on global trending, when the community is split on its usage, and an entirely different matter when they invade a community tag where everyone watching is opposed :)
I have a feeling it will work as is and we'd maintain it. Also I prefer the steemit frontend, but that's just my personal taste hehe...
Okay, cool. That answers my question. In the meantime, we still need to be discerning about what might show up under the nobidbot tag, and then when their ready, go through the blog lists. Can't wait. No pressure or anything. :)
Yea, no pressure!! I had no idea my little pre-announcement would garner so much attention.
So just to take a little pressure off. The first releases will be boring and less than perfect.
There, some of the pressure is off :)
I'd say the idea of a front-end +- identical to steemit but with an added"no bid bots allowed" mention, and showing posts according to this new metric (aka., no bidbots) an interesting idea.
there could even be an added "bidbot addicts" tab that showed the posts having used the most bidbots XD
Yes, I am actually looking at that but it would be down the road. It would have to be hosted on an offsite server that created the UI, but then directed people back to steemit for posting and wallet transfers etc.
Perhaps one of the younger more talented programmers will take up this mission and run with that. It would be VERY profitable to anyone that put it together fully.
I think the main part of the project would be the filtering of information under the different tabs/tags, AKA., through an integration with whatever system you've got up that filters posts depending on bidbots.
The UI itself would be a complete clone of Busy or Steemit, given the websites are open source.
That would really be awesome to have such a front end. I hope you go forward with it.
It would make the #nobidbot tag unnecessary (other than as a statement by the author), since the front end could easily filter out boosted posts and put them in their own tab.