# MF Wearable NFTs Spec

This doc describes MetaFactory's strategy/approach to interoperable 3D wearable NFTs.


### Requirements / Features
- Support multiple 3D files / formats in a single NFT
- 3D files stored in decentralized data stores (IPFS, Arweave, etc)
- Metadata stored permanently off-chain without requiring centralized API to serve it (Ceramic)
- Metadata can be retroactively updated by MetaFactory to add support for new file formats / versions of the 3D wearable

### Metadata Spec (based on 1155)

{
    "name": "Vaunker Hoodie",
    "description": "some description here",
    "image": "ipfs://...",
    "external_url": "https://mf.app/<tokenId>",
    "animation_url": "ipfs://...", // Points to primary 3D model
    "properties": {
        "brand": "Vaunker",
        "season": "2",
        "style": "Hoodie",
        "composition": "100% Cotton",
    "madeIn": "United States",
        "releaseDate": "Jan 1, 2022",
        "shopLink": "https://shop.metafactory.ai/..."
        "creators": [
            {
                "name": "weseeclearly",
                "share": 30,
                "role": "Technician",
                "did": "..."
            },
            {
                "name": "Van",
                "share": 70,
                "role": "Designer",
                "did": "..."
            }
        ],
        "files": [
            {
                "mimeType": "model/gltf-binary",
                "uri": "ipfs://...",
                "properties": {
                    "description": "a GLTF file for Webaverse, NeosVR, etc",
                } // Generic map of keys/values
            },
            {
                "mimeType": "model/vnd.usd+zip",
                "uri": "ipfs://...",
                "properties": {
                    "description": "a USD file for AR",
                }
            },
            {
                "mimeType": "application/octet-stream",
                "uri": "ipfs://...",
                "properties": {
                    "description": "CLO3D / Marvelous Designer Project File",
                }
            },
            {
                "mimeType": "model/vox", // not actually a real MIME type
                "uri": "ipfs://...",
                "properties": {
                    "description": "a VOX file for Cryptovoxels",
                }
            }
        ]
    }
}

### Repos / Code
- Wearable Files: https://github.com/madjin/metafactory-wearables
- NFT Claim Repo: https://github.com/MetaFactoryAI/wearable-nft-claims
-

### Smart Contracts
- Based on [Manifold Creator Architecture](https://www.dropbox.com/s/x9t53qf3werqxru/Manifold%20Creator%20Architecture.pdf?dl=0)
- Will have an 1155 extension that has each tokenURI set to the streamId pointing to a [Tile Document](https://developers.ceramic.network/streamtypes/tile-document/overview/) on Ceramic containing the NFT metadata. Can use the [HTTP API](https://github.com/ceramicnetwork/js-ceramic/pull/1395) to prefix the streamID into a URL that returns the JSON (in order to make it backwards compatible with any app/platform that doesn't know how to resolve the ceramic URI)
- NFTs that are associated with a physical item that has a KONG chip are uniquely identifiable and therefore need to be 721s (or 1155 with supply of 1 if that helps keep things more consistent)

### Other dev work needed
- [ ] Scripts to programatically generate / convert the 3D files to various formats and upload them to IPFS
- [ ] Scripts / interface to generate all the metadata and push it to Ceramic + keep track of streamIDs etc
- [ ] Scripts to mint the NFTs from generated metadata and set their tokenURIs

### Questions
1. Should we deploy on mainnet and use mixed ERC1155/721? Or deploy on a rollup and use 721s for everything?
2. How should we structure the CreatorCore + Extensions?
3. Should the tokenURI be a CAIP10 string, `ceramic://<streamId>`, or point to the [raw data HTTP endpoint](https://github.com/ceramicnetwork/js-ceramic/pull/1395)?

### Resources / Links
- https://hackmd.io/@XR/nftavatars
- https://hackmd.io/@XR/avatars
- https://twitter.com/dankvr/status/1420104524895764480
- MetaMundo NFT Metadata Spec:

- Title (free text) - required
- Description (free text) - required
- Master file (max 500mbs) - required
-- .fbx
-- .glTD
-- .glb
-- .obj
-- .vox
- Secondary versions
-- Decentraland file (.glTD, max 5mbs)
-- CryptoVoxel file (.vox)
- Category
-- Architecture
-- Cars & Vehicles
-- Wearables
-- Avatar
-- Fashion
-- Furniture
-- Dimensions
-- Height
-- Length
-- Width

- Royalty
-- % amount
-- wallet payout

# Test Plan

1. Test max number of claims in one TX
2. Measure gas costs to claim
3. Test minting NFTs to claims contract
4. Test generating + verifying merkle proofs
5. Test reading metadata from Ceramic
6. User cant claim more than once

---

# Mar 23 Sync with Holly/Penguin/MD

- Need to figure out how to structure royalties
- 5-7% going to be split between designers + MF
- Check if its feasible to handle splitting to designers automatically vs requiring them to all claim manually from each platform
- Scripts needed:
- Wearable data loaded into Ceramic
- Merkle root JSON generation for what addresses should get what NFTs
- Set MF Multisig as the owner of contract with MF EOA as an admin
-

# Mar 2 Sync with Holly/Penguin/MD/Drew

- Have to test claims and NFT implementation together
- KONG chipped 721 NFTs will need custom logic on transfer function so people can scan KONG chip to claim their NFTs. Initially we will focus on the 1155 NFTs with merkle claim for simplicity
- Holly to continue working on the claims process
- Kevin to implement Ceramic metadata storage for Create and Update. Writing up the Datamodel for the NFT Metadata
- Penguin to work on linking all the Vox files into Notion
- MD to get initial version of batch metadata ready to try out on testnet

# Jan 31 Sync with Jin

What's the best way to make NFT metadata compliant with `.metaversefile`?


https://github.com/webaverse/sword/blob/f6777403e2f883f985234ff5a8d1dd28a06f2e01/.metaversefile

.metaversefile is the successor to xrpk
atm feels like unpacked gltf, what is the "glb of .metaversefile"?
do we bundle these things still?

CV implementing VRM
will follow VRM spec, like meebits?
LL providing API

Armature + Wearable
Only M3taloot doing it

Export metadata w/ glTF like how VRM does
blender plugin?
not just NFT metadata, embedded into the file itself
less fields for NFT metadata then

generic optional properties, each platform has diff capabilities

> should we have gltf or glb?

glb

For handling LOD we can append additional models to array for now, in future explore gltf extension:

- https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Vendor/MSFT_lod/README.md
- https://www.simplygon.com/

Add spritesheet avatar as additional model
Add wearable to avatar -> generate sprite to update

Will write script to read directly from repo
Additional metadata: brand, rarity, where its manufactored?

Will circle back, going to look at decentral games wearables real quick

Metadata as text LOD
Pretend a blind person and describe the object
AI generation of stuff in the future

Wearables will be 1155s, all NFTs will have same metadata
Kong wearables will be 721s, can inject metadata from physical back to digital

Scanning will let you take ownership of physical asset
Scan to sign, chip has private key generated from silicon structure, can sign messages with it

On-chain representation has public key of chip associated with NFT, if someone signs message with chip its proof they have possession of that asset (can provide timestamp etc)

Protects against fakes in the future
Digi-physical hackerspace access pass
It's a pfp for the real world, token access to physical and digital spaces

AR token accessed realities

Loot larp did chips for doors / castles

Keep t-pose, a-pose mostly for window displays

VRChat requires FBX

traits = rarity = uniqueness
unbundle, wear loot, new NFT?

ceramic data streams
upstream data updated -> stream goes forward and can be manipulated, create another data stream, compose in many layers
update stream, derivs / way it got composed or used later on also updates

- https://ice.decentral.games/ice-nft-wearables
- https://docs.decentraland.org/decentraland/wearables-overview/
- https://docs.decentraland.org/decentraland/wearables-editor-user-guide/

---

# Wearables Pipeline Brain dump

At a high level:

1. Get design files from notion
2. Create texture for wearable
3. Generate 3D files
- a-pose + t-pose glb files first
- vox model next (tested needed)
- Decentraland wearable (planned)
4. Conversions: USDz + LOD
5. Photoshoot with avatars
- VRoid studio first
- Test in Webaverse
- Upload to VRoid hub
- Import to various games
- Notes: https://hackmd.io/@XR/avatars

---

When making interoperbale avatars the first step I do is go to the product page in notion and download the Design Files into a workspace folder

https://www.notion.so/metafactory/50d380c274dc48efb5576b09470d36c7?v=8375f6e560fa492aa6dbcfefec5cee45


Then I'll begin editing a UV mapped texture for a VRoid wearable base mesh in Gimp, a free and open source image editor: https://www.gimp.org/

You can use photoshop or whatever image editor that supports layers, I prefer FOSS. Many MF design files are .ai which require someone with Photoshop to export layers as transparent pngs.


> Note: Should we also export Gimp projects in order to preserve the layers?


For the best workflow it'd be good to have separate monitors in which you can keep the reference design open while editing the UV in your image editor and then export to test in Blender.


Next we can generate a t-pose and a-pose glb file using blender templates that we just have to switch the textures of

- T-pose is for custom avatars
- A-pose is for window shops / displays
- Idea: Flattened a-pose inside framed glass

To-do:

- [ ] Create a .blend project with segmented base mesh template to export voxelized chunks for Cryptovoxels compatibility


https://wiki.cryptovoxels.com/en/Player_customization/Create_a_wearable#creating-a-collection