user1052: I have been thinking recently about the way we are predominately creating NFTs on Cardano, right now the trend is to add the NFT attributes to the transaction metadata, however, I think this is not really that good if we want to do more interesting things with the tokens. As long as we keep adding the NFT attributes to the transaction metadata we will never have decentralized minting (creating new NFTs from smart contracts, e.g breeding mechanism etc), as we can not enforce any kind of restrictions on the transaction metadata from the scripts. The users always have all the freedom to add anything to the metadata. Also, we cant read the information stored there from the contracts, making it impossible to use for example to implement business logic on the chain.
I have the following idea, but I am not sure if it could work:
Objectives:

Stay away from an account base model and if possible keep the NFT as a native token.

Have the metadata accessible from the contracts (token metadata must
be inside an eUTXO).


Possible solution:
At minting time we create two tokens, for example:
“fffffffffffffffffffff.Monster00001” and “fffffffffffffffffffff.Monster00001_state” (they could be in the same policy or different policies).
Token “Monster00001” could still be freely traded as a native token, however token Monster00001_state will be trapped in an eUTXO which holds the token metadata or dynamic state (depending on the use case).
To retrieve the metadata for token fffffffffffffffffffff.Monster00001 we just need to find the eUTXO which contains fffffffffffffffffffff.Monster00001_state and read its datum (from off-chain code to for example display the NFT in a website), but here is where I am stuck.
I know that by using –tx-out-datum-embed-file we can embed the datum data on the transaction (as opposed to the datum hash). However, is this information persisted on the blockchain? (I am guessing it is as it is needed in some scripts validators), and if so, how can we retrieve this data?.

user2248: 
I know that by using –tx-out-datum-embed-file we can embed the datum
data on the transaction (as opposed to the datum hash). However, is
this information persisted on the blockchain? (I am guessing it is as
it is needed in some scripts validators), and if so, how can we
retrieve this data?.

Yes, this information is persisted, you can retrieve it using db-sync or blockfrost. For db-sync see this answer. If you want to use blockfrost, however, you will need to first get the datum-hash, which you can get from the UTxOs with https://cardano-testnet.blockfrost.io/api/v0/addresses/{address}/utxos (take a look here). Then, you'll use that datum-hash to get the actual datum with this request https://cardano-testnet.blockfrost.io/api/v0/scripts/datum/{datum_hash} (also take a look here)

1052: <p>I have been thinking recently about the way we are predominately creating NFTs on Cardano, right now the trend is to add the NFT attributes to the transaction metadata, however, I think this is not really that good if we want to do more interesting things with the tokens. As long as we keep adding the NFT attributes to the transaction metadata we will never have decentralized minting (creating new NFTs from smart contracts, e.g breeding mechanism etc), as we can not enforce any kind of restrictions on the transaction metadata from the scripts. The users always have all the freedom to add anything to the metadata. Also, we cant read the information stored there from the contracts, making it impossible to use for example to implement business logic on the chain.</p>
<p>I have the following idea, but I am not sure if it could work:</p>
<p>Objectives:</p>
<ol>
<li><p>Stay away from an account base model and if possible keep the NFT as a native token.</p>
</li>
<li><p>Have the metadata accessible from the contracts (token metadata must
be inside an eUTXO).</p>
</li>
</ol>
<p>Possible solution:</p>
<p>At minting time we create two tokens, for example:</p>
<p>“fffffffffffffffffffff.Monster00001” and “fffffffffffffffffffff.Monster00001_state” (they could be in the same policy or different policies).</p>
<p>Token “Monster00001” could still be freely traded as a native token, however token Monster00001_state will be trapped in an eUTXO which holds the token metadata or dynamic state (depending on the use case).</p>
<p>To retrieve the metadata for token fffffffffffffffffffff.Monster00001 we just need to find the eUTXO which contains fffffffffffffffffffff.Monster00001_state and read its datum (from off-chain code to for example display the NFT in a website), but here is where I am stuck.</p>
<p>I know that by using <strong>–tx-out-datum-embed-file</strong> we can embed the datum data on the transaction (as opposed to the datum hash). However, is this information persisted on the blockchain? (I am guessing it is as it is needed in some scripts validators), and if so, how can we retrieve this data?.</p>
 2248: <blockquote>
<p>I know that by using –tx-out-datum-embed-file we can embed the datum
data on the transaction (as opposed to the datum hash). However, is
this information persisted on the blockchain? (I am guessing it is as
it is needed in some scripts validators), and if so, how can we
retrieve this data?.</p>
</blockquote>
<p>Yes, this information is persisted, you can retrieve it using db-sync or blockfrost. For db-sync see <a href="https://cardano.stackexchange.com/a/5908/2248">this answer</a>. If you want to use blockfrost, however, you will need to first get the datum-hash, which you can get from the UTxOs with <code>https://cardano-testnet.blockfrost.io/api/v0/addresses/{address}/utxos</code> (take a look <a href="https://docs.blockfrost.io/#tag/Cardano-Addresses/paths/%7E1addresses%7E1%7Baddress%7D%7E1utxos/get" rel="nofollow noreferrer">here</a>). Then, you'll use that datum-hash to get the actual datum with this request <code>https://cardano-testnet.blockfrost.io/api/v0/scripts/datum/{datum_hash}</code> (also take a look <a href="https://docs.blockfrost.io/#tag/Cardano-Scripts/paths/%7E1scripts%7E1datum%7E1%7Bdatum_hash%7D/get" rel="nofollow noreferrer">here</a>)</p>
