Forem: cptMoh

Redeploying a Suspended Subgraph

cptMoh — Sat, 31 Dec 2022 09:29:06 +0000

So, it's the end of the year and I was going through all my projects for the year when I came across some of the first subgraphs that I created and are no longer active, and I thought, why don't I try and see if i can reactivate them, and share the process with you while i'm at it?

First of all, I think it's important that i first of all point out that the reason we're redeploying the subgraph is because The graph protocol suspends subgraphs that have not been active over a long period of time. Active here means queries being made to the subgraph. So, it suspends any subgraphs that haven't being receiving queries to save resources.

How do we get our subgraphs back up, you might ask? Well, i'm curious too, so I'm going to do just that. You can follow along as well if you want to find out how.

You need to install The Graph CLI globally using NPM or Yarn so that you can build and deploy your subgraphs. That is if you don't already have it installed. You can run the following command: npm install -g @graphprotocol/graph-cli

or yarn global add @graphprotocol/graph-cli If you are using Yarn instead.

I'm assuming you still have the folder and files from when you initially deployed the subgraph. And if you do not, then you can pull it from the GitHub repository that you pushed your code.
cd into the directory that you have your subgraph code, and run the following command:

graph auth --product hosted-service <access token>

You can get the subgraph access token from you subgraph's dashboard.

After you run the above command, you are going to get a response like this:

Deploy key set for https://api.thegraph.com/deploy/

Then go on and run the following command for the actual deployment:

graph deploy --product hosted-service <username>/<subgraph name>

In my case, my github username that I created the subgraph with is mufasasa and my subgraph name is 'raffle'. So, i'm going to run this command:

graph deploy --product hosted-service mufasasa/raffle

After I ran the command, Here'e what I got on my terminal:

apple@mohammeds-MacBook-Air raffle % graph deploy --product hosted-service mufasasa/raffle
  Skip migration: Bump mapping apiVersion from 0.0.1 to 0.0.2
  Skip migration: Bump mapping apiVersion from 0.0.2 to 0.0.3
  Skip migration: Bump mapping apiVersion from 0.0.3 to 0.0.4
  Skip migration: Bump mapping apiVersion from 0.0.4 to 0.0.5
  Skip migration: Bump mapping apiVersion from 0.0.5 to 0.0.6
  Skip migration: Bump manifest specVersion from 0.0.1 to 0.0.2
  Skip migration: Bump manifest specVersion from 0.0.2 to 0.0.4
✔ Apply migrations
✔ Load subgraph from subgraph.yaml
  Compile data source: Contract => build/Contract/Contract.wasm
✔ Compile subgraph
  Copy schema file build/schema.graphql
  Write subgraph file build/Contract/abis/Contract.json
  Write subgraph manifest build/subgraph.yaml
✔ Write compiled subgraph to build/
  Add file to IPFS build/schema.graphql
                .. QmbNuvtUUdbFB8rsqz1VtoSx53rXbG8wdgDQH6rN1pdsEs
  Add file to IPFS build/Contract/abis/Contract.json
                .. QmTBd3PKuZxHfyNSjKwsF6Srz3EdRTCz1M8fphmkuGyqBw
  Add file to IPFS build/Contract/Contract.wasm
                .. QmVAhCEFiXNG6LNVmTcz4HtfZ1WoJoTXDMmFM2uLUNz2P1
✔ Upload subgraph to IPFS

Build completed: QmT4KpqDiUmvNUyofvGJSojpnucEUHfBHiYFJWWYknhyCa

Deployed to https://thegraph.com/explorer/subgraph/mufasasa/raffle

Subgraph endpoints:
Queries (HTTP):     https://api.thegraph.com/subgraphs/name/mufasasa/raffle

And with that, my subgraph is back online and we can continue making queries to it!!

Thanks for coming along this far with me, enjoy the holidays, and cheers to a wonderful and fulfilling 2023

A faster way of creating subgraphs

cptMoh — Sun, 11 Dec 2022 15:07:55 +0000

This is a follow-up post to my guide on Creating ERC721 Subgraphs. I suggest that you read that first in order to fully appreciate this faster/easier way. Also, you'd gain more in-depth knowledge on creating subgraphs if you read that first.

Getting Started

For this guide, we are going to be using the hosted service. Head over there by clicking on this link and either create an account or login to your dashboard.
Once on your dashboard, click on the 'Add Subgraph' Button.
Fill in the required fields on the form. Make sure the name that you give to the subgraph is the same as the name you will give to your github repository for the subgraph.
Submit the form.
Next, You can click on the button to 'show commands' of how to install the graph CLI globally using either NPM or Yarn if you don't already have it installed. This is because you will need it to build and deploy subgraphs.

Initialising the Subgraph.

The Next step is to initialise the subgraph from your terminal. But before this, you need to cd into the directory/folder that you want to write your code in.

While in the directory, this is the command to run:

graph init --index-events --from-contract {Contract-address} --network {network-name} {subgraph-name}

Make sure you replace the 'contract-address' with the address of the contract that you want to index, the 'network-name' with the name of the network, and the 'subgraph-name' with the name of the subgraph that you want to create.

For instance, if we want to create a subgraph named 'raffle' that indexes the events from a contract on the arbitrum-one network, we run the following command:

graph init --index-events --from-contract 0xf53d383525117d1f51bf234966e39bd1508a5948 --network arbitrum-one raffle

When you open the subgraph.yaml file, you'll notice that that all the events on the contract have been automatically indexed!

specVersion: 0.0.4
schema:
  file: ./schema.graphql
dataSources:
  - kind: ethereum
    name: Contract
    network: arbitrum-one
    source:
      address: "0xf53d383525117d1f51bf234966e39bd1508a5948"
      abi: Contract
      startBlock: 16977962
    mapping:
      kind: ethereum/events
      apiVersion: 0.0.5
      language: wasm/assemblyscript
      entities:
        - NewAuctionWinner
        - NewBid
        - NewGoldenTicketWinner
        - NewRaffleWinner
        - OwnershipTransferred
      abis:
        - name: Contract
          file: ./abis/Contract.json
      eventHandlers:
        - event: NewAuctionWinner(uint256)
          handler: handleNewAuctionWinner
        - event: NewBid(address,uint256,uint256)
          handler: handleNewBid
        - event: NewGoldenTicketWinner(uint256)
          handler: handleNewGoldenTicketWinner
        - event: NewRaffleWinner(uint256)
          handler: handleNewRaffleWinner
        - event: OwnershipTransferred(indexed address,indexed address)
          handler: handleOwnershipTransferred
      file: ./src/contract.ts

The schema.graphql file has also been automatically generated for you with all the contract events schema automatically generated!

type NewAuctionWinner @entity {
  id: ID!
  bidderID: BigInt! # uint256
  block: BigInt! # uint256
  timestamp: BigInt! # uint256
}

type NewBid @entity {
  id: ID!
  bidder: Bytes! # address
  bidderID: BigInt! # uint256
  bidAmount: BigInt! # uint256
  block: BigInt! # uint256
  timestamp: BigInt! # uint256
}

type NewGoldenTicketWinner @entity {
  id: ID!
  bidderID: BigInt! # uint256
  block: BigInt! # uint256
  timestamp: BigInt! # uint256
}

type NewRaffleWinner @entity {
  id: ID!
  bidderID: BigInt! # uint256
  block: BigInt! # uint256
  timestamp: BigInt! # uint256
}

type OwnershipTransferred @entity {
  id: ID!
  previousOwner: Bytes! # address
  newOwner: Bytes! # address
  block: BigInt! # uint256
  timestamp: BigInt! # uint256
}

Now when we head over to the 'src/' directory, and open up the 'contract.ts' file, you'll also notice that all the mapping functions have already been generated! This is so easy, haha!

So, since all the heavy lifting has already been done for us, we can just go on and deploy our subgraph. You don't have to even change anything on the code as literally all the work has been done.

To deploy, run graph auth on your terminal

Choose the hosted service
It will ask you to enter the deploy key. Head to your dashboard, copy your access token, and then paste it.
Finally, run npm run deploy
Wait for it to compile your subgraph and deploy it.

If you head to your dashboard, you will see that your Subgraph is deployed and syncing.

Congratulations!!!

for more information about building subgraphs and the graph protocol in general, go to the graph academy

Creating an ERC721(NFT) Subgraph

cptMoh — Sat, 16 Jul 2022 17:08:00 +0000

Introducing The Graph

The Graph is the indexing and querying protocol for web3. It is a key piece of infrastructure in the decentralised web3 stack. With The Graph and open APIs called "subgraphs", developers can build applications and create and publish subgraphs that query data from blockchains.

For example, developers commonly create applications that display data to the application's end users - such as trades, NFTs and DAOs. Using The Graph, developers can create applications that quickly and easily display data retrieved from blockchains. Subgraphs make it easier for developers to build on top of blockchains and enabling UIs to be highly performant with rich and dynamic data.

Subgraphs index data that is defined by the developers that create it, based on what information they'd like to present in their UIs. A network of Indexers (node operators) index the subgraphs and process queries for dapps, ensuring dapps don't rely on single centralised servers.

Subgraphs

Subgraphs are open APIs that are created and published by developers. In essence, a subgraph defines how to ingest, index, and serve data, and they are used by developers to build dapps.

Subgraphs allow developers to more easily query complex blockchain data. Developers use subgraphs to feed data to the front-end interface of their applications, such as displaying financial data or NFT marketplace information to their users.

Without The Graph, dapp developers would have to run their own centralised back-end infrastructure to query blockchain data. Furthermore, the time saved by using subgraphs enables developers to focus on building high-quality applications and front-end interfaces. Subgraphs make it easier to build on web3 protocols, reduce the need for centralised databases, and eliminate specialised engineering resources and hardware.

Building a Subgraph

In this guide, we are going to look at what building a subgraph looks like by building one that indexes an ERC721 NFT Token.

First Steps

For this guide, we are going to be using the hosted service. Head over there by clicking on this link and either create an account or login to your dashboard.
Once on your dashboard, click on the 'Add Subgraph' Button.
Fill in the required fields on the form. Make sure the name that you give to the subgraph is the same as the name you will give to your github repository for the subgraph.
Submit the form.
Next, You can click on the button to 'show commands' of how to install the graph CLI globally using either NPM or Yarn if you don't already have it installed. This is because you will need it to build and deploy subgraphs.

Initialising the Subgraph.

The Next step is to initialise the subgraph from your terminal. But before this, you need to cd into the directory/folder that you want to write your code in.

Once you're there, go on and run:

graph init subgraph-name

Be sure to replace 'subgraph-name' with the name of the subgraph you are building. For example, since we're going to be making a bored apes subgraph, i'm going to run;

graph init boredapes

Next, you'll be prompted to choose a protocol on the terminal. For this, we can go on and choose ethereum

Choose the hosted service.
Next, you will be prompted to choose the name of your subgraph. It should be ‘your-github-account/your-subgraph-name’. for example, my github account is 'mufasasa', and the name of the subgraph we're making is 'boredapes'. Therefore, i'm going to put in 'mufasasa/boredapes'.
You'll then be asked to choose the directory that you want the subgraph to be created in. you can leave it as the current directory that you are working on, so just hit the 'enter' key.
You'll be prompted to choose from the available networks. Choose mainnet.
Provide the contract address of the smart contract that you want to index. The smart contract address can be gotten from etherscan. We are indexing the bored apes smart contract, so you can copy and past in the address 0xBC4CA0EdA7647A8aB7C2061c2E118A18a936f13D
You can leave the default contract name; Contract.
A new folder will be created for you with the name that you specified. Go on an cd into the folder, then open it up in your code editor.
Next, open the subgraph.yaml file and make the following edits;

specVersion: 0.0.4
schema:
  file: ./schema.graphql
dataSources:
  - kind: ethereum
    name: undefined
    network: mainnet
    source:
      address: "0xBC4CA0EdA7647A8aB7C2061c2E118A18a936f13D"
      abi: Contract
      startBlock: "12287507"
    mapping:
      kind: ethereum/events
      apiVersion: 0.0.5
      language: wasm/assemblyscript
      entities:
        - Approval
        - Transfer
      abis:
        - name: Contract
          file: ./abis/Contract.json
      eventHandlers:
        - event: Approval(indexed address,indexed address,indexed uint256)
          handler: handleApproval
        - event: Transfer(indexed address,indexed address,indexed uint256)
          handler: handleTransfer
      file: ./src/contract.ts

I added the StartBlock under the 'source subsection'. This is the Transaction Block of when the contract was deployed, and can be gotten from etherscan.

I also deleted 'approval for all' in the entities and event handlers subsection. Note Whenever you want to index a smart contract, be sure to check the contract code and see what event(s) the contract is emitting, and then proceed accordingly.

Defining our Schema.

we are now going to proceed to the schema.graphql file to define our schemas.

The very first thing that we'll do here is delete the example schema that we were given there.
Next, we'll define the schema of our entities in this file. A prior knowledge of graphql will come in handy here. But even if you don't know graphql, then that's okay too. You can just paste the following inside your schema.graphql file.

type TransferEvent @entity{

id: ID! 

" Id of the transferred token "
tokenId: BigInt!

"address of the sender "
sender: Bytes!

"address of the receiver "
destination: Bytes!

"event timestamp"
timestamp: BigInt!

"transaction hash"
transaction: Bytes!

}


type ApprovalEvent @entity{

id: ID!

" Id of the approved token "
tokenId: BigInt!

"address of the owner"
owner: Bytes!

"address of the approved"
approved: Bytes!

"event timestamp"
timestamp: BigInt!

"transaction hash"
transaction: Bytes!

}

What we're trying to do is defining the format that our entities are going to take. Kind of like defining our data models. I'll breakdown the models below so that we can have an idea of what is going on.

type TransferEvent @entity{

id: ID! 

" Id of the transferred token "
tokenId: BigInt!

"address of the sender "
sender: Bytes!

"address of the receiver "
destination: Bytes!

"event timestamp"
timestamp: BigInt!

"transaction hash"
transaction: Bytes!

}

At the very beginning we are declaring the 'TransferEvent' type, and we're saying it is an entity.The fields that we want inside the transfer event are then specified inside the curly brackets.

The first field there is the 'id' field. We then put a colon and 'ID' after it, meaning it is of type 'ID'. the exclamation mark means the field is required.
The second field is 'tokenId' which is of type 'BigInt' and is going to be holding the id of the NFT.
The third field, 'sender' is of type 'Bytes', and is also required. We are using the 'Bytes' type because we are going to be storing the wallet address of the sender in the field.

The fourth field is just like the third field, but storing the address of the receiver of the NFT. The fifth field stores the event time stamp and the sixth field stores the transaction hash.

Once you are done with the schema.graphql file, head on over to the 'src' directory, and open the 'contract.ts' file. This is where we are going to define our mappings. What we are going to be doing here is directing how an emitted event from the dapp is going to be mapped and saved in our database.

You can delete the automatically generated code there and paste the following code into the file;

import { Transfer, Approval } from "../generated/undefined/Contract";
import { TransferEvent, ApprovalEvent } from "../generated/schema";


export function handleTransfer(event:Transfer): void {
    let transferEvent = new TransferEvent(event.transaction.hash.toHex()+"-"+event.logIndex.toString());

    transferEvent.tokenId = event.params.tokenId;

    transferEvent.sender = event.params.from;

    transferEvent.destination = event.params.to;

    transferEvent.timestamp = event.block.timestamp;

    transferEvent.transaction = event.transaction.hash;
    transferEvent.save();
}


export function handleApproval(event:Approval): void {
    let approvalEvent = new ApprovalEvent(event.transaction.hash.toHex()+"-"+event.logIndex.toString());

    approvalEvent.tokenId = event.params.tokenId;

    approvalEvent.owner = event.params.owner;

    approvalEvent.approved = event.params.approved;

    approvalEvent.timestamp = event.block.timestamp;

    approvalEvent.transaction = event.transaction.hash;
    approvalEvent.save();
}

The two functions are going to be called whenever either a transfer or an approval event is emitted from the dapp.

Our subgraph is now ready to be deployed!!

To deploy, run graph auth on your terminal

Choose the hosted service
It will ask you to enter the deploy key. Head to your dashboard, copy your access token, and then paste it.
Finally, run npm run deploy
Wait for it to compile your subgraph and deploy it.

If you head to your dashboard, you will see that your Subgraph is deployed and syncing.

Congratulations!!!

for more information about building subgraphs and the graph protocol in general, go to the graph academy

Deploying a Smart Contract With Hardhat and Alchemy on an Ethereum Network

cptMoh — Fri, 25 Mar 2022 13:42:49 +0000

So, you've written your smart contract and maybe even played around with it a little on remix. But now you want to share it with all your friends and possibly even the world so that they can marvel at the wonder you've just created.

I personally write my contracts on Remix IDM, compile it, deploy on the javascript machine, play around with it a little, and test out the functions.

But Remix could be unreliable sometimes and you might want a more elaborate way of writing your contracts, including test and deployment scripts. For that, I personally like to use Hardhat and Alchemy. They are very easy to setup and use, but could be a little bit of a hassle if you have not used them before.

Because of that, i'll be sharing the documented steps that I have been using to get my dApps out there through Hardhat and Alchemy.

Alchemy Helps us broadcast our transaction on the blockchain when we deploy our contract. So, it is kind of like telling all the other nodes "hey everyone! A new contract has just been deployed and it's over here!!"

To get started with Alchemy, just head on over to their website and create an account with them.

After you have done that and have gotten logged in to your dashboard, click on Create App button. It's near the top to your right.

A pop up will come up and you can go ahead and enter the name of the app you want to create, and add some description of the application. This is for you, by the way. To help you remember what the application is about.

For the environment, I usually leave it as development. You can select the chain you'd be working on. I've personally worked with ethereum and polygon. The last dropdown is the network selection. You can either choose the main net of your network(where real money is paid and used, by the way) or choose from a test net(where it's free and fake money is used).

Next, copy the Key to your app and save it somewhere, we're going to need it later. You want to copy the HTTP option for this.

Now that we're done with Alchemy, open up your terminal and create a new directory with your project name, then cd into the directory.

In your project directory, run the following command;

npm init -y

You'll need npm installed for that to work, by the way. You can learn about installing npm here

Then run

npm install --save-dev @nomiclabs/hardhat-waffle ethereum-waffle chai @nomiclabs/hardhat-ethers ethers

To make sure that everything is running just fine, go ahead and run

npx hardhat compile
npx hardhat test

It should show you that your test has passed

When you check the contracts, test, and scripts folder you'd find some test files already there. You can go on and delete those. But don't delete the whole folders please, just the files inside of them.

Create a new file in your contracts folder and name it with the name of the contract you want to create. This is where you will write your contract code in solidity. So, you can just go ahead and do that. Alternatively, you could also copy your code from somewhere and paste it here. I usually first try out my contract code in Remix before transferring it here.

When you are done writing your contract, the next thing you'll have to do is write a 'deploy' script in your scripts folder. You can name the file 'deploy.js' This is what we are going to use to deploy your contract and get it on the blockchain for the world to see 🏄‍♂️

Here's an example of a simple contract script i've written

And the deployment script here 👇

The last thing you'd need to do before deploying your contract is going to your 'hardhat.config.js' file and change it to this

require("@nomiclabs/hardhat-waffle");

module.exports = {
  solidity: "0.8.0",
  networks: {
    rinkeby: {
      url: "YOUR_ALCHEMY_API_URL",
      accounts: ["YOUR_PRIVATE_ACCOUNT_KEY"]
    },
  },
};

Edit the file and add your alchemy url for the app. Also you'll need to add your private account key.

Finally, deploy your application to the blockchain by running this on your terminal 👇

npx hardhat run scripts/deploy.js --network {your blockchain network}

Note: you need to replace "{your blockchain network}" with the actual name of your network. So, if i'm deploying to rinkeby for example, it will look like this.

npx hardhat run scripts/deploy.js --network rinkeby

That's it!!! you've successfully deployed your app 🎉 🎉 🎊

FastAPI Deployment on Deta

cptMoh — Sat, 05 Mar 2022 23:31:21 +0000

We started using FastAPI, the Python web framework that's fast gaining popularity recently in our organisation. Which, by the way, I recommend to everyone building APIs with python because of how fast and easy it is to setup and get going. Fast API also boasts of speeds that are on par with NodeJs and GoLang because of its async nature.

Anyways, this led me to researching different ways of deploying FastAPI to a staging server for testing purposes before moving to production. Along the way, I bumped into Deta, a rather new and interesting platform as a service(PAAS), just like Heroku(which i have used a few times).

What's even more interesting about Deta is the fact that I found it on FastAPIs' website. Well, that has to count for something, right? I mean, if FastAPI, which is this mean beast of a python web framework is pushing for Deta, then it too must be just as good, right? Well, dig in and follow me as we go through my journey of discovery.

First of all, like i've told you before, FastAPI is really super fast to setup and get your api running in a few minutes, so, it makes sense that it will push for a platform that is just as easy and fast to make your deployments, yeah...? You got that right!

Deta deployments are insanely easy and quick with FastAPI. you can get your app up and running on their micros in under five minutes! I mean if that's not impressive, then I don't know what is. just a few clicks here and there and voila.

Before you do anything else, you need to create a free account with Deta
Done that? good. the very next thing you need to do is to download the Deta CLI.
You can do that like this on a MAC/Linus OS:

curl -fsSL https://get.deta.dev/cli.sh | sh

Or like this on Windows:

iwr https://get.deta.dev/cli.ps1 -useb | iex

Easy-peasy. now you need to login to your through your cli

deta login

Now, before this next step, you need to make your your 'app' is defined in a 'main.py' file on the directory you are working from. You also need to make sure your 'requirements.txt' file is located in that same directory. If you have all of that set, then go ahead and do this:

deta new

It should take about a minute, and then you'll get a response that should look like this.

deta new

Successfully created a new micro

💬 Notice the "endpoint" 🔍

{
    "name": "fastapideta",
    "runtime": "python3.7",
    "endpoint": "https://qltnci.deta.dev",
    "visor": "enabled",
    "http_auth": "enabled"
}

Adding dependencies...


████████████████████████████████████████ 100%


Successfully installed fastapi-0.61.1 pydantic-1.7.2 starlette-0.13.6

That's it, super easy and fast. you can access your app when you go to that endpoint.

I know what you must be thinking, lol. If deploying your fastAPI app on Deta was so easy, fast, and free, then why isn't everyone doing it, right?

Not so fast, smarty pants. The reason why so many people are not doing it is because there's a catch, or a few catches, actually.

With the exception of mysqlite3 and their native Deta Base, Deta micros don't work well with any other database. so hard luck if you're like me and you like using MongoDB because Deta totally does not support it. At least for now.
I suspect if you're testing your app on a staging server then you'd want to test your app as it would function on production right? well if it's not too much of a hassle switching between databases then it's not really a big deal.
Deta Base is really easy to set up and get going as well. i guess this is starting to become a trend for anything linked with FastAPI
For some reason, background tasks also don't work well on Deta. so good luck trying to test out your email sending functionality as a background task, lol.
Deta only supports micro web frameworks(think FastAPI and Flask) and no Django or any other big web framework.
Web sockets also do not work well on Deta.

If all of these are not an issue, then you should really check out Deta for deploying your FastAPI applications. They're meant to go hand in hand. And we hope Deta gets even better in the future. we'd love to see support for more Relational and non relational databases.

PS. I'd really love to hear about your thoughts on deta and FastAPI. Do you know of other ways of deployment you'd care to share? please leave a comment below.

Coming to Web3 from Web2

cptMoh — Wed, 02 Mar 2022 05:53:00 +0000

As a backend developer that's curious about web3, I have, so far learnt that the two webs differ in the following very basic and simple ways.

In the very ancient world of web2 that we're coming from, where we still use usernames and passwords to authenticate, We store all data, including user data, pertaining to an application centrally(in one place), usually controlled by a single entity.

This is not the case in the very progressive and futuristic world of web3 that you are about to enter. in our bright new world, data is stored on the blockchain, this means it's not stored at just a single place, yeah, i know what your'e thinking, Database?!

well, it's pretty easy to explain my friend, there's no single database. it's all distributed across different nodes on the blockchain. Think of it this way, if you were to write your name on a single piece of paper and keep it inside a locker at home, then you know exactly where your paper is, and if someone where to break your locker and take it away, then it's gone. That's basically how it works in web2.

Now, imagine if you wrote your name on a piece of paper, and then thousands of little copies of that paper are made and distributed and registered across the world. Now, your paper is everywhere. No one can steal it and deny your the pleasure of reading your name on your paper, because you can just easily get it from another source that registered it. No one person or entity controls or can take it down. This means there is no single point of failure.
And that, my very dear old friend, is how web3 works!

In a summarised one sentence, Web3 is basically a database on a blockchain!

Oh, yeah. authentication is also pretty simple, you just connect your wallet and it's done. No need to input any usernames and passwords. this means you get to keep your own data yourself and only present them where you want to. Imagine using the same credentials for every application or website that you want to visit and interact with. This is actually possible in web3, in fact, that's how it's done.

This isn't the case with web2 where you have to send in your details to every new app or platform that you want to register on.

That's all folks.

ps, I just enrolled in a cool new web3 internship organised by Blockgames, Nestcoin, and Zuriteam it's pretty fascinating so far. wagmi