Http-loopback is a Motoko package that allows canisters to submit call requests to other canisters using the Http Outcalls and Threshold ECDSA capabilities of the Internet Computer.
Github Repository
MOPS
This package takes a lot of inspiration from the IC-PY Python Agent from Rocklabs.
Why create a Motoko Agent?
I created this package because I want to use canister-controlled neurons to help fund developers and incentivize them to participate in governance. NNS neuron stake requests can only be submitted by self-authenticating principals. Canisters can’t submit requests directly to the IC’s HTTP Gateway so a combination of tECDSA and Http Outcalls needs to be used to submit a self-authenticating request.
Is it safe to use?
Probably not. I just got everything working with a very basic query and update call. While i’m pretty confident this means it should work for any call i haven’t stress-tested anything. If you do choose to use this package please be careful and do your own tests tailored to your scenario.
Shout Out
I want to say thank you to @Gekctek @skilesare @timo and ICDevs for funding and developing the motoko packages that made it possible for me to develop this library.
Feedback
I am open to feedback and questions. I want this to be useful for more developers than myself. If you’d like to communicate outside of the forums you can email me at bittoko@proton.me.
12 Likes
I was asked today what I think it would take to consider this safe to use and my honest answer is “I’m not sure”.
One obvious problem is that I am not currently verifying the signature on response certificates.
As I said in my post everything else seems to work fine. I’ve successfully submitted Call Requests and Read_State requests from a Motoko canister using this library. My test canister code is in the “test” directory if you want to see how I set that up.
The fact that the IC accepted my request tells me that the request envelope is being constructed and signed properly. The fact that I can then read the state of that request and extract the candid response tells me that my transformation function is working, I am correctly hashing the message to form the request_id, and that I am parsing the Certificate tree correctly.
If anyone has thoughts on suitable test cases I would appreciate that feedback.
Thanks!
Pretty cool stuff, can you describe how the read_state endpoint works here?
I’m not sure I understand the question entirely. Are you asking me to explain how the IC’s read_state endpoint works, or are you asking about the http-loopback client’s read_state_endpoint() method?
Ye essentially both of those questions you mentioned. I was more curious about how it was implemented here and I found it in the code, So does the update_method have two post requests via http outcalls (one to send the envelope another to read response)?
I’m just thinking it sounds expensive (if i’m correct), I wonder if it’s worth only reading the state if you want to - maybe via an argument in the update_method function.
Anyway, I have built something pretty similar via Motoko, but I haven’t implemented the read_state endpoint yet and I’m thinking about the best way to go about it.
It has, at a minimum, two requests. Since the IC only guarantees an eventual response it will continue issuing post requests to read_state until the request results in a reply, a reject, or an expiration.
I think there’s certainly room to tailor this for your needs. In my case I need the returned NueronID and I also like to know if the request was rejected or failed for some reason. But if you want to skip the read_state request you could create a modified agent using the Client class.
1 Like