toniq-labs / extendable-token Goto Github PK

would it make sense to add a new method like

userTokens(User) which would return all the tokenIds or even all the Metadata for the tokens that the user owns? Wallets would find that functionality useful. Also is there any discord for ToniqLabs?

SVG Module File not found in erc721.mo

Perhaps I'm missing something, but I don't see a way to keep track of minting events in the standard right now. Transactions are there, but not minting events. Update the @ext/archive Transaction type to include minting events?

type Transaction = {
    txid : TransactionId;
    data: { #TransferRequest; #MintingEvent; };  // Renamed request -> data
    date : Date;  // Sidenote: I think "timestamp" might be a better name
};

type MintingEvent = {
    minter : User;
    to : User;
    token : TokenIdentifier;
    amount : Balance;
    memo : Memo;
};

// \x0Atid" + canisterId + 32 bit index type TokenIdentifier = Text;

index < 16777216
// \x0Atid" + canisterId + 32 bit index (8bit index length + index value)
index > 16777216
// \x0Atid" + canisterId + 8bit index length + 32 bit index

I believe this files contains the wrong Markdown.
https://github.com/Toniq-Labs/extendable-token/blob/main/examples/erc721.md

Hi, thank you for your high quality standard, I would like to propose and extension to get extended NFT metadata.

Right now, if we have a browser wallet plugin, we are unable to uniformly retrieve the content-type of the NFT that is written based on your standard. That means our wallet plugin would need to know about the actual contract to know the NFT content-type or query some aggregation service. Also based on your specification, someone currently cannot uniformly implement an NFT that might return a jpeg for some TokenId while returning a mpeg for some other TokenId.

The second problem for us is that NFTs based on your standard doesn't provide a uniform location specification where the NFT binary/blob is located. People might store their NFT in the token contract directly, or in an other canister, IPFS, or on web. For clients like a wallet it would be good to be able to uniformly retrieve the NFT binary.

The suggested extension:

type ExtendedMetadata = {
  #fungible : {
    name : Text;
    symbol : Text;
    decimals : Nat8;
    metadata : ?Blob;
  };
  #nonfungible : {
    content-type : Text; // some kind of mime type or any other standard
    location: IPFS|Canister|TokenContract|....
    metadata : ?Blob;
  };
};

for example if the location is IPFS, then the metadata should be an IPFS hash, if it is Canister then maybe a canister Principal.... We can discuss this in details, if people are happy with this in Principal.

type ExtendedMetadata = actor {
  extended_metadata: shared query (token : TokenIdentifier) -> async Result<ExtendedMetadata, CommonError>;

};

https://github.com/Toniq-Labs/extendable-token/blob/main/examples/erc721.md
https://github.com/Toniq-Labs/extendable-token/blob/main/examples/erc20.md

I converted the string input value of front-size to Blob and used it as an argument to the mintNFTfunction to mint erc721-like nft, but got an error below.
I think metadeta value doesn't match blob variant, so need to match Blob type in motoko and blob in javascript.But I don't know what I do. What is needed? Thank you in advance.

error (chrome validation)

myNFT
index.js:17781 Blob {size: 5, type: 'text/html'}
index.js:17791 name::::myNFT
index.js:17793 miner::::rrkah-fqaaa-aaaaa-aaaaq-cai
index.js:4524 Uncaught (in promise) Error: Invalid record {to:variant {principal:principal; address:text}; metadata:opt vec nat8} argument: {"to":{"principal":{"_arr":{"0":0,"1":0,"2":0,"3":0,"4":0,"5":0,"6":0,"7":1,"8":1,"9":1},"_isPrincipal":true},"address":""},"metadeta":{}}
    at index.js:4524:19
    at index.js:3435:29
    at Array.map (<anonymous>)
    at zipWith (index.js:3435:15)
    at Module.encode (index.js:4522:75)
    at caller (index.js:199:74)
    at CanisterActor.handler [as mintNFT] (index.js:221:34)
    at HTMLButtonElement.<anonymous> (index.js:17798:99)
（匿名） @ index.js:4524
（匿名） @ index.js:3435
zipWith @ index.js:3435
encode @ index.js:4522
caller @ index.js:199
handler @ index.js:221
（匿名） @ index.js:17798

index.js (src/myNFT_assets)

document.getElementById("mintNftBtn").addEventListener("click", async () => {
  const nft = document.getElementById("nft").value.toString();
  console.log(nft);
  const blob = new Blob([nft], {type: 'text/html'});
  console.log(blob);
  function readAsText(b) {
    return new Promise((resolve, reject) => {
      let reader = new FileReader();
      reader.onload = () => { resolve(reader.result); };
      reader.onerror = () => { reject(reader.error); };
      reader.readAsText(b);
    });
  };
  const name = await readAsText(blob);
  console.log("name::::"+name);
  const minter = await dfinity_nft_ext.getMinter();
  console.log("miner::::"+minter);
  const mintReq = {
    to: { principal: minter, address: "" },
    metadeta: blob  // as execute, empty: "metadeta":{}
  };
  const minted = await dfinity_nft_ext.mintNFT(mintReq);  // mint
  console.log("minted::::"+minted);  //Maybe return minted number

Ethereum emits a new event every time a new transaction is done or an approval happened. Currently in the Archive interface we are only able to retrieve transaction events, but not approval events. Should we also archive the approval events?

Can we get a liberal open source license on this thing?

I've just created a new token with a name and symbol,
Then again I tried created another new token with same and symbol with different supply and it worked. Now I've tokens with same name and symbol but two different id's.

I'm struggling to figure out how to use the token examples / standards within other canisters.

Scenario: I want to create a token not from a frontend, but another "backend" canister instead.

Expected behavior:

I can deploy my canister with the token standard as a dependency and create new tokens whenever I want.

I configured my test env like this:

...
"canisters": {
    "erc20": {
      "main": "src/token_test/assets/examples/erc20.mo",
      "type": "motoko"
    },
    "token_test": {
      "main": "src/token_test/main.mo",
      "type": "motoko",
      "dependencies": ["erc20"]
    }
  },
...

Actual behavior:

Dfinity fails with "Invalid data: Expected arguments but found none.".
To my understanding, this happens because the tokens are defined as actors so that they can be deployed on their own. But in my case, this throws an error because dfinity tries to deploy the erc20 dependency (which would create a token).

Now I understand I can remove the "actor" and just use the token as a class, but I don't know if that is the desired behavior here.

What do you suggest?