This is the first time I've noticed this project. I'll soon be looking at your repo to see if there is anything to learn from it. I'm interested to learn what made you choose to fork BEEM rather than starting from scratch or from something less bloated and a bit more suitable for integrated usage like lihghive.

When diving back into HIVE python code (I wrote the asyncsteem lib back in the early days) I looked at my old (Python 2) code, BEEM and lighthive, and after dismissing BEEM I gave lighthive a long thought and try before ending up starting from scratch myself. My own efforts are less general purpose ( aiohivebot ), and delayed because my main project (that I aim to incorporate) is about piggybagging (and eventualy integrating) hash based signatures, so quite a long way from usable, also because I'm not adding signing untill I can complete my stack and add both eliptic curve and hash based signatures at the same time.

So basicly my old python 2 code was too outdated (it was pure python 2, used twisted and used unthrottled communication with the nodes), beem was too synchonous, too bloated, using virtualy zero runtime python features that could make the codebase much leaner and massive the TDD focus felt just too much like an overengineered school project for what I felt should be a lean and mean lib. Lighthive was very good, with some async code under the hood, but my ideas about redundant multi-API-node async design just were too far from @emrebeyler's vission to try and fit it in.

I personaly considered BEEM a deadend road, lighthive a good general purpose replacement, and my own effort (eventualy) a specialized alternative for bots and L2 solutions unsuitable for commandline tools.

I would be interested to learn why you chose to fork from beem and not @emrebeyler's lighthive?