marzilli / minter

OpenMinter is dApp framework for enabling the creation and collection of non-fungible tokens (NFTs) on Tezos.

OpenMinter

OpenMinter is dApp framework for enabling the creation and collection of non-fungible tokens (NFTs) on Tezos. The dApp enables anyone to create an NFT by filling in just a few fields, create new collection contracts, see their NFTs across contracts, and enable marketplace capabilities to trade them.

Current version supports the following:

🌐 Mainnet and Delphinet (Edonet soon)

🎨 Image-based NFTs

👛 Beacon support

⚙️ The latest FA2 spec

🚀 IPFS support (locally and Pinata)

Dependencies

• Tezos sandbox: Flextesa
• Blockhain indexer: Better Call Dev Backend
• Database: PostgreSQL
• InterPlanetary File System: IPFS

Usage

Installation

To install and build the dependences required for local development, run:

$ yarn install

The installation process will fetch toplevel NPM dependences and build the minter-ui-dev and minter-api-dev Docker images.

Configuration

The Minter can be configured to run on three different networks: sandbox, testnet (currently set to delphinet), and mainnet.

Each network has its own configuration file in the config folder under minter.<network>.json. The schema of these files can be defined as this TypeScript type:

type Config = {
  rpc: string,
  network: string,
  bcd: {
    api: string,
    gui: string
  },
  admin: {
    address: string,
    secret: string
  },
  pinata?: {
    apiKey: string,
    secretKey: string
  },
  contracts?: {
    nftFaucet?: string
  }
}

For example, the following minter.sandbox.json configuration defines the RPC url for the local sandbox node and the default alice address as the administrator during contract origination:

{
	"rpc": "http://localhost:8732",
	"admin": {
		"address": "tz1YPSCGWXwBdTncK2aCctSZAXWvGsGwVJqU",
		"secret": "edsk3RFgDiCt7tWB2oe96w1eRw72iYiiqZPLu9nnEY23MYRp2d8Kkx"
	}
}

Note: Since sandbox keys don't represent sensitive accounts, the config/ folder includes default configurations with admin wallets. To configure OpenMinter for the testnet or mainnet networks, update the definitions in config/minter.<network>.example.json and copy it to the proper path for the application to read it. For example:

cp config/minter.mainnet.example.json config/minter.mainnet.json

If the contracts key or its child nftFaucet keys is not specified, a new contract will be originated and its addresses saved in the configuration file when starting the OpenMinter development environment.

Pinata

Testnet and Mainnet instances of OpenMinter can include Pinata API keys in order to direct all file uploads through their service. This allows for ease of use while working with IPFS as running OpenMinter without Pinata will rely on using and maintaining a local IPFS node.

⚠️ Note: The example testnet and mainnet configurations in the config/ folder have placeholder Pinata API keys as it's the most robust way to easily persist data on IPFS. Using OpenMinter on these networks without Pinata may cause data loss as the NFT metadata and artifacts must be resolved over IPFS. If you want to use OpenMinter on these networks without Pinata, remove the pinata key from the configuration, but be aware that this entails running and maintaining your own IPFS gateway in order for your NFT data token remain accessible.

Starting and Stopping

During its start process, OpenMinter will create or update Docker services for its specified environment and also bootstrap the required contracts if their addresses are not defined in the environment's configuration file.

Sandbox

To start Minter in a sandbox network, run:

$ yarn start:sandbox

This command will start the following services:

• flextesa sandbox container
• Better Call Dev indexer API, GUI, and its required backend services
• Minter UI
• Minter API
• IPFS Node

To stop and teardown these services, run:

$ yarn stop:sandbox

Testnet

To start Minter on the testnet network, run:

$ yarn start:testnet

This command will start the following services:

• Minter UI
• Minter API
• IPFS Node

To stop and teardown these services, run:

$ yarn stop:testnet

Mainnet

To start Minter on the mainnet network, run:

$ yarn start:mainnet

This command will start the following services:

• Minter UI
• Minter API
• IPFS Node

To stop and teardown these services, run:

$ yarn stop:mainnet

Interacting with Minter

After starting Minter, you can now open:

• http://localhost:9000 to view the Minter application.
• http://localhost:9000/graphql to open the GraphQL playground.
• http://localhost:5001/webui to open the IPFS Web UI

Development

To see a list of services running after you've started the system, run:

$ docker service ls

Accessing Service Logs

To view each service's logs, the bin/log command is available. It can be run using yarn scripts yarn log or directly. It's a small wrapper around docker service logs that matches the first service you provide it:

$ yarn log:api

...which is a shorter way of doing the following:

$ docker service logs minter-dev-sandbox_api-server --follow --raw

To view the UI output, for example, run:

$ yarn log:ui

You may also override the script's default docker service logs arguments (--follow and --raw) by passing them at the end of the command. For example:

$ yarn log:api --since 5m

Editor Environments

Docker development images are set up to reload server and web UI on source code changes.

To setup this project for an IDE, you will want to install NPM dependencies outside of Docker. Make sure you have Yarn (version 1.22.x or above) installed:

$ pushd client; yarn; popd
$ pushd server; yarn; popd

Restarting Services

Individual services in docker stack can be restarted like so:

$ docker service scale minter-dev-sandbox_api-server=0
$ docker service scale minter-dev-sandbox_api-server=1

Or with a helper shell function

$ svc-restart api-server

where svc-restart is defined as

$ svc-restart(){docker service scale minter-dev-sandbox_$1=0 && docker service scale minter-dev-sandbox_$1=1}

Release Builds (WIP)

Development UI and API server builds can be swapped out for release builds:

$ bin/build-release-images

and then

STACK_API_SERVER_DEF=api-server STACK_UI_DEF=ui bin/start