Using 721 or 1155 depends on the type of assets you want to add to your system and the growth you expect for your project. This is: if you're totally sure that you won't need anything else than:
- Store notes, with links to IPFS.
- Pay for them using the native token of your blockchain.
Then you will be OK with 721. Now, let's think another scenario: You deployed your 721 contract and everything goes well, but then you feel the need to create another contract to be part of your ecosystem. That contract, on deployment, would take the address of one or more contracts of your already-deployed ecosystem and... another token would be useful, say, for a new feature you are implementing. If you feel that need would come to you, then better go for an 1155 contract (specially if you feel the need to create new fungible tokens).
But if you are fine, and you think you will always be fine, with the current structure of your project where nothing but the NFTs you are creating will exist (save for the native token of your chain)... then stick to 721.
Now, IPFS and IPNS are part of the same. Typically, IPNS is a way to get aliases to some documents you store in IPFS. One particular implementation is to use DNSLink (in which you have your.fancy.domain registered and you add some specific records, and then /ipns/your.fancy.domain/... paths are available through IPFS). Typically, you would want the metadata for your NFTs to be in some sort of
mapping(uint256 => string), with the value being the CID (e.g.
"QmejFS6no1bJLffPtWdHrsh19skHyG6run8FmNUsutSCGj" for id =
1) of an IPFS resource, and then the method to return the URI should return, for id
1, the URI
"ipfs://QmejFS6no1bJLffPtWdHrsh19skHyG6run8FmNUsutSCGj". Usually, you will not overcomplicate yourself with ipns and will just use ipfs.
this is a good approach to build an application, this depends on more details I don't know, but you need to know something:
- Users can mint an NFT with a certain link to an existing note in IPFS.
- Users might need to change the note. This means that users, as NFT owners, must be enabled to change the link to the current note (since IPFS files cannot be edited) to point to the new note file.
- For this to work, the IPFS notes must be pinned into another server which allows you to (e.g. pinata, infura).
Then you can do what you are asking for, if you take that into account.
STATE-MODIFYING FUNCTIONS MUST ALWAYS RUN INSIDE TRANSACTIONS. This implies: it will ALWAYS cost gas. One of the things I was been thinking about is that you would create some sort of sponsoring server in which:
- Your server would receive a signature from a client wallet and, with it, the server (using a custom private key, signing for a custom wallet, which you will know and will already have afforded some native coins into it) would invoke the NFT minting / updating operation on your target smart contract, on the client's behalf (that's what the signature would serve for), but this needs additional methods you have to invent (and I am not sure how to do this, but I read it in a link I will search later for you).
- For this to work, you have to fund that server's wallet address manually. Perhaps you can establish a business model in which your server will sell some advertising space to earn some money. This is up to you.
And finally, yes: As long as you use any EVM-compatible network, you can use OpenZeppelin's contracts (ERC721, ERC1155, whatever), and add more methods on top of it (e.g. to do that "sponsoring" stuff).
Edit: For the thing about signed messages, which you may need if you use some sort of "sponsoring" technique, this link could give you an insight. In this case, the purpose is different (it allows to have two different networks to verify the same requester of the operation to be verified in the two chains - but in this case you would make use of the user verification).
Edit 2: The idea behind sponsoring servers is that such server is optional for the user. While the signature process would make the user more trustworty, you should publish the sponsoring server sourcecode so they understand that no cheat can be done there.
Also, the contract will still have (actually: must still have) the direct methods to be invoked by the users who prefer to pay the gas themselves and hit the blockchain themselves, instead of hitting your sponsoring server. If they use an external client being ERC721 or ERC1155 compatible (there are many ones out there which are abstractions over specific standards) and everything works ok, it will suffice for the sake of usage as long as they can see the results appropriately later (querying the contract externally does not consume gas).
Still, for the users to trust you, always publish the source code of the contract (there are tools to reverse-engineer the EVM code of a contract, but being proactive and open about the contract's/contracts' source code(s) will give you a better image).