Open johnwhitton opened 2 years ago
Can you gitignore everything under /deployment
? No auto-generated code or local-environment specific stuff should be checked in
Can all Mini1155 and 721 related deployment and testing stuff be removed? They are launch templates other developers may use, and have nothing to do with SMS Wallet features. The contract themselves may be moved to separate places as well
Can you move all work-in-progress and MiniID related items to separate PR? Let's make one thing perfectly good, solid for production, and as minimal as possible in code, before moving on to the next.
There is still the issue unresolved, related to recording proxy, logic, and storage addresses for those hardhat deployed contracts, and fine-control on these contract's upgrade process. We can't just use deploy
or upgrade
without knowing or controlling each and every step what it is doing. Are they using factories and create2? Using EOA and create
op code? In some situations we also need to control the address which the contracts are deployed to. We need to know all these. In other situations when we upgrade the contracts, the storage slots may mess up because of storage layout issues, and we need to test ahead of time. We cannot do this without complete visibility and fine-control over the deploy and upgrade process
Let's also move development notes to miniwallet/devlog/
with a README stating they are development notes for internal discussions, not meant for documentation or guiding users or developers.
We can polish and move things out to component-root folder after they are ready for production and presentable for external audience
I have two more files to read: NFTID.md and PROXY.md. I went through other files.
Let's break down this PR into multiple parts (each has its own PR):
The PRs can be made in chains (each PR's branch merge into the branch of previous PR) rather than all pointing to the base (main) branch, since each may be dependent on some of the work in previous PR
On a second thought - I think (2) can be merged in after using a better proxy, so we can get it up and running ASAP. We can improve this process in a later PR
Version 0 work based on https://github.com/polymorpher/sms-wallet/issues/13