From e047c9e58ce1a665440d9a21cf285180a25cce35 Mon Sep 17 00:00:00 2001 From: Oleg Andreev Date: Tue, 26 Dec 2023 16:43:05 +0100 Subject: [PATCH 1/5] prepare referral code spec --- 0000-template.md => 0000-referral-query-id.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) rename 0000-template.md => 0000-referral-query-id.md (83%) diff --git a/0000-template.md b/0000-referral-query-id.md similarity index 83% rename from 0000-template.md rename to 0000-referral-query-id.md index f83558e6..88b4a4c6 100644 --- a/0000-template.md +++ b/0000-referral-query-id.md @@ -1,11 +1,9 @@ - **TEP**: [0](https://github.com/ton-blockchain/TEPs/pull/0) *(don't change)* -- **title**: TEP Template *(write title of TEP here)* +- **title**: Referral code in Query ID - **status**: Draft -- **type**: Meta / Core / Contract Interface *(choose one)* -- **authors**: [Vladimir Lebedev](https://github.com/hacker-volodya) *(replace)* -- **created**: DD.MM.YYYY *(fill with current date)* -- **replaces**: [TEP-0](https://github.com/ton-blockchain/TEPs/blob/master/0000-template.md) -- **replaced by**: - +- **type**: Contract Interface +- **authors**: [Denis Subbotin](https://github.com/mr-tron), [Oleg Andreev](https://github.com/oleganza) +- **created**: 26.12.2023 # Summary From 43d4503f740f946491d6ee2d671a96c2cdf47433 Mon Sep 17 00:00:00 2001 From: Oleg Andreev Date: Tue, 26 Dec 2023 17:03:09 +0100 Subject: [PATCH 2/5] Update 0000-referral-query-id.md --- 0000-referral-query-id.md | 29 +++++++++-------------------- 1 file changed, 9 insertions(+), 20 deletions(-) diff --git a/0000-referral-query-id.md b/0000-referral-query-id.md index 88b4a4c6..5fe207e0 100644 --- a/0000-referral-query-id.md +++ b/0000-referral-query-id.md @@ -7,40 +7,29 @@ # Summary -Which feature this document introduces? Describe it in one paragraph. +This is a proposal to split Query ID in two halves: the referral code and arbitrary app-specific data. # Motivation -Which problem we address? Why it is important to make a new TEP? +Standard way to self-identify apps that initiate transactions makes it easier to operate referral and profit-sharing programs and gather usage statistics. # Guide -Explain this document in simple language, as if you were teaching it to another developers. Give examples how your feature will work in real life. +* Applications and services may self-assign unique identifiers to disambiguate their application from others. +* In privacy-preserving applications users may expect absence of any referral codes. In such cases apps may offer an option to leave the referral code as all-zeroes or use other app’s well-known identifier at random. # Specification -This section describes your feature formally. It contains requirements, which must be followed in order to implement your TEP. To keep things formal, it is convenient to follow [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). You should include following text at the beginning of this section: +Split 64-bit Query ID in two halves: -> The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. +* First 32 bits (high bits) identify the author of the transaction: dapp or wallet that originates the message to the TON network. +* Second 32 bits (low bits) are reserved for arbitrary use: identifying individual queries in smart-contracts, random nonces etc. # Drawbacks -Why should we *not* do this? +This proposal splits the space of possible identifiers in two equal halves. If one's application needs a longer than 32-bit identifiers for the queries, part of the referral code space must be used. # Rationale and alternatives -- Why is this design the best in the space of possible designs? -- What other designs have been considered and what is the rationale for not choosing them? -- What is the impact of not doing this? +The suggested proposal is simple and easy to follow, making on-chain statistics and referral programs easy to operate. -# Prior art - -Discuss prior art, both the good and the bad, in relation to this proposal. How the problem stated in "Motivation" section was solved in another blockchains? This section encourages you as an author to learn from others' mistakes. Feel free to include links to blogs, books, Durov's whitepapers, etc. - -# Unresolved questions - -If there are some questions that have to be discussed during review process or to be solved during implementation of this TEP, write it here. - -# Future possibilities - -Do you have ideas, which things can be implemented on top of this TEP later? Write possible ideas of new TEPs, which are related to this TEP. From a44850d6d0403e3e3e25abe366e803e97bdb8913 Mon Sep 17 00:00:00 2001 From: Oleg Andreev Date: Tue, 26 Dec 2023 17:03:26 +0100 Subject: [PATCH 3/5] Update 0000-referral-query-id.md --- 0000-referral-query-id.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/0000-referral-query-id.md b/0000-referral-query-id.md index 5fe207e0..0907df47 100644 --- a/0000-referral-query-id.md +++ b/0000-referral-query-id.md @@ -16,7 +16,7 @@ Standard way to self-identify apps that initiate transactions makes it easier to # Guide * Applications and services may self-assign unique identifiers to disambiguate their application from others. -* In privacy-preserving applications users may expect absence of any referral codes. In such cases apps may offer an option to leave the referral code as all-zeroes or use other app’s well-known identifier at random. +* In privacy-preserving applications users may expect absence of any referral codes. In such cases apps may offer an option to leave the referral code as all-zeros or use other app’s well-known identifier at random. # Specification From 67bad8fcda35533d991e46c2f00f69ae5753eace Mon Sep 17 00:00:00 2001 From: Oleg Andreev Date: Mon, 26 Feb 2024 12:46:51 +0100 Subject: [PATCH 4/5] Create 0000-template.md bring back template file --- 0000-template.md | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 0000-template.md diff --git a/0000-template.md b/0000-template.md new file mode 100644 index 00000000..f83558e6 --- /dev/null +++ b/0000-template.md @@ -0,0 +1,48 @@ +- **TEP**: [0](https://github.com/ton-blockchain/TEPs/pull/0) *(don't change)* +- **title**: TEP Template *(write title of TEP here)* +- **status**: Draft +- **type**: Meta / Core / Contract Interface *(choose one)* +- **authors**: [Vladimir Lebedev](https://github.com/hacker-volodya) *(replace)* +- **created**: DD.MM.YYYY *(fill with current date)* +- **replaces**: [TEP-0](https://github.com/ton-blockchain/TEPs/blob/master/0000-template.md) +- **replaced by**: - + +# Summary + +Which feature this document introduces? Describe it in one paragraph. + +# Motivation + +Which problem we address? Why it is important to make a new TEP? + +# Guide + +Explain this document in simple language, as if you were teaching it to another developers. Give examples how your feature will work in real life. + +# Specification + +This section describes your feature formally. It contains requirements, which must be followed in order to implement your TEP. To keep things formal, it is convenient to follow [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). You should include following text at the beginning of this section: + +> The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. + +# Drawbacks + +Why should we *not* do this? + +# Rationale and alternatives + +- Why is this design the best in the space of possible designs? +- What other designs have been considered and what is the rationale for not choosing them? +- What is the impact of not doing this? + +# Prior art + +Discuss prior art, both the good and the bad, in relation to this proposal. How the problem stated in "Motivation" section was solved in another blockchains? This section encourages you as an author to learn from others' mistakes. Feel free to include links to blogs, books, Durov's whitepapers, etc. + +# Unresolved questions + +If there are some questions that have to be discussed during review process or to be solved during implementation of this TEP, write it here. + +# Future possibilities + +Do you have ideas, which things can be implemented on top of this TEP later? Write possible ideas of new TEPs, which are related to this TEP. From 8cd37ecef7d359f0b6cfa2462e322ab03b5142c7 Mon Sep 17 00:00:00 2001 From: Oleg Andreev Date: Mon, 26 Feb 2024 12:52:37 +0100 Subject: [PATCH 5/5] added crc32 and trustedness comments --- 0000-referral-query-id.md | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/0000-referral-query-id.md b/0000-referral-query-id.md index 0907df47..3f645bfa 100644 --- a/0000-referral-query-id.md +++ b/0000-referral-query-id.md @@ -11,25 +11,32 @@ This is a proposal to split Query ID in two halves: the referral code and arbitr # Motivation -Standard way to self-identify apps that initiate transactions makes it easier to operate referral and profit-sharing programs and gather usage statistics. +Standard way to self-identify apps that initiate transactions makes it easier to operate referral and profit-sharing programs and gather usage statistics in off-chain context. # Guide -* Applications and services may self-assign unique identifiers to disambiguate their application from others. -* In privacy-preserving applications users may expect absence of any referral codes. In such cases apps may offer an option to leave the referral code as all-zeros or use other app’s well-known identifier at random. +Applications and services may self-assign unique identifiers to disambiguate their application from others. We suggest using CRC32 code: + +``` +crc32('tonkeeper') = 0x546de4ef +crc32('dedust') = 0xc671412d +``` + +In privacy-preserving applications users may expect absence of any referral codes. In such cases apps may offer an option to leave the referral code as all-zeros or use other app’s well-known identifier at random. # Specification Split 64-bit Query ID in two halves: -* First 32 bits (high bits) identify the author of the transaction: dapp or wallet that originates the message to the TON network. +* First 32 bits (high bits) identify the author of the transaction: dapp or wallet that originates the message to the TON network. You SHOULD use CRC32 code of a fully-specified string describing your application. * Second 32 bits (low bits) are reserved for arbitrary use: identifying individual queries in smart-contracts, random nonces etc. # Drawbacks -This proposal splits the space of possible identifiers in two equal halves. If one's application needs a longer than 32-bit identifiers for the queries, part of the referral code space must be used. +This proposal splits the space of possible identifiers in two equal halves. If one's application needs a longer than 32-bit identifiers for the queries, part of the referral code space must be used. -# Rationale and alternatives +There is no authentication of the referral code, so this data cannot be trusted: anyone can use anyone else's referral code. -The suggested proposal is simple and easy to follow, making on-chain statistics and referral programs easy to operate. +# Rationale and alternatives +The suggested proposal is simple and easy to follow, making statistics and referral programs easy to operate.