@we-are charity bot progress

This post is a brief update about the Hive account@we-are bot system, current progress and plans for the future. For those that have no idea with Hive account@we-are is about, I'll start with a brief introduction.

(Source: Pixabay / cegoh CC0)

STATUS: Currently upvoting 374 unique users with 24 voting accounts that collectively control over 10000 SP. Closed invite-only trial mode.

What is Hive account@we-are?

The Hive account@we-are bot is a community based free upvote bot service. The philosophy is that communities the coal face method to nurture new users and improve social stickability. If you're a lone wolf then Hive account@we-are is not for you: check out Hive account@steembasicincome instead.
It will allow communities to access voting power without having to set up any technical infrastructure. There will be simple steem memo based system for managing memberships. Community levels will be expected to ensure the posting quality of their members and to remediate, rehabilitate or eject members that are posting poor quality work.
Donors can target their SP-delegations at a level of granularity that suits their policies. There will eventually be reporting on the effectiveness of their donations.

What's implemented right now?

The core feature, automated upvoting of posts by members from communities, is working. The voting accounts arrange themselves in a flexible manner so that many communities are served by more than one voting account. For example, Nigeria communities are upvoted by Hive account@we-are-nigeria, Hive account@we-are-africa, Hive account@we-are and Hive account@we-are-one.
The voting account Hive account@we-are-community exclusively upvotes posts made by admins of communities that are on Hive account@we-are.
The Hive account@we-are-lucky account gives a 100% upvote to a single random post made by a Hive account@we-are member whenever Hive account@we-are-lucky has spare SP. Hive account@we-are-lucky has 5000SP

How can I/my community join?

Hive account@we-are is in a closed trial. So, we are not accepting new applicants at this time. However, if you are meet ALL of the following criteria:

1. At least twenty active community members
2. Community admin accounts are in good standing
3. Will provide at least 1000SP (either by delegation or POSTING keys)
4. Are willing to accept reasonable instability etc that is inherent to a closed beta trial.

then I will consider adding your community to the trial. Contact me on discord.

State of the Union

I originally paid a programmer to create the first version of this bot. His model worked very well and I consider the money well spent, however it relied on a Steem Database service. I spent the first few weeks changing the system to work with the steem blockchain instead. This version only supported a single voting account and all config was in a JSON file.

My first version of the bot would check every voting account every seventeen or so minutes, and then, for each voting account go and fetch the most recent posts for each Hive account@we-are member that was eligible for upvotes from the voting account. This would quickly lead to scaling problems such as API nodes that would, quite justifiably, rate limit the bot. I expended a lot of energy trying to locally cache data and to retry API operations. The steemjs library is also not very fault tolerant.
The bot was originally coded with a "philosophy" of javascript that, while still valid, was a bit outdated. My own additions used a different philosophy until I decide we should migrate the code, gradually, towards using a Promise() based philosophy. That meant the code base was horrible. The config was also placed into an SQLite database too.

It became clear that I needed to rebuild the bot from the group up to use a more scalable architecture. I changed to using dsteem instead of steemjs and found it much easier to follow. The SQLite config database is retained. The most significant architectural change is to streaming the whole blockchain, filtering the stream for events (e.g. posts) and then passing these off to be voted upon. This is much more scalable than continually polling for data about members that might have gone inactive. The bot is quite resilient because it persists crucial data to LevelDB.

Right now, the new bot is not quite the full functionality of the old bot. However, with the new architecture, it is much easier to add on new features.

The main thing is that I expect to be able to gradually expand the use of the bot (see terms above) to test its scalability. The next significant set of features I will work on are:

• Transfer memo based API for adding/removing members
• Alternative voting policies, especially a vote follower for communities with active curators.
• Enforcement of upvoting a maximum of 1 post and 10 comments per day
• Enforcement of community tags - posts must be tagged to their communities

I don't have timelines for these changes. I will fit them around my work schedule.

Thanks for your patience.
-- Hive account@eturnerx [Hive account@we-are founder]