Repository
Details
Asyncsteem and Beem are currently two independent and incompatible Python RPC libraries for communicating with STEEM API nodes. Beem provides a purely synchronous/blocking API that includes signed operations whereas asyncsteem provides an asynchronous /non-blocking but currently comes without support for signed operations.
Rather than reinvent the wheel with respect to signed operations, it is desirable to find a way in which to use the signing part of Beem with the asynchronous RPC part of asyncsteem in a way that doesn't depend on any blocking IO. Given the way signing works signing depends on RPC primitives that in Beem currently are both blocking and synchronous, something that for integration into asyncsteem is a show stopper.
There is also an alternative blocking Python lib with signing support, Lightsteem that is worth considering.
The task at hand is both complex and simple. Complex in the way that Asyncsteem RPC and Beem or Lightsteem signing need to be made to work together. Simple in the way that this task does not include having to worry about how to best eventually integrate this into the asyncsteem library and possibly the Beem or Lightsteem library, or how to allow different types of signed operations. Just pick one type of signed operation. Voting is fine, transferring 0.001 STEEM or 0.001 SBD to @null is fine also, pick what is most convenient and write a proof of concept asyncsteem Python script that does a nonblocking asynchronous signed operation within the context of handling an asynchronous event. The proof of concept script should use asynchonous nonblocking asyncsteem RPC primitives together with Beem or Lightsteem signing primitives in a way that introduces no inadvertently blocking operations itself other than potentially the blocking introduced by CPU performing the signing operation. No IO based blocking.
Components
The task may influence all components of asyncsteem if needed for completing the proof of concept. The changes to the library needed to complete the proof of concept should go in a separate pull request from the proof of concept script and should use a new topic branch. The proof of concept script should go under its own subdirectory under sample_code and can be offered in a pull request against the master.
Deadline
There are two deadlines.
- If the task is completed before the 8th of October 0:00 AOE time, @mattockfs has placed a bounty of 34 STEEM on this task.
- Separate from the above deadline, if the task isn't completed by someone before the 20th of October 0:00 AOE time, then Beem/Lightsteem compatibility will get abandoned and @mattockfs will start on reinventing the wheel on this point.
Communication
Please comment on this post if there is anything unclear about the above. Note that I tried to define this task in a way that leaves a lot of freedom. I'll figure out how to best make things fit in. The big question now is, can it fit in. So you have quite a bit of freedom in how you wish to show that it can. If discussion below starts going a few levels deep, we could move things to Discord, but lets use the comments section of this post first.
Github
Sometimes it's okay to reinvent the wheel. After all there's a reason you're not driving around with wooden wagon wheels on your modern car.
Interesting though, If I have time I might try and solve it.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
You have a minor grammatical mistake in the following sentence:
It should be its own instead of it's own.Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit