Theses from the AMA developer session at TON
📢 The main points of what was said:
1. The primary path is "open possibly serverless shitty dapp from Telegram or some random github page on mobile"
2. Let's have a standard button and widget to show a selection of the wallet apps, so when the user selects one — the wallet knows where to connect. Wallets list should be customizeable on the app's end. Return url is not always possible and should be optional.
3. This means, the rendezvous server is actually a bridge and the bridge is provided by the wallet. All
comm and
tx requests are going through that bridge.
4. Desktop-mobile use case is covered with universal link opening a QR code and a back button. It could even automatically redirect back when the wallet responds.
Q: how do we distinguish between two sorts of
return_urls: one for the user to go back to Telegram and another for QR code page to go back to the app, and not make it confusing for devs?
5A. To identify the apps upon connect we need a lightweight flow without signed requests. The serverless dapp cannot sign, and we are not transmitting PII anyway.
5B. To identify
tx requests we use optional TON DNS to label the addresses. TON DNS is cool because it eliminates intermediaries and lets use Telegram and other distribution mechanisms as untrusted traffic hoses. But we should make its usage more friendly and efficient for devs.
Q: how to implement and mandate immutably-bound names? Through constraints on DNS items, or as a separate registry? Who would design that registry? Without such protocol in place, DNS names are mutable and could fool users just like immutable contracts could. Need to avoid a slippery slope from the start.
Q: who should protect against phishing? With TON DNS we have a chance to spread this protection across multiple layers and not be locked into dependency on Telegram, CAs and other intermediaries. E.g. both Telegram could kick off scammers, and wallets and blockchain APIs could mark phishy names, and the developer is always in direct control over their identification.
6. The workflow for users should be close regardless of whether they connect to a dapp or a service. Button ⟶ prompt ⟶ confirm ⟶ back to the app.
7
. SDK for developers should be ±unified for both cases because it matches users' flow, but with clear definition of each scenario. E.g. unsigned requests for connect come with no guarantee and cannot be used for sign-in, but okay for serverless dapps.
8.
We need to check the trade-offs of the emerging design for desktop-mobile, desktop-desktop situations and dapp-within-wallet use cases. If they are too inconvenient, we need to revisit the above assumptions.
💬 Outside the scope:
1. Detecting which wallets are installed.
2. How to sign arbitrary messages for use in smart contracts
(proper domain-separation needs to be uniformely adopted).
3. How the dapp connects to the blockchain.
4. How the wallet evaluates non-standard
tx payload to inform the user properly.
Front TON |
Front NFT