Request for feedback: Considerations for NFT developers

I’ve collected some best practices and considerations for developers of NFTs on the IC. We’ll probably add them to the Developer Docs, but I’d like to ask for feedback here first.

7 Likes

This is a great list! Thanks for putting it together. I haven’t written any reject messages in motoko yet. Any chance we could have some best practices and patterns for rejecting messages put together?

3 Likes

Thank you Austin.

I’ll see what I can do, but it will take a few weeks because I’m out for holidays soon. Are you talking about the inspect message feature for ingress messages? What’s the use case you have mind?

Yes.

  1. You mention rejecting queries in certain instances, can inspect message do this?

  2. There are probably a broader set of best practices that should be used for inspecting messages and we have very few docs/example code/patterns. I could almost see another working group that adresses these concerns, makes recommendations, and publishes software to help canister devs keep their canisters safe and operational. We have really seen any brute force/cycle drain attacks on specific canisters yet(at least publicly) but they will come with more attention.

No, canister_inspect_message is not invoked in for query calls. From my understanding this feature was introduced to give canister developers an opportunity to reject a message before it gets into replicated state. Query calls are performed by a single replica anyways. My suggestion in the article was to have a guard in the query method that traps or returns an error if the balance is below a certain threshold, similarly to authentication guards.

Yep, I agree.

Btw. @dsarlis is working on rejecting query calls for frozen canisters. See this PR to the Interface Spec.

1 Like

Hi, I see the document is quite general and in my opinions it covers a good viewpoint for NFT developers (though I’m not). Clearly, not that hard to read and thanks for gathering them.

1 Like