Forem: Jimmy

Mint Solana NFT Using Rust & Metaplex SDK

Jimmy — Tue, 25 Jul 2023 12:51:04 +0000

Solana is a public, permissionless blockchain launched in 2020. It leverages computer hardware for its high throughput and performance. Solana has been the pioneer in cutting-edge innovation leading in the adoption of tech like concurrent Merkle trees, interfaces, token-2022...etc

I briefly talked about some differences between Solana and EVM chains previously and in this article I will take you through the process of minting an NFT using the Rust Solana SDK and the MetapleX SDK.

Environmental Setup
Introduction to Tokens in Solana
Intro to Native Rust Solana Development 1
Client Side Set up 1
More on Native Rust Solana Dev
Client Side Set up 2
Further Reading

Environmental Set-up

Consider: Solana Playground - A dedicated online playground where you can write and deploy your Solana programs using anchor, native Rust or Seahorse-lang online.

You can also skip this section if you already your Solana environment setup.

Convenient (must have) tool that will make development easier

Rust Installed
solana cli
Rust Analyzer - Install it via extensions, if working on VS Code, other wise any Rust Language Server works.

To install the Solana CLI run the command below,

sh -c "$(curl -sSfL https://release.solana.com/stable/install)"

Depending on your system, you might get an installer messaging

Please update your PATH environment variable to include the solana programs:

Follow the installer instructions and Confirm the solana suite is installed properly by running,

solana --version

Next, we need to set up a paper wallet, that we will use to test our programs locally and deploy them.

solana-keygen new

This command creates a new paper wallet in the ~/.config/solana/id.json directory, though you have the option to tell it where to save the file using the -o, --outfile <FILEPATH> flag.

In this tutorial we will be writing a native Rust Solana Program though it's advisable to use the anchor framework.

Why Native? Because at the moment the solana cli and anchor are incompatible.

Introduction to Tokens in Solana

To start off, in Solana, everything is an account. You have data accounts that, you guessed it, store data and executable account(smart contracts) that run code when certain conditions are met.

In the context of tokens/NFTs, Unlike in Ethereum, where you have predefined standards/interfaces for creating a contract that mint's tokens(nfts included), solana has the Token program. That means you do not have to deploy a contract every time you want to mint a new token. This also makes it really easy to mint token using TypeScript or Python, if you have the web3.js Solana SDK.

Lets talk about some terminologies that usually trip up new developers,

The Token that you want to create. It can be a Fungible ERC-20 like Token or a non-fungible ERC-721 like NFT.
How are Solana tokens different? In Solana to represent a non fungible token, usually has 0 decimals meaning it can not be subdivided any further.
Fungible tokens on the other hand, have the supply greater than one and can have decimals.
The mint accounts or token mint is an account that contains information about a specific token type.
For example, the mint authority(who can create more tokens), freeze authority - who can freeze accounts for a certain mint account, total supply e.t.c
The mint account does not hold any token. It just defines the rules for the token you are creating.
The token account is a general term for any account that holds tokens for a particular mint.
The Associated Token Account, refers to a token account that's associated with a particular primary address.
They are deterministic account that are derived using the address and the mint account.
For example, say a user has 200 tokens associated with a specific mint. He would need to manage all the keys for these tokens. If the user wanted to send or receive a token, he would need to know the token account for a new address beforehand.
With ATA the user can send and receive tokens using his main address. Since the ATA is derived deterministically, it'll be guaranteed to just work.

More in the official documentation.
Metaplex is a protocol built on top of Solana to mint and trade NFTs.
It allows us to attach metadata, images, audio or video to tokens.
Mater Edition is a type of NFT that manages and mints a series of prints or edition from a single piece
of artwork.
This is what enables us to create collection and map related nfts items from the same collection together.
For example, if you have an artpiece and create a master edition for it, you could create 100 unique 'prints' each linked back to the master edition carrying a unique edition number like 1 of 100, 20 of 100 etc
To Bring it all back together:
If you want to create an 10 nfts called MyToken, you would instruct the Token Program to create/mint the MyToken by start initializing the mint account. It would be this account that contains details such as the token decimals, in this case 0 and a total supply of 1. These NFTs are stored in the Token Account. When one of these nfts is transferred to a wallet address, an Associated Token Account is created.
To mint something like a collection of nfts, you would use something like master edition from Metaplex.

It can be hard learning new things, so take a break and revisit these concepts after a few days.

Intro to Native Rust Solana Development.

To get started we will initialize a new empty rust lib project with cargo.

cargo new --lib solana-nft-native

These are the crates that we will need to create our program.

Note: We are using versioned crates because there is a borsh version mismatch between what metaplex and solana-program-library uses.

solana-program crate which provides the necessary APIs that allow us to interact with Solana.
borsh allows us to efficiently encode and decode data structures in a compact binary format.
borsh derive is a procedural macro that allows us to #[derive(BorshSerialize, BorshDeserialize)] our data structs.
spl-token to allow gives us access to the spl-token program.
spl-associated-token-account allowing us to derive associated token accounts.
mpl-token-metadata allowing us to use Metaplex functions to add metadata to our token.

cargo add solana-program@=1.14.20
cargo add borsh@0.9.3
cargo add borsh-derive@0.9.3
cargo add spl-token@3.3.0 --features=no-entrypoint
cargo add spl-associated-token-account@1.0.3 --features=no-entrypoint
cargo add mpl-token-metadata@1.2.5 --features=no-entrypoint

We will also make to our Anchor.toml file.

[lib]
crate-type = ["cdylib", "lib"]

[lib] means that our project, compiles to a library crate, which can be used and linked by other libraries and executable. In the context of our program, we have defined the crate-type options as lib and cdylib, read more

Note: Solana programs must specify the crate-type as cdylib. This enables them to be automatically be discovered and built by the cargo build-spf.

Test everything works properly by building the program.

 cargo build-sbf

If your program builds successfully, let's head into our src/lib.rs file, clear the contents of this file.
populate it with the contents below.

This is a simple hello world program program that logs hello world! when called on a solana cluster like devnet.

use solana_program::{
    account_info::AccountInfo, entrypoint, entrypoint::ProgramResult, msg, pubkey::Pubkey,
};

entrypoint!(process_instruction);

pub fn process_instruction(
    _program_id: &Pubkey,
    _accounts: &[AccountInfo],
    _instruction_data: &[u8],
) -> ProgramResult {
    msg!("Hello, World!");

    Ok(())
}

Let's break down the line:

We get started by bringing into scope the packages that we added using cargo.

use solana_program::{
    account_info::AccountInfo, entrypoint, entrypoint::ProgramResult, msg, pubkey::Pubkey,
};

account_info::AccountInfo - provides the metadata of an account which it carries, including the data it holds, pubkey, etc.
entrypoint - used to mark the entrypoint of a program. Whenever a call is made to a solana program, it's the function in this macro that will be run.
entrypoint::ProgramResult - signifies the result of a program. Did it execute properly or did it return an error.
msg - used to log messages during the execution of a program since dbg! and println! does not work.
Keep in mind that:
- the more frequent your msg calls are, the more computational overhead you will have per transaction.
- the longer your message length, the more data it will consume.
pubkey::Pubkey - solana public key struct. used when you define public key values.

Next we use the entrypoint! macro to define the function that will be called when a tx is made to our program. In our case it is the process_instruction function.

entrypoint!(process_instruction);

Finally we have our process_instruction function.

pub fn process_instruction(
    _program_id: &Pubkey,
    _accounts: &[AccountInfo],
    _instruction_data: &[u8],
) -> ProgramResult {
    msg!("Hello, World!");

    Ok(())
}

Our process_instruction function has three parameters,

_program_id - this the the address of your program. you receive it once you've deployed your program.
_accounts - NOTE: solana programs are stateless. What that means is that there is not data stored on a solana program. Instead you have to create other accounts should you want to write data on-chain and pass them as _accounts arguments. You pass all the account to which you will read/mutate as a slice of accounts.
_instruction_data - This is where you pass in any serialized data that, mutates/writes to accounts that the program interacts with.

Client Side Set-up 1

Let's initialize a new ts project which will act as our client to interact with our program.
I am not a big fan of monorepos so this will be in another directory

mkdir solana-nft-native-client
cd solana-nft-native-client
npm init -y
git init
tsc --init
mkdir src
cd src
touch main.ts utils.ts

Install our versioned ts packages

npm i @metaplex-foundation/mpl-token-metadata@2.13.0 @solana/spl-token@0.3.8 @solana/web3.js@1.78.0  borsh@0.7.0 buffer@6.0.3 fs@0.0.1-security
npm i --save-dev typescript@4.9.5 @types/bn.js@5.1.1

After installing our packages, we will also add an npm command dev, to call ts-node on our client side code. Make sure you have ts-node installed.

. Your finished package.json should resemble,

{
    "scripts": {
        "dev": "ts-node src/main.ts"
    },
    "dependencies": {
        "@metaplex-foundation/mpl-token-metadata": "^2.13.0",
        "@solana/spl-token": "^0.3.8",
        "@solana/web3.js": "^1.78.0",
        "borsh": "^0.7.0",
        "buffer": "^6.0.3",
        "fs": "^0.0.1-security"
    },
    "devDependencies": {
        "@types/bn.js": "^5.1.1",
        "typescript": "^4.9.5"
    }
}

We will also switch our node version to v16.17.1 using nvm. This is because solana-test-validator does not work with anything above v17.

nvm use v16.17.1

Let's write a script to test our hello world program.

First we will create our utility functions to derive our command line wallet Keypair and program Keypair.

NOTE: make sure your PROGRAM_KEYPAIR_PATH and USER_KEYPAIR_PATH paths are set correctly.

Populate your src/utils.ts with,

import { readFileSync } from "fs";
import { Keypair } from "@solana/web3.js";
import { homedir } from "os";

const PROGRAM_KEYPAIR_PATH =
    homedir() +
    "/Documents/web3/solana/solana-nft-native/target/deploy/solana_nft_native-keypair.json";
const USER_KEYPAIR_PATH = homedir() + "/.config/solana/id.json";

export function userKeyPair(): Keypair {
    return Keypair.fromSecretKey(
        Buffer.from(JSON.parse(readFileSync(USER_KEYPAIR_PATH, "utf-8")))
    );
}

export function programKeyPair() {
    return Keypair.fromSecretKey(
        Buffer.from(JSON.parse(readFileSync(PROGRAM_KEYPAIR_PATH, "utf-8")))
    );
}

console.log("user keypair", userKeyPair().publicKey.toString());
console.log("program keypair", programKeyPair().publicKey.toString());

Running the script above with npm run dev should print the two public keys.

Next we will write client code to call our program. If everything runs successfully, then our program should log hello world.

Populate main.ts with

import {
    Connection,
    Keypair,
    PublicKey,
    sendAndConfirmTransaction,
    Transaction,
    TransactionInstruction,
} from "@solana/web3.js";
import { userKeyPair, programKeyPair } from "./utils";

let connection = new Connection("http://localhost:8899");
let programId = programKeyPair().publicKey;
const payer = userKeyPair();

async function helloWorld(): Promise<String> {
    const ix = new TransactionInstruction({
        keys: [],
        programId,
    });

    const tx = new Transaction().add(ix);

    return await sendAndConfirmTransaction(connection, tx, [payer]);
}

helloWorld()
    .then((txSig) => console.log("tx sig: ", txSig))
    .catch((err) => console.error("program execution unsuccessful", err));

In the code snippet above, we define three global variables:

connection which we use to communicate with the solana network. Right now, it is set to connect to our local solana network.
programId is our program's public key
payer is our keypair which we will use to pay for transactions.

To understand the function, you must understand how transactions work in solana. In Solana a transaction can contain one of multiple instructions. And what are instruction? Simply, it is a method or functions of a Solana program.

In solana an instruction takes in three arguments, the first being the addresses of the programs the instruction will interact with the programIdand finally data which you want to write to an account. In our ix, the data is omitted because we are not writing to any account.

The sendAndConfirmTransaction method allows us to send and sign transactions.

To ran our client, we will need to set up a local validator. In a new terminal window run

solana-test-validator

Next we will need the solana cli to send our transaction to this test-validator we are running with

solana config set --url localhost

We will now compile our program and deploy it. Run the build-sbf command in your program directory.

cargo build-sbf

We will now deploy our compiled program. This will be the .so (shared object) file in the target/deploy directory.

solana program deploy solana_nft_native.so

Head back to the directory where you wrote your client code.

Open a new terminal window or tab. We will use this to view our program logs

solana logs --url localhost

We will now run our client script and if successful, we should see the logs with the string Hello, World! logged out.

With the basics in place, let's head back to where our program code lives and write the code to mint our nft.

More on Native Rust Solana Dev

Clear everything except our package imports. We will start by importing borsh for serialization.

use borsh::{BorshDeserialize, BorshSerialize}; //new
use mpl_token_metadata::instruction as mpl_instruction; //new
use solana_program::{
    account_info::{next_account_info, AccountInfo}, //new
    entrypoint,
    entrypoint::ProgramResult,
    msg,
    program::invoke,    //new
    pubkey::Pubkey,
    rent::Rent,         //new
    system_instruction, //new
    sysvar::Sysvar,     //new
};
use spl_token::{instruction as token_instruction, state::Mint}; //new

entrypoint!(process_instruction);

pub fn process_instruction(
    _program_id: &Pubkey,
    _accounts: &[AccountInfo],
    _instruction_data: &[u8],
) -> ProgramResult {
    msg!("Hello, World!");

    Ok(())
}

The new imports:

borsh::{BorshDeserialize, BorshSerialize}; - serialize and deserialize our data.
mpl_token_metadata::instruction as mpl_instruction; - provides functions for us to interact with the Metaplex Token Metadata program.
account_info::{next_account_info function is used to parse accounts passed in as input to our Solana program. Remember that Solana need to know before hand the accounts that it will touch, and this is done by providing the addresses of said accounts.
program::invoke is used to make Cross Program Invocations. It takes two arguments. The instructions to run and the accounts that it will touch.
rent::Rent is used to pay for the storage space we will take up when storing data on the blockchain.
system_instruction is a module that allows us to construct system level instructions that directly interact with the Solana blockchain. For example, when creating an account, you would make a call using a system instruction.
sysvar::Sysvar - is a module that provides various system variables about the state of the blockchain. They are read only. For example you might want to use the Clock Sysvar that contains information about the epochs and slots
spl_token::{instruction as token_instruction, state::Mint}; - provides methods for us to interact with the token program.

When creating our token, we will need to pass in a title, symbol and our metadata uri. This data will need to be serialized and deserialized so that the client and the program can make sense of it. To do this we will use the Serialize and Deserialize borsh traits in a derive attribute.

We will pass on these arguments to the Metaplex Metadata Program

#[derive(BorshSerialize, BorshDeserialize)]
pub struct CreateTokenArgs {
    pub nft_title: String,
    pub nft_symbol: String,
    pub nft_uri: String,
}

Next, let's invoke the function that will call our token and metaplex program. We will call it create_nft.


fn create_nft(accounts: &[AccountInfo], create_token_data: CreateTokenArgs) -> ProgramResult {
    let accounts_iter = &mut accounts.iter();

    let mint_account = next_account_info(accounts_iter)?;
    let mint_authority = next_account_info(accounts_iter)?;
    let metadata_account = next_account_info(accounts_iter)?;
    let payer = next_account_info(accounts_iter)?;
    let rent = next_account_info(accounts_iter)?;
    let system_program = next_account_info(accounts_iter)?;
    let token_program = next_account_info(accounts_iter)?;
    let token_metadata_program = next_account_info(accounts_iter)?;

    Ok(())
}

The functions takes a slice of type AccountInfo and create a mutable iterator for the accounts input. it is from this accounts that we pull out the accounts that are required to create an nft while interacting with the metadata and token programs.

The mint_account contains details about the mint.
The mint_authority contains the address of the person who will control the mint
The metadata_account as it's name suggests will store the metadata details
The payer contains the account that will bare the costs for minting the nft and rent for opening the required accounts.
rent. When opening an account, you need to set aside SOL to pay for it. You can recover this once you close an account.
system_program This executable accounts/program is what is responsible for opening up new accounts. In Solana a good mental model to think about things is that every program/accounts will always have an owner that controls it.
token_program will be the address for our token program, while token_metadata_program will be the address for the token metadata program.

We are now ready to start calling instructions that will create our nft.

// invoke the system program to create our account
    msg!("Creating mint account...");
    msg!("Mint: {}", mint_account.key);
    invoke(
        &system_instruction::create_account(
            &payer.key,
            &mint_account.key,
            (Rent::get()?).minimum_balance(Mint::LEN),
            Mint::LEN as u64,
            &token_program.key,
        ),
        &[
            mint_account.clone(),
            payer.clone(),
            system_program.clone(),
            token_program.clone(),
        ],
    )?;

What is this ↑ piece of code doing? Well, we are using invoke to make a cross program call between our system_program and our token_program. To make a CPI call, you need to pass the instruction you want to call and all the accounts that the call interacts with as arguments.

In the first parameter for our instruction we are calling the create_account instruction from system_program to initialize a new account. These are the parameters we are required to pass to our instruction -

&payer.key Is the public key that will pay for the accounts creation,
&mint_account.key Is the public key for the account being created,
(Rent::get()?).minimum_balance(Mint::LEN), when creating an account in solana, you are required to pay for blockspace. There is not such thing as a free lunch. To store data on Solana in an account, you need to pay for it.
To note, is that there code above is checking whether our account is rent exempt. We check the minimum_balance required to keep the account rent exempt
rent exempt is a concept in Solana that allows an account to not incur any rent rent collection for a duration of two years.
Rent is the program that manages this.
Mint::LEN as u64 is passed in to determine the length/space our account will take. The default size is 82 bytes
&token_program.key is the address of the account that owns or account. In this case it's the token_program.

The next parameter is a slice of the account that invoke will touch.

Next we initialize the created account as the mint account

    //initialize the created account as the mint
    msg!("Initializing mint account...");
    msg!("Mint: {}", mint_account.key);
    invoke(
        &token_instruction::initialize_mint(
            &token_program.key, //token program public key
            &mint_account.key, //mint public key
            &mint_authority.key, //mint authority
            Some(&mint_authority.key), //freeze authority
            0, //decimals
        )?,
        &[
            mint_account.clone(),
            mint_authority.clone(),
            token_program.clone(),
            rent.clone(),
        ],
    )?;

As with the previous invoke call, we pass two arguments to this method. One is the instructions that we will invoke and the second is the accounts that the cross program call will touch.

our token_instruction::initialize_mint takes in 5 parameters, as indicated by the comments.
To note, is the no of decimals. For a token in Solana to be non-fungible, it should not be divisible, hence zero.

To finish off our program, we call the token metadata program from Metaplex. We will use the create_metadata_accounts_v3 instruction to create our Metadata.

 //call Metaplex token metadata program
    msg!("Creating metadata account...");
    msg!("Metadata account address: {}", metadata_account.key);
    invoke(
        &mpl_instruction::create_metadata_accounts_v3(
            *token_metadata_program.key, //program id
            *metadata_account.key,       // metadata address
            *mint_account.key,           //mint address
            *mint_authority.key,         //mint authority address
            *payer.key, //payer public key address
            *mint_authority.key, //update authority address
            create_token_metadata.nft_title, //nft title
            create_token_metadata.nft_symbol, //nft symbol
            create_token_metadata.nft_uri, //nft uri
            None, //creators. for something you pass in a VEC of their addresses
            0, //royalties
            true, //is the payer the update authority
            false, //can we update the token metadata
            None, //collection the nft belongs to. struct of pubkey and
            None, //uses
            None, //collection details
        ),
        &[
            metadata_account.clone(),
            mint_account.clone(),
            mint_authority.clone(),
            payer.clone(),
            token_metadata_program.clone(),
            rent.clone(),
        ],
    )?;

    msg!("Token mint created successfully.");

The code pattern is the same as the previous one. We first call invoke with two arguments. The instruction and the accounts we touch.

The create_metadata_accounts_v3 will create our metadata account and write to it our metadata information. Each argument is commented to show what it represents.

To finally, finally finish off our program, we being our create_token into our process_instruction function which will now look like this

pub fn process_instruction(
    _program_id: &Pubkey,
    accounts: &[AccountInfo],
    instruction_data: &[u8],
) -> ProgramResult {
    let token_metadata = CreateTokenArgs::try_from_slice(instruction_data)?; //new

    create_nft(accounts, token_metadata)?;

    Ok(())
}

The method is not something that is new. What is new, is try_from_slice. Remember that to efficiently sent messages to and from Solana and reduce computational overhead, your data needs to be serialized to a format(binary format) that can efficiently do this.

Thetry_from_slice method is part of the BorshDeserialize trait, and it's used to convert a byte slice (&[u8]) into an instance of our CreateTokenArgs.

And yes, You will need to serialize data from the client side too. This is why a lot of dev prefer using anchor as it automatically handles this boilerplate of serializing and deserializing data.

Altogether your src/lib.rs should resemble.

use borsh::{BorshDeserialize, BorshSerialize};
use mpl_token_metadata::instruction as mpl_instruction;
use solana_program::{
    account_info::{next_account_info, AccountInfo},
    entrypoint,
    entrypoint::ProgramResult,
    msg,
    program::invoke,
    program_pack::Pack,
    pubkey::Pubkey,
    rent::Rent,
    system_instruction,
    sysvar::Sysvar,
};
use spl_token::{instruction as token_instruction, state::Mint};

entrypoint!(process_instruction);

pub fn process_instruction(
    _program_id: &Pubkey,
    accounts: &[AccountInfo],
    instruction_data: &[u8],
) -> ProgramResult {
    let token_metadata = CreateTokenArgs::try_from_slice(instruction_data)?;

    create_nft(accounts, token_metadata)?;

    Ok(())
}

#[derive(BorshSerialize, BorshDeserialize)]
pub struct CreateTokenArgs {
    pub nft_title: String,
    pub nft_symbol: String,
    pub nft_uri: String,
}

fn create_nft(accounts: &[AccountInfo], create_token_metadata: CreateTokenArgs) -> ProgramResult {
    let accounts_iter = &mut accounts.iter();

    //pick out our accounts
    let mint_account = next_account_info(accounts_iter)?;
    let mint_authority = next_account_info(accounts_iter)?;
    let metadata_account = next_account_info(accounts_iter)?;
    let payer = next_account_info(accounts_iter)?;
    let rent = next_account_info(accounts_iter)?;
    let system_program = next_account_info(accounts_iter)?;
    let token_program = next_account_info(accounts_iter)?;
    let token_metadata_program = next_account_info(accounts_iter)?;

    // invoke the system program to create our account
    msg!("Creating mint account...");
    msg!("Mint: {}", mint_account.key);
    invoke(
        &system_instruction::create_account(
            &payer.key,
            &mint_account.key,
            (Rent::get()?).minimum_balance(Mint::LEN),
            Mint::LEN as u64,
            &token_program.key,
        ),
        &[
            mint_account.clone(),
            payer.clone(),
            system_program.clone(),
            token_program.clone(),
        ],
    )?;

    //initialize the created account as the mint
    msg!("Initializing mint account...");
    msg!("Mint: {}", mint_account.key);
    invoke(
        &token_instruction::initialize_mint(
            &token_program.key,
            &mint_account.key,
            &mint_authority.key,
            Some(&mint_authority.key),
            0,
        )?,
        &[
            mint_account.clone(),
            mint_authority.clone(),
            token_program.clone(),
            rent.clone(),
        ],
    )?;

    //call Metaplex token metadata program
    msg!("Creating metadata account...");
    msg!("Metadata account address: {}", metadata_account.key);
    invoke(
        &mpl_instruction::create_metadata_accounts_v3(
            *token_metadata_program.key,      //program id
            *metadata_account.key,            // metadata address
            *mint_account.key,                //mint address
            *mint_authority.key,              //mint authority address
            *payer.key,                       //payer public key address
            *mint_authority.key,              //update authority address
            create_token_metadata.nft_title,  //nft title
            create_token_metadata.nft_symbol, //nft symbol
            create_token_metadata.nft_uri,    //nft uri
            None,  //creators. for something you pass in a VEC of their addresses
            0,     //royalties
            true,  //is the payer the update authority
            false, //can we update the token metadata
            None,  //collection the nft belongs to. struct of pubkey and
            None,  //uses
            None,  //collection details
        ),
        &[
            metadata_account.clone(),
            mint_account.clone(),
            mint_authority.clone(),
            payer.clone(),
            token_metadata_program.clone(),
            rent.clone(),
        ],
    )?;

    msg!("Token mint created successfully.");

    Ok(())
}

To finish off our program side development, we are going to build and deploy our program on devnet.

solana config set --url devnet
cargo build-sbf
solana program deploy solana_nft_native.so

Note: Your so file is in the target/deploy directory.

Client Side Set-up 2

We are almost at the end of our journey of creating nfts for Solana.

Going back to where you set up your client code before. You can comment out the helloWorld function we wrote. We will create a class to serialize our data.

class TokenArgs {
    nft_title: string;
    nft_symbol: string;
    nft_uri: string;

    constructor(nft_title: string, nft_symbol: string, nft_uri: string) {
        this.nft_title = nft_title;
        this.nft_symbol = nft_symbol;
        this.nft_uri = nft_uri;
    }

    serializeCreateTokenData(data: TokenArgs): Uint8Array {
        const schema = new Map([
            [
                TokenArgs,
                {
                    kind: "struct",
                    fields: [
                        ["nft_title", "string"],
                        ["nft_symbol", "string"],
                        ["nft_uri", "string"],
                    ],
                },
            ],
        ]);
        return Buffer.from(borsh.serialize(schema, data));
    }
}

We have abstracted the logic to serializing our data to the TokenArgs class.

In it we have our constructor which sets our nft_title, nft_symbol and nft_uri member variables.

Next we have our serializeTokenData method which contains our borsh schema and it's this methods that serializes our data, ready to be send to our program.

We then set up our createToken function. We will create our mint accounts keypair using Keypair.generate(); functions and derive a pda which will store our metadata. The seeds to do so are metadata, TOKEN_METADATA_PROGRAM_ID and mintKeypair.publicKey.

import { PROGRAM_ID as TOKEN_METADATA_PROGRAM_ID } from "@metaplex-foundation/mpl-token-metadata";

const mintKeypair: Keypair = Keypair.generate();

const metadataAddress = PublicKey.findProgramAddressSync(
    [
        Buffer.from("metadata"),
        TOKEN_METADATA_PROGRAM_ID.toBuffer(),
        mintKeypair.publicKey.toBuffer(),
    ],
    TOKEN_METADATA_PROGRAM_ID
)[0];

Let finish off by declaring our data variables and assigning them appropriately.

async function createToken(): Promise<String> {
    let connection = new Connection("http://localhost:8899");
    let programId = programKeyPair().publicKey;
    const payer = userKeyPair();

    const mintKeypair: Keypair = Keypair.generate();

    const metadataAddress = PublicKey.findProgramAddressSync(
        [
            Buffer.from("metadata"),
            TOKEN_METADATA_PROGRAM_ID.toBuffer(),
            mintKeypair.publicKey.toBuffer(),
        ],
        TOKEN_METADATA_PROGRAM_ID
    )[0];

    const instructionData = new TokenArgs(
        "Kobeni",
        "KBN",
        "https://raw.githubusercontent.com/687c/solana-nft-native-client/main/metadata.json"
    );

    let ix = new TransactionInstruction({
        keys: [
            { pubkey: mintKeypair.publicKey, isSigner: true, isWritable: true }, // Mint account
            { pubkey: payer.publicKey, isSigner: false, isWritable: true }, // Mint authority account
            { pubkey: metadataAddress, isSigner: false, isWritable: true }, // Metadata account
            { pubkey: payer.publicKey, isSigner: true, isWritable: true }, // Payer
            { pubkey: SYSVAR_RENT_PUBKEY, isSigner: false, isWritable: false }, // Rent account
            {
                pubkey: SystemProgram.programId,
                isSigner: false,
                isWritable: false,
            }, // System program
            { pubkey: TOKEN_PROGRAM_ID, isSigner: false, isWritable: false }, // Token program
            {
                pubkey: TOKEN_METADATA_PROGRAM_ID,
                isSigner: false,
                isWritable: false,
            }, // Token metadata program
        ],
        data: instructionData.serialize(),
        programId: programId,
    });

    const modifyComputeUnits = ComputeBudgetProgram.setComputeUnitLimit({
        units: 1000000,
    });

    const tx = new Transaction().add(modifyComputeUnits).add(ix);

    return await sendAndConfirmTransaction(connection, tx, [
        payer,
        mintKeypair,
    ]);
}

In our script above, we modify our tx and increase our compute units. This will prevent us from running into unwanted, compute limit exceeded errors.

Note:, you need to pass in all account that sign, in the signers array. In our case, these are, payer and mintKeypair.

createToken()
    .then((txSig) =>
        console.log(`tx hash: https://solscan.io/tx/${txSig}?cluster=devnet`)
    )
    .catch((err) => console.error("program execution unsuccessful", err));

And finally, finally, let's call our client script, npm run dev.

Open the link returned after running your script. It should take you to the solscan explorer.

To look at our token on solscan, we will click on the second signer. The one surrounded by a yellow border. That is our token mint account.

Open the second account and it should show you the details about the nft you created.

Find the code for the client side here and for the Solana program here.

And finally, huge shout out to the Solana program examples repository from where the code for this article was lifted. 😂

In the next part we modify our code to mint the tokens directly to our wallet or a specified address.

Open source projects are taking on SaaS giants.

Jimmy — Wed, 01 Dec 2021 19:09:55 +0000

Open source and SaaS. If you're in tech you've probably heard these terms being thrown around. Even if you aren't into tech, there are very high chances that you've at some point interacted with a product defined by these two terms.

Open source by definition includes software whose source code is publicly made available to everyone. Now, even though the source code is freely made available for everyone to inspect and make sure that nothing shady is going on behind the scenes, it doesn't necessary mean that it's to be free. Same goes for free software free as in speech not as in beer, that puts emphasis on the freedom of the user to do whatever they want with it. Even though free software and Open source might interlap in so many ways in their definition, free software is well .. software while an open source project might be just a couple lines of code you make public. GNU + Linux, VLC, Blender, anything that has the apache rubber stamp on it are all open source. Big companies too, after seeing the success of open source projects have also open sourced some of their work. VScode by Microsoft -not technically open but you take what you can get-, Angular 2 by Google and react by Facebook open source are some top tier projects which, if we to turn back time to two decades ago, would probably and most likely be proprietary. Heck at some point in History Java was proprietary.

Switching gears to the other elephant in this virtual room, we have Software as a Service (SaaS). It is a product or Software, but mostly product that is made available to users over the internet for a subscription. Netflix, Spotify, Crunchyroll etc. Any software that must be connected to the internet to work and that you must pay for can be defined as a SaaS product.

Most of the SaaS products are proprietary and their code is hidden from their users, unless you're twitch off-course 😂. Why? Because most of these platforms are extorting millions and millions of dollars from you by selling your data, but hey, you get to watch the latest, greatest, most incredible show by Leonardo DiCaprio and go to Twitter to share your opinion with the entire planet? (I'm not being sarcastic)

I know the tension is killing most of you reading this masterpiece of a blog post, wanting to know what I am trying to sell you. Let's change that.

Chatwood an open source software as a service product that allows companies to not only interact with their ccustomers/clients not only from the website alone, but also from other social mediums such as WhatsApp, FaceBook and Instagram. So why Chatwood? What makes it better than the rest if the bunch.

To paraphrase an article by big commerece on the importance of open source, 'by removing the barriers to the barriers between innovators, open sourced projects allow and drive competition and innovations within the community, enabling new or improving on previous projects'. Chatwood is a perfect embodiment of this sentiment. The project, initially a customer support software failed to take off as a business and was shut down. Still, to the surprise of the maintainers, got a lot of love from the community when they decided to open source it during Hacktoberfest. This is hugely thanks to the support from contribution from open source contributors which has enabled it thrive and compete with industry SaaS giants that also offer customer support software.

By integrating the open source community to their community the maintainer of Chatwood have enabled new and innovative ideas to be incorporated into their product while also getting support to fix previous bugs. This makes Chatwood even more secure. How so? .Everyday we see news of hackers finding new ways and creating new tool to exploit vulnerabilities in proprietary software. In a perfect world the security teams behind these products should be able to thwart these threats. But the world is not perfect, its flawed and broken and in this man eat man society everyone will do whatever it takes to get the bag, be it something illegal like holding code for the product for ransom. So how does this differ for open source products. Like I said Chatwood, while being open source does make money. What is stopping hackers from exploiting it? While security bugs do exist and are common place to anything that is ones and zeros, open source companies have the added benefit that everyone has access to the code and the permission to modify it. All without having to worry about the End User Agreements that users of proprietary software agree to. Chatwood also enjoys this added advantage. With developers from across the globe analyzing and testing the code for any vulnerabilities and patches being ruled out for fixes, you can be sure that your customers will be safe from exploitation and even if a bug is discovered someone from the community will be quick enough to roll out a patch for the fix. Another fight that open source is winning against industry giants.

No, it's not the bad ending you were thinking of it to be. As previously stated, Chatwood once died but thanks but after three days... no, no, not that story... Chatwood, as a proprietary project once shut down because it did not take off. But once it open sources, because of contributions from netizens around the world, It was granted a new lease on life. In the future, the maintainers may decide to hand over the project to new ones but they can be assured that support from the community will still be coming in. A good example of this longevity is GNU + Linux - the powerhouse operating system that drives the internet - Although the project has been around for over two decades it is still thriving and going on strong. This is not because GNU + Linux has some hidden piece of code that is monetized. Nop. It is because of the strong open source community behind it. When it started folks in the tech industry were hungry for an operating system that they could extend and they still are. There are no limitations on what you can do with it, extend it as you please and configure it according to what you like and dislike. As with Chatwood, you can also self host and extend some of the functionality if the default configuration does not please you. A feature that industry giant proprietary software do not come with.

JIM'S definitive guide to using GNU-NANO

Jimmy — Sat, 29 Aug 2020 20:16:42 +0000

Nano or GNU Nano is a text editor that comes with almost every Linux distro these days.Now according to Wikipedia, the original name of the editor was tip, but tot avoid naming conflicts, it was changed to Nano, in which nano is 1000 times awesomer than pico(yet another text editor).
If you would like to know more about the history then this Wikipedia link is your best friend.

Now until recently, I did not know of about any of these features until I stumbled upon the help section of the editor. Now if you’re like me and would not like to spend half a day figuring out how to get started here is my divinely definitive short guide to using the nano editor effectively.

If you do not have it installed, sudo apt-get install nano will do the trick if you’re on a Debian based system. To launch nano just go to your terminal and type nano with the file you’d like to edit or just start from scratch like a madman. Now a full list of these command can be accessed easily by going to CTRL + G.

Lets begin. Sometimes you will want to enable mouse support and turns out this can be done quite easily using ALT + M or by pressing the escape key and then M depending on your preferences. There you go, now it is possible to navigate to line 328 in your file using the mouse cursor, without the hustle and bustle of using the down key. The command can be quite useful for example, setting the encryption key in a GCP .boto file. God this was impossible to find.

For those developers who would like to see the number of lines of code they have written there is the ALT + # to take care of your self esteem. This is another handy one. It was one of the main reasons I stumbled upon those commands. Again you could press the escape key and then # depending on your preferences.

To cut a section of line and save it in the cutbuffer use CRTL + K and to uncut it, use CTRL + U. Another conundrum that you might be faced with might be, how do you highlight a section of the file. Well to do this, you set a mark using ALT + A that is, the beginning of the line you want to cut and using the mouse cursor click the end of where you want your operation to end. To completely delete or throw way the marked or highlighted line use ALT + DEL.

Now one major feature that is super useful these days while working with large files is syntax highlighting and NANO out of the box comes with it enabled(my version 3.2 at least has it). Now if you’re a psychopath who hates colors there is also a command to turn it off using ALT + Y. If you have a linter all set up to your preferred coding style, you could make use of it using ALT + B. The spell check could be put into good use using CTRL + B , if it is available.

In the spirit of keeping this document short, I am going to end it here. NANO does have other features but you would be better off to using a text editor like VS code or its clone VS Codium for full-blown development. The options listed here are for working with touch and go files.

APPS YOU SHOULD USE WITH DEEPIN OS

Jimmy — Sat, 02 May 2020 12:54:42 +0000

I have been using Deepin as my main operating system for slightly over six months now, and i can proudly proclaim that the experience has been somewhat pleasant. Although its far from perfect like, and cannot compare to heavy weights like Ubuntu,it gets the job done.

Enough about my feelings about it, lets get to the meat and beans of things, and here is a list of apps you should get and what you should use if by any chance you decide to try out Deepin.

VS CODE
It goes without saying that this is the best editor out there and nothing comes close. Almost every web developer on the globe uses it, and why wouldn’t they. It offers a plethora of tools and supports almost every programming language known to man with extensions that make development feel like a hobby, that is if your not dealing with bugs. The main selling point for me about this editor is the ability to customize it in whichever way pleases me. Do not get me wrong atom too does well in this sector but the fact that it does not feature a way to remove the ugly annoying tittle bar really set me off.
NETBEANS
On our list the second development tool is Netbeans. I also do not know who or what is behind the name. Its a java application for writing, well you guessed it java programs with extensions for writing c/c++ applications, node js apps and php. It is a very powerful IDE and i use it for writing c++ and so far it has never failed to deliver. It also features an extension for removing the title bar so you can guess why i love it so much. If you do get the IDE i recommend using darkula LAF as your theme.
Deepin editor
As the name suggests this is also an editor but it does not have any of the fancy features that vs code offers like intelis-sense and so on. So do not even think about writing programs on it, you have been warned. Typically when you clone a project and have a file that you need to look at quickly you should use this. There is no point in going throught the hussle and bussle of opening a project with an ide just to change on line.
If you have never used notepad+++ then give this a try and if you have, still, give this a try. It comes as one of the bloatware with deepin so need to install it,
Chrome
Now ,if your new to coding you have probably been told that googling is your best friend. So why not use the browser made by google. Chrome is by far the most used browser in the world. And this is the reason why i probably use it. The ability to save passwords and bookmarks and sync them across different devices is very productive. It also features some very powerful developer tools. This is also among the bloatware that Deepin comes with so no need to install it although, it is outdated and i highly recommend you update it once you get the OS.
FIREFOX
Another awesome browser is Firefox. It also supports the features that chrome supports like password saving and sharing. I will not talk about it extensively because i do not use as much as chrome. What i do like about it and what every other web developer will say is that, it has the best CSS features out there when writing web pages, especially when working with CSS grid.
LOLLIPOP
This is by far the best music player for Dinux right now. In terms of user interface nothing else comes close. It features an album view, artist listing and an equalizer although not the best. It also has lyrics support so give it too a try. If you would like a music player to play your music offline this is for you. You might struggle with the installation a few times if your installing it directly from source but its worth it.
WPS OFFICE SUITE
Yes , this is also bloatware that Deepin comes with and it is what is use personally: wps writer for my essays and pdf viewer for viewing pdf documents. It is really pleasing and the interface looks very nice. You could buy the premium suite but software is best enjoyed when it is free.