Yep, one of the design decisions is the “reverse gas” model which allows keeping the barriers for dapp users low. (Btw. I think you wanted to say caller instead of callee in the inter-canister call example).
I think something like ic0.accept_message would be also useful for inter-canister calls because the callee still pays for the execution of its own code. Hence, you still need a mechanism to guard against DoS/cycle draining from another canister.
We’d LOVE to have that in the docs, but we don’t want to rob you of an opportunity for a great blog post. @gabe, how would you like to do it? My personal favourite option would be to have it as a blog post on your own site, and then re-publish it on the docs page with very obvious credits and links back to the original.
I’d also love to see it in the docs and I think your suggestion sounds perfect! I’ll try to have a blog post ready within a week or so and make an update here once it’s ready.
Thought I’d share some interesting findings of my very rough calculations regarding the messaging protocol that I’m building. This estimate does not include costs for update instructions executed and assumes that a 100 kB message stored takes up exactly 100 kB of stable memory, i.e ignores data structures, etc.
Assuming worst-case where every message is the current maximum of 100 kB each, the estimated cost is:
$300 to send… (one ingress message per message sent), and
$540 for one year storage of…
…not one, not one thousand, but one million messages completely on-chain.
@gabe, awesome! This is a great collection of cycles-related information, I am also very much looking forward to the blog post and seeing this in the docs!