Add integrate guide

docs/build/interfaces.md

@@ -14,7 +14,7 @@ This table summarizes the core interfaces that may be used in the application's
 
 The `IMessagePort` interface within the Msgport is crafted to simplify the complexities of underlying cross-chain messaging protocols for dApp developers. It offers a standardized interface to send cross-chain messages across various messaging protocols. The interface includes two critical functions:
 
-- **`send()`**: Serves as the gateway for users or applications to dispatch cross-chain messages.
+- **`send()`**: Serves as the gateway for users or applications to send a cross-chain message. It returns a msgId, which is the identifier of the message and can be used to track the message status.
 - **`fee()`**: Retrieves the necessary fee information for utilizing the **`send()`** function.
 
 The Msgport layer accommodates a variety of messaging protocols that adhere to this interface, including ORMP, ICMP, and XCMP, among others. The code for the interface furnishes detailed explanations of each function's use.

docs/build/tutorial/validation.md

@@ -4,7 +4,7 @@ For the application that receives cross-chain messages, it is crucial to validat
 
 The basic validation materials are provided by the Msgport [Application](../interfaces.md#application) contract. It provides the following functions:
 
-* `_msgPort()`: Returns the `msg.sender` of the received message, typically the address of the corresponding message port.
+* `_msgPort()`: Returns the `msg.sender` of the received message, typically the address of the corresponding port.
 * `_messageId()`: Returns the message ID of the received message.
 * `_chainId()`: Returns the chain ID of the source chain. It is recommended to validate it by default.
 * `_xmsgSender()`: Returns the application address in the source chain from which the received message originates. It is recommended to validate it by default.

docs/build/workflow.md

@@ -1,42 +1,48 @@
-# Message Workflow
+# Integrate Msgport into Your Application
 
-Within the diverse landscape of today's blockchain technology, each blockchain possesses its unique architecture and set of features. This diversity often results in cross-chain messaging protocols that are multifaceted, involving numerous roles, and can appear daunting to comprehend in terms of message transmission and execution across different chains.
+!!! note
+    It's recommended to understand the [core interface](./interfaces.md) of the Msgport before diving into the integration process.
 
-For dApp developers looking to incorporate these cross-chain messaging protocols into their applications, a solid grasp of the underlying mechanics is crucial. This knowledge becomes particularly important when encountering unexpected issues during development, which can often be resolved with an awareness of how these complex systems operate.
+!!! note
+    For those interested in gaining a more in-depth understanding of how Msgport operates, there are some [runnable examples available](https://github.com/msgport/msgport-examples) for reference. This can be a valuable resource to see the Msgport in action.
 
-The purpose of this page is to provide you with a clear understanding of how the Msgport and [ORMP](../learn/messaging-protocols/ormp.md) messaging protocols facilitate cross-chain interactions. By breaking down these protocols, we aim to demystify the process, making it more accessible for developers needing to integrate cross-chain functionality into their projects.
+The purpose of this page is to provide a step-by-step guide on how to integrate the Msgport into your application and the concrete steps to follow in the process. By following these instructions, you can quickly and easily integrate Msgport into your application and unlock the potential of cross-chain messaging.
 
-## Check Network Support
+The guide is divided into the following steps:
 
-Before diving into the integration of the Msgport protocol, the initial and critical step is to confirm whether the [Msgport supports the network](./networks.md) you intend to use. If the network is supported, the integration process simplifies significantly, and your focus shifts to learning how to utilize the Msgport contract's capabilities for sending and receiving cross-chain messages. Typically, getting accustomed to these functions could take as little as half a day.
+1. [Check Network Support](#check-network-support)
+2. [Find Port Contract Address](#find-port-contract-address)
+3. [Extend Target Chain Receiver](#extend-target-chain-receiver)
+4. [Prepare the Message Payload](#prepare-the-message-payload)
+4. [Estimate Message Fee](#estimate-message-fee)
+5. [Send Message](#send-message)
+6. [Track the Message Status](#track-the-message-status)
 
-On the other hand, if the network is not currently supported, your first course of action should be to Msgport team to inquire about potential future support. Alternatively, if you prefer a more hands-on approach, you have the option to develop and deploy the necessary contracts yourself and register them with the PortRegister.
+## Check Network Support
 
-## Messaging Workflow
+Before diving into the integration of the Msgport, the initial and critical step is to confirm whether the [Msgport supports the network](./networks.md) you intend to use. If the network is supported, the integration process simplifies significantly, and your focus shifts to learning how to utilize the Msgport contract's capabilities for sending and receiving cross-chain messages. Typically, getting accustomed to these functions could take as little as half a day.
 
-!!! note
-    For those interested in gaining a more in-depth understanding of how Msgport operates, there are some [runnable examples available](https://github.com/msgport/msgport-examples) for reference. This can be a valuable resource to see the message port in action.
+On the other hand, if the network is not currently supported, your first course of action should be to Msgport team to inquire about potential future support. Alternatively, if you prefer a more hands-on approach, you have the option to develop and deploy the necessary contracts yourself and register them with the PortRegister.
 
-### Find The Port Contract Address
+## Find Port Contract Address
 
 After verifying that the Msgport aligns with your project's objectives, the subsequent step is to locate the port contract address. If you're unfamiliar with the concept of a port contract, you can learn more by visiting **[this link](../learn/glossary.md#port)**. There are two methods to acquire the appropriate port address:
 
 1. Check the [Supported Networks list](./networks.md) for the endpoint. The port addresses are standardized across all networks to enhance clarity and ease of use, and you can easily find this information there.
 2. Use the  `get(uint256 chainId, string calldata name)` function to consult the [PortRegistry](../learn/glossary.md#portregistry) contract. By supplying the chainId and the specific protocol name, you can retrieve the endpoint for the target network. The PortRegistry contract is a detailed ledger of all registered port contracts, providing a trustworthy reference point.
 
-### Build Receiver In the Target Chain
+## Extend Target Chain Receiver
 
 Integrating Msgport into the receiver application on the target chain is a straightforward process. Simply extend your contract to implement the [Application](./interfaces.md#application) interface, and then incorporate your business logic into the contract as usual. Below is a demo code snippet for your reference.
 
-```solidity linenums="1" title="TestReceiver.sol"
+```solidity linenums="1" title="ExampleReceiver.sol"
 pragma solidity ^0.8.17;
 
-import "lib/darwinia-msgport/src/user/Application.sol";
+import "msgport/user/Application.sol";
 
-contract TestReceiver is Application {
+contract ExampleReceiver is Application {
     event DappMessageRecv(uint256 fromChainId, address fromDapp, address localPort, uint256 num);
 
-    // local port address
     address public immutable PORT;
 
     uint256 public sum;
@@ -46,44 +52,46 @@ contract TestReceiver is Application {
         REMOTE_DAPP = remoteDapp;
     }
 
-    /// @notice You could check the fromDapp address or messagePort address.
     function addReceiveNum(uint256 num) external {
+        // optional validation
         uint256 fromChainId = _fromChainId();
         address fromDapp = _xmsgSender();
         address localPort = _msgPort();
         require(localPort == PORT);
+        
         sum += num;
+
         emit DappMessageRecv(fromChainId, fromDapp, localPort, num);
     }
 }
 ```
 
-The **`TestReceiver`** contains a public **`num`** variable and provides an **`addReceiveNum`** function that can be used to increment this value. Next, we will outline the steps for activating this function through Msgport to increase the **`num`** value from a different blockchain.
+The **`ExampleReceiver`** contains a public **`sum`** variable and provides an **`addReceiveNum`** function that can be used to increment this value. Next, we will outline the steps for activating this function through Msgport to increase the **`sum`** value from a different blockchain.
 
-### Setting Up The Message Content
+## Prepare the Message Payload
 
 Prior to initiating a cross chain transaction, it's essential to determine the content of the message, which encompasses several key fields required for the message transmission process:
 
 - **`toChainId`**: This is the identifier of the destination chain where the message will be sent.
-- **`toDapp`**: This refers to the contract address of the user application that will receive the message on the destination chain, in this example, the `TestReceiver` address.
-- **`message`**: This is the ABI-encoded call data that contains the information or instructions for the receiving contract, in this example, `bytes memory message = abi.encodeCall(TestReceiver.addReceiveNum, 10);`
+- **`toDapp`**: This refers to the contract address of the user application that will receive the message on the destination chain, in this example, the `ExampleReceiver` address.
+- **`message`**: This is the ABI-encoded call data that contains the information or instructions for the receiving contract, in this example, `bytes memory message = abi.encodeCall(ExampleReceiver.addReceiveNum, 10);`
 
-### Estimate Message Fee in Native Token
+## Estimate Message Fee
 
 Message fees play a critical role in the design of a cross-chain messaging protocol. They represent not just the cost of incorporating cross-chain functionality into your applications, but they also impact the user experience of your application. A thoughtfully constructed fee mechanism is crucial for success.
 
-The fee structure for Msgport is implemented through the [Msgport API](https://github.com/msgport/msgport-api). For detailed information on the fee design, please refer to the [Msgport API Document](./api.md). Additionally, you can explore the [Msgport examples](https://github.com/msgport/msgport-examples) to see how the fee mechanism is applied in practice.
+The cross-chain estimated fee can be obtained through the [Msgport API](https://apidog.msgport.xyz/). For more information on how to use the API, refer to the [documentation](./api.md). Additionally, you can find examples of how to fetch the estimated fee via script in the [Msgport Examples](https://github.com/msgport/msgport-examples) repository.
 
-### Send Message In Source Chain Application
+## Send Message
 
-With the preliminary setup out of the way, you're all set to send your cross-chain message. The process is quite simple—refer to the demo code below for guidance.
+With the preliminary setup out of the way, you're all set to send your cross-chain message. The process is quite simple, and refer to the demo code below for guidance.
 
-```solidity linenums="1" title="TestSender.sol"
+```solidity linenums="1" title="ExampleSender.sol"
 pragma solidity ^0.8.17;
 
-import "lib/darwinia-msgport/src/interfaces/IMessagePort.sol";
+import "msgport/interfaces/IMessagePort.sol";
 
-contract TestSender {
+contract ExampleSender {
     event DappMessageSent(address localPort, bytes message);
 
     address public immutable PORT;
@@ -93,21 +101,21 @@ contract TestSender {
     }
 
     function send(uint256 toChainId, address toDapp, bytes calldata message, bytes calldata params) external payable {
-        **IMessagePort(PORT).send{value: msg.value}(toChainId, toDapp, message, params);**
+        IMessagePort(PORT).send{value: msg.value}(toChainId, toDapp, message, params);
+
         emit DappMessageSent(PORT, message);
     }
 }
 ```
 
 The line **`IMessagePort(PORT).send{value: msg.value}(toChainId, toDapp, message, params);`** initiates the cross-chain messaging process. Here's a breakdown of its components:
 
-- **`PORT`**: This is the port contract address you've located in the previous "Find the Port Contract Address" step.
-- **`toChainId`**, **`toDapp`**, and **`message`**: These are the variables you've established while preparing the message content, the
-- **`msg.value`** and **`params`**: These represent the estimated message fee in the native token, as determined in the "Estimate Message Fee" step.
-
-By invoking the **`send`** function within the TestSender demo with the parameters you've prepared, your message is transmitted to the specified **`toChainId`** and will be executed by the **`toDapp`** contract on the destination chain. And that's the entire process.
+- **`PORT`**: This is the port contract address you've located in the previous [Find Port Contract Address](#find-port-contract-address) step.
+- **`toChainId`**, **`toDapp`**, and **`message`**: These are the variables you've established while [Prepare the Message Payload](#prepare-the-message-payload).
+- **`msg.value`** and **`params`**: These represent the estimated message fee in the native token, as determined in the [Estimate Message Fee](#estimate-message-fee) step.
 
-### Monitor The Message Status
+By invoking the **`send`** function within the ExampleSender demo with the parameters you've prepared, your message is transmitted to the specified **`toChainId`** and will be executed by the **`toDapp`** contract on the destination chain. And that's the entire process.
 
-The delivery and execution of your message on the target chain may take approximately 5 to 15 minutes. To monitor the status of your message, we offer a scanning tool [Messages Scan](https://scan.msgport.xyz/) that allows you to track the progress using your sent message's transaction hash or the message hash itself.
+## Track the Message Status
 
+The delivery and execution of your message on the target chain may take approximately 5 minutes. To monitor the status of your message, we offer a scanning tool [Messages Scan](https://scan.msgport.xyz/) that allows you to track the progress using your sent message's transaction hash or the message id.

mkdocs.yml

@@ -186,7 +186,7 @@ nav:
   - Developers:
       - Supported Networks: "build/networks.md"
       - Core Interfaces: "build/interfaces.md"
-      - Message Workflow: "build/workflow.md"
+      - Integration Guide: "build/workflow.md"
       - Message Scan: "build/scan.md"
       - API Documentation: "build/api.md"
       - Tutorial: