You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While reviewing our NFT Minting pages it is clear we serve a fragmented and confusing experience. Ultimately, this complexity stalls new web3 builders and makes our examples incredibly hard to follow. My goals for simplifying the minting process are as follows:
(Table Stakes) Teach foundation concepts by integrating with an existing mint-able contract.
Start with a trivial minting experience with a bare-bones ERC721 contract.
Layer on complexity via progression thought the guide.. Start Simple and progress iteratively.
Structure our examples as components / building-blocks
Keep the UX simple, leave the complexity in code.
So what does this mean for our project? What am I suggesting? I suggest we refactor the NFT mint experience into three separate learning flows:
(Simple) Implementing a Mint Button on your Site
First, we walk builders through adding a mint button on their page. Draw inspiration from Open Minting Platforms like mint.fun
Focus heavily on :
How to interact with a NFT Contract + Metadata
Connecting a wallet
Explaining the steps to implement a Smart Contract Write Function.
(Intermediate) Creating a Simple ERC 721 Contract
We layer on complexity in the next section showcasing how you can write and deploy your own ERC 721 built upon one of the many Open Source ERC721 Solidity libraries.
Create a basic contract
Deploy that contract using Foundry
Integrate your smart contract into the existing project.
Layer on some more complex examples (e.g. Minting to an ENS address via a RPC lookup)
(Complex)
Until we have developed a stronger opinion how to integrate advanced use-cases into our UX, we will keep these examples in code-only. We should move instructions to readme's inline with these code samples.
Signature Mint
AllowList Mint
However, we should pivot these examples to be extensions to the base case rather than their own new entity. For example, do we really need a whole new contract or can we just showcase how to do this with a tidy function.
For example, we could showcase how to add a signature mint with a new foundational building block (rather than an entire contract):
function freeMint(address account, bytes memory signature) external {
string ethSignedMessageHash = "free mint";
address signer = ECDSA.recover(ethSignedMessageHash, signature);
require(signer == "0x0000", "Unable to verify Signature");
// Mint the NFT
_mint(account, ++currentId);
emit Mint(account, currentId, 0);
}
To do this effectively we might want to consider writing a common Solidity library for functions we need to support (e.g. signature validation)
Describe alternatives you've considered.
No response
The text was updated successfully, but these errors were encountered:
Describe the solution you'd like
Draft ..
While reviewing our NFT Minting pages it is clear we serve a fragmented and confusing experience. Ultimately, this complexity stalls new web3 builders and makes our examples incredibly hard to follow. My goals for simplifying the minting process are as follows:
So what does this mean for our project? What am I suggesting? I suggest we refactor the NFT mint experience into three separate learning flows:
(Simple) Implementing a Mint Button on your Site
First, we walk builders through adding a mint button on their page. Draw inspiration from Open Minting Platforms like mint.fun
Focus heavily on :
(Intermediate) Creating a Simple ERC 721 Contract
We layer on complexity in the next section showcasing how you can write and deploy your own ERC 721 built upon one of the many Open Source ERC721 Solidity libraries.
(Complex)
Until we have developed a stronger opinion how to integrate advanced use-cases into our UX, we will keep these examples in code-only. We should move instructions to readme's inline with these code samples.
However, we should pivot these examples to be extensions to the base case rather than their own new entity. For example, do we really need a whole new contract or can we just showcase how to do this with a tidy function.
For example, we could showcase how to add a signature mint with a new foundational building block (rather than an entire contract):
To do this effectively we might want to consider writing a common Solidity library for functions we need to support (e.g. signature validation)
Describe alternatives you've considered.
No response
The text was updated successfully, but these errors were encountered: