2022-09-15 12:01:52
Выжимка по АМА-сессии разработчиков на TON
Главное из того, что было сказано:
1. Основная цель — «открыть, возможно, бессерверный незатейливый dapp из Telegram или какой-нибудь случайной страницы github на мобильном».
2. Можно сделать стандартную кнопку и виджет для отображения выбора приложений кошелька, чтобы когда пользователь выбирал одно из них — кошелек знал, куда подключаться. Список кошельков должен быть настраиваемым в конце приложения. Возвращаемый URL не всегда возможен и должен быть необязательным.
3. Сервер фактически является мостом, а мост предоставляется кошельком. Все comm и tx запросы проходят через этот мост.
4. Десктопно-мобильный вариант использует универсальной ссылку, которая открывает QR-код и кнопку «Назад». Он может даже автоматически перенаправлять обратно, когда кошелек отвечает.
Вопрос: как разграничить два вида return_urls: один для пользователя, чтобы вернуться в Telegram, и другой для страницы QR-кода, чтобы вернуться в приложение, и не запутать разработчиков?
5А. Чтобы идентифицировать приложения при подключении, нужен облегченный поток без подписанных запросов. Бессерверный dapp не может подписывать запросы, и в любом случае не будет передачи PII.
5B. Для идентификации запросов tx используется необязательный TON DNS для маркировки адресов. TON DNS — это круто, потому что он устраняет посредников и позволяет использовать Telegram и другие механизмы распределения в качестве ненадежных каналов трафика. Но нужно сделать его использование более удобным и эффективным для разработчиков.
Вопрос: как реализовать и контролировать неизменяемые имена? Через ограничения на элементы DNS или в виде отдельного реестра? Кто будет разрабатывать этот реестр? Без такого протокола DNS-имена будут изменяемы и могут обмануть пользователей так же, как и неизменяемые контракты. Необходимо с самого начала избежать скользкой дорожки.
Вопрос: кто должен защищать от фишинга? С TON DNS есть шанс распространить эту защиту на несколько уровней и не зависеть от Telegram, CA и других посредников. Например, и Telegram может спровоцировать мошенников, и кошельки и API-интерфейсы блокчейна могут помечать фишинговые имена, и разработчик всегда имеет прямой контроль над их идентификацией.
6. Рабочий процесс для пользователей должен быть закрытым независимо от того, подключаются ли они к децентрализованному приложению или сервису. Кнопка ⟶ запрос ⟶ подтверждение ⟶ возврат в приложение.
7. SDK для разработчиков должен быть ± унифицирован для обоих случаев, поскольку он соответствует потоку пользователей, но с четким определением каждого сценария. Например, неподписанные запросы на подключение не дают никаких гарантий и не могут быть использованы для входа в систему, но могут быть использованы для бессерверных dapps.
8. Нужно проверить компромиссы возникающего дизайна для ситуаций десктоп-мобильный, десктоп-десктоп и сценариев использования dapp-within-wallet. Если они окажутся слишком неудобными, нужно пересмотреть вышеприведенные предположения.
За рамками:
1. Определение установленных кошельков.
2. Как подписывать произвольные сообщения для использования в смарт-контрактах
(необходимо единообразное разделение доменов).
3. Как dapp подключается к блокчейну.
4. Как кошелек оценивает нестандартный tx payload, чтобы правильно информировать пользователя.
Парадная TON | Парадная NFT
389 viewsedited 09:01