Советует - там, где это возможно и работает. А для остальных ситуаций поддерживает application password. Как по мне - CLI это как раз та ситуация, когда использование OAuth не совсем уместно. В частности, многие CLI утилиты должны быть работоспособны на сервере, где браузера нет. А даже если они используются на десктопе, они зачастую используются из скриптов или других приложений, в рамках работы которых запускать браузер и требовать наличия юзера за компом может быть совершенно неуместно. Добавим к этим недостаткам ещё и сложности с реализацией описанного в статье, и вопрос "нафига?" становится крайне уместным.
Насколько я помню доку по OAuth, в ней нет такого понятия как application password. Т.е. по факту это отдельная фича (не связанная с OAuth), которую разные сервисы могут реализовывать или нет, и делать это любым способом. Соответственно, такие application password могут не поддерживать ограничение прав доступа а-ля OAuth scope. Ну и как сервис реализует видимость для юзера созданных им application passwords и возможность их удалять - тоже зависит от конкретного сервиса. Насколько я понимаю - на этих пунктах недостатки этого подхода заканчиваются. В остальном - подход достаточно общепринятый и используется многими сервисами (напр. на гитхабе и на Digital Ocean эта фича называется Personal Access Tokens).
Иными словами данный совет гугла - это его личное предпочтение. Мотивация его неясна, причин не использовать application password там, где клиентам это удобнее - нет.
А не проще для CLI приложений использовать т.н. "application password"? По сути это аналог токена без экспайра, который юзер создаёт на том же сайте, а потом прописывает в конфиг CLI приложения вместо своего настоящего пароля.
Ведь в этом случае CLI может ничего про OAuth не знать и не иметь никаких проблем из-за возможных конфликтов портов, потенциальной уязвимости через перехват кода на этом порту сторонним приложением, сложностей из-за встроенного веб-сервера и необходимости обновлять токен автоматически либо просить юзера снова логиниться через браузер…
Несколько лет назад в PostgreSQL переделали реализацию для Serializable, в результате чего он стал сравним по скорости с предыдущим уровнем, с одним нюансом: если обнаружен конфликт то транзакция вернёт ошибку и её нужно будет повторить ручками (на уровне приложения). Повтор транзакции по этой ошибке обычно несложно автоматизировать универсальной обёрткой над функцией выполняющей транзакцию.
В результате такого подхода смысл использовать уровни ниже Serializable с PostgreSQL практически пропал (т.е. его вполне разумно включать по умолчанию при условии использования вышеупомянутой обёртки). Этот подход позволяет сэкономить немало сил и времени на анализ допустимости использования менее надёжных уровней изоляции транзакций и отладку связанных с этим очень неприятных багов.
Понижать уровень изоляции при этом подходе может иметь смысл только в виде исключения для отдельных запросов, которые реально уже создали проблемы с производительностью, и при этом для них приемлемы меньшие гарантии изоляции - но в большинстве проектов подходящих под эти условия запросов не найдётся и все запросы будут отлично работать на Serializable.
Ну, может и не "обычная", но временами такое реально случается. За последние пару лет у меня такая ситуация была один раз.
Конкретный пример из личного опыта: я архитект, и нужно было спроектировать довольно сложный конечный автомат. В определённую точку кода в непредсказуемом порядке могли прилетать события разных типов из разных источников, которые в сумме должны были изменять некое общее состояние. Количество возможных источников и событий было достаточно большим, их эффект на общее состояние был не всегда простым и очевидным. Накидать "вроде бы корректное" решение (на бумаге, в виде алгоритма) я смог за пол дня. Проблема была в том, что глядя на это решение я сам не понимал корректное ли оно и как в этом убедиться. На то, чтобы отрефакторить это решение (найти способ записи данных и алгоритма на той же бумаге) так, чтобы оно стало намного более ясным и проверяемым, и в процессе пофиксить кучу частных случаев, которые ранее (до нахождения достаточно ясного способа записи) было сложно даже увидеть, и которые, разумеется, не были корректно учтены в начальном решении - у меня ушло ещё дней 8.
Идти с этой проблемой "за помощью" мне было тупо не к кому: остальные разработчики были миддлами и в принципе бы не потянули эту задачу, идти с этим к тех.диру тоже было бесполезно, потому что у него просто нет возможности выделить этой задаче достаточно времени, чтобы хотя бы успеть загрузить её целиком в голову.
В мире, где (ещё) нет ни войны ни санкций - было именно так, как Вы говорите. Но в данный момент ситуация изменилась, вследствие чего полагаться на банки как раньше стало сложно.
Из того, что мне лично рассказывали знакомые: банковский перевод с зарплатой подвисал-терялся на пару месяцев (перевод из-за рубежа), в результате чего компания не могла оперативно платить з/п сотрудникам, в связи с чем перешла на оплату в USDT. А сотрудники на это согласились, если не все то практически все - потому что кушать что-то надо, причём лично они с USDT могут даже вообще никак не сталкиваться, достаточно прийти в заданный день в крипто-обменку, сказать код, и получить свою з/п на руки в баксах.
Что до займов, то тут тоже всё просто: когда знакомому нужно занять денег на еду, а ему предлагают займ исключительно в USDT, то он и установит крипто-кошелёк и разберётся как делать вывод на вышеупомянутый крипто-обменник. Удивительно, на что способны люди, которым срочно нужны деньги, да? ;-)
Основные кейсы: альтернатива банкам и рынку акций, защищённая от кастодианов (у меня кошельки только некастодиальные, CEX не пользуюсь).
В качестве замены банку: приём платежей, займы/платежи знакомым, вывод в наличку "на еду", в перспективе думаю начать использовать криптокарту для покупок через инет.
В качестве замены рынку акций: диверсификация активов между разными монетами (разные стейблы и разные не стейблы) и блокчейнами, большая часть с целью просто держать пока не появится нужда тратить их на жизнь.
В общем и целом - похоже что Вы правы. Действительно, хоть телега/Дуров и дистанцируется от бота@walletи его владельцев, он действительно похож на активатор поддержки TON для телеги. И два других крипто-бота кошелька этого функционала не имеют, чем косвенно подтверждают полу-официальный статус этого бота.
Более того, хотя данный бот и кастодиальный, сейчас через его же меню доступен некий альтернативный кошелёк TON Space "бета", который уже некастодиальный. Правда, этот TON Space никак не привязан к аккаунту телеги и никак не упрощает пересылку монет другим аккаунтам телеги. Сходу у TON Space наблюдается серьёзная проблема с безопасностью: он позволяет увидеть секретную фразу кошелька через настройки без какой-либо защиты (пин кода, уведомления о количестве просмотров, полного блокирования возможности её увидеть после подтверждения что юзер сделал её бэкап), типичной для других некастодиальных кошельков.
Документация на TON Space находится в доке на@wallet, что косвенно говорит о том, что данный некастодиальный кошелёк разработан той же компанией, что и этот бот… так что на него, по логике, тоже распространяется полу-официальный статус. Но пока неясно, есть ли у него хоть какие-то преимущества по сравнению со сторонними некастодиальными кошельками-приложениями.
У меня кошелек оказался встроен (у меня андроид и макос), кому-то пришлось обновлять версию телеграма.
Я думаю, Вы ошибаетесь. В телеге нет встроенного кошелька. Существующие кошельки перечислены на https://ton.tg/en/wallets, и среди них нет телеги. Там есть три бота, один из которых Вы, скорее всего, и имеете в виду. Но эти боты не более "встроены в телегу" чем любые другие боты. И (возможно, в связи с ограничениями API ботов) все они кастодиальные.
Все остальные кошельки, что характерно, некастодиальные. Но все они - отдельные приложения и внутри телеги работать не будут.
он встроен (но как я понял не на всех устройствах)
А что, он хоть где-то встроен? У меня десктоп/Linux и андроид - нет ни там ни там.
кастодиальный он или нет
Это не мелочь, которая не имеет принципиального значения и которую можно с такой лёгкостью игнорировать. Это достаточно принципиальный момент при использовании крипты. Можно доверить часть своих средств кастодиану, если он предоставляет какие-то серьёзные возможности (напр. CEX вроде Binance), но этот выбор не должен быть лёгким и автоматическим - множество людей уже потеряло свои средства из-за взломов бирж, exit scam, внезапных санкций и т.д. и т.п. Для обычной пересылки средств между кошельками участие кастодиана явно лишнее: оно создаёт дополнительные и значительные риски не давая ничего полезного взамен.
Телеграм просто дал низкий порог входа. Хочешь перевести, знаешь ник - переводи. А при переводах по сети, нужно адрес кошелька и сеть знать, при обмене этими данными на любом этапе может возникнуть ошибка, стресс.
Вот если бы некастодиальный кошелёк действительно был бы встроен в сам телеграм, то всё это бы работало так же просто, но при этом без участия лишнего кастодиана. А сейчас стресс возникает из-за наличия кастодиана. :)
То есть идея была хранить там не накопления на квартиру, а деньги на повседневные/карманные расходы.
С этого всё обычно начинается. А потом сам не заметишь, как начнёшь получать туда зарплату.
Зависит от государства. В Википедии есть страничка со списком легальности крипты по странам. Ну и плюс штатные девиации между законом и тем, что происходит по факту.
А что это изменит? Я вот вроде разобрался, но всё-равно решил, что использовать кастодиальный кошелёк не хочу. По факту получается, что Вы собираете статистику не среди тех, кто пользуется криптой, а среди их подмножества: тех, кто на общем хайпе крипту использовать начал, но либо при этом не понимает толком для чего она нужна и в чём разница между кастодиальным и не кастодиальным кошельком, либо понимает разницу но считает приемлемым держать свои средства вместо обычного кастодиана-банка (который достаточно жёстко и контролируется, и страховку на случай если он лопнет какую-то обычно имеет от государства) в каком-то странном боте телеги.
У меня вопрос в данном случае не к выборке, а к трактовке результатов: в статье предполагается, что если человек не принял TON, то он про него не знает и/или не пользуется криптой. В моём случае оба утверждения были бы ложными.
По состоянию на 12 октября мир, оказался не готов к переходу на криптовалютные переводы.
Хм. Я активно использую крипту, разные монеты на разных блокчейнах. Но вот TON среди моих активов пока нет. Я бы и не против им пользоваться, но пока не вижу, чтобы в клиент телеграм "был встроен TON кошелек" (как Вы написали), вместо этого я пока видел исключительно разные телеграм-боты для TON, причём все были кастодиальными - а кастодиальными я пользоваться не хочу принципиально, приватный ключ от моих средств должен быть только у меня.
Я в очередной раз разочаровался в человечестве, но не потерял надежду.
А я в очередной раз разочаровался в способности людей корректно собирать статистику.
Нынче задачи архитекта разрослись, и привели к тому, что появились разные роли архитектов. Причём на данный момент чёткого определения названий и ответственности этих ролей ещё нет. Обычно роли с названиями вроде Enterprise/Solution/Systems Architect работают больше с бумажками, чем с кодом (причём нередко с кодом они вообще не работают!), а роли Application/Software Architect работают с бумажками и кодом примерно 50/50.
В контексте данного обсуждения я подразумевал последних - тех, кто отвечает за то, что данный конкретный проект заработает (в т.ч. "собравшись" из кучки микросервисов), будет соответствовать функциональным и нефункциональным требованиям, и усилия по его поддержке и развитию будут приемлемыми. И хотя они действительно не ревьювят все коммиты, но общий контроль над происходящем в коде они всё-таки осуществляют. Что включает в себя, в том числе, как определение общей структуры и архитектуры кода, так и проверку что всё это соблюдается разработчиками. В случае микросервисной архитектуры на их же плечи ложится разделение функционала проекта между микросервисами и определение их API. При этом контроль над архитектурой и структурой самих микросервисов вполне может ослабнуть, т.к. объём что нужно контролировать сильно возрастает, а критичность этого сильно падает.
А по части рекомендаций, которые разработчики вполне могут игнорить - это к первой группе ролей архитектов, они слишком далеки от кода.
В случае микросервисов - да, квалификация разработчиков может быть ниже, чем в монолите, а квалификация архитекта должна быть выше, чем в монолите. Потому что любой бардак, который разработчики устроят в конкретном микросервисе, причинит значительно меньше ущерба, чем аналогичный бардак в монолите либо бардак в связях и API самих микросервисов. Да и переписать большинство (все те, которые реально "микро") микросервисов можно за пару недель силами одного-двух разработчиков.
Ну, так лучше, конечно, но перехват ещё можно организовать тупо прибив этот CLI после запуска браузера и подняв на том же порту свой веб-сервер.
Советует - там, где это возможно и работает. А для остальных ситуаций поддерживает application password. Как по мне - CLI это как раз та ситуация, когда использование OAuth не совсем уместно. В частности, многие CLI утилиты должны быть работоспособны на сервере, где браузера нет. А даже если они используются на десктопе, они зачастую используются из скриптов или других приложений, в рамках работы которых запускать браузер и требовать наличия юзера за компом может быть совершенно неуместно. Добавим к этим недостаткам ещё и сложности с реализацией описанного в статье, и вопрос "нафига?" становится крайне уместным.
Насколько я помню доку по OAuth, в ней нет такого понятия как application password. Т.е. по факту это отдельная фича (не связанная с OAuth), которую разные сервисы могут реализовывать или нет, и делать это любым способом. Соответственно, такие application password могут не поддерживать ограничение прав доступа а-ля OAuth scope. Ну и как сервис реализует видимость для юзера созданных им application passwords и возможность их удалять - тоже зависит от конкретного сервиса. Насколько я понимаю - на этих пунктах недостатки этого подхода заканчиваются. В остальном - подход достаточно общепринятый и используется многими сервисами (напр. на гитхабе и на Digital Ocean эта фича называется Personal Access Tokens).
Иными словами данный совет гугла - это его личное предпочтение. Мотивация его неясна, причин не использовать application password там, где клиентам это удобнее - нет.
А не проще для CLI приложений использовать т.н. "application password"? По сути это аналог токена без экспайра, который юзер создаёт на том же сайте, а потом прописывает в конфиг CLI приложения вместо своего настоящего пароля.
Ведь в этом случае CLI может ничего про OAuth не знать и не иметь никаких проблем из-за возможных конфликтов портов, потенциальной уязвимости через перехват кода на этом порту сторонним приложением, сложностей из-за встроенного веб-сервера и необходимости обновлять токен автоматически либо просить юзера снова логиниться через браузер…
Несколько лет назад в PostgreSQL переделали реализацию для Serializable, в результате чего он стал сравним по скорости с предыдущим уровнем, с одним нюансом: если обнаружен конфликт то транзакция вернёт ошибку и её нужно будет повторить ручками (на уровне приложения). Повтор транзакции по этой ошибке обычно несложно автоматизировать универсальной обёрткой над функцией выполняющей транзакцию.
В результате такого подхода смысл использовать уровни ниже Serializable с PostgreSQL практически пропал (т.е. его вполне разумно включать по умолчанию при условии использования вышеупомянутой обёртки). Этот подход позволяет сэкономить немало сил и времени на анализ допустимости использования менее надёжных уровней изоляции транзакций и отладку связанных с этим очень неприятных багов.
Понижать уровень изоляции при этом подходе может иметь смысл только в виде исключения для отдельных запросов, которые реально уже создали проблемы с производительностью, и при этом для них приемлемы меньшие гарантии изоляции - но в большинстве проектов подходящих под эти условия запросов не найдётся и все запросы будут отлично работать на Serializable.
Ну, может и не "обычная", но временами такое реально случается. За последние пару лет у меня такая ситуация была один раз.
Конкретный пример из личного опыта: я архитект, и нужно было спроектировать довольно сложный конечный автомат. В определённую точку кода в непредсказуемом порядке могли прилетать события разных типов из разных источников, которые в сумме должны были изменять некое общее состояние. Количество возможных источников и событий было достаточно большим, их эффект на общее состояние был не всегда простым и очевидным. Накидать "вроде бы корректное" решение (на бумаге, в виде алгоритма) я смог за пол дня. Проблема была в том, что глядя на это решение я сам не понимал корректное ли оно и как в этом убедиться. На то, чтобы отрефакторить это решение (найти способ записи данных и алгоритма на той же бумаге) так, чтобы оно стало намного более ясным и проверяемым, и в процессе пофиксить кучу частных случаев, которые ранее (до нахождения достаточно ясного способа записи) было сложно даже увидеть, и которые, разумеется, не были корректно учтены в начальном решении - у меня ушло ещё дней 8.
Идти с этой проблемой "за помощью" мне было тупо не к кому: остальные разработчики были миддлами и в принципе бы не потянули эту задачу, идти с этим к тех.диру тоже было бесполезно, потому что у него просто нет возможности выделить этой задаче достаточно времени, чтобы хотя бы успеть загрузить её целиком в голову.
Ну, раз автор пересказ книги прервал, то Вам имеет смысл пойти по ссылке в начале этой статьи и почитать саму книгу. Оригинал всегда лучше! :-)
В мире, где (ещё) нет ни войны ни санкций - было именно так, как Вы говорите. Но в данный момент ситуация изменилась, вследствие чего полагаться на банки как раньше стало сложно.
Из того, что мне лично рассказывали знакомые: банковский перевод с зарплатой подвисал-терялся на пару месяцев (перевод из-за рубежа), в результате чего компания не могла оперативно платить з/п сотрудникам, в связи с чем перешла на оплату в USDT. А сотрудники на это согласились, если не все то практически все - потому что кушать что-то надо, причём лично они с USDT могут даже вообще никак не сталкиваться, достаточно прийти в заданный день в крипто-обменку, сказать код, и получить свою з/п на руки в баксах.
Что до займов, то тут тоже всё просто: когда знакомому нужно занять денег на еду, а ему предлагают займ исключительно в USDT, то он и установит крипто-кошелёк и разберётся как делать вывод на вышеупомянутый крипто-обменник. Удивительно, на что способны люди, которым срочно нужны деньги, да? ;-)
Основные кейсы: альтернатива банкам и рынку акций, защищённая от кастодианов (у меня кошельки только некастодиальные, CEX не пользуюсь).
В качестве замены банку: приём платежей, займы/платежи знакомым, вывод в наличку "на еду", в перспективе думаю начать использовать криптокарту для покупок через инет.
В качестве замены рынку акций: диверсификация активов между разными монетами (разные стейблы и разные не стейблы) и блокчейнами, большая часть с целью просто держать пока не появится нужда тратить их на жизнь.
В общем и целом - похоже что Вы правы. Действительно, хоть телега/Дуров и дистанцируется от бота@walletи его владельцев, он действительно похож на активатор поддержки TON для телеги. И два других крипто-бота кошелька этого функционала не имеют, чем косвенно подтверждают полу-официальный статус этого бота.
Более того, хотя данный бот и кастодиальный, сейчас через его же меню доступен некий альтернативный кошелёк TON Space "бета", который уже некастодиальный. Правда, этот TON Space никак не привязан к аккаунту телеги и никак не упрощает пересылку монет другим аккаунтам телеги. Сходу у TON Space наблюдается серьёзная проблема с безопасностью: он позволяет увидеть секретную фразу кошелька через настройки без какой-либо защиты (пин кода, уведомления о количестве просмотров, полного блокирования возможности её увидеть после подтверждения что юзер сделал её бэкап), типичной для других некастодиальных кошельков.
Документация на TON Space находится в доке на@wallet, что косвенно говорит о том, что данный некастодиальный кошелёк разработан той же компанией, что и этот бот… так что на него, по логике, тоже распространяется полу-официальный статус. Но пока неясно, есть ли у него хоть какие-то преимущества по сравнению со сторонними некастодиальными кошельками-приложениями.
Ну, технически Дуров называет этот кошелёк сторонним приложением:
Так что тема однозначно мутная.
Честно говоря, на первый взгляд то, что бот может добавить пункт в меню настроек, не делает его официальным:
Я думаю, Вы ошибаетесь. В телеге нет встроенного кошелька. Существующие кошельки перечислены на https://ton.tg/en/wallets, и среди них нет телеги. Там есть три бота, один из которых Вы, скорее всего, и имеете в виду. Но эти боты не более "встроены в телегу" чем любые другие боты. И (возможно, в связи с ограничениями API ботов) все они кастодиальные.
Все остальные кошельки, что характерно, некастодиальные. Но все они - отдельные приложения и внутри телеги работать не будут.
Разменивать комиссию в 11 центов на риск потерять все средства… ну, такое.
А что, он хоть где-то встроен? У меня десктоп/Linux и андроид - нет ни там ни там.
Это не мелочь, которая не имеет принципиального значения и которую можно с такой лёгкостью игнорировать. Это достаточно принципиальный момент при использовании крипты. Можно доверить часть своих средств кастодиану, если он предоставляет какие-то серьёзные возможности (напр. CEX вроде Binance), но этот выбор не должен быть лёгким и автоматическим - множество людей уже потеряло свои средства из-за взломов бирж, exit scam, внезапных санкций и т.д. и т.п. Для обычной пересылки средств между кошельками участие кастодиана явно лишнее: оно создаёт дополнительные и значительные риски не давая ничего полезного взамен.
Вот если бы некастодиальный кошелёк действительно был бы встроен в сам телеграм, то всё это бы работало так же просто, но при этом без участия лишнего кастодиана. А сейчас стресс возникает из-за наличия кастодиана. :)
С этого всё обычно начинается. А потом сам не заметишь, как начнёшь получать туда зарплату.
Зависит от государства. В Википедии есть страничка со списком легальности крипты по странам. Ну и плюс штатные девиации между законом и тем, что происходит по факту.
А что это изменит? Я вот вроде разобрался, но всё-равно решил, что использовать кастодиальный кошелёк не хочу. По факту получается, что Вы собираете статистику не среди тех, кто пользуется криптой, а среди их подмножества: тех, кто на общем хайпе крипту использовать начал, но либо при этом не понимает толком для чего она нужна и в чём разница между кастодиальным и не кастодиальным кошельком, либо понимает разницу но считает приемлемым держать свои средства вместо обычного кастодиана-банка (который достаточно жёстко и контролируется, и страховку на случай если он лопнет какую-то обычно имеет от государства) в каком-то странном боте телеги.
У меня вопрос в данном случае не к выборке, а к трактовке результатов: в статье предполагается, что если человек не принял TON, то он про него не знает и/или не пользуется криптой. В моём случае оба утверждения были бы ложными.
Хм. Я активно использую крипту, разные монеты на разных блокчейнах. Но вот TON среди моих активов пока нет. Я бы и не против им пользоваться, но пока не вижу, чтобы в клиент телеграм "был встроен TON кошелек" (как Вы написали), вместо этого я пока видел исключительно разные телеграм-боты для TON, причём все были кастодиальными - а кастодиальными я пользоваться не хочу принципиально, приватный ключ от моих средств должен быть только у меня.
А я в очередной раз разочаровался в способности людей корректно собирать статистику.
Нынче задачи архитекта разрослись, и привели к тому, что появились разные роли архитектов. Причём на данный момент чёткого определения названий и ответственности этих ролей ещё нет. Обычно роли с названиями вроде Enterprise/Solution/Systems Architect работают больше с бумажками, чем с кодом (причём нередко с кодом они вообще не работают!), а роли Application/Software Architect работают с бумажками и кодом примерно 50/50.
В контексте данного обсуждения я подразумевал последних - тех, кто отвечает за то, что данный конкретный проект заработает (в т.ч. "собравшись" из кучки микросервисов), будет соответствовать функциональным и нефункциональным требованиям, и усилия по его поддержке и развитию будут приемлемыми. И хотя они действительно не ревьювят все коммиты, но общий контроль над происходящем в коде они всё-таки осуществляют. Что включает в себя, в том числе, как определение общей структуры и архитектуры кода, так и проверку что всё это соблюдается разработчиками. В случае микросервисной архитектуры на их же плечи ложится разделение функционала проекта между микросервисами и определение их API. При этом контроль над архитектурой и структурой самих микросервисов вполне может ослабнуть, т.к. объём что нужно контролировать сильно возрастает, а критичность этого сильно падает.
А по части рекомендаций, которые разработчики вполне могут игнорить - это к первой группе ролей архитектов, они слишком далеки от кода.
В случае микросервисов - да, квалификация разработчиков может быть ниже, чем в монолите, а квалификация архитекта должна быть выше, чем в монолите. Потому что любой бардак, который разработчики устроят в конкретном микросервисе, причинит значительно меньше ущерба, чем аналогичный бардак в монолите либо бардак в связях и API самих микросервисов. Да и переписать большинство (все те, которые реально "микро") микросервисов можно за пару недель силами одного-двух разработчиков.