Design of my Follow/Unfollow Service

in #bots7 years ago

After seeing the numeric success of those who have follower bots, I decided I would write my own.

There is a new pysteem-API (0.18.3) which I have just updated Steemfiles to work with. There is steem-js which runs entirely in the user's browser. With one or both of these I knew I could do a little bot.

Robot Drawing Source Pixabay

So in this post, I offered the bot to anyone who would vote said post up. Now that seven days have past, and the bot is nearly finished. It is too late for those reading this now to vote that post up but those that did will be able to use this bot.

The first thing I did was read the docs. A programmer should only need to read the docs of the APIs to be used. The phrase "use the source Luke" is a cute way of saying that the authors of said APIs left the easiest but the most important part out. With a well worded spec, you can write the implementation, but the implementation might not give you the intended spec.

Now, if I had not having read the docs before starting, I might have attempted to run a for-loop of follow routine calls. I looked at TransactionBuilder class in pySteem. With this you can follow 100 people in a single transaction. The nice thing about this, is if one fail, they all do. The database can rollback and no changes are made. If you use a for loop, a failure of one might give you 23 follows and you'll need to handle that exception.

Now, the user can get a CGI-script where they follow and sign with their key. The key has to go to the server. Now what about an automatic unfollow? Either the user has to come backand enter his key again to create an unfollow transaction or the key of the user must be stored in a database.

Disgusted Man source Pixabay

Either of these solutions is just horrible. What if we create a transaction for unfollow at the same time the user does the follow transaction? This means that the key need not be stored and the user need not come back! Excellent.

Ideally, a copy of users' keys should be used and destroyed. It's a moral hazard to store keys, and so that's avoided but can we improve things a bit more by keeping the keys in the browser? Of course! This is what Steemit does. Now, I am putting the steem-js API to do the signing after the pysteem API creates the mass transactions. The javascript code makes a byte vector whereas the pysteem code makes strings. It is possible the conversion method is just an easy ASCII encoding but I am yet to try that out.

The software is hard on my develoment machine. The script takes a much longer time than I would have expected. Creating the transactions takes a full minute! I may decide to make this a lottery system or charge micropayments.