Are there any plans on getting access to query logs? I would imagine there must be some logs somewhere on what queries are being made, either on the replicas themselves or on the entry nodes / icproxy nodes. Are there any plans on exposing that somehow to the canister owners?
The first use case would be getting insights into how an app is used (but this could be solved with 3rd party analytics in the client front-end, but it’s ugly and feels icky).
The second, more interesting use case would allow game sessions based on just two updates - start the round, and finish the round. My thinking goes along the lines: create a series of secrets/seeds on the canister. The client sends update_start_game(), and receives a seed. It goes through the level generated by that seed, and kills mobs / whatever. Whenever it needs to make a “decision” it sends a query_next_seed(), based on the “decision” they took. Thus at the end of the game the client can send an update_end_game(vec [decisions_took]) and the canister, provided the query logs, could verify that said client did in fact make those - and only those - query requests.
I would be ok with this being an async call to an on-chain API or something along those lines (so it doesn’t get abused for state changing based on GET calls - a terrible practice). And it would obviously not be secure enough to be used for sensitive apps, just simple games & inconsequential stuff. Would something like this eventually be possible? Is it even on someone’s radar?
Right, I’m asking if there’s any plans regarding query calls specifically. I understand there are good reasons for which they can’t update state, and that’s fine; I also think it would be useful to be able to “request” (just so I don’t use query and confuse things) your own canister’s logs, as this would allow for use of the query calls as “witnesses” or something like that.
This might interested you. It’s not exactly what you’re asking for but it might achieve the same thing. This discussion is in the context of HTTP requests.
This seems interesting. It would allow for fast “choice making” in the game, (i.e. the client doesn’t have to wait for an update, it will get the next seed in ~100ms, but the system would still track the use of queries, and be able to detect multiple requests for multiple choices).
This would not, however, optimize the cost of launching a “game instance/dungeon/etc”. In the end, the “cost” of one “choice” would be 1 query + 1 update. An interesting tradeoff, and it might work in some cases. Thank you for linking that, I’ll put that thread on my follow list.