algokittens / arc69 Goto Github PK

It's astonishing to me that there is no facility for expanding the hashtags beyond just the few ones there. Many systems may want to specialize in something else and use the hashtags and they will not be able to and so will need to increase the number of requests for rendering their galleries.

Need a #mime to mean 'other'. Should allow full mime type of it will fit. Should also decide now what field name people can use to specify a preview image if they support a less popular media type like PDFs or 3d models or anything that could benefit from a preview image. Rather than deciding that later or having people come up with random names. It would be an optional field.

Have raised these issues in Discord already. Just recording them here in case I am not actually crazy and some other people feel the same way down the line.

Similar to ipfs:// links, it would be nice to reference things on the arweave permaweb without having to resort to https://arweave.net links, which rely on a gateway, which could be fragile.

in my NFTs it show metadata standard CUSTOM How to set metadata standard ARC69

While ARC69 is fantastic, there is an issue with how rarities are calculated. It would be great to have a hybrid option to have rarity score added or not added based on a proposed modifier.

For example, in tinyhorse, we want to have leveling the horses be a filterable trait in the ARC69 metadata so it is searchable on sites like Randgallery.com or nftexplorer.app. At the same time, we don't want to piss off collectors by changing the rarity score and the option of having all of the levels be unique to not change rarity score would make filtering not work.

This is also an issue for series like Al Goanna which were not designed with trait rarity in mind. Having a toggle that removes a trait from rarity score would be help both series and collectors.

The proposed change is simple, add a new trait type category with a -r at the end or whatever else works so the sites can exclude that specific trait from the rarity calculations. Please see the example below:

{
standard: "arc69",
description: "tinyhorse 1",
external_url: "thurstober.com",
attributes: [
{ trait_type: "Background", value: "Canyon" },
{ trait_type: "Coat Color", value: "Yellow
{ trait_type: "Coat Marking", value: "Dapple" },
{ trait_type-r: "Level", value: "0" },
],
}

I am planning to start putting the trait data in the Reserve Address field (in addition to the config notes). I don't see another option that will allow smart contracts to access it.

Example: item has color, and power traits. 3 different colors (0 - bronze 1 - silver, 2 - gold), and power from 0 to 100. So say the item is color: silver and power: 50 the reserve address (as a byte array) would be something like

[1,50,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]

This will allow for the development of games that run on chain. For example (forgive me if I am getting some details wrong, just a hypothetical I haven't tried), a battle between two characters (represented as ASAs) can use the Txn.ForeignAssets to pass in two fighting characters, then access the asset params, generate a random number and weight it with the second (or 31st?) byte (the power level) and compare the two to see which character wins the fight round. Etc.

The example in 'pre-existing-NFTs.md' appears to be using to deprecated 'attributes' iteration instead of 'properties'. This should probably be updated with an up to date example to prevent any confusion.

The status still says "First draft" 😂

Creators often want to define filterable custom attributes that do not impact trait rarity. If filterable attributes were defined in a standardised way frontends could provide filtering support on these attributes. Examples are "dream state" for mostly frens or filtering on animated traits only for FUMs.

Example:

{
  "properties": {
    "background": "yellow",
    "head": "curly"
  },
  "filters": {
    "dream stage": "REM"
  }
}

If you're insistent about not having this in the foundations repo I think it should be renamed to something else to prevent confusion when ARC-0069 does come around