I don’t think that’s him.
Just want to chime in that once Enable canisters to make HTTP(S) requests is implemented, one can use it to call read_state end point on IC itself. Not exactly a satisfying solution, but will be possible.
1 Like
1 Like
If a piece of private state is only meant to be read by controllers, then the security of a call must ensure that the caller is genuine, not just that the result is certified. But of course this is more of a question about how non-replicated query call is going to work.
That’s a fantastic idea. Certifying data is a huge pain and doesn’t scale well. The only way out of this misery is automation.
Amen. I wrote two async runtimes for Rust canisters, and I still hate all things async passionately. State machines is the only true way to specify and build distributed software.
Also, I wish I learned about TLA+ 3 years ago 
4 Likes
What is the current status of this? Has it been deployed or is it still in the design or implementation phase? Thanks.
I wanted to follow up if the read_state query function (callable by both canisters and external users) will launch soon. Thanks!
Hi @jzxchiang, this has not really been moved further than discussions about what an MVP solution would look like, so I wouldn’t expect it to launch soon.
Hey all,
Very very very late to the game here and only just seeing how useful this proposal is. ic-spec is an intimidating document!
Did we ever end up somewhere here? I know we have outbound HTTP requests so… technically… this is possible. But, I think being able to verify the /canister/<canister_id>/* would solve a ton of composability issues we struggled with building quark.
1 Like