[!] fix build issue

Author: nykma

.github/workflows/deploy.yml

@@ -11,12 +11,12 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v3
-      - uses: pnpm/action-setup@646cdf48217256a3d0b80361c5a50727664284f2
+      - uses: pnpm/action-setup@v4
         with:
-          version: 7.9.0
+          version: 10.5.2
       - uses: actions/setup-node@v3
         with:
-          node-version: 16.x
+          node-version: 18.x
           cache: pnpm
       - name: Install dependencies
         run: pnpm i

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

@@ -3,17 +3,17 @@ id: as-intro
 title: Web3 Auth, Auth Service
 sidebar_position: 2
 ---
-As we already built up the connection between avatar and [other identities](core-concepts/proof-service/ps-intro#supported-platform). The idea of letting DApps have its own version of "Sign-in with Google/Twitter" came out naturally. Auth Service is designed to help DApps realize this capability.
+As we already built up the connection between avatar and [other identities](https://github.com/NextDotID/proof_server#supported). The idea of letting DApps have its own version of "Sign-in with Google/Twitter" came out naturally. Auth Service is designed to help DApps realize this capability.
 
 ## How it works
 
-### Workflow of Auth with 3rd party platform 
+### Workflow of Auth with 3rd party platform
 
 ![](../../../static/img/core-concept/authservice-workflow.png)
 
 When a DApp initiates an authorization process, it must specify an `AuthService` instance (We strongly recommend to self-host one) to carry out the authentication. (step 2)
 
-`AuthService` begins by authenticating the identity using third-party platforms (e.g., Twitter ID). 
+`AuthService` begins by authenticating the identity using third-party platforms (e.g., Twitter ID).
 Once authenticated, `AuthService` queries the [ProofService](./ps-intro) to check the binding avatar result of this identity. (step 3-4)
 
 If the authenticated identity is associated with an Avatar, and this Avatar aligns with one of the pre-configured Avatars in `AuthService`, then `AuthService` grants the DApp permission to use the Avatar as its identity for a set experimental duration. (step 5-6)
@@ -28,8 +28,8 @@ The process concludes by redirecting to the DApp with the following parameters(s
 5. `subkey_cert_sig` (string, required): Subkey certification signature signed by Avatar, encoded in Base58.
 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. 
+### 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.
 
 #### 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.

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

@@ -8,7 +8,7 @@ sidebar_position: 1
 
 ![](../../../static/img/avatar-diagram.png)
 
-## How to build the connection 
+## How to build the connection
 
 ### Work Flow
 Use Twitter platform as an example to explain how to use `ProofService` to build a bi-directional binding between a Twitter account and an avatar:
@@ -18,7 +18,7 @@ Use Twitter platform as an example to explain how to use `ProofService` to build
 ```
 Struct SignaturePayload {
     action: Action,  // create/delete, refer to bind/unbind
-    created_at: number, // timestamp 
+    created_at: number, // timestamp
     platform: Platform;
     identity: string;
     prev :null | string, //the previous create/delete operation signature related to this avatar
@@ -34,11 +34,11 @@ Basically, the generic idea is to prove that the Avatar and another identity bel
 
 ### Data Structure
 
-After the binding, ProofService will use a blockchain-like model called ProofChain to record of "Avatar <-> Identity" connection(we called Proof) and save it in both the ProofService side and upload it to Arweave. The definitions of the proof and proofchain are as the followings.
+After the binding, ProofService will use a blockchain-like model called ProofChain to record of `Avatar <-> Identity` connection(we called Proof) and save it in both the ProofService side and upload it to Arweave. The definitions of the proof and proofchain are as the followings.
 
 #### 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 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:
 
 ```
@@ -62,24 +62,24 @@ interface Proof {
     // If this is genesis link, leave it null; else, it equals
     // previous link's signature. Worked as a pointer.
     prev: Signature | null;
-    
+
     avatar: String;
     action: Action;
     platform: Platform;
     identity: string;
-    
+
     // if action === Action.create, it shouldn't be empty(except ethereum); else, left null
     proof_location: string | null;
-    
+
     // UNIX timestamp (unit: second)
     created_at: number;
-    
+
     // An UUID of this link, works as a global identifier.
     uuid: string;
-    
+
     // See the definition above
     signature_payload: SignaturePayload;
-    
+
     // Signature of this link made by avatar.
     signature: Signature;
 }
@@ -104,10 +104,11 @@ From day one, the connection data in Proof Service to public so that everyone ca
 [API docs](../../rest-api/kvservice-api.md)
 [An example of data in Arweave](https://viewblock.io/arweave/tx/wvzDhXgcglrUWob9CUjTfJ6tj322eCWDKI2bVtU_cx4)
 
-Noted that the APIs in the docs contain the API to help bind "Avatar <-> Identity", like `POST /v1/proof/payload` or `POST /v1/proof`, but also serval APIs to query the state of the [proofs](https://github.com/NextDotID/proof_server/blob/develop/docs/api.apib#L160) and [the proofchain under an avatar](https://github.com/NextDotID/proof_server/blob/develop/docs/api.apib#L285).
+Noted that the APIs in the docs contain the API to help bind `Avatar <-> Identity`, like `POST /v1/proof/payload` or `POST /v1/proof`, but also serval APIs to query the state of the [proofs](https://github.com/NextDotID/proof_server/blob/develop/docs/api.apib#L160) and [the proofchain under an avatar](https://github.com/NextDotID/proof_server/blob/develop/docs/api.apib#L285).
 The Arweave example contains the single Proof record and based on the mechanism of Arweave, can keep getting the previous record until Genesis one.
 
-## Supported Platform 
+## Supported Platform
+
 [Supported Platform](https://github.com/NextDotID/proof_server#supported)
 
 ## How to contribute

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

@@ -6,7 +6,7 @@ sidebar_position: 1
 
 In the preceding chapter, we discussed how to construct an identity graph using `ProofService`. Besides ProofService, there are several other data sources both on-chain and off-chain offering similar connections.`RelationService` aggregates the existing identities from ProofService and the other protocol whose identities are bound to and in parallel to Next.ID, structure the identities with the graph database and finally provide to the public via GraphQL. Hope to open up a range of possibilities for integration with external protocols and build a more comprehensive identity graph.
 
-`RelationService` aggregates and indexes the other third-party "identity <-> identity" connections from the data source to enrich the identity graph:
+`RelationService` aggregates and indexes the other third-party `identity <-> identity` connections from the data source to enrich the identity graph:
 
 - [ENS]
 - [Farcaster]

docs/introduction/how-it-works.md

@@ -39,7 +39,7 @@ After `ProofService`validates the signature with `uuid` and `created_at` fr
 
 ## [KVService](../core-concepts/proof-service/kvservice.md)
 
-### [Write Data](core-concepts/proof-service/ks-intro#write-data)
+### [Write Data](../core-concepts/proof-service/ks-intro#work-flow-for-writing)
 
 In this scenario, User requests for a modification on an Application. `KVService` will return the `sign_payload` based on the Application’s `POST /v1/KV/payload`.
 

docs/rest-api/kvservice-api.md

@@ -51,7 +51,7 @@ for Rust.
           + content (object, required) - KV-pair of this entry.
 
   + Body
-
+    ```json
         {
           "avatar": "0x04c7cacde73af939c35d527b34e0556ea84bab27e6c0ed7c6c59be70f6d2db59c206b23529977117dc8a5d61fa848f94950422b79d1c142bcf623862e49f9e6575",
           "proofs": [{
@@ -70,6 +70,7 @@ for Rust.
             }
           }]
         }
+    ```
 
 + Response 404 (application/json)
 
@@ -90,7 +91,8 @@ Persona not found (no KV was ever created).
 
   + Body
 
-        {
+    ```json
+    {
           "avatar": "0x04c7cacde73af939c35d527b34e0556ea84bab27e6c0ed7c6c59be70f6d2db59c206b23529977117dc8a5d61fa848f94950422b79d1c142bcf623862e49f9e6575",
           "platform": "nextid",
           "identity": "0x04c7cacde73af939c35d527b34e0556ea84bab27e6c0ed7c6c59be70f6d2db59c206b23529977117dc8a5d61fa848f94950422b79d1c142bcf623862e49f9e6575",
@@ -105,6 +107,7 @@ Persona not found (no KV was ever created).
               }
             }
         }
+    ```
 
 + Response 200 (application/json)
 
@@ -116,11 +119,13 @@ Persona not found (no KV was ever created).
 
   + Body
 
+    ```json
         {
           "uuid": "40c13c92-31e5-40d1-aebb-143d8e5b9c5e",
           "created_at": 1646983606,
           "sign_payload": "{\"action\":\"kv\",\"created_at\":1646983606,\"patch\":{\"a\":\"sample\",\"key_to_delete\":null,\"structure\":[\"it\",\"could\",\"be\",\"anything\"],\"this\":\"is\"},\"prev\":null,\"uuid\":\"40c13c92-31e5-40d1-aebb-143d8e5b9c5e\"}"
         }
+    ```
 
 ### Apply a patch [POST /v1/kv] {#patch}
 
@@ -137,7 +142,7 @@ Persona not found (no KV was ever created).
     + patch (object, required) - Patch content
 
   + Body
-
+    ```json
         {
           "avatar": "0x04c7cacde73af939c35d527b34e0556ea84bab27e6c0ed7c6c59be70f6d2db59c206b23529977117dc8a5d61fa848f94950422b79d1c142bcf623862e49f9e6575",
           "platform": "nextid",
@@ -156,7 +161,7 @@ Persona not found (no KV was ever created).
               }
             }
         }
-
+    ```
 + Response 201 (application/json)
 
-Created successfully. Response is same as `GET /v1/kv`.
+  Created successfully. Response is same as `GET /v1/kv`.