Fix: typos

docs/core-concepts/proof-service/authservice.md

@@ -29,10 +29,10 @@ The process concludes by redirecting to the DApp with the following parameters(s
 6. `sig` (string, required): Signature of `avatar=${avatar}\nredirect_uri={redirect_uri}\nexpired_at=${expired_at}\nstate=${state}` singed by Subkey, encoded in Base58.
 
 ### Configuration 
-Understanding how it operates, the preliminary step before launching an instance of `Auth Service` is to prepare a configuration file.There are three parts. 
+Understanding how it operates, the preliminary step before launching an instance of `Auth Service` is to prepare a configuration file. There are three parts. 
 
 #### The Avatar and a subkey that is signed by the avatar:
-In the configuration, the list of avatars represents the identity that can be authenticated by this instance of `AuthService`. The private key is used to sign ta message, proving the ownership of the avatar. We strongly recommend using a subkey that is signed by the avatar instead of the avatar itself in the configuration. For enhanced security, it's advisable to generate a unique subkey for specific cases. This not only tailors the security to the situation but also minimizes the risk of exposing the avatar's private key.
+In the configuration, the list of avatars represents the identity that can be authenticated by this instance of `AuthService`. The private key is used to sign a message, proving the ownership of the avatar. We strongly recommend using a subkey that is signed by the avatar instead of the avatar itself in the configuration. For enhanced security, it's advisable to generate a unique subkey for specific cases. This not only tailors the security to the situation but also minimizes the risk of exposing the avatar's private key.
 
 Run the following command with [generate_subkey.py](https://github.com/nextdotid/auth_server/blob/develop/build/generate_subkey.py) to generate a new subkey and sign it with your Avatar private key:
 

docs/core-concepts/proof-service/intro.md

@@ -39,7 +39,7 @@ After the binding, ProofService will use a blockchain-like model called ProofCha
 #### Proof
 
 The definition of the proof contains all the necessary information between the connection of "Avatar <-> Identity", contains the operation type that is binding or dismiss, which platform and identity, timestamp, signature by the avatar...
-The structure is definied as:
+The structure is defined as:
 
 ```
 type Signature = string;

docs/core-concepts/proof-service/kvservice.md

@@ -16,7 +16,7 @@ While developing the Next.ID, we found that we still need a place to keep some c
 The generation signature and verification steps to guarantee the modification request is from the owner of Avatar.
 
 ### Query data
-After writing the data, everyone can get it via API.See [GET /v1/kv](/rest-api/kvservice-api#query).
+After writing the data, everyone can get it via API. See [GET /v1/kv](/rest-api/kvservice-api#query).
 
 
 ### Design

docs/core-concepts/relation-service/exampleQuery.md

@@ -5,7 +5,7 @@ sidebar_position: 3
 ---
 Here are some query use cases for reference.
 
-### Query an identity (w/ its relations to other identitites)
+### Query an identity (w/ its relations to other identities)
 ```graphql
 query findOneIdentity {
   identity(platform: "twitter", identity: "suji_yan") {
@@ -18,7 +18,7 @@ query findOneIdentity {
     updatedAt
     # Here we perform a 3-depth deep search for this identity's "neighbor".
     neighborWithTraversal(depth: 5) {
-      # neighbor returns is EdgeUnion, your should define every type of EdgeUnion's fields
+      # neighbor returns is EdgeUnion, you should define every type of EdgeUnion's fields
       ... on ProofRecord {
         __typename
         source # Which upstream provides this connection info.
@@ -56,7 +56,7 @@ query findOneIdentity {
 }
 ```
 
-### Query a list of identities (w/ its relations to other identitites and their sources)
+### Query a list of identities (w/ its relations to other identities and their sources)
 If you don't need to rebuild the relation graph, just want to get a list of nodes, or just want to know which upstream (sources) provides this connection info.
 
 ```graphql
@@ -82,7 +82,7 @@ query findOneIdentityWithSource {
   }
 }
 ```
-### Query an NFT (w/ its owner, owner's other NFTs, and owner's related identites)
+### Query an NFT (w/ its owner, owner's other NFTs, and owner's related identities)
 :::info
 `nft` field will possibly have value only when its parent identity is `platform: ethereum`.
 :::

docs/core-concepts/relation-service/graphDB.md

@@ -4,7 +4,7 @@ title: GraphDB
 sidebar_position: 2
 ---
 
-As `RelationService` aims to build comprehensive personal identity graphs, incorporating both on-chain and off-chain data to provide a holistic view of an individual’s digital presence.The Graph Database is the most important technology behind, aiming to supporting a full range of identity queries and social use cases. 
+As `RelationService` aims to build comprehensive personal identity graphs, incorporating both on-chain and off-chain data to provide a holistic view of an individual’s digital presence. The Graph Database is the most important technology behind, aiming to support a full range of identity queries and social use cases. 
 Graph Databases focus on relationships between data, making them a better option when dealing with complex relationships between intertwined data stored in multiple tables.
 
 ## What is a graph database?
@@ -29,7 +29,7 @@ In `RelationService`, we defined two type of `Vertices`
 - **Contract**: a contract object on a specific chain
 
 four type of `Edges`
-- **Proof**: represent a bi-directional relation (e.g.a Twitter account and an Ethereum account that bonded in `ProofService`)
+- **Proof**: represent a bi-directional relation (e.g. a Twitter account and an Ethereum account that bonded in `ProofService`)
 - **Hold**: usually represent Identity "hold" an asset (eg: an account hold a NFT)
 - **Resolve**: refer to the relation between the domain service and account (eg: ENS)
 - **Relation**: record static info between two identities

docs/faq.md

@@ -73,7 +73,7 @@ However, we recommend specifying the platform and identity for more precise stor
 
 ### **Role Clarification**
 
-RelationService serves as a relation aggregator and does not create new relationships. Consequently, we do no need to issue any "token-like" entities.
+RelationService serves as a relation aggregator and does not create new relationships. Consequently, we do not need to issue any "token-like" entities.
 
 ## **Should I Use the "Official" Instance of RelationService in My Production Environment?**
 
@@ -86,4 +86,4 @@ Our official server is an excellent starting point for exploring the capabilitie
 However, as your dependency on this service grows, we recommend hosting your own instance for the following reasons:
 
 - **Statelessness**: RelationService is designed to be stateless, offering flexibility in deployment.
-- **Smooth Migration**: Database migrations between different versions are designed to be smooth and hassle-free.
+- **Smooth Migration**: Database migrations between different versions are designed to be smooth and hassle-free.

docs/introduction/how-it-works.md

@@ -18,7 +18,7 @@ Then, the Application requests for the user’s Avatar's Private Key to generate
 
 After `ProofService` validates the Proof Post's existence and verifies the Private Key, it will relay the successful binding notification back to Application and User.
 
-Example of how it will look like to a user: The user requests for an account (eg: @nextdotid on Twitter) to be bound to their Avatar. The user signs a transaction to authenticate ownership of the account of the Twitter account. Thzte Avatar then generates a public tweet with a signature. When published by the user, this tweet, along with the signature, independently verifies the user's linking of the account to the Avatar.
+Example of how it will look like to a user: The user requests for an account (eg: @nextdotid on Twitter) to be bound to their Avatar. The user signs a transaction to authenticate ownership of the account of the Twitter account. The Avatar then generates a public tweet with a signature. When published by the user, this tweet, along with the signature, independently verifies the user's linking of the account to the Avatar.
 ![](../../static/img/how-it-works/platform-binding.png)
 
 ### Binding an Avatar to an Application via Ethereum wallet
@@ -34,7 +34,7 @@ In this scenario, User revokes a previously-established Binding made with an App
 
 Then, the Application requests the user’s Avatar Private Key to generate a signature based on `sign_payload`.
 
-After `ProofService`validates the signature with `uuid` and `created_at` from `sign_payload` , it verifies the Avatar's and Wallet's signatures for a Revoke action. When this is done, it will relay the successful Revoke notification back to the Application and user.
+After `ProofService`validates the signature with `uuid` and `created_at` from `sign_payload`, it verifies the Avatar's and Wallet's signatures for a Revoke action. When this is done, it will relay the successful Revoke notification back to the Application and user.
 ![](../../static/img/how-it-works/revoke-binding.png)
 
 ## [KVService](../core-concepts/proof-service/kvservice.md)
@@ -45,5 +45,5 @@ In this scenario, User requests for a modification on an Application. `KVServic
 
 Then, the application requests the user’s Avatar's Private Key to generate a signature based on `sign_payload`.
 
-After `KVService` validates the signature with `uuid` and `created_at` from `sign_payload` , it will then verify the Avatar Signature for the Write Data action. After that, it will relay the successful notification back to Application and User.
+After `KVService` validates the signature with `uuid` and `created_at` from `sign_payload`, it will then verify the Avatar Signature for the Write Data action. After that, it will relay the successful notification back to Application and User.
 ![](../../static/img/how-it-works/write-data.png)

docs/introduction/intro.md

@@ -4,7 +4,7 @@ title: Introduction
 slug: /
 ---
 
-Next.ID is an decentralized identity (DID) creation and management protocol built for developers. The Next ID protocol is used as the secure connecting fiber between different web2 and web3 identifiers, such as wallets, twitter profiles, ENS names, Lens profiles, and many more.
+Next.ID is a decentralized identity (DID) creation and management protocol built for developers. The Next ID protocol is used as the secure connecting fiber between different web2 and web3 identifiers, such as wallets, twitter profiles, ENS names, Lens profiles, and many more.
 By connecting a person’s different identifiers together, they form an identity graph - a powerful, portable, sovereign (self-owned) digital identities. Next ID refers to these identities, digital representations of self, as avatars.
 
 We provide services for creating DIDs, querying existing relationships, attaching data payloads to DIDs.
@@ -22,7 +22,7 @@ Next.ID creates an identity infrastructure that securely aggregates users’ ide
 ![](../../static/img/hyper-multi-graph.png)
 
 ## Universal Profile API - One API for all web3 profiles
-Identity graphs consist of identifiers, like twitter, reddit, or github handles. These are used to build Universal Profiles for users. Developers, using the the Universal Profile SDK import information-rich user profiles, decreasing onboarding time and enabling instant personalization.
+Identity graphs consist of identifiers, like twitter, reddit, or github handles. These are used to build Universal Profiles for users. Developers, using the Universal Profile SDK import information-rich user profiles, decreasing onboarding time and enabling instant personalization.
 ![](../../static/img/universal-profile.png)
 [Universal Profile](https://api.web3.bio)