Free decentralized storage and bandwidth for NFTs on IPFS and Filecoin.

Table of Contents

• Client Libraries
• HTTP API
• Developer Tools
• Development
  • Getting Started
  • Local environment configuration
  • Release
    • What's a Release PR?
    • How should I write my commits?
• Contributing
• License

Client Libraries

The JS client library is the official and supported client to nft.storage. Other libraries listed have been generated from the OpenAPI schema and are experimental, unsupported and may not work at all!

• JavaScript
• Go (Generated from OpenAPI schema)
• Java (Generated from OpenAPI schema)
• PHP (Generated from OpenAPI schema)
• Python (Generated from OpenAPI schema)
• Ruby (Generated from OpenAPI schema)
• Rust (Generated from OpenAPI schema)
• Unity (C#)

HTTP API

Check out the HTTP API documentation.

Developer Tools

We've created some scripts to help developers with bulk imports, status checks, file listings and more:

https://github.com/nftstorage/nft.storage-tools

Development

Instructions for developers working on the nft.storage API and website.

psst: want to do some frontend work done without an environment? check out this guide

Getting Started

We use yarn in this project and commit the yarn.lock file.

1. Install dependencies.

   # install all dependencies in the mono-repo
   yarn
   # setup git hooks
   npx simple-git-hooks

2. Setup your local environment with a .env file. See intructions.
3. Follow the getting started guides in /packages/api and /packages/website.
4. Run locally by starting the following processes.
   1. API server (yarn dev in /packages/api).
   2. Web server (yarn dev in /packages/website).

The site should now be available at http://localhost:4000

Local environment configuration

In the root folder create a .env file with the following:

# Wrangler overrides
DEBUG=true

# API Secrets
SALT=secret
MAILCHIMP_API_KEY=secret
METAPLEX_AUTH_TOKEN=secret
# needs to be real so create a personal magic.link account or use the staging key
MAGIC_SECRET_KEY=secret
LOGTAIL_TOKEN=secret
PRIVATE_KEY=xmbtWjE9eYuAxae9G65lQSkw36HV6H+0LSFq2aKqVwY=

## API Sentry
SENTRY_DSN=https://000000@0000000.ingest.sentry.io/00000
SENTRY_TOKEN=secret
SENTRY_UPLOAD=false

## API PostgREST
DATABASE_URL=http://localhost:3000
DATABASE_TOKEN=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJzdXBhYmFzZSIsImlhdCI6MTYwMzk2ODgzNCwiZXhwIjoyNTUwNjUzNjM0LCJyb2xlIjoic2VydmljZV9yb2xlIn0.necIJaiP7X2T2QjGeV-FhpkizcNTX8HjDDBAxpgQTEI

# Postgres Database
DATABASE_CONNECTION=postgresql://postgres:postgres@localhost:5432/postgres

# Vars below this line are optional or can have fake values
# You only need to have real values if you are manually deploying or running cron jobs locally

# Cloudflare
CF_TOKEN=<token>
CF_ACCOUNT_ID=<account-id>

# IPFS Cluster
CLUSTER1_API_URL = https://nft.storage.ipfscluster.io/api/
CLUSTER1_BASIC_AUTH_TOKEN=<token>

CLUSTER2_API_URL = https://nft2.storage.ipfscluster.io/api/
CLUSTER2_BASIC_AUTH_TOKEN=<token>

CLUSTER3_API_URL = https://nft3.storage.ipfscluster.io/api/
CLUSTER3_BASIC_AUTH_TOKEN=<token>

# Postgrest
PROD_DATABASE_URL=https://db.nft.storage
PROD_DATABASE_TOKEN=<token>

STAGING_DATABASE_URL=https://db-staging.nft.storage
STAGING_DATABASE_TOKEN=<token>

# Postgres Database
PROD_DATABASE_CONNECTION=<connection-string>

STAGING_DATABASE_CONNECTION=<connection-string>

# Pinata
PINATA_JWT=<token>

# dag cargo
DAG_CARGO_HOST=<ip>
DAG_CARGO_DATABASE=<db-name>
DAG_CARGO_USER=<db-user>
DAG_CARGO_PASSWORD=<db-password>

Production vars should be set in Github Actions secrets.

Release

Release Please automates CHANGELOG generation, the creation of GitHub releases, and version bumps for our packages. Release Please does so by parsing your git history, looking for Conventional Commit messages, and creating release PRs.

What's a Release PR?

Rather than continuously releasing what's landed to our default branch, release-please maintains Release PRs:

These Release PRs are kept up-to-date as additional work is merged. When we're ready to tag a release, we simply merge the release PR.

When the release PR is merged the release job is triggered to create a new tag, a new github release and run other package specific jobs. Only merge ONE release PR at a time and wait for CI to finish before merging another.

Release PRs are created individually for each package in the mono repo.

How should I write my commits?

Release Please assumes you are using Conventional Commit messages.

The most important prefixes you should have in mind are:

• fix: which represents bug fixes, and correlates to a SemVer patch.
• feat: which represents a new feature, and correlates to a SemVer minor.
• feat!:, or fix!:, refactor!:, etc., which represent a breaking change (indicated by the !) and will result in a SemVer major.

Contributing

Feel free to join in. All welcome. Open an issue!

License

Dual-licensed under MIT + Apache 2.0