Ответ на #вопрос в посте https://t.me/cryptazapro/2706?comment=40043
Причин тому, чтоб не брать комиссию за перевод в сети, несколько может быть:
1. Если есть эмиссия, валидаторы могут зарабатывать за счёт неё, предоставляя пользователям Bandwidth в соответствии с застейканным количеством токенов.
Те же, кто за них голосуют, чаще всего ничего не получают.
Bandwidth = пропускная способность аккаунта.
Эмиссия чаще всего компенсируется сжиганием или лишь спросом, что не самый лучший вариант (хотя зависит от процента годовой эмиссии).
Либо она может быть завершена, а распределяться заранее напечатанные токены.
Например, проект, у которого всего 1 МЛРД токенов.
Но на руках 100 МЛН.
Далее распределяется валидаторам, например, 20 МЛН в год, пока не будет достигнута сумма в 1 МЛРД.
Примерами блокчейнов с эмиссией могут быть #Golos, #Viz, #Steem, #Hive.
Блокчейнов же с примайном и последующим распределением не помню, хотя как-то давно встречались...
2. Также комиссию может не брать недавно запущенный блокчейн с целью привлечения аудитории, например, Aurora не берёт комиссии с транзакций (либо с целью маркетинга, либо по причине достаточного дохода от их токена $AURORA).
3. Это может быть централизованная фигня, работающая на 1-2 серверах основателей.
4. Это может быть скам проект, который решил забрать деньги у людей, но он же скорее всего будет централизованным (СМ. пункт 3).
Сбор средств при этом может быть на этапе перевода токенов через мост с созданием фантиков в сети, на этапе небезопасного стейкинга и пр.
Про экономику проектов с эмиссией или распределением ранее созданных активов:
1. Выпуск токенов, допустим, 10% в год со снимком в определённую дату.
При этом, реализуются механики сжигания токенов, например, в #golos сжигаются токены для рекламы постов (правда сжигаются не $GOLOS, а $GBG, поэтому эффективность малая для основного актива).
2. Реализация множества сервисов, чтоб формировался спрос.
Этот метод может быть плох тем, что наличие сервисов не может гарантировать спрос.
Например, это игры, форумы, блоги, иные сайты / приложения, торрент трекеры и пр.
Пункты 1 и 2 могут сочетаться.
3. Все их объединяет то, что вы получаете определённое кол-во КБ для выполнения транзакций.
Доля от общего количества равна доле от общей суммы застейканных токенов.
Напомню:
1. Стейк - блокировка для участия в ДАО или выполнения иных функций.
2. Скам - мошенничество с целью сбора средств и последующим закрытием.
Благодарю за внимание, и предлагаю обсудить пост в чате.
---
Канал, Чат, Бот, Twitter
Причин тому, чтоб не брать комиссию за перевод в сети, несколько может быть:
1. Если есть эмиссия, валидаторы могут зарабатывать за счёт неё, предоставляя пользователям Bandwidth в соответствии с застейканным количеством токенов.
Те же, кто за них голосуют, чаще всего ничего не получают.
Bandwidth = пропускная способность аккаунта.
Эмиссия чаще всего компенсируется сжиганием или лишь спросом, что не самый лучший вариант (хотя зависит от процента годовой эмиссии).
Либо она может быть завершена, а распределяться заранее напечатанные токены.
Например, проект, у которого всего 1 МЛРД токенов.
Но на руках 100 МЛН.
Далее распределяется валидаторам, например, 20 МЛН в год, пока не будет достигнута сумма в 1 МЛРД.
Примерами блокчейнов с эмиссией могут быть #Golos, #Viz, #Steem, #Hive.
Блокчейнов же с примайном и последующим распределением не помню, хотя как-то давно встречались...
2. Также комиссию может не брать недавно запущенный блокчейн с целью привлечения аудитории, например, Aurora не берёт комиссии с транзакций (либо с целью маркетинга, либо по причине достаточного дохода от их токена $AURORA).
3. Это может быть централизованная фигня, работающая на 1-2 серверах основателей.
4. Это может быть скам проект, который решил забрать деньги у людей, но он же скорее всего будет централизованным (СМ. пункт 3).
Сбор средств при этом может быть на этапе перевода токенов через мост с созданием фантиков в сети, на этапе небезопасного стейкинга и пр.
Про экономику проектов с эмиссией или распределением ранее созданных активов:
1. Выпуск токенов, допустим, 10% в год со снимком в определённую дату.
При этом, реализуются механики сжигания токенов, например, в #golos сжигаются токены для рекламы постов (правда сжигаются не $GOLOS, а $GBG, поэтому эффективность малая для основного актива).
2. Реализация множества сервисов, чтоб формировался спрос.
Этот метод может быть плох тем, что наличие сервисов не может гарантировать спрос.
Например, это игры, форумы, блоги, иные сайты / приложения, торрент трекеры и пр.
Пункты 1 и 2 могут сочетаться.
3. Все их объединяет то, что вы получаете определённое кол-во КБ для выполнения транзакций.
Доля от общего количества равна доле от общей суммы застейканных токенов.
Напомню:
1. Стейк - блокировка для участия в ДАО или выполнения иных функций.
2. Скам - мошенничество с целью сбора средств и последующим закрытием.
Благодарю за внимание, и предлагаю обсудить пост в чате.
---
Канал, Чат, Бот, Twitter
#идея #разработки: криптанский метод отложенного постинга в Telegram каналы.
Сейчас существует множество ботов для отложенной публикации. Но все они централизованы.
Был даже случай, когда бот публиковал в канале лозунги...
Сегодня пришла идея:
А почему бы не сделать максимально криптанский метод отложенного постинга...
Суть:
1. Пользователь скачивает html страницу. При желании и наличии навыков может изучить код, либо передать знакомым.
2. Авторизуется при помощи #viz, #steem, #hive, #golos аккаунта или иного блокчейна.
3. Идёт в @BotFather
И создаёт бота.
4. На странице открывает блок "Настройки" (спойлер), после чего заполняет полученный API ключ бота, а также, после добавление бота в канал, id (с -) или логин.
Данные шифруются и добавляются в localStorage.
Также в настройках в редакторе визуальном он может написать шапку и подвал поста (верхнюю и нижнюю часть).
Они также будут сохранены.
И заполняет в поле "Сервер отправки" аккаунт / адрес кошелька сервера отправки.
5. Когда возникает надобность написать пост, пользователь пишет текст поста.
По окончании нажимает "Предпросмотр", и ему выводится текст поста, как он отобразится в Telegram.
6. Заполняет дату и время отправки.
7. Если всё ок, нажимает "Отправить".
После этого данные зашифровываются приватным ключом пользователя и публичным ключом сервера отправки.
8. Далее в блокчейн публикуется отложенная транзакция custom с ID v2tg и JSON:
{ak: "...", c_id: "...", t: "...", a: "."}, где
… - зашифрованные значения соответствующих ключей.
ak - API ключ бота (напомню, что в зашифрованном ключом пользователя виде).
c_id - id канала.
t - текст поста.
a - аккаунт сервера отправки.
9. Скрипт сервера отправки видит, что:
А) id соответствует и формат JSON правильный;
Б) Логин аккаунта соответствует ему.
10. Расшифровывает данные, в функции этой же запускает бота, указывает текст и отправляет в Telegram.
После чего забывает о данных, которые передал пользователь.
Далее он может принять транзакцию от другого пользователя...
Недостатки:
1. Скрипт может быть модефицирован для сохранения данных.
Соответственно придётся самому разворачивать... Но тогда не проще ли будет просто создать самому бота и запустить, либо создать мне готовый скрипт бота отложенной отправки, чтоб каждый смог его установить без заморочек?
2. Нужен визуальный html редактор, которые будет поддерживать только разрешённые Telegram теги: есть ли такие?
3. При использовании публичных известных серверов отправки, которым отправляют многие, по сути, создаются те же риски, что и при использовании текущих централизованных ботов...
4. Модель монетизации публичных серверов непонятна...
Если централизованные боты могут у себя рекламу рассылать, то тут никак...
Разве что требовать для отправки ещё одной транзакции: перевод средств на определённую сумму...
В общем, в начале поста мне показалась идея прекрасной, а сейчас появились сомнения, нужно ли делать...
Пишите свои мысли в @blind_dev_chat: по обсуждаем.
Суть же в том, что я хочу сделать более надёжный и анонимный инструмент отложенного постинга в свои каналы. И об этих отправках никто кроме автора не должен знать... А если и будет известна сама отправка, не будет понятно, в какой канал и каким ботом...
Да и аккаунт можно создать под эту задачу...
P. S. Данную методику можно транслировать и на BTC / другие блокчейны, где есть отложенные транзакции.
Благодарю за внимание, и ещё раз предлагаю посетить чат @blind_dev_chat: мне важно знать, стоит ли такое делать... Либо бота с лёгкой установкой и открытым кодом...
---
Нравится то, как веду канал? Отправьте донат
Ссылки канала
@blind_dev
Сейчас существует множество ботов для отложенной публикации. Но все они централизованы.
Был даже случай, когда бот публиковал в канале лозунги...
Сегодня пришла идея:
А почему бы не сделать максимально криптанский метод отложенного постинга...
Суть:
1. Пользователь скачивает html страницу. При желании и наличии навыков может изучить код, либо передать знакомым.
2. Авторизуется при помощи #viz, #steem, #hive, #golos аккаунта или иного блокчейна.
3. Идёт в @BotFather
И создаёт бота.
4. На странице открывает блок "Настройки" (спойлер), после чего заполняет полученный API ключ бота, а также, после добавление бота в канал, id (с -) или логин.
Данные шифруются и добавляются в localStorage.
Также в настройках в редакторе визуальном он может написать шапку и подвал поста (верхнюю и нижнюю часть).
Они также будут сохранены.
И заполняет в поле "Сервер отправки" аккаунт / адрес кошелька сервера отправки.
5. Когда возникает надобность написать пост, пользователь пишет текст поста.
По окончании нажимает "Предпросмотр", и ему выводится текст поста, как он отобразится в Telegram.
6. Заполняет дату и время отправки.
7. Если всё ок, нажимает "Отправить".
После этого данные зашифровываются приватным ключом пользователя и публичным ключом сервера отправки.
8. Далее в блокчейн публикуется отложенная транзакция custom с ID v2tg и JSON:
{ak: "...", c_id: "...", t: "...", a: "."}, где
… - зашифрованные значения соответствующих ключей.
ak - API ключ бота (напомню, что в зашифрованном ключом пользователя виде).
c_id - id канала.
t - текст поста.
a - аккаунт сервера отправки.
9. Скрипт сервера отправки видит, что:
А) id соответствует и формат JSON правильный;
Б) Логин аккаунта соответствует ему.
10. Расшифровывает данные, в функции этой же запускает бота, указывает текст и отправляет в Telegram.
После чего забывает о данных, которые передал пользователь.
Далее он может принять транзакцию от другого пользователя...
Недостатки:
1. Скрипт может быть модефицирован для сохранения данных.
Соответственно придётся самому разворачивать... Но тогда не проще ли будет просто создать самому бота и запустить, либо создать мне готовый скрипт бота отложенной отправки, чтоб каждый смог его установить без заморочек?
2. Нужен визуальный html редактор, которые будет поддерживать только разрешённые Telegram теги: есть ли такие?
3. При использовании публичных известных серверов отправки, которым отправляют многие, по сути, создаются те же риски, что и при использовании текущих централизованных ботов...
4. Модель монетизации публичных серверов непонятна...
Если централизованные боты могут у себя рекламу рассылать, то тут никак...
Разве что требовать для отправки ещё одной транзакции: перевод средств на определённую сумму...
В общем, в начале поста мне показалась идея прекрасной, а сейчас появились сомнения, нужно ли делать...
Пишите свои мысли в @blind_dev_chat: по обсуждаем.
Суть же в том, что я хочу сделать более надёжный и анонимный инструмент отложенного постинга в свои каналы. И об этих отправках никто кроме автора не должен знать... А если и будет известна сама отправка, не будет понятно, в какой канал и каким ботом...
Да и аккаунт можно создать под эту задачу...
P. S. Данную методику можно транслировать и на BTC / другие блокчейны, где есть отложенные транзакции.
Благодарю за внимание, и ещё раз предлагаю посетить чат @blind_dev_chat: мне важно знать, стоит ли такое делать... Либо бота с лёгкой установкой и открытым кодом...
---
Нравится то, как веду канал? Отправьте донат
Ссылки канала
@blind_dev
❤1
#обзоры моего проекта dpos.space.
Если кто не знает - это сайт, поддерживающий 8 PoS блокчейнов, которыми сам пользуюсь.
Представляю список обзоров, так как было много желающих с ними ознакомиться в опросе.
Правда обзоры текстовые не ко всем БЧ, но есть видео:
1. Golos.
Тут несколько обзоров. Ссылки на них и видео размещены на странице https://dpos.space/golos/help
2. #Viz: https://viz.media/obzor-servisov-dpos-space-viz/
3. #Steem: https://steemit.com/hive-176147/@lllll1ll/obzor-servisov-prilozheniya-dpos-space-dlya-blokcheina-steem - написан был вчера по моей просьбе. Запускал там конкурс.
Видео в конце.
4. #Minter: видео справки на https://dpos.space/minter/help
5. Видео обзор по Cyber тут: https://dpos.space/cyber/help
Либо ссылка на YouTube видео: https://www.youtube.com/watch?v=b3tC6iniGr8
6. Serey и Hive похожи на Steem. Только в Serey нет swap сервиса, поэтому обзоры по ним отсутствуют.
7. Decimal ещё не доделан, соответственно обзора ещё тоже нет.
Но в любом случае, обзоры появятся в разделе "Справка" после завершения разработки.
Поэтому здесь уже размещать не буду. Разве что в посте с новостями.
Благодарю за внимание. Всем хорошего дня.
Незрячий web3 программист
Чат, Бот, Донат
Если кто не знает - это сайт, поддерживающий 8 PoS блокчейнов, которыми сам пользуюсь.
Представляю список обзоров, так как было много желающих с ними ознакомиться в опросе.
Правда обзоры текстовые не ко всем БЧ, но есть видео:
1. Golos.
Тут несколько обзоров. Ссылки на них и видео размещены на странице https://dpos.space/golos/help
2. #Viz: https://viz.media/obzor-servisov-dpos-space-viz/
3. #Steem: https://steemit.com/hive-176147/@lllll1ll/obzor-servisov-prilozheniya-dpos-space-dlya-blokcheina-steem - написан был вчера по моей просьбе. Запускал там конкурс.
Видео в конце.
4. #Minter: видео справки на https://dpos.space/minter/help
5. Видео обзор по Cyber тут: https://dpos.space/cyber/help
Либо ссылка на YouTube видео: https://www.youtube.com/watch?v=b3tC6iniGr8
6. Serey и Hive похожи на Steem. Только в Serey нет swap сервиса, поэтому обзоры по ним отсутствуют.
7. Decimal ещё не доделан, соответственно обзора ещё тоже нет.
Но в любом случае, обзоры появятся в разделе "Справка" после завершения разработки.
Поэтому здесь уже размещать не буду. Разве что в посте с новостями.
Благодарю за внимание. Всем хорошего дня.
Незрячий web3 программист
Чат, Бот, Донат
👍10
Про децентрализованные интерфейсы #комментарии
Давно я не писал по этому тегу, но на днях прочитал пост про децентрализованные интерфейсы.
И решил порассуждать над вариантами реализации.
Сразу скажу: если будет что-то непонятно, пишите в комментариях - отвечу.
0. О причинах.
Интерфейс Tornado cash заблокировали / удалили - это заставило задуматься сторонников web 3.0, что пора создавать децентрализованные интерфейсы, которые не будут зависеть от кого-либо.
1. Ipfs.
Если кто не знает, это распределённая сеть, типа торрентов (если очень упрощать - различий много).
Так вот: можно просто открывать страницы в ipfs.
Js файлы и стили css тоже подключаем в коде, указывая ipfs хэши.
И важно, что не прокладку, типа ipfs.io, поскольку это снижает безопасность, а просто ipfs хэш.
Далее браузер / софт локально подключается к сети и скачивает нужные данные - только так...
Можно теоретически приложения создавать для ОС, обслуживающие ipfs, но это вряд ли станет популярным.
Другое дело ipfs браузер...
Вместо Ipfs можно использовать другие P2P сети.
2. Блокчейн, как хранилище страниц и файлов.
Этот вариант не является практичным, но упомяну его...
Естественно BTC или Эфир нельзя для этого использовать ☺: сожрут все деньги...
Но вот чейны с Bandwidth (пропускной способностью аккаунтов) возможно можно...
Примерами таких являются #steem, #hive, #viz и пр.
2.1. Страницу можно разместить в посте.
Самый простой вариант. Даже помню 4 года назад игрался с этим и писал пост.
Если кратко, отправляется операция с частью страницы или всей страницей.
2.2. В custom_json (в #viz называется custom).
Добавляем части страницы и указываем блоки с custom id других частей или файлов.
Далее Клиент загружает основной блок, а оттуда собирает указания на остальные блоки и загружает страницу.
Естественно js содержимое, также как и стили, указывается в отдельных блоках тоже, а затем указывается на странице.
Пример:
``<script src="viz://@login/block/id"></script>``
Думаю понятно, где что...
Можно размещать и весь html код страницы, но тогда исчезает возможность создания шаблона гибкого, да и есть риск, что в случае большого объёма контента страница не добавится в блокчейн...
3. Что-то неизвестное...
Нельзя отрицать возможность появления новых протоколов загрузки страниц, форматов интерфейсов и так далее...
4. Домены.
Оптимальной связкой мне видится сейчас распределённые домены + Ipfs или иная P2P сеть.
4.1. Владелец сайта регистрирует домен, например, в Ens, unstoppable domains или Viz.
4.2. Устанавливает браузер с поддержкой доменов.
4.3. Добавляет в блокчейн (в настройки) информацию с ipfs хэшем главной страницы.
4.4. Когда браузер открывает домен, он получает инфу о хэше, подключается к Ipfs, скачивает данный файл и выдаёт пользователю.
Естественно скрипты, стили, изображения и прочие файлы, которые есть на странице, указываются в виде ipfs хэшей, благодаря чему браузер их спокойно загружает.
4.4. Система доменных имён может давать возможность создания именования файлов и страниц, чтоб были не непонятные наборы символов, а красивые имена, типа site/about.
5. Про Viz домены.
Про ENS и unstoppable вы найдёте инфу в интернете спокойно, а вот Viz малоизвестный проект, поэтому думаю стоит рассказать про домены.
Дело всё в том, что в Визе есть аккаунты и субаккаунты. Тем самым и реализуется система, похожая на доменные имена.
Примеры:
Мой акаунт bda (Blind dev apps) и создал mgb.bda субаккаунт (mgb = mini games bot).
denis-skripnik и субаккаунт social.denis-skripnik.
У каждого аккаунта есть json_metadata -json, в котором можно хранить любую (естественно ограниченную по размеру) информацию.
Сейчас чаще всего это профиль, но можно сделать сервис, который будет добавлять:
А) Ip адрес сервера - половинчатый вариант.
Б) - Ipfs хэш главной и хэши других страниц с их именованиями.
В) Подключение к своей системе распределённого хранения за оплату (планируется Viz Hub).
Г) Иная реализация.
Всё.
Благодарю за внимание.
А вы что думаете по этой теме? Считаете ли децентрализованные интерфейсы важными? Буду рад комментариям.
И хороших выходных!
Давно я не писал по этому тегу, но на днях прочитал пост про децентрализованные интерфейсы.
И решил порассуждать над вариантами реализации.
Сразу скажу: если будет что-то непонятно, пишите в комментариях - отвечу.
0. О причинах.
Интерфейс Tornado cash заблокировали / удалили - это заставило задуматься сторонников web 3.0, что пора создавать децентрализованные интерфейсы, которые не будут зависеть от кого-либо.
1. Ipfs.
Если кто не знает, это распределённая сеть, типа торрентов (если очень упрощать - различий много).
Так вот: можно просто открывать страницы в ipfs.
Js файлы и стили css тоже подключаем в коде, указывая ipfs хэши.
И важно, что не прокладку, типа ipfs.io, поскольку это снижает безопасность, а просто ipfs хэш.
Далее браузер / софт локально подключается к сети и скачивает нужные данные - только так...
Можно теоретически приложения создавать для ОС, обслуживающие ipfs, но это вряд ли станет популярным.
Другое дело ipfs браузер...
Вместо Ipfs можно использовать другие P2P сети.
2. Блокчейн, как хранилище страниц и файлов.
Этот вариант не является практичным, но упомяну его...
Естественно BTC или Эфир нельзя для этого использовать ☺: сожрут все деньги...
Но вот чейны с Bandwidth (пропускной способностью аккаунтов) возможно можно...
Примерами таких являются #steem, #hive, #viz и пр.
2.1. Страницу можно разместить в посте.
Самый простой вариант. Даже помню 4 года назад игрался с этим и писал пост.
Если кратко, отправляется операция с частью страницы или всей страницей.
2.2. В custom_json (в #viz называется custom).
Добавляем части страницы и указываем блоки с custom id других частей или файлов.
Далее Клиент загружает основной блок, а оттуда собирает указания на остальные блоки и загружает страницу.
Естественно js содержимое, также как и стили, указывается в отдельных блоках тоже, а затем указывается на странице.
Пример:
``<script src="viz://@login/block/id"></script>``
Думаю понятно, где что...
Можно размещать и весь html код страницы, но тогда исчезает возможность создания шаблона гибкого, да и есть риск, что в случае большого объёма контента страница не добавится в блокчейн...
3. Что-то неизвестное...
Нельзя отрицать возможность появления новых протоколов загрузки страниц, форматов интерфейсов и так далее...
4. Домены.
Оптимальной связкой мне видится сейчас распределённые домены + Ipfs или иная P2P сеть.
4.1. Владелец сайта регистрирует домен, например, в Ens, unstoppable domains или Viz.
4.2. Устанавливает браузер с поддержкой доменов.
4.3. Добавляет в блокчейн (в настройки) информацию с ipfs хэшем главной страницы.
4.4. Когда браузер открывает домен, он получает инфу о хэше, подключается к Ipfs, скачивает данный файл и выдаёт пользователю.
Естественно скрипты, стили, изображения и прочие файлы, которые есть на странице, указываются в виде ipfs хэшей, благодаря чему браузер их спокойно загружает.
4.4. Система доменных имён может давать возможность создания именования файлов и страниц, чтоб были не непонятные наборы символов, а красивые имена, типа site/about.
5. Про Viz домены.
Про ENS и unstoppable вы найдёте инфу в интернете спокойно, а вот Viz малоизвестный проект, поэтому думаю стоит рассказать про домены.
Дело всё в том, что в Визе есть аккаунты и субаккаунты. Тем самым и реализуется система, похожая на доменные имена.
Примеры:
Мой акаунт bda (Blind dev apps) и создал mgb.bda субаккаунт (mgb = mini games bot).
denis-skripnik и субаккаунт social.denis-skripnik.
У каждого аккаунта есть json_metadata -json, в котором можно хранить любую (естественно ограниченную по размеру) информацию.
Сейчас чаще всего это профиль, но можно сделать сервис, который будет добавлять:
А) Ip адрес сервера - половинчатый вариант.
Б) - Ipfs хэш главной и хэши других страниц с их именованиями.
В) Подключение к своей системе распределённого хранения за оплату (планируется Viz Hub).
Г) Иная реализация.
Всё.
Благодарю за внимание.
А вы что думаете по этой теме? Считаете ли децентрализованные интерфейсы важными? Буду рад комментариям.
И хороших выходных!
Telegraph
Проекты DeFi будут разрабатывать децентрализованные пользовательские интерфейсы после падения Tornado Cash
Небольшое, но растущее число децентрализованных финансовых (DeFi) проектов, включая dYdX, Liquidity, GMX, Kwenta и другие, работает над децентрализованными фронтендами (DeFe) после введения санкций против Tornado Cash. Ранее в этом месяце Управление по контролю…
👍10