But how would this affect the client, the initiator of the update call that made the http outcall? Would they get an optimistic response, and then a verified response?
Effectively yes. The way I would want it done is that you get an unsecure response and then at some later time wait/look at the result of a promise to confirm that consensus validated the unsecure response and it effectively becomes secure. This is done at a later time, normally before an action relies on the response, so you are never acting on unsecure information, just choosing to display it potentially (unlikely).
I dont know enough about the IC to comment on the rest so leave that to others, but this idea would work best if it was built into how the IC worked, but you could hack it up with the Non replicated HTTPS outcalls:
You send a non-replicated call along with a normal HTTP call asynchronously. You use the non replicated call output and run it through the same transformers as the standard calls, when you need a response quick but rely on the normal call when you need security. You would need a way to tie the two responses together but that doesn’t seem too hard, the real unknown would be getting the outputs from both calls to diff in a way that tells you consensus failed and it wasn’t a timing issue between the proxy and the IC nodes.
This can solve the speed issue but actually makes the http calls more expensive since you do 2 requests at a high level. I believe this could be solved eloquently if built into the IC