The python library aiohivebot project is one of three projects that I have on my current spare-time development list.
It is stuck in the middle in a proof of concept stack that I'm working on.

While the main goal of the stack is to demonstrate piggyback of hash-based signatures on the HIVE blockchain, the idea of making all of the stack usefull beyond that is very appealing.

I recently moved the hash-based signatures part (CoinZdense) from an initial Python based proof of concept of core functionality into a the start of a rewrite in C. I experimented a bit with Rust for a bit, and Rust is great, but language bindings in Rust for important languages like Python are a pain and erase much of the advantages that Rust has over C. While the new libcoinzdense has most of my focus right now, it currently has zero users because I'm not really that far yet.

I don't know how many users aiohivebot has. At least one (apart from me) because I have one user talking to me about features, even if there are no signed operations yet (I need a solid optional-piggybacking API between aiohivebot and the python bindings for libcoinzdense first), that user is already suggesting interesting aditions to aiohivebot.

What makes aiohivebot different ?

The aiohivebot library currently is a Python library for HIVE that unlike the amazing lightweight lighthive by Hive account@emrebeyler or the legacy BEEM by Hive account@holger80 that Hive account@thecrazygm is working on reviving as hive-nectar, isn't meant to be a general purpose HIVE library. Instead it is meant specificly for long running bots and L2 nodes that other than for catch-up purposes after downtime are primaraly chain-event driven. Interaction between an aiohivebot based app and the public API nodes is mostly driven by new events on the chain that are acted upon.

An aiohivebot App doesn't just connect to one public API node, it connects to ALL known public API nodes and periodically tests their avalability, their API round-trip time and error rate. It polls all nodes for the availability of new blocks and processes these. Client operations will go to the top nodes in terms of acceptable error rates and API round-trip speed. There is rate limiting available, either respecting the rate-limiting headers the API nodes provide, or using a client side rate-limit is the node doesn't provide such headers.

This makes aiohivebot Apps a bit more of a load on the HIVE infrastructure than lighthive or hive-nectar scripts and bots. But at the same time it provides a level of robustness that lighthive or hive-nectar will need to implement manualy with their own fail-over strategies. Or at least it will once signing has made aiohivebot usable for more than just monitoring and reporting.

Price feeds, L2s and other chains.

While aiohivebot was initially meant just for HIVE, there are multiple logical extensions to the lib that would combine the HIVE event feed with feeds from other chains and other sources and potentially API calls to other chains.
I myself had Blurt on the radar, but since recently I think I might need to drop it at least a few places. My currently only (known) user requested a price feed, maybe from coingecko or coinmarketcap.

Other feeds with potential matching API clients I'm considering adding are BitShares, Solana and possibly WAX. Other chains may be great aditions too, but I'm not puting any effort into REST or gRPC at the moment, that is for much later, so I'm open to suggestions, but prefarably for chains that use JSON-RPC or simple alternative JSON based API's using a similar philosophy.

Currently aiohivebot has some abstractions for processing L2 custom-json and there is a sub-API for hive-engine available. I haven't yet looked into if there are sub-APIs for other L2s so far. I'm open to requests to add these though, and I'll give them priority. As well if any of them needs a side-chain event stream. Contact me and walk me through the sub-API and I'll put it at the top of my todo list.

Renaming ?

When I add the price feed options there will still be no need to change the project name, but once I start adding alternate chains such as Blurt, Solana or BitShares, the name aiohivebot will become a bit of a misnomer. My first thought was to replace hive with web3, or w3 so renaming the project to either aioweb3bot or aiow3bot. But then I was thinking, while the prime usecase is for bots, the potential of the lib, especialy after completing the API between the library and the Python language bindings for libcoinzdense and adding other event sources will exceed that of mere bots. That API will also need to contain hooks to part of the Wen3 layer of CoinZdense. Notem WeN3 not WeB3. The "Web 3.0 ENtropy layer for subkey least authority and for treating entropy as an exaustable master seed derived resource.

Keeping Web 3.0 and Wen3 ambiguous in this matter, the new name I'm currently considering is the short name aiow3.

Blurt spam

Untill recently Blurt was at the top of my list due to it's shared STEEM history with HIVE. I'm not going to support STEEM for obvious reasons. Sun Juchen is a vilain and I'm not going to either support STEEM or Tron or any other chain he is affiliated with, but until recently Blurt seemed like a friendly smaller brother to HIVE. But then Hive account@blrtannouncement came in and started mass tagging everyone and their little sister for some post about how great it is that Blurt doesn't have downvotes. IMHO mass tagging is exactly the spammy type of behaviour that makes that HIVE needs downvotes.

I'm not sure if Hive account@blrtannouncement is just a rogue Blurt user who is a bit misguided in his attempts to promote Blurt here, or if he is representative of the Blurt ecosystem, but this incident doesn't exactly want to spent my limited spare time into supporting Blurt. I'm not dismissing Blurt support completely, but I'm moving it to the very bottom of my list.

Prioritizing; feedback needed

Given that right now my whole (known) userbase exists of two people and I am one of them, my choices of expanding the event sources and sub-APIs are relatively arbitrary. Because of that I want to call out to potential users to help me prioritize. What do you consider the most usefull? What L2 and/or side-chain events and sub-API should I support? What price-feed APIs? What non-HIVE Web 3.0 chains would you like to see supported (JSON-RPC will get priority for now). Any input is welcome right now. It's not my main focus right now, but I need to get back to adding event sources and sub APIs to keep my feel with Python and the only part of my stack that has a (one) prospect user right now experimenting with what I have so far. It's all early stuff untill the coinZdense API makes it clear whow I should add signing, but all input is highly welcome. I want to make the whole stack as usefull as I possibly can.