What should your zkApp _not_ do?

​This is a zkIgnite community coversation hosted by Teddy from the Mina Foundation product team.

​Dive into a friendly discussion on defining and designing requirements of zero knowledge Applications (zkApps) from a unique perspective. Our focus will be on what zkApps do and, importantly, on what they intentionally avoid. This approach will allow us to enhance product requirements and shine a light on the potential capabilities of zkApps in a nuanced way, illuminating how negative detailing in product requirements can provide boundaries to scope, clearly define user personas and effectiveness in development and design."

​Pre-reads/Prompts:

​- Consider what you desire zkApps not to do & how it might change the zkApp's value proposition.

​Discussion Prompts:

​- How can we develop zkApps that allow users to select what information is negated while satisfying regulatory requirements? For example, in a private payment scenario, how might the app function differently if a user wants to hide their identity versus their location?

​- What instances where understanding what a product doesn't do would have improved its overall effectiveness or value proposition? For example, a messaging app that doesn't store messages versus one that does but encrypts them.

​- What impact might 'negative detailing' have on network effects, particularly in regards to attracting and maintaining liquidity within the protocol? How could deliberately excluding certain functionalities affect user engagement and protocol adoption?

​- How can this practice of feature negation allow zkApp developers to build concrete, targeted solutions? How does this specificity contribute to the creation of a competitive moat and foster the embeddedness of the zkApp within its user base or ecosystem?

​- By defining what our zkApp doesn't do, can we foresee a potential increase in trust and transparency? And could this increased trust spur further adoption, creating a positive feedback loop that fuels network growth?