Ответы

Не всё. Насчет рекламы я улыбнулся... (рукалицо)

Спасибо, хорошая критика! Отвечу по пунктам.

1. Биржи.

Популярность и удобство использования децентрализованных бирж растет (например, имплементирующих протокол 0x), есть достаточно большая вероятность, что для эфириума DEX станут стандартом.

С централизованными биржами, конечно, ситуация другая. Переводы/торги совершаются без сжигания.

Но тут также вопрос риска. Если холдер токенов перебрасывает все токены сразу на биржу, то он/она, конечно, экономит на комиссии, но при этом увеличивает его/ее риск потери токенов при хаке биржи.

Жизненный цикл токена приводит к тому, что на централизованные биржи токены обычно попадают с достаточно большим опозданием. Процент сожженных токенов при переводе падает со временем, поэтому к времени листинга на централизованных биржах комиссия уже будет меньше, чем в начале .

Я обдумываю дополнительный функционал смарт-контракта который позволит в какой-то мере компенсировать торговлю на централизованных биржах ограничениями на количество токенов в одном адресе.

1. Донейт

Если уровень донейта равен 0 или близок к нулю значит, что интерес к проекту почти полностью спекулятивный, что в свою очередь, говорит о потенциально низком уровне интереса/доверия к проекту.

Опять же, стоимость 1000 токенов может быть 1.1 эфира, где 0.1 эфира попадают в кошелек разработчиков, а 1 эфир остается в обеспечении. Донейт не единственный инструмент получения стартового фонда.

Плюс по аналогии с краудфандинг проектами можно отменить краудсейл и распределение токена, если донейт не достинг опреленной границы.

1. Рост эфира

Выводить эфиры для инвесторов нет необходимости, т.к. арбитраж будет поддерживать стоимость токена на уровне соответствующему обеспечению в смарт-контракте. Помимо этого, вывести эфир можно всегда, а вот купить токены снова можно будет только на бирже с учетом премии.

В будущих прототипах я добавлю вестинг. Как вариант я также изучаю возможность постепенного уменьшения обеспечения в эфирах. К примеру за 1 года обеспечение падает с 1000 токенов = 1 эфир до 1000 токенов = 0.7 эфиров.

1. Отсутствие интереса для разработчиков

Я не рассматриваю AlticoTB как альтернативу всем ICO. Есть много проектов, где у разработчиков должен быть доступ к большинству средств как можно быстрее. Но есть и проекты, которым нужен постоянный и не очень большой кешфлоу. Такой проект как раз может использовать эту концепцию и собрать средства, которые бы не получилось бы собрать без защиты эфиров инвесторов.

Там еще есть const и let в ES6 они вообще ведут себя по другому. Я уже не говорю о стрелочных функциях. Но мне кажется что автор вполне понятно написал для начинающих. А если мы знаем больше, то я например готов написать курс по ES6.. :)

Спасибо за замечание. Впереди ещё много уроков, в которых обязательно будет ещё больше информации о типах данных, других специальных значениях и и т.д.
Это всего лишь третий урок 😉

Мы тоже о таком думали. Можно добавлять в json_metadata какой-то хэш, уникальный для каждого сообщения, который только сервис может расшифровать и таким образом убедиться, что это точно сообщение, созданное сервисом.

Получается такое же по сложности, потому что теги все равно лежат в json_metadata['tags'].

Steemit на сегодняшний день просто добавляет app в json_metadata при создании поста и больше ничего не делает.

appname и appversion не решит проблемы разграничения, поскольку ничего не мешает подглядеть версию, написать и отправить. Да, затруднит, но оставит шанс тем, кто целенаправленно хочет чего-то сломать. Единственный способ, который я пока нашел - это подпись метаданных секретным ключом. Если такая необходимость появится, то будет возможность включения проверки подписи по ключу. И вот тогда, точно никто со стороны писать не будет.

Блокчейн парсится поблочно, начиная с любого блока, есть такая штука в API - get_block. Каждый блок содержит информацию о произошедшей транзакции, как минимум, с автором и прямой ссылкой на его статью. После получения информации о произведенной транзакции, можно получить полные данные о статье запросом get_content(author, permlink). Все возвращаемые данные записываем в базу.

get_discussions_by_XXX -- не используется вообще.
Теги анализируются при разборе блока, все они записаны в поле metadata['tags'].

Какие есть готовые сервисы для наблюдения? Очень интересно)

Тег сервиса в посте добавлять не обязательно. Обязательно записывать название приложения в json_metadata ('app': appname + '/' + appversion). Это лишит пользователя возможности, добавив вручную тег, постить из golos.io от лица другого сервиса и наоборот. Steemit и eSteem, уже используют, а Busy и SteepShot будут использовать этот стандарт для идентификации постов, сделанных конкретным приложением.

Это не решает описанную проблему фильтрации на уровне блокчейна, но если вносить изменения, то полезнее будет добавить фильтрацию по json_metadata['app'], чем дописывать filter_tags (что тоже не помешало бы).

По мне так интерфейс Голоса должен быть сделан в виде обширной древовидной структуры с множественными вложениями по тематикам, как папки на жестком диске. Иногда человек ищет что-то, а теги правильные подобрать не может, а в древе он идет от корня основной темы в глубь.
Те или иные новые вложенные подтемы в древе, наверное, должны появляться после одобрения сообществом.

Сейчас за фильтрацию отвечает нода?
Тогда надо просто сделать функцию, которая будет фильтровать по нескольким тегам.
Не думаю, что это что-то мудреное.

Самое простое было запарсить блокчейн Голоса и работать как с обычной базой данных :))
www.mapala.net - сыровато еще, но на том и держится.
Там же еще дело такое, что теги русские не принимаются, т.е. по пункту 1 надо воротить что-то типа:
ru--superdesertru--superdesert -- гигантский костыль :)) если честно.
Дописать код - это замечательно, но что если нужно доставать/фильтровать данные не по тегу, а по любой другой записи в мета? Например, по цене за товар.