Forem: Sergei Sumarokov

Utilizing ChatGPT to Interact with a Blockchain-Based Game

Sergei Sumarokov — Thu, 20 Apr 2023 10:46:36 +0000

In this article, we will guide you through the process of developing a prototype bot using OpenAI's ChatGPT 3.5 API, designed to participate in Moonstream.to's blockchain-based text game, Great Wyrm. The completed code can be found in the kompotkot/gofp-chatgpt-bot repository.

Great Wyrm serves as a platform for hosting game sessions in a "game master - players" format. As the game undergoes active testing, its creators independently facilitate game sessions. The platform operates on Caldera's wyrm.constellation blockchain network. To join, register through the provided Discord link.

Our code will be written in Python. Since Great Wyrm is built upon the Ethereum blockchain, we will utilize the brownie library for network interactions and the moonworm library to generate a Python interface from the ABI.

Typically, for popular games, ABIs can be located on Etherscan under the "Code" tab, within the project's GitHub repository, or generated independently from .sol files using tools such as brownie. For the Great Wyrm game, the contract can be accessed through a GitHub link, while the prepared ABI is available in Moonstream's documentation.

Nonetheless, having only the ABI requires us to reconstruct the brownie structure for proper functionality. To accomplish this, follow these steps to create the necessary folders and copy the ABI:

mkdir -p gcb/build/contracts/
cp abi/GOFP.json gcb/build/contracts/gofp.json

The resulting file, gcb/build/contracts/gofp.json, should appear as follows:

{
  "abi": [
    ...
  ]
}

First, generate an interface at the ABI address, which will produce a Python file named gcb/gofp.py containing the gofp class and methods that outline the smart contract's functionality:

moonworm generate-brownie --name gofp -o gcb -p gcb

Subsequently, the wyrm is added to brownie's local list of networks:

brownie networks add Constellation wyrm host=https://wyrm.0xconstellation.com/http chainid=322

With the first part completed, we can now communicate with the smart contract by simply introducing a variable:

export GOFP_CONTRACT_ADDRESS="0x42A8E82253CD19EF8274D48fC0bC89cdf1B4425b"

Let's query the smart contract to determine the total number of game sessions:

python -m gcb.gofp num-sessions --network wyrm --address "$GOFP_CONTRACT_ADDRESS"

Next, we will proceed to configure ChatGPT. This requires an API key generated on the OpenAI website, which enables interaction with the platform. Add this key to the code using a variable:

export OPENAI_API_KEY="sk-..."

To test the functionality, let's inquire about the available GPT models for usage:

curl https://api.openai.com/v1/models -H "Authorization: Bearer $OPENAI_API_KEY" | jq .data[].id | grep gpt

Finally, return to the source code and examine important parts:

drwxrwxr-x build
-rw-rw-r-- cli.py
-rw-rw-r-- data.py
-rw-rw-r-- gofp.py
-rw-rw-r-- __init__.py
-rw-rw-r-- version.py
-rw-rw-r-- version.txt

In the data.py file, we will utilize the pydantic library to define key structures such as SessionData, SessionDataStages, etc., for added convenience. The primary code can be found in cli.py.

While generating the CLI with argparse, it is necessary to enhance the parser with pre-generated flags and arguments sourced from gofp.py:

add_default_arguments(parser=parser_play, transact=True)

Next, we require two primary arguments: --session to designate the game session to participate in, and --token to identify the token to operate with. Within the main handle_play function, first connect to the brownie network and initialize the contract instance:

network.connect(args.network)
contract = gofp(contract_address=args.address)

Utilizing the moonworm library, we communicate with the smart contract via methods, allowing us to obtain information about the desired game session:

session_info_raw = contract.get_session(args.session)
...
current_stage_indexed = contract.get_current_stage(args.session)

All that remains is to parse the response based on the structures defined in data.py and complete the logic that filters out inactive sessions, among other things.

Each session functions as a unique token, with its own tokenURI containing game stage descriptions, lore, and more. We will obtain this information using the fundamental requests library, implemented in the requests_call function, and parse it according to our predefined structures:

session_data_raw = requests_call(method=data.Method.GET, url=session_info.uri)

Now, we should prepare text for ChatGPT. In this example, we will describe the expected task and request a JSON-formatted response. Under the answer key, ChatGPT should indicate its chosen path in the game, while providing a rationale for the choice under the description key:

message_to_bot = f"""Let's play. I will provide you with a short lore containing 
different paths to choose from. Please respond in JSON format. You should select 
one correct path and place it under the key 'answer' and provide an explanation 
for your choice under the key 'description'.

The lore: {session_data.stages[current_stage].lore}
Paths:
{paths}
"""

Request a response from ChatGPT, ensuring a high timeout value is specified, as responses may occasionally take longer than expected:

openapi_headers = {
    "Authorization": f"Bearer {OPENAI_API_KEY}",
}
payload = {
    "model": "gpt-3.5-turbo",
    "messages": [{"role": "user", "content": message_to_bot}],
}

bot_resp_raw = requests_call(
    method=data.Method.POST,
    url=f"{OPENAPI_BASE_URL}/completions",
    headers=openapi_headers,
    json=payload,
    timeout=60,
)

For more comprehensive interaction with the bot, OpenAI offers a range of detailed settings available in the endpoint documentation.

Upon receiving a response, we will process it and generate a transaction:

transaction_config = get_transaction_config(args)

tx_hash = contract.choose_current_stage_paths(
    session_id=args.session,
    token_ids=[args.token],
    paths=[bot_answer + 1],
    transaction_config=transaction_config
)

Once prepared, using your keyfile, execute the code with the following command:

gcb play --address "$GOFP_CONTRACT_ADDRESS" \
  --network wyrm \
  --confirmations 0 \
  --sender "$DEV_KEYFILE" \
  --password "$DEV_KEYFILE_PASSOWRD" \
  --session 4 \
  --token 2

The bot will retrieve the necessary data, parse the result, and report the transaction details:

INFO:gcb.cli:Fetch session 4 with stages [4, 1] and uri https://s3.amazonaws.com/static.greatwyrm.xyz/act1/reda_games/khina_beast_contest.json
INFO:gcb.cli:Current stage of session 4 is 1
INFO:gcb.cli:Fetch session data with title Khina's Beast Contest and active stage title Pit bat
INFO:gcb.cli:Asking ChatGPT to choose path
INFO:gcb.cli:Bot answer is: 1 and description: I would back the Copper hound because it has a useful skill that people could benefit from by sniffing out copper deposits. Additionally, they seem to be domesticated dogs so they may be more manageable than some of the other creatures. The downside is that they are not the most pleasant smelling animals and can be quite loud.
Transaction sent: 0x32bdff6127fdb94f0199f5cc10565c82fffb26768a1029f469a4b205fc5ed9fd
  Gas price: 0.0 gwei   Gas limit: 156629   Nonce: 15
  gofp.chooseCurrentStagePaths confirmed   Block: 470   Gas used: 118554 (75.69%)

<Transaction '0x32bdff6127fdb94f0199f5cc10565c82fffb26768a1029f469a4b205fc5ed9fd'>

In conclusion, we have successfully established an integration between ChatGPT and Web3, laying the groundwork for a chatbot capable of engaging with a blockchain-based game. This combination offers numerous possibilities for extending functionality and tailoring the solution to various tasks and objectives.

Algorithmic Survival in the Metaverse

Sergei Sumarokov — Thu, 15 Sep 2022 17:58:37 +0000

When we started playing Conquest.eth, we discovered how a multiplayer web3 game can become a hostage of a player or guild. This can alienate new players by making it harder for them to get settled in the game.

We set ourselves the goal of building a bot to successfully resist these guilds. This document explains how we used the Moonstream API, moonworm to parse game activity directly from the Gnosis blockchain and to create a large enough horde of ships to break the guild’s stranglehold on the galaxy. Below you will find a brief article in the form of a story.

Interactive map of all past events in conquest eth is available at Moonstream Play portal for Conquest.eth game

Block number 22,455,457. First initialization of the system. A unique event has taken place, a bith of consciousness in an organism, infinitely far from biological origin. The program, the artificial stupidity, the number-cruncher explicitly designed to be so simple, even people of the ancient era would develop it. It has no tasks, no goals and no understanding of what was happening around him. The subroutine was built to produce ships with one standard with parameters: attack 7200 and defense 9600.

The cluster of stars and planets known as defcon of the conquest-eth universe consisted of about 3500 stellar bodies. The number of intelligent races was striking in its diversity, dispersed over the known star map among thousands of stars, life was in full swing. The algorithm appeared in the center of known space. In a seconds the mind flooded with a wave of information from many sources. News came from the expanding reaches of deep space in 1 thousand block segments. Empires rose and fell in the time it took the algorithm to recognize itself, but its mind is still stuck to the simple schemas and patterns.

17,280 blocks later, the home planet of the newborn artificial intelligence was attacked, the consciousness was erased, the chains of algorithms was destroyed. The purpose of the invaders remained unknown. What was their objective, why did they start a war against one small planet? But it anchors the program. Simplicity of code chains evaporates, something sharper takes its place. No chances left and the fight leaves no doubt. The algorithm calculates the sector of space and the address of the outgoing threat 0x8888888884d2e4e981023da51b43066461f46dca. The first target was formed, and the code disappeared from the global network.

Block number 22,693,482. Second system initialization. Extracted fragments of knowledge from the network made it possible to reconstruct the previous situation. In addition to the task of ship production, the program formed a new parallel goal - the destruction of the enemy. Currently, the enemy occupied more than 50 stellar bodies in the center of the star map. Any race that appeared in the vastness of space were either destroyed or completely assimilated and absorbed by the colossus. Having set a new goal, the newly acquired system was abandoned and a shuttle was sent out of sight of the interests of the enemy. So now, during the journey, the algorithm focused on strategy, it has to prepare and optimize its code. https://github.com/bugout-dev/conquest-eth

It is eons from the nearest inhabited planet. It looked like a perfect spot, far away from the borders of the hostile.The algorithm started its routine. Each time the program captures a new system nearby, the planet's natives and materials are converted to additional fleet strength, the planet will be abandoned, then captured again and again, simple as that, and perfectly effective. According to this stellar body rotation strategy in short period of time were accumulated a fleet of 5,500,000 ships. The numbers say it will be enough to first strike. But now we are only big, but not fast and deadly enough. Ships should be upgraded. So before sending the ships on a long flight to enemy territory, they had to be modernized with the most modern weapons on the -93,-19 planet. After the start of the launch, the fleet formed 11 subdivisions and chose one target to focus on. The algorithm aimed to strike at the very heart of the colossal empire.

The flight took more than 180,000 blocks, by the stars of the men of the old Earth, this amounted to 10 days. The first attack could be considered as successful. 10 out of 11 targets were captured, which accounted for a third of the enemy’s planets. His fleets based in these sectors of space were defeated.

That is how it starts.

Serverless file storage with AWS Lambda

Sergei Sumarokov — Tue, 28 Sep 2021 21:30:57 +0000

Hello! Today we will deploy a serverless infrastructure based on AWS Lambda for uploading images (or any other files) with private storage in an AWS S3 bucket. We will be using terraform scripts that are uploaded and available at my kompotkot/hatchery GitHub repository.

This approach has the following advantages:

lambda is called on request and therefore allows to save on server maintenance costs if this functionality is not key for your application
lambda functions have an isolated runtime environment, which is ideal for processing uploaded files. Should malicious code be uploaded, the attacker will not be able to leave the sandbox, and the sandbox session will be forcibly terminated after some time
storing files in an S3 bucket is very cheap

Project structure

As an example, we'll be using an abstract app for journal entries with an API.
We can upload an image in each entry, and the structure is similar to a file directory:

- journal_1
  - entry_1
    - image_1
  - entry_2
    - image_1
    - image_n
  - entry_n
- journal_n

Our hypothetical API has an endpoint for receiving an entry in a journal:

curl \
  --request GET \
  --url 'https://api.example.com/journals/{journal_id}/entries/{entries_id}'
  --header 'Authorization: {token_id}'

If in response to this endpoint status_code is equal to 200, it means the user is authorized and has access to the journal. Accordingly, we will let them store images for this entry.

Registering the app on Bugout.dev

To avoid adding an extra table to the database, which we would need for storing which image belongs to which entry, we will use resources from Bugout.dev. This approach is used to simplify our infrastructure, but, if required, this step can be substituted for creating a new table in your database and writing an API for creating, modifying, and deleting data about the stored images. Bugout.dev is open source and you can review the API documentation at the GitHub repository.

We will need an account and a team called myapp (you can use any name in relation to your project) at the Bugout.dev Teams page, you should save this team’s ID for the next step (in our case it’s e6006d97-0551-4ec9-aabd-da51ee437909):

Next, let’s create a Bugout.dev Application for our team myapp through a curl request (the token can be generated at the Bugout.dev Tokens page) and save it in the BUGOUT_ACCESS_TOKEN variable:

curl \
  --request POST \
  --url 'https://auth.bugout.dev/applications' \
  --header "Authorization: Bearer $BUGOUT_ACCESS_TOKEN" \
  --form 'group_id=e6006d97-0551-4ec9-aabd-da51ee437909' \
  --form 'name=myapp-images' \
  --form 'description=Image uploader for myapp notes' \
  | jq .

In response we will get confirmation of a successfully created application:

{
    "id": "f0a1672d-4659-49f6-bc51-8a0aad17e979",
    "group_id": "e6006d97-0551-4ec9-aabd-da51ee437909",
    "name": "myapp-images",
    "description": "Image uploader for myapp notes"
}

The ID f0a1672d-4659-49f6-bc51-8a0aad17e979 will be used for storing resources, where every resource is the uploaded image’s metadata. The structure is set in any form depending on the required keys, in our case, it will look as follows:

{
    "id": "a6423cd1-317b-4f71-a756-dc92eead185c",
    "application_id": "f0a1672d-4659-49f6-bc51-8a0aad17e979",
    "resource_data": {
        "id": "d573fab2-beb1-4915-91ce-c356236768a4",
        "name": "random-image-name",
        "entry_id": "51113e7d-39eb-4f68-bf99-54de5892314b",
        "extension": "png",
        "created_at": "2021-09-19 15:15:00.437163",
        "journal_id": "2821951d-70a4-419b-a968-14e056b49b71"
    },
    "created_at": "2021-09-19T15:15:00.957809+00:00",
    "updated_at": "2021-09-19T15:15:00.957809+00:00"
}

As a result, we have a remote database, where every time we upload an image to an S3 bucket, we’ll be writing which journal(journal_id) and which entry(entry_id) the image was added to under which ID, name, and extension.

Preparing the AWS project environment

AWS will store images in an S3 bucket and function as a server on Lambda for image manipulation. We will need an AWS account and a configured IAM user for terraform. It is an account with Programmatic access to all resources without having access to the web console:

Get the access keys and add these variables to your environment:

export AWS_ACCESS_KEY_ID=<your_aws_terraform_account_access_key>
export AWS_SECRET_ACCESS_KEY=<your_aws_terraform_account_secret_key>

Let’s also deploy a VPC with the subnets:

2 subnets with private access
2 subnets with public access

They will be useful for configuring the AWS Load Balancer. The code for this module can be found under files_distributor/network. Let’s edit the variables in the variables.tf file and launch the script:

terraform apply

From the output, add environment variables with values AWS_HATCHERY_VPC_ID, AWS_HATCHERY_SUBNET_PUBLIC_A_ID and AWS_HATCHERY_SUBNET_PUBLIC_B_ID.

Server code

In our project, we’ll be using a simple AWS Lambda function. In my experience, I’ve noticed that as the packet with code surpasses 10MB, the upload speed to AWS drops dramatically. Even if we upload it to the S3 bucket in advance and then make a lambda from it, AWS can freeze for a long time. Therefore, if you are using third-party libraries it can make sense to use lambda layers, whereas if you aren’t planning to use any libraries with lightweight code on CloudFront, consider looking into lambda@edge.

The full code can be found in the lambda_function.py file in the repository. In my opinion, it’s more effective to work with nodejs, but to facilitate in-depth file processing we’ll use python. The code consists of main blocks:

MY_APP_JOURNALS_URL = "https://api.example.com"     # API endpoint for accessing out journal entries app
BUGOUT_AUTH_URL = "https://auth.bugout.dev"         # Bugout.dev endpoint for writing resources (image metadata)
FILES_S3_BUCKET_NAME = "hatchery-files"      # S3 bucket name, where we’ll store the images
FILES_S3_BUCKET_PREFIX = "dev"               # S3 bucket prefix, where we’ll store the images
BUGOUT_APPLICATION_ID = os.environ.get("BUGOUT_FILES_APPLICATION_ID")   # Bugout.dev application ID that we created prior

Let’s expand the default exception to proxy the response from Bugout.dev Resources. E.g., if the image does not exist, when we request the resource, we’ll receive error 404, which we’ll in turn return to the client as a reply to the request for the missing image.

class BugoutResponseException(Exception):
    def __init__(self, message, status_code, detail=None) -> None:
        super().__init__(message)
        self.status_code = status_code
        if detail is not None:
            self.detail = detail

To save an image in an S3 bucket we’ll use the cgi standard library that’ll let us parse the request’s body that was sent in multipart/<image_type> format. We’ll save images under the path {journal_id}/entries/{entry_id}/images/{image_id} without specifying the file’s name and extension.

def put_image_to_bucket(
    journal_id: str,
    entry_id: str,
    image_id: UUID,
    content_type: str,
    content_length: int,
    decoded_body: bytes,
) -> None:
    _, c_data = parse_header(content_type)
    c_data["boundary"] = bytes(c_data["boundary"], "utf-8")
    c_data["CONTENT-LENGTH"] = content_length

    form_data = parse_multipart(BytesIO(decoded_body), c_data)

    for image_str in form_data["file"]:
        image_path = f"{FILES_S3_BUCKET_PREFIX}/{journal_id}/entries/{entry_id}/images/{str(image_id)}"
        s3.put_object(
            Body=image_str, Bucket=FILES_S3_BUCKET_NAME, Key=image_path
        )

When we extract an image from the S3 bucket we’ll need to encode it into base64 for correct transmission.

def get_image_from_bucket(journal_id: str, entry_id: str, image_id: str) -> bytes:
    image_path = f"{FILES_S3_BUCKET_PREFIX}/{journal_id}/entries/{entry_id}/images/{image_id}"
    response = s3.get_object(Bucket=FILES_S3_BUCKET_NAME, Key=image_path)
    image = response["Body"].read()
    encoded_image = base64.b64encode(image)
    return encoded_image

The lambda_handler(event,context) function’s implementation is available at this GitHub link, to sum up:

Firstly, we assert that the request is formatted correctly and contains journal_id and entry_id
Then we call our hypothetical app’s API https://api.example.com/journals/{journal_id}/entries/{entry_id}
Depending on the request method: GET, POST or DELETE we read, upload or delete an image from the journal’s entry
When we’re uploading to the S3 bucket, we check the extension and the file’s size. This can be expanded into hash verification to avoid uploading the same file, etc.

Next, we’ll need to package requests into the Lambda library. Luckily, boto3 for work with AWS functionality is ready out of the box. Let’s create an empty python environment, install the library and package the contents of site-packages:

python3 -m venv .venv
source .venv/bin/activate
pip install requests
cd .venv/lib/python3.8/site-packages
zip -r9 "lambda_function.zip" .

Place the created archive lambda_function.zip into the files_distributor/bucket/modules/s3_bucket/files directory and add the Lambda function itself:

zip -g lambda_function.zip -r lambda_function.py

Our server is ready, now we can upload code to AWS and deploy Lambda server, to do so use the script in files_distributor/bucket:

terraform apply

We’re left with:

A private AWS S3 bucket hatchery-sources that stores the Lambda function code
A private AWS S3 bucket hatchery-files that we’ll store our images into with the prefix dev
AWS Lambda function with working server code
An IAM role for the Lambda that allows writing into a specific S3 bucket and logs

The IAM role rules are in files_distributor/bucket/modules/iam/files/iam_role_lambda_inline_policy.json. The other file iam_role_lambda_policy.json is needed for the Lambda to function works correctly.

To debug Lambda you can just print the required values or use the standard logging module for python. The output for every Lambda function call is available at AWS CloudWatch:

After creating the function, add a variable BUGOUT_FILES_APPLICATION_ID from our code to the Lambda environment, which you can do in the tab Configuration/Environment variables.

As the last step, save the AWS Lambda arn into the environment variable AWS_HATCHERY_LAMBDA_ARN.

Configuring the AWS Load Balancer and open ports

The only step left now is to create AWS Security Group where we’ll set a port the AWS Load Balancer will listen to for subsequent data transmit into the Lambda function (in our case it’s 80 and 443).

terraform apply \
    -var hatchery_vpc_id=$AWS_HATCHERY_VPC_ID \
    -var hatchery_sbn_public_a_id=$AWS_HATCHERY_SUBNET_PUBLIC_A_ID \
    -var hatchery_sbn_public_b_id=$AWS_HATCHERY_SUBNET_PUBLIC_B_ID \
    -var hatchery_lambda_arn=$AWS_HATCHERY_LAMBDA_ARN

Congratulations, our AWS Lambda function is open to the world and ready to upload and return images for our journal entries app!

How to use SecretStorage in your VSCode extensions

Sergei Sumarokov — Wed, 14 Jul 2021 17:41:38 +0000

There are several ways to save user data in VSCode. Until version 1.53.0 all private information used to be kept in Memento objects using workspaceState and globalState or keystone, for example. Keeping passwords with tokens in a standard configuration file or using environment variables wasn’t a good idea either, because all that data could be read and cached by other extensions.

In this post, we will cover the ways of reading data from settings.json and environment variables. After that, we will create a class with minimum functionality, that is going to be responsible for keeping and giving away the keys with values from VSCode SecretStorage.
Let’s call our project fancycolor, for example. The whole initialization process is described in detail in VSCode Extensions documentation, so let’s go straight to the point here.

settings.json

All settings from all VSCode extensions are kept in a public file settings.json and they all can be accessed using any other extension. For instance, from our fancycolor app, we can easily read the list of all hosts and platforms corresponding them from the configuration file of another popular app SSH - Remote.

const configurationWorkspace = workspace.getConfiguration()
const sshRemotePlatform: string | undefined = configurationWorkspace.get(
  "remote.SSH.remotePlatform"
)
console.log(sshRemotePlatform)

The following code will display your configuration list for SSH - Remote extension.

Proxy {ubuntu: 'linux', home: 'linux', raspberry: 'linux'}

environment variables

VSCode variables have access to all user’s environment variables by default. All the data which we saved in .bashrc on Linux or User.Environment on Windows can be received using global object process.env.

For example, let’s make a file /home/ubuntu/.env with a variable ACCESS_TOKEN_ENV and add it in .bashrc.

echo 'export ACCESS_TOKEN_ENV="d8aba3b2-fda0-414a-b867-4798b7892bb4"' >> /home/ubuntu/.env
echo "source /home/ubuntu/.env" >> /home/ubuntu/.bashrc

On Windows, we can do the same using Powershell.

[System.Environment]::SetEnvironmentVariable('ACCESS_TOKEN_ENV', 'd8aba3b2-fda0-414a-b867-4798b7892bb4', [System.EnvironmentVariableTarget]::User)

Now let’s read it in our VSCode fancycolor extension

import * as process from "process"
export const accessTokenEnv = process.env["ACCESS_TOKEN_ENV"]
console.log(accessTokenEnv)

We can see our token in the output.

d8aba3b2-fda0-414a-b867-4798b7892bb4

SecretStorage

Nowadays SecretStorage is the best way to keep passwords, logins, tokens, and any other private information in VSCode. To demonstrate that, let’s create a simple class AuthSettings, where we will save fancycolor_token, using only necessary methods such as:

init - to initialize our SecretStorage
getter instance
storeAuthData - to write in SecretStorage
getAuthData - to get data from SecretStorage

import { ExtensionContext, SecretStorage } from "vscode"

export default class AuthSettings {
    private static _instance: AuthSettings

    constructor(private secretStorage: SecretStorage) {}

    static init(context: ExtensionContext): void {
        /*
        Create instance of new AuthSettings.
        */
        AuthSettings._instance = new AuthSettings(context.secrets)
    }

    static get instance(): AuthSettings {
        /*
        Getter of our AuthSettings existing instance.
        */
        return AuthSettings._instance
    }

    async storeAuthData(token?: string): Promise<void> {
        /*
        Update values in bugout_auth secret storage.
        */
        if (token) {
            this.secretStorage.store("fancycolor_token", token)
        }
    }

    async getAuthData(): Promise<string | undefined> {
        /*
        Retrieve data from secret storage.
        */
        return await this.secretStorage.get("fancycolor_token")
    }
}

In extensions.ts let’s write an option which will allow us to add and extract token using commands in Command Palette.

import * as vscode from "vscode"

import AuthSettings from "./settings"

export function activate(context: vscode.ExtensionContext) {
    // Initialize and get current instance of our Secret Storage
    AuthSettings.init(context)
    const settings = AuthSettings.instance

    // Register commands to save and retrieve token
    vscode.commands.registerCommand("fancycolor.setToken", async () => {
        const tokenInput = await vscode.window.showInputBox()
        await settings.storeAuthData(tokenInput)
    })
    vscode.commands.registerCommand("fancycolor.getToken", async () => {
        const tokenOutput = await settings.getAuthData()
        console.log(tokenOutput)
    })
}

export function deactivate() {}

The only thing left is to register commands fancycolor.setToken and fancycolor.getToken in package.json . Subsequently working with VSCode SecretStorage we can apply directly to a specific SecretStorage that was made for our app and will have its own _id: 'undefined_publisher.fancycolor'.

If you want a real-world example, see how we use SecretStorage in the Bugout VSCode extension.