Добрый день!
Уважаемые делегаты и члены коммьюнити!
В Wiki.golos.io сегодня была опубликована очередная версия HF 19.0.
Команда Golos•Core дублирует содержание публикации в этом посте, чтобы у сообщества появилась возможность поделиться фидбеком и задать вопросы по конкретным пунктам новой версии, в которой реализованы новые функциональные возможности, а также устранены недостатки предыдущих версий. Обновления поддержаны большинством голосов делегатов.
Внедрение реферальной программы в блокчейн Golos (задача №295)
Делагатами было предложено реализовать в HF-19.0 новую функциональную возможность — внедрить реферальную программу привлечения новых пользователей.
Реализация новой функциональности
Реализация реферальной программы предусматривает вознаграждение пользователей (рефереров), пригласивших для регистрации в блокчейн своих друзей или сторонних лиц через социальные сети (просматривая публикации сторонних авторов или размещая собственные посты о блокчейне).
Для реализации реферальной программы в HF-19.0 добавлены следующие операции:
- Создание аккаунта-реферала для приглашенного пользователя. В качестве реферера для аккаунт-реферала может быть указан как пользователем, непосредственно пригласивший другого пользователя, так и сторонний аккаунт;
- Прекращение действия реферальной программы пользователем-рефералом через выкуп своего аккаунта. Операция позволяет рефералу выкупить свой аккаунт для прекращения выплат рефереру;
- Получение информации о пользователе-реферале;
- Получение информации о пользователе-реферале по его комментарию или посту.
1.
Пример команды для создания аккаунта-реферала с использованием cli_wallet
имеет вид:
create_account_referral test "0.200 GOLOS" "0.000001 GESTS" <referral account name> "{}" {"referrer": "test", "interest_rate": 900, "end_date": "2018-09-26T14:00:00", "break_fee": "0.000 GOLOS"} true
где:
referral
— имя аккаунта-реферала;
referrer
— имя аккаунта-реферера;
interest_rate
— процент выплат рефереру от доходов реферала, умноженный на 100.
Максимальный процент выплаты рефереру устанавливается голосованием делегатов через операцию update_chain_properties()
. Выплаты рефереру осуществляются через назначение реферера бенефициаром в публикуемых постах.
end_date
— дата окончания выплат рефереру из доходов реферала. Максимальный срок выплаты рефереру устанавливается голосованием делегатов через операцию update_chain_properties()
.
break_fee
— cумма выкупа рефералом своего аккаунта для прекращения выплат рефереру. Если в качестве сумма выплаты будет указан 0, то аккаунт нельзя будет выкупить. Максимальная сумма выплаты выбирается делегатами через операцию update_chain_properties()
по медиане.
2.
Пример задания команды для операции по прекращению выплат рефереру имеет вид:
break_free_referral <referral account name> true
3.
Для получения информации о пользователе-реферале через cli_wallet
используется команда get_account
. Для придания аккаунту-рефералу особого статуса в системе в ответ API-метода golos.api.getAccounts()
добавлены следующие поля:
"referrer_account": "test",
"referrer_interest_rate": 900,
"referral_end_date": "2018-09-26T14:00:00",
"referral_break_fee": "0.002 GOLOS"
В период действия реферальной программы для аккаунта-реферала значения полей соответствуют полям из account_referral_options
. После прекращения действия реферальной программы поля принимают нулевые значения.
4.
Для получения информации о пользователе-реферале по его комментарию или посту в поле beneficiaries
добавляется объект с параметрами account= < referrer name> и weight=<referrer_interest_rate>. Выплата рефереру осуществляются с учетом этих параметров.
Изменение метода начисления вознаграждения кураторам (доработка для штрафного окна голосования, задача №898)
Начало голосования за пост начинается сразу по завершении его публикации. Размер вознаграждения кураторам за голосование зависит от времени голосования. Длительность интервала, отведенного для голосования составляла 30 мин — аукционное окно (англ. auction window), которое открывалось сразу по завершении создания поста. Вес голоса, отданного в интервале этого окна вычислялся по формуле:
W = t / (30 × 60) × weight
где:
t — время голосования с момента открытия окна (в секундах);
(30 × 60) — продолжительность окна (в секундах);
weight — вес голоса аккаунта.
В соответствии с этой формулой результирующий вес W уменьшается пропорционально раннему голосованию — более ранний голос, отданный в период открытого окна, получает более меньший вес. При этом недостающая (срезанная) часть токенов начисляется автору поста. Голосование в период открытого окна более выгодно авторам поста.
В версии HF-19.0 (по предложению делегатов) доработан алгоритм для более гибкого начисления вознаграждения кураторам, в том числе:
- Стало возможным изменять длительность аукционного окна голосованием делегатов через операцию
update_chain_properties()
; - Стало возможным возвращать недостающую (срезанную) часть токенов либо в пул вознаграждений, либо кураторам, проголосовавшим после закрытия аукционного окна. Решение о том, куда направлять срезанную часть токенов, принимает автор поста.
С этой целью в метод comment_options_operation
добавлена опция comment_auction_window_reward_destination
, принимающая следующие значения:
to_reward_fund
— возврат токенов в пул вознаграждений. При возврате токенов в пул-вознаграждений генерируется виртуальная операция auction_window_reward_operation;to_curators
— возврат токенов кураторам, проголосовавшим после закрытия аукционного окна;to_author
— только для постов, созданных до релиза HF-19.0 (после релиза HF-19.0 выбор данного варианта будет невозможным).
Возможность делегатов изменять интервалы времени, отводимые на оставление комментариев и голосование (задача №533)
Делегатами было предложено сократить временные интервалы, отводимые на оставление комментариев к посту и голосование, составляющие 20 и 3 с соответственно. Такие жестко установленные интервалы имеют недостаток. Например, за отведенное время 20 с могут появиться до десяти и более комментариев, на ответы которых делегатам приходится затрачивать значительное время.
В версии HF-19.0 появилась возможность изменять длительности интервалов (окон), отводимых на оставление комментариев и на голосование, а также возможность изменять предельно допустимое количество комментариев и голосов, оставляемых в течение этих интервалов.
В операцию update_chain_properties
, с помощью которой конфигурируется блокчейн, добавлены параметры comments_window
, comments_per_window
, votes_window
, votes_per_window
. С помощью этих параметров делегаты могут задавать длительности интервалов, в течение которых разрешается оставлять комментарии и голосовать, а также допустимое количество комментариев и голосов, оставляемых в течение этих интервалов. Значения этих параметров определяются голосованием делегатов через операцию update_chain_properties(), за результаты которых принимаются медианные значения.
В версии HF-19.0 длительность окна для комментирования и допустимое количество оставленных комментариев в течение этого окна составляют 200 с и 10 шт. соответственно. Длительность окна для голосования и допустимое количество отданных голосов в течение этого окна составляют 15 с и 5 шт. соответственно.
Также был доработан алгоритм, ограничивающий чрезмерную активность пользователей в комментировании и голосовании. Алгоритм позволяет более гибко совершать действия подряд без ожидания завершения 20-секундного интервала до начала следующего действия. Алгоритм работает по принципу «батарейки». Минимальная частота совершаемых действий определяется по формуле:
V=window/items
Где:
window — длительность интервала, отведенного на голосование;
items — количество комментариев или голосов, оставленных в интервале голосования.
Медианное значение выбирается через сортировку указанных делегатами значений по двум величинам - минимальная частота действий, и длина окна в которое эти действия можно совершать.
Пользователь может оставлять комментарии или участвовать в голосовании при условии наличия ресурсов (заряда) в его «батарейке». Алгоритм фиксирует время появления поста и содержимого заряда «батарейки», расходуемого с оставлением каждого комментария к посту или голосованием.
Начисление делегирующему Силы голоса доли от кураторских (задача №756)
Количество желающих делегировать Силу голоса невелико. Отчасти это вызвано тем, что делегирующий (инвестор СГ) не получает каких-либо отчислений от кураторских вознаграждений и следовательно не получает вознаграждение вообще.
В версии HF-19.0 добавлена возможность устанавливать процент отчислений инвестору СГ. Куратору, которому делегируется СГ, по результатам голосования за пост отчисляет часть кураторских выплат инвестору.
Алгоритм начисления инвесторам СГ реализован в соответствии со следующими особенностями :
- Выплата вознаграждений инвесторам происходит одновременно с выплатами кураторам, которым делегировали СГ инвесторы. Инвестору начисляется определенный процент от выплаты куратору. Размер отчисления инвестору определяется по следующей формуле:
Вознаграждение инвестору = (вознаграждение куратора) × (доля инвестора в СГ куратора) × (процент отчислений инвестору)
где:
доля инвестора в СГ куратора = (количество делегированной СГ) / (общее количество СГ куратора)
Процент отчислений инвестору назначается непосредственно инвестором.
Верхнее значение процента отчислений инвестору устанавливается голосованием делегатов с использованием операции update_chain_properties()`;В блокчейн добавлена новая виртуальная операция
delegation_reward_operation
, которая используется для уведомления делегаторов о получаемых ими вознаграждениях за делегированную СГ;Возможность отказа от делегированной СГ получателем (в случае нежелания обмена выплат с инвестором). Для этого была добавлена операция
reject_vesting_shares_delegation_operation
.
При отказе получателя от делегированной СГ, ее автоматическое зачисление на его баланс получателя не производится. Возврат делегированной СГ делегатору происходит после окончания заморозки длительностью 7 дней.
Возможность пользователя хранить личную информацию в хэш-таблице хранилища в виде key-value (задача №924)
Делегатами было предложено реализовать в HF-19.0 новую функциональную возможность — предоставить возможность пользователю сохранять нужную ему информацию в хэш-таблице хранилища в виде key-value.
Решение основано на создании нового плагина account_notes
, который позволяет аккаунту сохранять необходимую для него информацию в хэш-таблице базы данных системы в виде записей «key-value» в зависимости от настроек конфигурационного файла config.ini
. Объем информации для хранения на отдельном Узле (ноде) блокчейна определяется с учетом ресурсов этого Узла.
В плагине account_notes
реализован вызов операции set_value_operation
, выполняющей создание, изменение и удаление записи в хэш-таблице хранилища. Операция вызывается с полями account, key и value.
Для изменения записи в хэш-таблице операция вызывается с ключом уже имеющейся записи. Для удаления записи в хэш-таблице операция вызывается с ключом уже имеющейся записи и пустым значением.
В конфигурационный файл config.ini
добавлены следующие настраиваемые параметры:
- an-tracked-accounts — «белый» список аккаунтов. Используется для задания списка аккаунтов, которым разрешено сохранять записи. По умолчанию задается пустое поле, разрешающее хранение записей всем аккаунтам;
- an-untracked-accounts — «черный» список аккаунтов. Содержит список аккаунтов, которым не разрешается хранение записей. По умолчанию задается пустое поле;
- an-max-key-length — максимально допустимое количество символов в ключе. По умолчанию содержит значение 20;
- an-max-value-length — максимально допустимое количество символов в записи. По умолчанию содержит значение 512;
- an-max-note-count — максимально допустимое количество записей для одного аккаунта. По умолчанию содержит значение 10.
В случае превышения в сохраняемой записи установленных граничных значений операция не выполняется. При этом сообщение об ошибке не выдается. Для контроля успешного сохранения информации пользователь должен запросить у Узла его текущую конфигурацию и сопоставить данные сохраняемой записи с граничными значениями этого Узла.
После HF-19.0 стоимость ресурсов бендвича для операций custom_json
будет увеличиваться за счет умножения на значение мультипликатора. По умолчанию значение мультипликатора составляет 100. Делегаты могут изменить данное значение путем голосования через операцию update_chain_properties()
. Это позволяет пользователям с большим количеством СГ сохранять в хэш-таблице информацию более часто и большего размера в отличие от пользователей с меньшим количеством СГ.
Возможность автора устанавливать размер кураторских отчислений за пост (задача №324)
В предыдущих версиях блокчейна доля выплаты кураторам от вознаграждения автора была неизменной и составляла 25 %.
В версии HF-19.0 автор уполномочен самостоятельно устанавливать процент отчисления кураторам для каждого поста. Увеличивая процент кураторских отчислений, автор поста стимулирует кураторов голосовать за их посты как можно чаще.
После создания поста автор может указать процент кураторских отчислений от ожидаемого вознаграждения за этот пост.
В операцию update_chain_properties
, с помощью которой конфигурируется блокчейн, добавлены параметры min_curation_percent
и max_curation_percent
. С помощью этих параметров делегаты могут устанавливать предельно допустимые значения процента кураторских отчислений. Эти значения определяются голосованием делегатов, за результаты которых принимаются медианные значения. В конфигурационный файл config.hpp
добавлены константы STEEMIT_MIN_CURATION_PERCENT и STEEMIT_MAX_CURATION_PERCENT для задания минимального и максимального их значений по умолчанию, которые составляют 25 и 95 % соответственно.
Пороговое значение кураторских отчислений за пост 95 % означает, что автору гарантируется вознаграждение в размере не менее 5 % от общей суммы начисления за пост.
В операцию comment_options_operation
добавлена структура comment_curation_rewards_percent
. С помощью этой операции автор может задать процент кураторских отчислений.
Устранение недостатка в ответе API-метода get_account (задача №825)
Во входящем ответе на запрос get_accounts
API-метода информация о количестве постов и комментариев находилась исключительно в поле post_count
, при этом поле comment_count
всегда возвращалось пустым. Также при этом отсутствовало какое-либо сообщение об ошибке, что могло привести пользователей в конфузное состояние.
В версии HF-19.0 этот недостаток устранен. Был доработан метод get_accounts
для корректной записи данных в соответствующие поля при создании поста и комментария. Поле comment_count
содержит количество комментариев, а поле post_count
— только количество постов.
Каналы коммуникации с Golos•Core
- https://t.me/goloscoretc (решение технических вопросов, связанных с работой блокчейн, нод, api и др.)
- https://t.me/joinchat/BLwf_A118xQ57nsM1Q4MPA (канал для вноса предложений от комьюнити, обсуждение перехода на кодовую базу EOS)
- https://t.me/golos_tools (решение вопросов по различным интерфейсам и дополнительным инструментам, создаваемым Golos•Core)
- https://t.me/goloscore_analytics (решение вопросов по работе экономики блокчейн, статистическим экономическим данным, аналитике данных)
- https://t.me/goloscoretech (новостной канал, с актуальной информацией от Golos•Core).
- Мы будем очень рады, если вы поддержите делегата @goloscore. Заходите на страничку https://golos.id/~witnesses голосуйте за делегата Golos•Core!
Спасибо за внимание и хорошего дня!
С уважением,
Команда Golos•Core: @korpusenko, @andreypf, @maslenitsa, @muhazokotuha, @zxcat, @annaeq, @anazarov79, @kaynarov, @s-medvedev
Я лично ожидал, что и для постов будет сделано так же как и для комментариев. То есть пубикация N постов сразу. Пускай будет допустим (24*60 / 5 минут) 288 постов в сутки. Может для кого то выгодно будет отстреляться и отдыхать весь день. Как информационные посты.
Непонятно, зачем было сделано регулирование custom_json операции, если значения хранятся в данных плагина, а не у всех делегатов. Хотя наверное и нужно было ограничить, если такого ограничения не было.
Ну и не нравится возможность не дать откупиться от кабалы рефералу. Может дать возможность делегатам задать min_break_fee? Если большинство задатут 0, то бог с ним.
@ropox Рефералу - это невыгодно: выставлять в 0, к нему никто не пойдет.
@andreypf Да, но выставляет то он их уже при регистрации. Ладно кто то с репутацией, не будет этим злоупотреблять. Бог его знает.
@ropox, я твою мысль уже читал, обдумывал и не понял. "Острелялся и отдыхай весь день" - это как? Тут получается
потом надо полтора месяца отдыхать. При лимите 6 постов в сутки.
@retroscope Ну я в основном про технические посты и за сообщества думаю. Если есть к примеру 4 поста к публикации. Отправил их за один присест и гуляй смело. Сиди пиши следующие. Не надо сидеть и ждать по 20 минут каждый раз
@ropox зачем тому откупаться? Обычно реферал ли ты или не реферал никаким плохим образом это на тебе не сказывается. Поэтому и толку откупаться нету. Только если рефералка реализована не как у нормальных людей то конечно да...
В таком случае проблема решается созданием нового "свободного" аккаунта.
@raldin Тут же четко сказано что сделано "не как у нормальных людей" и рефералка будет выплачиваться не за счет системы/эмиссии как должно быть, а за счет конкретного автора-реферала. Ниже я написала к чему это приведет, проходили через это на некоторых буксах, в итоге от этого отказались и рефералку рефереру стали выплачивать не за счет реферала а за счет системы. Зачем подкладывать бревна, когда давным давно изобретено колесо?
@lindsay Самая простая схема высасывания пула:
@andreypf
рефер с большой силой публикует пост
рефер голосует за свой пост
рефер получает бонус
эта схема НЕ работает на выкачивание пула. она работает к примеру для Марины. когда за счет нее регистрируются новые пользователи и она потом их апает с рандомным процентом.
или для новых сообществ типа ВП когда тех аккаунт регистируется за счет основного и с него идет пост деятельность и тогда не надо перечислять инвесторам средства ручками. редактор просто публикует посты а аккаунт инвесторов его апает по мере сил. и получает свою долю
@ksantoprotein это не про пул вознаграждений, это про пул реферальной программы, в случае его наличия.
@andreypf а себя же можно указать рефером при создании реферала?
@ksantoprotein like
Думаю, киты не станут этим заморачиваться,проще продать ап в бустере. А все что ниже, даже если это касаточный ап - овчинка выделки не стоит.
Усложним схему:
странная схема.
если я владею приватниками реферала и меня спосируют те кто готов дать токены на прокачку и за перепостинг с внешнего канала. то зачем мне заморачиваться так. если я просто свой профит буду брать переданным ликвидом.
это имеет место, если у того кто делает перепост нет доступа к монетам. поэтому он просто постит зная только приватный постинг ключ, а уже кто-то другой прокачивает за счет своих средств выбранные посты на свою левую пятку. и тогда тот кто занимается постингом получает свою награду.
ранее была иная схема. делался пост отчет и его апали (или коммент) так было проще без рефералки.
какие есть еще схемы в сферическом вакууме для анализа?
@ksantoprotein это сферическая схема, если в системе будет отдельный пул для реферальной программы - как высасывать награду из этого пула.
@andreypf теоретически вроде выгодно но на практике скорее всего не взлетит. Прокачка постов нынче довольно трудозатратный и творческий процесс с непредсказуемым результатом, просто так ботом все доступные апы не скупишь в плюс, а покупать какую-то часть с нынешним курсом, это не окупит даже затраты на создание бота. конечно кто-то будет пытаться вручную это делать, но здесь есть масса способов заработать намного больше за эту же единицу затраченного времени.
@mamatata, @andreypf like
Отлично, зафиг тогда это было нужно? Идея же была в том, чтобы заставить автора делиться с кураторами положенными 25%. А если решает автор - то эта работа коту под хвост, ладно бы если бы решали делегаты, ещё куда не шло.
Может быть я чего-то не понимаю, но 15с и 5 штук, это голосование каждый блок. Зачем тогда вообще это окно? Т.е. человек если захочет злоупотреблять просто высадит себе батарейку. Поясните идею, или это защита от голосования с мелкой силой?
Эх, сделано как в VIZ, хотя я предлагал оставить выбор процента кураторских за куратором... Самый прикол в том, что если вы не делаете линейную кривую куратоскую о чем говорил @vvk, то и смысла в выборе кураторского % нет, ибо голосующий после кита/дельфина ничего не получит независимо от процента.
Да, для тех кто не в курсе: с текущей кураторской кривой всю кураторскую награду заберут ранние кураторы. Это будет очень прикольно выглядеть на постах с большим кураторским процентом.
Выскажусь.
Я согласен с @litrbooh и @vvk, что самым правильным вариантом было сгладить кривую, но:
Мое мнение, интересно все таки:
Важный момент - нам все равно доставлять еще один ХФ и в очень ближайшее время, потому что, к нашему сожалению, разработчик не успевает доставить воркеров, а мы должны эту функциональность доставить.
Поэтому у нас варианты:
@andreypf
Важен не срок, а результат. Не вижу смысла принимать ХФ, который не только не ведет в результатам, которые хотелось достичь своими предложениям, а наоборот удаляет от них. Вы свой интерпретацией только усложнили ХФ, потратили больше времени, но изменили первоначальную идею до неузнаваемости и она просто потеряла смысл.
Так это к вам вопрос почему вы отказались обсуждать этот вопрос. Лично я предлагал обсудить изменения кураторских 10 раз, но у вас не нашлось на это времени. А все предлагаемые изменения без сглаживания кривой НЕ НУЖНЫ. Почему вы проигнорировали этот факт, почему вы не вынесли его на обсуждение, почему вы отказались от обсуждения - это к вам вопрос. У меня нет на него ответа.
Я так не считаю, я в своих постах неоднократно описывал как я вижу изменения в кураторских. Решать текущие проблемы по частям нельзя.
Это не так, вы оставили это выбор автора.
Будет всё тоже самое.
В 11 раз предложу провести дискорд в делегатском канале в адекватное по Москве время.
низкий уровень уровень команды и тимлида приводит к появлению реализации задачь "на пол шишечки"
опять тяп-ляп таску реализовали. Ну вот расскажи как? как люди которыми ты и мира так китичесь, могут сделать не подумав?
а потом когда вам пишут о косяке, вместо исправления ответ что "время поджимает". а кто вас собственно гонит? Можешь сказать?
Вон воркеров до сих пор нет, лучше там подожми время чб воркеры быстрее появились.
@vvk кураторские паровозики должны будут сильно поумнеть и не апать все подряд 95%
технически наступит момент когда апать 95% пост просто нет смысла
Ты же сам вроде так и предлагал ))
@ropox , я предлагал про комменты вроде
Ещё и пропала возможность сознательно отдать автору свои кураторские, проголосовав сразу после публикации поста.
@retroscope , это как раз хорошо. Другой вопрос, что я предлагал выбор % оставить на кураторе...
Автору экономически выгодно направить срезку кураторам. Думаю, этот параметр стоит перенести в chain_params, чтобы делегаты выставляли.
Очень сомнительное нововведение. Есть bandwidth аккаунта, не вижу большого смысла в дополнительных лимитах, зато вижу усложнение кода. Если аккаунт начинает спамить, он в любом случае упрётся в bandwidth. Данные новые ограничения можно будет обойти, разбив стэйк на несколько аккаунтов. В общем я бы предпочёл просто убрать лимиты.
Тоже сомнительная фишка, не знаю почему приняли на реализацию, я не видел реальных запросов на такое от пользователей. Усложнение кода. Против.
А для market операций почему бы тогда тоже не сделать мультипликатор голосуемым? Хотет.
Резюме
Вместо реализации крайне востребованной функциональности воркеров, имплементировано несколько второстепенных фич. В предлагаемом виде я не буду накатывать эту версию.
@vvk
Это была моя идея, я писал об этом большой пост. В сочетании с большим процентом кураторских и линейными кураторскими это позволит пассивным кураторам не просто тупо продавать апы, а с большим профитом делегировать СГ проф. кураторам. При это стекхолдер будет получать свой процент и куратор будет получать за работу.
Бинго! Их-то у нас и нет. Думаю стоит отложить тогда пока эту фичу. А ещё, всё-таки хотелось бы увидеть потенциальных пользователей этой фишки, чтобы они как-то себя проявили, типа "да, хотим делегировать, нужно".
@vvk , ну если эта фича будет реализована как я её описал - с большим процентом кураторских и с линейными кураторскими без штрафов, то я хочу, буду и т.п. Почему нет?
Кстати, с линейными кураторскими и штраф этот несчастный не нужен... который они наплодили в голосовалку.
@urri, @litrbooh like
фича отличная, особенно в рамках того что стимулирует спящих китов на делегирование силы. но вот линейные кураторские толькр усилять эффект.
Да, хочу делегировать, нужно!
@anela тоже была заинтересована, насколько я помню)
вообще за все эти фичи ведь голосовали в табличке, почему только сейчас недовольство?)
Я не голосовал в той табличке, потому что оттуда выпилили воркеров, забанили @litrbooh-а, в общем цирк с конями.
Ладно, остаются спорные моменты:
Думаю пока эти моменты не обсуждены, стоит придержать принятие хардфорка.
ну рулить явно должны делегаты, а кураторская кривая давно просится чб ее поправили)
заоодно решить вопрос с долгом по ГБГ
@t3ran13 like
custom_json это же еще подписка и отписка? если бендвич будет с мультипликатором 100. то новорег просто не может ни на кого подписаться.
@ksantoprotein Настроить же можно будет делагатам.
@ropox это да. после массовых обращений от новорегов... и интересно будет понаблюдать как отреагируют пользователи ГВ с небольшой СГ после такого мультипликатора. там так же кастом задействуется при входе
Чисто нумерологически, число 19 - кармическое. Так что ничего хорошего ждать не приходится :))
Ваш пост поддержали следующие Инвесторы Сообщества "Добрый кит":
neo, midnight, amikphoto, semasping, ladyzarulem, mryabinin, irimeiff, chirakovalsky, aleos, ezavarov
Поэтому я тоже проголосовал за него!
Узнать подробности о сообществе можно тут:
Разрешите представиться - Кит Добрый
Правила
Инструкция по внесению Инвестиционного взноса
Вы тоже можете стать Инвестором и поддержать проект!!!
Если Вы хотите отказаться от поддержки Доброго Кита, то ответьте на этот комментарий командой "!нехочу"
dobryj.kit теперь стал Делегатом! Ваш голос важен для всего сообщества!!!
Поддержите нас:
@goloscore, Поздравляю!
Ваш пост был упомянут в моем хит-параде в следующей категории:
это ближайший хф или еще небыло 18?
@stepanov 18 было же уже, в июне
Что будет с делегированной ранее СГ? Каждое делегирование прийдётся перевыставлять с указанием бенефициарских, при необходимости?
@retroscope Да
Рефералка с выкупом - рабство какое-то. Человек пару дней попишет, потом когда разберется что к чему - откажется от аккаунта и заведет новый без рефки. Если не через пару дней то через пару месяцев, когда насобирается достаточная СГ и он увидит сколько реально денег уходит в "дань". Даже тем кому плевать на деньги - будет психологическое давление от того что человек вынужден будет по гроб жизни кому-то платить дань пока не "выкупит душу". Таким образом, мало того что мы будем плодить кладбище из тысячи аккаунтов-мертвецов, так еще и рефереры будут недовольны тем, что рефералы, чтобы привлечь которых, пришлось нехило потратиться на рекламу, будут уходить в свободное плавание без выкупа. Еще один повод для обидок, срачей, негатива и флагов. Ребята, не в обиду, но это полная хрень. Вообще ни на какую голову не налазит.
@lindsay Да, возможно это было бы правильно. Сделать отдельный пул, для рефералки. Где же вы были раньше, когда все обсуждалось. Ах да, на голосе не обсуждалось, только в github-е )) Я уже кучу раз писал, что бы под каждую фичу создавался пост и велось обсуждение на голосе.
А по существу, кабала в данном случае будет регулируемой, в определенных пределах. Может что и выйдет. К примеру размер выкупа тоже будет регулируемый. Не думаю, что он будет настолько заоблочный, что бы люди страдали и бросали аккаунты.
Принципиально, тот же golos.io может сделать регистрацию через рефералку. Отщипывать кусок бенефициарских рефереру. Вы берете ссылку у golos.io и приводите человека, который регается по ссылке. Вас указывают как рефера и к примеру 2% кабальных. А уже к у поста созданного в бенефициарах будет golos.io 8% и рефер 2%. Если сумма откупа будет 10-100 голосов, то я думаю это не будет настолько смертельно для автора, хато приработок реферу
@ropox
Не думаю, что он будет настолько заоблочный, что бы люди страдали и бросали аккаунты.
Если сумма откупа будет 10-100 голосов, то я думаю это не будет настолько смертельно для автора, хато приработок реферу
Для меня даже 1 голос в качестве "цены выкупа" был бы смертелен, тут дело не в сумме а в самом факте того, что я кому-то что-то должна, хотя ни у кого ничего не брала в долг. Из принципа бросила бы аккаунт но не заплатила бы ни копейки. И так поступил бы любой уважающий себя человек.
С другой стороны, реферер если узнает своего бывшего реферала под новым ником - полюбому начнет его флаговать и тоже будет абсолютно прав, потому что он вкинул хренову тучу денег в рекламу, размещение баннеров и задания на буксах, рассчитывая сделать на рефералке сумасшедшие иксы, а вместо этого рефералы все разбежались и никто не хочет платить. Вот Вы захотели бы залить на реферальный аккаунт хотя бы лям СГ, зная что 1-5% дохода с этого акка будет уходить рефереру, если можно завести новый без всякого рабства? А какого размера выкуп поставит реферер для реферала с лямом СГ? Человеческая природа ведь мерзкая, люди жадные. Я бы поставила такую сумму чтобы выкупиться было невыгодно, может быть именно лям голосов и поставила бы.
Эта вся затея с рефералкой - просто сталкиваение лбами одних пользователей с другими. Пойду-ка зарегаю пару тысяч акаунтов без рефки, пригодятся =)
Еще более глупая затея со штрафным окном (Бамбусс уже написал выше, почему). Даже не представляю какой тут начнется дурдом и хаос, и кто у нас будет собирать все апы и выходить в топ.
UPD: У меня есть хорошая идея по реализации рефералки при которой всем будет хорошо, но меня никто не станет слушать, а если и станут - то за это мне никто не заплатит.
@lindsay На том же bitshares все работает и никто не жужжит. Все как накопят и разберутся, покупают LT-членство тем самым убирая 20% отчислений регистратору. Так и тут. Тот у кого есть ХХХЗЗЗЗ сколько токенов откупится от рефералки, у кого их нету, тот и так будет отчислять 10% от заработанной копеечки. Да и рефереры могут поддерживать своих рефералов апами. Опять же на битшарах есть такие, кто возвращают 20% своим рефералам.
Короче поживем - увидим
И как это осилить простым пользователям?:((
"Возможность автора устанавливать размер кураторских отчислений за пост (задача №324)"
Думается, что в нынешних условиях аморфности и алчности голосят это запоздалое решение, уже утратившее актуальность. Потому что 99% топодрочеров и дальше будут постить свою колипасту, выставляя 100% или 95 % откат кураторам. И именно на них большинство продавцов СГ и настроит своих ботов. А то, что уходит им в СГ, этими проапанными будет выводиться на биржу.
С рефералками то же самое, время ушло. Про Голос слышал весь рунет, кто хотел зайти тот уже зашел.
Буду рад ошибиться, конечно.
Но разумней бы вам сосредоточиться на том, чтобы удержать тех, кто уже есть. Для начала хотя-бы сократите окно выплаты до трех суток. Потом наймите маркетмейкера и тд...
@bammbuss флаги нужно делать бесплатными, которые не сажают батарейки. Тогда я думаю пойдет мощное флагование копипасты. Конечно это всё может выльется во флаговою войну. Что не есть хорошо.
@raldin С флагами ничего не поменяется хоть сажают они, хоть не сажают батарейку, потому что от флагов чаще всего народ воздерживается не потому что жалко батарейку (она восстанавливается), а потому что боятся ответных флагов (особенно когда у того кого флагуют, больше СГ).
Вот кстати да) Если при нынешних профитных копейках еще и начнут конкурировать за пул с помощью флагов, то будет совсем кисло тем, кто не имеет щита в виде кнопки от СГ карманного кита.
Неплохая работа! Много очень полезных/нужных фич.
Каким образом определяется сумма выкупа? Она произвольна?
@raldin Произвольная, но есть ограничение сверху выставляемое делегатами.
привет. много полезных фич для тех, кто понимает. я спрошу конкретнее. если какой-либо автор срезает кураторские покупкой кита, к примеру, а куратор увидел это дело и хочет его отменить. что должен сделать куратор, не отягощенный знанием кода? может ли он что-то сделать?
@ladyzarulem, отменить - никак. Разве, что апвот снять.
Тут суть в другом. Автор не сможет теперь резать кураторские. Всё срезанное уйдёт или всё же кураторам, или мимо его кармана обратно в пул.
Теоретически, клиенты должны выставлять по дефолту в пользу пула. На мой взгляд. Хотя это довольно спорно.
Сам с собой спорю и не могу прийти к единому мнению. :-)
@ladyzarulem после 19 ХФ срезанные кураторские не будут оставаться у автора.
Автор может выбрать только два варианта куда их направить:
У автора не останется возможности единолично получить срезанные кураторские.
Если автор выберет - перераспределить - то куратор, увидевший это дело, может проголосовать после аукционного окна и получить долю срезанных кураторских, или (или все срезанные кураторские, если он проголосует один).
мне трудно представить такого технически оснащенного куратора, который будет в уме рассчитывать возможную выгоу и риски при апе в поисках жирных кураторских.
у нас есть два типа кураторов. первый тип апает то, что по душе и им все равно сколько они на самом деле получат обратно в СГ за счет курирования. вторый выставились на "бустерах" и указали свой ценник. собственно и им как бы все равно куда и как направляются кураторские.
есть горох (и еще парочка), кто кодит скрипты и анализирует и апает нужных авторов в нужное время, но такая игра не работает на длинной дистанции на самом деле. пиково можно и +300% сделать. а потом недобирать за счет курирования.
вы же говорите за тех кураторов нового типа, которого нет на голосе в первозданном виде. кроме того, апание в первые минуты поста необходимо для продвижения в топ. если цель автора будет заработок, то он будет покупать инвесторов за пределами штрафного окна в удобное для себя время.
и только те, кому ну почему то нужно вывести пост в топ - будут платить за это чутка больше, чем сейчас... а потом их креатор просто отфлагует, просто потому что ему так захотелось.
Отличные нововведения.