We could have call a contract hold on the same account, but that disturb the contract's state. In any case, because it's not easy to delete state and re-create account for a child of testnet or near, we choose to hold contract that requires state on a further sub-account, which we can easily delete and recreate the account if anything fails during migration. As for the web4 page; as something like sub-account.account.testnet.page fails when we try to visit that page (due to some HSTS error), we have to hold it on account.testnet.page instead.
One had to admit, this is a really difficult decision, as it makes users, whom have to go into this hassle of opening up nft.storage and login (assuming they don't have GitHub so login is more difficult than those whom does), then find the API Keys tab, click on it, give it a name for the key, then save API. Irregardless of whether we're using cookies to store it for future use or not, even one single time going through that process is unreasonable, for a user that even have difficulty trying to control his/her mouse!
API Keys are stupid. IPFS API keys doesn't allow partial access. It doesn't have restrictions. Most importantly: it's on the frontend! Anyone can get access to the API key when you hard-coded it! Unless they do something like "generate new API Key on demand" and "disposable single-use only API key", otherwise, even storing it on the
process.envmakes discoverable on the web console. Check here for how to access a
process.envAPI key and hack it away!
Well, storage cost! Currently, IPFS is free, NEAR isn't. Testnet is free, but not on mainnet. If we are not to disturb the user worrying about having to pay money just to post their blog, how do we pay for them minimal cost? Assuming one wants to be as stingy as possible, storing the CID (and perhaps storing it as the most cost effective form, least byte format) decreases maintenance cost. Something that we can support even with minimal gas fee: that only cost the 30% of gas fee paid to contract host (if you know about that info, you know what one means. Ignore if you don't know.)
We actually want free of charge save; but there are security issues with it. Initially, we thought of checking whether the CID is valid; then check whether it saves the information we need; then check it's saved on nft.storage; then smart contract refuses to compile after include ehttp library. Similarly, smart contract refuses to compile when using async with reqwest library, with "Contract API cannot be async." error. So, we'll go back to the easiest way to solve the problem: just ask the user to pay for storage. As of NEAR $10 USD, it cost about 1.2 cents; and as of now, it's less than a cent for save. We are only scared of DDOS that takes all our money away; otherwise, should be fine.
Well, that's because if we need a "last", we need to know how many items there are. We could know that if write some function to support that; but so far, time constraint prevent one from focusing on that. Maybe in the future.