ERC721 | ERC-721 Token based on non-finalised spec | Blockchain library

Simply put I had to go down a rabbit hole to work this out as I'm pretty new to Solidity.

I had to do the following;

1. Learn and use https://www.trufflesuite.com/ to setup a project and put my contract there (Using Ganache helped a lot with testing for anyone new to Solidity too)
2. Use HD Wallet provider package and follow tutorial here to get it on ropsten Etherscan https://medium.com/coinmonks/5-minute-guide-to-deploying-smart-contracts-with-truffle-and-ropsten-b3e30d5ee1e
3. Finally, use truffle-plugin-verify https://github.com/rkalis/truffle-plugin-verify to verify the contract on Etherscan

All in all, I am pretty sure there is no way within the Etherscan web app to verify a contract that contains an imported file.

The final product is here if anyone is interested in seeing how I structured it all https://github.com/lukecurtis93/viper-nft (it's just a CryptoKitties clone I found online as a base and updated it all)

The ERC-721 standard does not define a "best" or "correct" way to mint new tokens (such as whether it should be open or restricted) and it's up to each contract developer to implement or omit the minting feature in a way that reflects their needs.

Creating of NFTs ("minting") and destruction NFTs ("burning") is not included in the specification. Your contract may implement these by other means. Please see the event documentation for your responsibilities when creating or destroying NFTs.

But having a whitelist of addresses that are authorized to mint new tokens (e.g. MINTER_ROLE or onlyOwner) seems to be more common than allowing anyone to freely mint new tokens.

Even though it's theoretically possible to deploy new contract each time a new token is minted, it's not a standard approach (and I personally haven't seen any contract that does it). In most cases the minting process "just" creates a new ID, stores a new string/URL value associated with the ID, associates this new token with an owner address (of the token, not a contract owner), plus updates some metadata such as amount of tokens owned by an address (see example below).

The token owner can then transfer their tokens, give anyone control over their tokens, and do other stuff depending on the contract implementation.

The mappings that you point out in your question (_owners and _balances) suggest that they store token owner (not contract owner) addresses as well as amount of tokens held by each address.

Example:

1. Contract owner mints token ID 1 to address 0x123.

   • Value of _owners[1] is 0x123 (was 0, the default value)

   • Value of _balances[0x123] becomes 1 (was 0, the default value)

2. Contract owner mints token ID 2 to address 0x123.

   • Value of _owners[1] is still 0x123

   • Value of _owners[2] is now 0x123 (was 0, the default value)

   • Value of _balances[0x123] becomes 2 (because they now own 2 tokens)

Install a Web3.js middleware layer that signs transactions locally, instead of sending a JSON-RPC method to Infura.

One of the solutions is Truffle HDWallet.

OpenZeppelin's Ownable.sol defines the default owner value as the contract deployer. You can later change it by calling transferOwnership() or renounce the owner (i.e. set to 0x0) by calling renounceOwnership().

The onlyOwner modifier reverts the transaction if it's not sent by the current owner. (see the code)

So you need to call the mintNFT() function from the same address that deployed the contract, because that's the current owner. Or you can change the owner first by calling transferOwnership() (from the current owner address).

Removing the onlyOwner modifier from the mintNFT() function would allow anyone to call the function.

Your ERC721Full .sol has a space in the name, before the dot.

Remove the space, so that it's ERC721Full.sol, and you'll be able to import it.

It's a visibility issue.

If you want to access the _baseURI property in a derived contract, you need to make it at least internal (it's currently private).

Which also means copying a set of contracts locally so that you can update the ERC721Metadata.sol and import the updated version (and not the remote version) from the other contracts.

The _setBaseURI() function alone can be overridden because it's visible from your contract.

Private functions and state variables are only visible for the contract they are defined in and not in derived contracts.

Cannot access private property in a derived contract.

Source of the quote: https://docs.soliditylang.org/en/v0.8.3/contracts.html#visibility-and-getters

IPFS is immutable, meaning when you add your directory along with the files, the directory gets a unique CID based on the contents of the directory. So in a sense, nobody can modify it, not even you, because it's immutable. I believe this confusion can be resolved with more background on how IPFS works.

When you add things to IPFS each file is hashed, and given a CID. The same is true for directories, but their CID can more easily be understood as a sum of the contents of the directory. So if any files in the directory are updated, added, or deleted, the directory gets a new CID.

Understanding this, if someone else added the exact same content in the exact same way, they'd end up with the exact same CID! With this, if two people added the same CID, and a third person requested that file (or directory), both nodes would be able to serve the data, as we know it's exactly the same. The same is true if you simply shared your CID and another node pinned it, both nodes would have the same data, so if anyone requested it, both nodes would be able to serve it.

So your local copy, cannot be edited by anyone. In a sense, if you're relying on the IPFS CID as the address of your data, not even by you! This is why IPFS is typically referred to as "immutable", because any data you request via an IPFS CID will always be the same. If you change any of the data, you'll get a new CID.

More info can be found here: Content Addressing & Immutability

If you read all this and thought "well what if I want mutable data?", I'd recommend looking into IPNS and possibly ipfs-sync if you're looking for a tool to automatically update IPNS for you.

Solution: I had the wrong address in the transaction object. I had the account address and not the contract address. Correction below.

If you want to store the data on-chain, a mapping (uint256 => Property), where the uint256 is the token ID and Property is "struct(location, price, ...)", containing the data is probably the cheapest option gas-wise.

But since your question states you don't want to use struct, you can chose to store the data on-chain with a series of mappings: