add initial sui docs

docs/develop/message-transfer-via-crosstalk/sample-idapps/on-sui/README.mdx

@@ -0,0 +1,20 @@
+---
+title: Sample Sui iDapps
+sidebar_position: 1
+---
+
+import {
+  HomepageCard as Card,
+  HomepageSection as Section,
+} from '../../../../../src/components/HomepageComponents';
+
+This section will include a step-by-step guide to building Near iDapps by leveraging Router's infra.
+
+
+  <Section>
+  <Card
+  title="Cross-chain Ping Pong"
+  description="Create a ping pong iDapp which can send message from one chain to another along with receiving an acknowledgement of the message."
+  to="ping-pong"
+  />
+  </Section>

docs/develop/message-transfer-via-crosstalk/sample-idapps/on-sui/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "On Sui",
+  "position": 3
+}

docs/develop/message-transfer-via-crosstalk/sample-idapps/on-sui/ping-pong.md

@@ -0,0 +1,81 @@
+---
+title: Cross-chain Ping Pong
+sidebar_position: 1
+description: A simple ping pong dApp using Router CrossTalk
+---
+
+## Overview
+
+In this section, we will create a cross-chain ping pong dApp using Router CrossTalk. Using this dApp, you can send any message (ping) from a source chain to a destination chain and receive an acknowledgment (pong) back to the source chain. 
+
+## Step-by-Step Guide
+
+<details>
+<summary><b>Step 1) Prerequisites </b></summary>
+Before you begin, ensure you have met the following requirements:
+
+* [Sui](https://docs.sui.io/guides/developer/getting-started/sui-install)
+* [Node.js](https://nodejs.org/en/download/package-manager)
+
+</details>
+
+<details>
+<summary><b>Step 2) Cloning the Ping Pong Contract Locally Written In Sui Move</b></summary>
+
+```bash
+git clone https://github.com/router-protocol/new-crosstalk-sample.git
+```
+After cloning the this repo, change your directory:
+
+```bash
+cd ./sui
+```
+</details>
+
+<details>
+<summary><b>Step 3) Program Structure </b></summary>
+
+### Events
+
+* [`AckFromDestination`](https://github.com/router-protocol/new-crosstalk-sample/blob/master/sui/contracts/ping_pong/sources/ping_pong.move#L23): Acknowledgment event emitted after receiving a message from a destination chain.
+* [`PingFromSource`](https://github.com/router-protocol/new-crosstalk-sample/blob/master/sui/contracts/ping_pong/sources/ping_pong.move#L30): Event emitted when a ping is received from a source chain.
+* [`NewPing`](https://github.com/router-protocol/new-crosstalk-sample/blob/master/sui/contracts/ping_pong/sources/ping_pong.move#L19): Event emitted when a new ping is sent.
+
+### Main Functions
+
+* 💡[`initialize`](https://github.com/router-protocol/new-crosstalk-sample/blob/master/sui/contracts/ping_pong/sources/ping_pong.move#L73): Set's metadata object in state and chain id.
+* [`set_dapp_metadata`](https://github.com/router-protocol/new-crosstalk-sample/blob/master/sui/contracts/ping_pong/sources/ping_pong.move#L131): Sets the fee payer on the router chain. This enables the chain to deduct the fee from the designated fee payer for any cross-chain request (fees are deducted in ROUTE tokens).
+:::note
+`set_dapp_metadata` must be called before invoking the `i_ping` request.
+:::
+* [`i_ping`](https://github.com/router-protocol/new-crosstalk-sample/blob/master/sui/contracts/ping_pong/sources/ping_pong.move#L84): Sends a ping to another blockchain, specifying the destination chain, contract, and metadata. Internally, it initializes a `request_packet` account and sets the destination contract and packet.
+:::note
+Please note, before making a ping call, approve the fee payer request on explorer.
+:::
+* [`i_receive`](https://github.com/router-protocol/new-crosstalk-sample/blob/master/sui/contracts/ping_pong/sources/ping_pong.move#L150): Receives a ping from another chain and processes it.
+* [`i_ack`](https://github.com/router-protocol/new-crosstalk-sample/blob/master/sui/contracts/ping_pong/sources/ping_pong.move#L182): Acknowledges a message and emits relevant events.
+
+Implementing the default trait is necessary on Sui to acheive cross-chain functionality.
+</details>
+
+
+<details>
+<summary><b>Step 4) Build Ping Pong Program And Publish It On Testnet </b></summary>
+
+Build program before deploying
+
+```bash
+sui move build
+```
+
+Publish it now on testnet
+
+```bash
+sui client switch --env testnet                                                                                                      
+```
+
+```bash
+sui client publish --gas-budget 8000000000 .
+```
+</details>
+

docs/develop/message-transfer-via-crosstalk/sui-guides/README.mdx

@@ -0,0 +1,24 @@
+---
+title: Sui Guides
+sidebar_position: 1
+---
+
+import {
+  HomepageCard as Card,
+  HomepageSection as Section,
+} from '../../../../src/components/HomepageComponents';
+
+This section will cover how the crosschain framework can be used for Sui contracts to build iDapps. It provides the details around various functions and how they can be implemented using some sample contracts.
+
+<Section title="Theoretical Concepts" id="web-sdks">
+    <Card
+    title="iDapp Functions"
+    description="Understand the various functions Crosstalk provides to create your iDapp."
+    to="idapp-functions"
+  />
+  <Card
+    title="Additional Security Module"
+    description="How iDapps can use ASM to add another layer of security as required."
+    to="asm-implementation"
+  />
+</Section>

docs/develop/message-transfer-via-crosstalk/sui-guides/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Sui Guides",
+  "position": 5
+}

docs/develop/message-transfer-via-crosstalk/sui-guides/asm-implementation/README.md

@@ -0,0 +1,61 @@
+---
+title: ASM Implementation
+sidebar_position: 1
+---
+
+:::info
+To understand how Router ASM works, refer to this [link](../../message-transfer-via-crosstalk/key-concepts/additional-security-modules#how-does-an-asm-work).
+:::
+
+The function `verify_cross_chain_request` enhances security for a specific cross-chain flow.
+
+When a request is received on the destination chain, the `verify_cross_chain_request` function is invoked on the specified ASM (Application Security Module) address before executing the user's contract calls. The ASM can return either `true` or `false` to instantly validate or invalidate the request. If further time is needed for validation, the ASM can revert the request.
+
+If the function returns `true`, the execution of the user contract calls will proceed. If it returns `false`, the contract calls will be skipped. Should the ASM implementation revert the request, the transaction will be rolled back, and no state changes will occur on the Gateway.
+
+The ASM module can continue to revert requests until it can confidently validate or invalidate them. This ensures that application-level validation is completed before any cross-chain request is executed on the Gateway contract and sent to the destination contract.
+
+```rust
+public entry fun verify_cross_contract_request(
+    self: &mut AsmContract, 
+    gateway_contract_obj: &mut gateway_contract::GatewayContract, 
+    sent: Receiving<gateway_contract::ValidateAsm>, 
+    ctx: &mut TxContext
+)
+```
+
+In this function selector, there are 6 arguments that can be retrieved by calling `get_verify_cross_chain_request_args`. Within this function, any necessary business logic or validation can be added using these arguments. Each argument has its own purpose in the `verify_cross_chain_request` request:
+
+```rust
+public fun get_verify_cross_chain_request_args(self: &ValidateAsm): (
+    u256, 
+    u256,     
+    String, 
+    String, 
+    vector<u8>, 
+    address, 
+    address
+)
+```
+
+##### Return Arguments:
+
+* `request_identifier`: A unique identifier of the request. It is added by the source chain's Gateway contract.
+* `request_timestamp`: Timestamp when a request is added/verified on the Router Chain.
+* `request_sender`: The address of the application's contract on the source chain, represented as a string.
+* `src_chain_id`: The chain ID of the src chain, in string format.
+* `packet`: dst packet bytes
+* `dapp_module_address`: dapp package id
+* `dapp_object_id`: dapp state id
+
+After validation, the ASM must call the `validate_asm` function in the gateway contract, where the valid state determines if the request is valid or not.
+
+```rust
+public fun validate_asm(
+    self: &mut GatewayContract, 
+    validate_asm: ValidateAsm, 
+    valid: bool,
+    ctx: &mut TxContext
+)
+```
+

docs/develop/message-transfer-via-crosstalk/sui-guides/asm-implementation/_category_.json

@@ -0,0 +1,4 @@
+{
+    "label": "ASM Implementation",
+    "position": 4
+}

docs/develop/message-transfer-via-crosstalk/sui-guides/iDapp-functions/README.md

@@ -0,0 +1,8 @@
+# Sui iDapp Functions
+
+Cross-chain message transmission on the Sui chain is enabled through the `i_send` function in Router's Gateway contract. When initiating a cross-chain request, developers can invoke this function, passing the required parameters along with the payload that needs to be transferred from the source chain to the destination chain.
+
+To ensure successful cross-chain communication, Sui iDapp developers must also implement the following essential functions within their contracts:
+1. `i_receive`: This function must be included on the destination chain to handle incoming cross-chain requests.
+2. `i_ack`: Implement this function to process acknowledgment of requests on the source chain, particularly when cross-chain acknowledgment is required.
+3. `set_dapp_metadata`: This function is necessary to designate a fee_payer for executing cross-chain requests. Without setting this, requests will remain in a blocked state on the Router Chain.

docs/develop/message-transfer-via-crosstalk/sui-guides/iDapp-functions/_category_.json

@@ -0,0 +1,4 @@
+{
+    "label": "iDapp Functions",
+    "position": 2
+}

docs/develop/message-transfer-via-crosstalk/sui-guides/iDapp-functions/i_ack.md

@@ -0,0 +1,48 @@
+---
+title: i_ack
+sidebar_position: 4
+---
+
+After the `i_receive` function is executed, an acknowledgment is generated by Router's destination chain Gateway contract, indicating whether the call was successful. The i_ack function must be implemented in your contract with the following structure:
+
+```rust
+ public entry fun i_ack(
+    self: &mut DappContract,
+    gateway_contract_obj: &mut gateway_contract::GatewayContract,
+    sent: Receiving<gateway_contract::ExecuteDappIAck>,
+    _ctx: &mut TxContext
+)
+```
+
+#### Parameters:
+
+* `self`: The dapp package state object ID.
+* `gateway_contract_obj`: The state ID of the gateway package.
+* `sent`: The object being sent to the self object while making the `i_ack` call on the gateway contract.
+
+To obtain the arguments required for the i_receive function, the contract should call `get_i_ack_args` in the gateway package. This function will return a tuple containing:
+
+* `request_identifier`: This is the same nonce received when calling the `i_send` function on the source chain's Gateway contract. It helps map the acknowledgment to the corresponding request.
+* `exec_flag`: A boolean value indicating the execution status of the request on the destination chain.
+* `exec_data`: exec data returned on the dst i_Receive call.
+
+```rust
+public fun get_i_ack_args(self: &ExecuteDappIAck): (u256, bool, vector<u8>)
+```
+
+Note: Similar to `i_receive`, after the execution of `i_ack`, the DApp needs to call the `executed_i_ack_dapp` function in the gateway contract to complete the flow.
+
+```rust
+public fun executed_i_ack_dapp(
+    self: &mut GatewayContract, 
+    execute_dapp: ExecuteDappIAck, 
+    exec_data: vector<u8>, 
+    exec_flag: bool
+)
+```
+
+:::caution
+It is mandatory to include this function in your contract on the src chain if i_ack is required; otherwise, the request will fail.
+:::
+
+

docs/develop/message-transfer-via-crosstalk/sui-guides/iDapp-functions/i_receive.md

@@ -0,0 +1,47 @@
+---
+title: i_receive
+sidebar_position: 3
+---
+
+The cross-chain request initiated from the source chain will deliver the payload to the destination contract address specified in the `contractCalls` parameter. On the destination contract, a function must be implemented to handle this payload:
+
+```rust
+public entry fun i_receive(
+    self: &mut DappContract,
+    gateway_contract_obj: &mut gateway_contract::GatewayContract,
+    sent: Receiving<gateway_contract::ExecuteDappIReceive>,
+    ctx: &mut TxContext
+)
+```
+
+#### Parameters:
+
+* `self`: The dapp package state object ID.
+* `gateway_contract_obj`: The state ID of the gateway package.
+* `sent`: The object being sent to the self object while making the i_receive call on the gateway contract.
+
+To obtain the arguments required for the i_receive function, the contract should call `get_i_receive_args` in the gateway package. This function will return a tuple containing:
+
+1. `request_Sender`: The address of the sender making the request.
+2. `packet`: A vector of bytes (`vector<u8>`) representing the data packet.
+3. `src_chain_id`: The source chain ID from which the request originated.
+
+```rust
+public fun get_i_receive_args(self: &ExecuteDappIReceive): (String, vector<u8>, String)
+```
+
+Note: After the execution of `i_receive`, the DApp needs to call the `executed_i_receive_dapp` function in the gateway contract to complete the flow.
+
+```rust
+public fun executed_i_receive_dapp(
+    self: &mut GatewayContract, 
+    execute_dapp: ExecuteDappIReceive, 
+    exec_data: vector<u8>,
+    exec_flag: bool, 
+    ctx: &mut TxContext
+)
+```
+
+:::caution
+It is mandatory to include this function in your contract on the destination chain; otherwise, the request will fail.
+:::