diff --git a/docs.json b/docs.json index d3909d2d..d1e84713 100644 --- a/docs.json +++ b/docs.json @@ -124,6 +124,7 @@ "pages": [ "ecosystem/ton-connect/index", "ecosystem/ton-connect/manifest", + "ecosystem/ton-connect/message-lookup", { "group": "Applications (dApps)", "pages": [ @@ -167,7 +168,6 @@ "group": "RPC providers", "pages": [ "ecosystem/rpc/overview", - "ecosystem/rpc/external-normalization", "ecosystem/rpc/toncenter" ] }, diff --git a/ecosystem/rpc/external-normalization.mdx b/ecosystem/ton-connect/message-lookup.mdx similarity index 87% rename from ecosystem/rpc/external-normalization.mdx rename to ecosystem/ton-connect/message-lookup.mdx index 58b36450..1ef524b4 100644 --- a/ecosystem/rpc/external-normalization.mdx +++ b/ecosystem/ton-connect/message-lookup.mdx @@ -1,5 +1,5 @@ --- -title: "External message normalisation" +title: "Message lookup" --- import { Aside } from "/snippets/aside.jsx"; @@ -8,14 +8,15 @@ import { Aside } from "/snippets/aside.jsx"; You should never use external message tracking for payment processing purposes. Check out [payment processing](/guidebook/payment) for more details. +## Introduction -Normalization is a standardization process that converts different representations into a consistent format. While messages across interfaces follow the TL-B scheme, structural differences in implementation sometimes lead to collisions. +The process of seeking a transaction associated with an `external-in` message is called **message lookup**. It should only be used for better UX to display, for example, the progress of the operation and its result. -To address this, the ecosystem defines a standard that ensures consistent hash calculation. The normalization rules are specified in detail in [TEP-467](https://github.com/ton-blockchain/TEPs/pull/467). +### Message normalization -**The problem normalization solves:** +Normalization is a standardization process that converts different external-in message representations into a consistent format. This needs to be done because the structure of external-in messages allows the same message to be constructed in different forms, which results in different possible hashes for the same external message. -Functionally identical messages may differ in how they represent the `src`, `import_fee`, and `init` fields. These variations result in different hashes for messages with equivalent content, which complicates transaction tracking and deduplication. +To address this, the ecosystem defines a standard that ensures consistent hash calculation. The normalization rules are specified in detail in the [TEP-467 proposal](https://github.com/ton-blockchain/TEPs/pull/467). Message lookup by its normalized hash is already implemented in most TON [RPC providers](/ecosystem/rpc/overview). **How normalization works:** @@ -26,15 +27,7 @@ The normalized hash is computed by applying the following standardization rules 3. **InitState (`init`)**: set to an empty value 4. **Body**: always stored as a reference -# Transaction lookup using external message from TON Connect - -This guide shows how to find the transaction associated with an `external-in` message on the TON blockchain. - -## Message normalization - -In TON, messages may contain fields like `init`, `src` and `importFee`. These fields should be removed or zeroed out before calculating the message hash, as described in [TEP-467](https://github.com/ton-blockchain/TEPs/blob/8b3beda2d8611c90ec02a18bec946f5e33a80091/text/0467-normalized-message-hash.md). - -Use the function below to generate a **normalized message hash**: +## Transaction lookup using external message from TON Connect ```ts /**