Відкрита децентралізована електронна система колективного прийняття рішень "Сила Довіри" / "The Power of Trust"

Hide all replies | Show all replies Original topic
3 Oct
Відкрита децентралізована електронна система колективного прийняття рішень "Сила Довіри" / "The Power of Trust"
#Ukraine
Концепція:
  • Open Source (відкритий код)
    10 May
    Код буде опубліковано на GitHub
    9 May
    Є пропозиція: український GitLab. Крім того, там репозиторій може бути приватним.
    10 May
    А є ще вагомі переваги, окрім приватності?
    Просто про GitHub більше знають і більше там мають аккаунти з ключиками.
    14 Jun
    Там можна вести пре-публічну розробку.
    20 Dec
    Проект не компілюється, тому після встановлення всі файли з кодом проекта, де вся логіка та алгоритми, є доступними для читання.
    Нічого не приховано, не зашифровано, не обфусковано.
    12 Jan
     Я предлагаю лицензировать https://creativecommons.org/licenses/by-nc-sa/3.0/deed.ru Опен сорс в чистом виде легко обходиться коммерческими компаниями. http://www.gnu.org/philosophy/who-does-that-server-really-serve.html
  • Децентралізація
    6 Nov
    Система буде працювати на базі однорангової мережі (Peer-to-Peer, P2P). Будь-яке централізоване рішення є ненадійним, бо найбільший вплив на таку систему (маніпуляції, атаки, цензура) матиме той, хто може вплинути на центральні сервера.
    18 Feb
    Барабаш Григорій: P2P ще більше вразливий до зміни інформації, а ніж серверно-клієнтська реалізація
    18 Feb
    Можете аргументувати це твердження?
    18 Feb
    Барабаш Григорій: при P2P кожний учасник мережі є її вузлом, який приймає участь в передачі і обробці інформації, яку можна перехопити, розшифрувати і змінити.
    При серверно-клієнтській реалізації кожний учасник отримує і передає меншу кількість інформації та не приймає безпосередньої участі в обробці інформації. І сервери захистити значно легше, а ніж всіх учасників системи P2P.
    18 Feb
    P2P-мережі бувають різні. Почитайте про blockchain і принцип public ledger у мережі Bitcoin. Там немає вказаних Вами недоліків, крім як слабкий захист окремих вузлів, який компенсується їх кількістю.
    Цілісність і коректність даних забезпечується синхронізацією єдиної бази між усіма учасниками мережі (аналогічно, як public ledger у мережі Bitcoin).
    20 Dec
    Чому не використовується технологія blockchain.
     
    Якщо використати систему блокчейна з майнінгом, то владу буде мати той у кого більше ресурсів і також, якщо буде рости складність, то дуже швидко звичайні громадяни не зможуть брати повноцінну участь у підтримці мережі.
     
    Саме тому у нашому проекті я працюю над системою консенсусу, яка не потребує майнінга, але там виграє просто той, хто підніме більше нод (тобто компутерів з виділеною ІР адресою). Наслідком є те, що будь-який громадянин завжди має технічну можливість підтримувати стійкість мережі. А завдяки суті яку я стараюся закласти в мережу (довіра) можна буде унеможливити захоплення мережі через піднімання великої кількості сторонніх нод, бо такі ноди будуть мати нульовий рівень довіри і ніхто до них просто не буде конектитися і таким чином не вдасться країні-противнику підмінити нам базу на змінену.
    9 May
    Тобто Ви хочете побудувати систему на кшталт Proof-of-stake, але з довірою замість монет
    9 May
    Деяка схожість ніби є, але все ж таки тут немає майнінга і нічого пруфити не треба. Просто якщо нода втрачає довіру — вона випадає з мережі і не може впливати на неї. Згодом просто буде, що нода = людина, тому й буде використовувати для цього рівень довіри до людини в мережі.
    9 May
    А що з конфліктами?
    10 May
    Система вирішення конфліктів ще має бути розроблена. Базуватися буде на тому, щоб приймати ті записи, які вже прийняті більшістю нод, яким ми довіряємо.
    . Ну, це дещо виправдовує введення "Довіри".
    Але я думаю краще використати для цих цілей якийсь публічний блокчейн, орієнтований на зберігання інформації. Наприклад, https://nxt.org/what-is-nxt/data-cloud/.
    9 May
    Проаналізуйте, чим краще.
    На мою думку використання чужого блокчейна дуже навіть хибний шлях.
    9 May
    Плюси:
    • більшанадійність збереження за рахунок більшої кількості учасників
    • більша стабільність і надійність за рахунок більшої команди розробників
    Мінус:
    • ціна. Але за все треба платити. В дпнному випадку - за надійність.
    Щоправда, є майже безкоштовний варінт: Storj -- точніше, там буде легко досягти 0 вартості при перевагах проекта з більшою спільнотою розробників.
    10 May
    Вказані плюси є тимчасовими, теоретично.
     
    А от, якщо взяти всі перелічені особливості проекта і проаналізувати, як саме їх можна реалізувати на вже існуючих платформах, то виходить 3 шлях:
    1. використати існуючу крипто-платформу типу Ethereum для реалізації як логіки роботи, так і збереження всіх записів;
    2. використати існуючий блокчейн чисто для збереження даних, а логіку реалізувати окремим сервісом, може навіть централізовано;
    3. зробити форк якогось open source проекта і реалізувати все поверх нього і запустити свою мережу;
    4. робити повністю своє рішення зі своєю незалежною мережею.
     
    Я особисто вирішив піти останнім шляхом.
    Мені відомо ще про один проект http://e-vox.org, який на скільки я розумію обрав перший шлях.
    Іншим прикладом є http://www.eauction.io, який пішов третім шляхом (але там поки суто аукціони).
    Кожен може приєднатися до того проекту, який йому більше до вподоби, або започаткувати свій.
     
    Я обрав перший шлях саме через повну незалежність і свободу у реалізації будь-яких задумів (про Ethereum чув у доповідях, як розробники впиралися в технічні обмеження).
    Надійність і стабільність на початку не є критична, а з часом і ростом кількості користувачів і команди вона має поступово зростати.
     
    А щоб не тримати цілодобово включеним свій домашній компутер я вже замовив з Кореї міні-компутер за 60$
    6 Nov
    ODROID C+ (з ARM-процесором, 32bit). Це є один з аналогів більш відомого Raspberry Pi
    25 Jul
    з 25.07.2019 система потребує 64-bit процесара та операційної системи.
    який стоїть біля раутера і цілодобово підтримує роботу ноди. Тобто я роблю ставку саме на кількість вузлів для підтримки цілісності мережі, а не на потужність.
     
    Якщо хтось запропонує краще рішення — з радістю реалізуємо.
    26 Mar
    Мені от не подобається блокчейн тим, що в ньому є місце для цензури: майнер одноосібно може вирішити не включати певні транзакції (записи в базі даних) у блоки і якщо такий майнер створює блок — то всі змушені його прийняти (бо не порушуються правила формування блокчейна). І якщо припустити найгіший випадок, то при достатніх ресурсах і везінні один майнер може довго не допустити появи в мережі наприклад певної публікації, чи блокувати дії певних осіб, тощо.
    26 Mar
    Алексей Аяхов:
    Майнер може вирішити, але його рішення не створить нового відгалудження чейна, якщо у нього немає більшості потужнсті, чи не так? В той же час, навіть в вашій реалізації більшість може змовитися і переробити базу, як хочеться?
    26 Mar
    >його рішення не створить нового відгалудження чейна
    В тому то й проблема, що його блок буде частиною основного ланцюга, саме це і приводить до цензури.
    >більшість може змовитися і переробити базу
    Це нормально і навіть може бути використано для вирішення деяких технічних проблем, чи конфліктів — ключовий момент, що більшість має бути згідна з такими змінами.
    Аналогічно і з блокчейном, його теж можна перебудувати при згоді держателів більшості потужностей, чи стейків (у POS).
    При POW це звичайно надзвичайно важко зробити, бо мережа орієнтується на ланцюг не тільки максимальний по довжині, а й по сумарній складності. Тобто переписати історію певної кількості останніх блоків — цілком реально, але чим далі по довжині назад, тим важче.
     
    У нашій системі не використовується блокчейн, у нас немає блоків, немає майнерів і відповідно немає можливостей для подібної цензури.
    18 Nov
    Важливо щоб система була максимально незалежною від будь-яких централізованих сервісів (не можна використовувати аккаунти існуючих соціалок, різні хмарні сервіси, тощо).
    Єдине, що я ще не можу децентралізувати — це висилання повідомлень (емейл, соціалки) з середини системи учаснику на вказану пошту (зворотній зв'язок, дайджести, повідомлення про фінансові операції). На початку таки буде центральний сторонній сервіс, який буде розсилати повідомлення.
    31 Dec
    Це коли система працює на багатьох компутерах одночасно і всі учасники є рівноправними (в ідеалі), тобто немає головного центрального сервера, немає якогось головного адміна з усією повнотою влади. Всі зміни в системі відбуваються по спільній згоді учасників і лише так.
    Здача такого технічного підходу — збільшення довіри до системи, так як є гарантія що у ній все відбувається максимально прозоро і чесно.
  • Делегування голосів
    20 Feb
    • про делегування
      3 Oct
      Сначало бы нужно решить вопрос: Сколько у человека голосов?
      3 Oct
      А как учитывается компетентность человека в вопросе? Ведь иначе (по схеме "один человек = один голос") так и будет профанация решения, а все хитрые перестановки и делегирования не выйдут за пределы статистической погрешности.
      3 Oct
      Базова пропозиція обговорюється тут.
      В системі буде створена відповідна задача і кожен зможе запропонувати своє рішення. А рішення за яке проголосує більшість буде реалізовано в системі.
      Если один - то он не может им пользоватся в других голосованиях, пока не будет известен результат госолосания, в котором он уже отдал свой голос.
      3 Oct
      Сейчас планируется один голос на каждый вопрос.
      Блокирование голоса до результатов голосования несовместимо с "всегда открытым" голосованием.
      3 Oct
      Согласен. Это так. Тогда нужно сформулировать условие, что чел может голосовать по решению разных вопросов неограниченное число раз, но при этом голос во всех голосованиях у него будет всегда один
      3 Oct
      Так и будет, засчитывается только последний голос по вопросу. Это обязательно будет указанно в правилах.
      3 Oct
      Тут есть ловушка: Если будут проводится голосования по одной и той же проблеме, но на разных страницах голосований и с разными способами решения этой проблемы, то голосующий может проголосовать на этих станицах голосования прямо противоположно
      3 Oct
      По ідеї не має бути такої ситуації:
      1) альтернативні рішення мають бути додані до можливих рішень у першій задачі (буде можливість запропонувати нове рішення)
      2) якщо задача дублює існуючу, то вона буде замінусована і зникне з загального списку.
      3 Oct
      Второе, что нужно решить: Какая сила у голоса может быть? У людей если человек шепчет, то его мало кто слышит. А если голос громкий - то вся толпа ему внимает. Мне кажется, что и тут так должно быть: чел сам должен решать, какую часть своего полного голоса он проявляет.
      3 Oct
      При обычном голосование за один из вариантов такого напрямую нет, но при варианте голосовании по методу Шульце (автор голосование выбирает тип), такое присутствует неявно (через ранжирование).
      Другой аспект — голосование за аргументацию: уже есть возможности голосовать за силу аргумента за/против указывая силу (от "незначительный" до "критический").
      3 Oct
      Рейтенговое голосование ( деление голоса между несколькими вариантами в разных соотношениях) позволяет более точно учесть предпочтения голосующих. Не отданная "часть голоса" ни за какой вариант - просто не учитывается. такой вариант рассматривали?
      3 Oct
      Ще ні. Дякую за пропозицію.
    • Можливість делегувати свій голос особі, якій Ви довіряєте і вважаєте, що вона більш компетентна у даному питанні.
      3 Oct
      Той, хто хоче, аби за нього голосували, буде намагатися всіма засобами втертися у довіру до людей, так само як це роблять звичайні шахраї. Голосування робить довіру товаром, який коштує конкретну суму грошей (досить велику).
      3 Oct
      Не думаю, что один человек, сможет обмануть многих, при равных условиях обмана всеми кандидатами.
      А если это доверие будет собиратся постепенно, а не только в выборную компанию, то набать себе много доверителей будет сложно - не хватит ни денег, ни обмана.
      3 Oct
      Скажем, при выборах мэра - хвалебные статьи и реклама на ТВ, создают неравные условия. Это и решает исход голосования, а не подтасовки (процент которых относительно невелик).
      3 Oct
      Чтобы выбрать своего "делегата" нужно представлять, какие области захватывает решение Вопроса, и нужен Реестр спецов по всем отраслям.
      3 Oct
      Так це буде серйозною проблемою. Проти цього передбачена можливість переделегування і зниження довіри делегату, якщо він себе дискредитував. Відновити довіру в такій системі буде важче ніж здобути.
      Звичайно це породжує широкий простір для підстав, провокацій, популізму і чорного піару. Але ми і зараз це маємо тільки без можливості на щось вплинути, окрім як голосування раз на 4-5 років. А в запропонованій системі як мінімум цього інтервалу можна позбутися.
      3 Oct
      Так проблема вирішується елементарно:
      - голоси делегуються окремо по категоріях (наука, освіта, економіка, оборона та ін.)
      - завжди можна спостерігати, як голосує твій голос/делегат
      - можливість в будь-який момент змінити свій голос, доки триває голосування. Для різних стадій (ініціаціатива, обговорення, прийняття рішень) час на голосування може відрізнятися.
      - можливість в будь-який момент відібрати делегований голос у делегата
      Намахати вдастся лише раз
      3 Oct
      Чтобы выбрать своего "делегата" нужно представлять, какие области захватывает решение Вопроса, и нужен Реестр спецов по всем отраслям.
      3 Oct
      Делегування голосу - це системна помилка, а її впровадження в такий інструмент - то є переніс вад традиційної представницької демократії в інструмент електронної демократії. Голос має бути завжди персоналізований, а його вага мала б бути різною за номіналом, відносно рейтингу експерта. якщо людина нічого не розуміє у медицині, но нічого їй і брати участь у прийнятті медичних рішень.
      3 Oct
      Так, є так різні погляди у цьому питанні. В ідеалі хотілося би взяти лише найкраще з кожного підходу.
      По цьому питанню буде проводитися голосування у системі, і відносно прийнятого рішення будемо розвиватися відповідний напрямок.
       
      У початковій версії системи вже є реалізовано лише просте делегування, навіть без коефіцієнту по втраті ваги голосу. Воно дійсно на практиці є безтолкове на мою думку, але треба з чогось почати.
      Професійні рівні — складніша задача, але дуже пріоритетна, тому над нею працюватиму найближчим часом.
      3 Oct
      Взагалі, коли я тільки починав працювати над проектом, багаторівневе делегування здавалося дійсно класною ідеєю, але коли глибше занурюєшся у проблеми прийняття якісних рішень стає зрозуміло, що таке делегування може просто привести до того, що виграє не голос кращого експерта, а просто того у кого більше друзів/знайомих, справжніх/проплачених, чи просто хто більш публічний (кого більше рекламують у ЗМІ) — виходить той самий цирк, що маємо зараз перед виборами…
       
      Я думаю, що ми розробимо більш адекватні методи зважування голосів і в результаті у системі не буде ніякого делегування голосів взагалі.
      19 Apr
      Ось дане питання на обговоренні у системі — Можливість делегування голосу (Liquid Democracy)
      3 Oct
      Считаю что не следуют вводить коэффициенты и органичения на количество набираемых голосов. Делегирование не призвано исправить/улучшить качество голосования, а ускорить/оптимизировать/автоматизировать его естественный демократический процесс.
      Если я постоянно голосую как человек которого я для себя определил авторитетом в каких-то вопросах. То делегирование - экономит мое время и время других. Я могу сконцетрироваться на обсуждение других вопросов, в которых специализируюсь и другие могут меня уполномочить голосовать от их имени. Делегирование - это не что иное как народная сертификация специалиста, эксперта. В идеале по вопросу будут собираться только эксперты с весом в тысячи голосов, обсуждать и решать вопрос.
      3 Oct
      Как показывает практика социальных сетей подписыватся на страницу тысячи, лайки ставят сотни, оставляют коменты десятки, а из этих десятков коментов только единцы имеют какой-то смысловой вес. Для принятия решения должны использоваться принципы поэтапности и выбывания аргументов из игры, что можно увидеть на примеры игры "мафия". Необходимо ввести активные сессии и сессии обсуждения. "Мафия" отличный полигон для демонстрации сути процесса.
      3 Oct
      То что вы говорите - это умозрительные суждения, вызванные страхами. Я предлагаю сначала использовать делегирование в читом виде, в большей степени как "ускоритель" процесса голосования. Затем иследовать как оно получилось и если нужно вводить коррективы. А троить химеры с самого начала - это сразу пусть в один их многих тупиков.
      3 Oct
      Тот, кому делегированы голоса, должен голосовать всей их массой. Если ему доверяют 294857 человек - его вклад при подсчёте голосов составляет 294857 плюс 1 (его личный). Никакого переделегирования быть не должно. Каждый должен иметь право либо отдать свой голос эксперту, либо голосовать самому. Иное приведёт к полному размыванию ответственности (а я верил этому, а тому я не верил... и так далее).
      3 Oct
      Раз согласия по этому моменту нет, то следует оставить это на выбор пользователям. При делегировании нужно будет выбрать подлежит ли переделигированию голос или нет.
      Не будем же мы ущемлять демократические свободы и ограничивать потенциальную эффективность делегирования.
    • Делегат може також делегувати усі довірені йому голоси ще більш компетентній на його думку особі.
      3 Oct
      Считаю, что нельзя допускать переделегирование, может возникнуть конфликтная ситация, а на мою думку, сама "живая демократия" является инструментом, котрый создан чтобы исключить саму возможность возникновения конфликта интересов.
      3 Oct
      Если я не имею четкого мнения по "данному" воросу и звоню специалисту/доверному лицу - то имеете ли вы прово меня ограничивать? Делегирование только лишь ускоряет мой свободный выбор использовать опыт/знания других.
      Конфликт интересов в свободном обществое останется всегда. Исключить конфликт интересов можно либо в тоталитарном обществе (где любые другие интересы исключаются) либо в конесенсусе - что возможно только в ограниченных сообществах.
      3 Oct
      Михайло Петелицький: можливість делегування другого рівня - коли делегат далі делегує свої голоси може призвести до корупції і тиску на делегатів. + людина, яка делегує свій голос делегатові не завжди може довіряти тій іншій людині. Тут виникатиме конфлікт інтересів.
      3 Oct
      Можливі рішення:
      1) Якщо людина побачила, що її голос пішов не туди, куди вона хоче (про кожен рух має бути хоч якесь повідомлення) то вона завжди може відкликати свій голос і перенаправити. Конфлікт вирішений.
      2) Кількість рівнів делегування зробити динамічною змінною і визначати її значення завжди відкритим голосуванням. Тоді, якщо більшість буде за обмеження делегування одним рівнем, — так і буде автоматично без переробок у системі. Конфлікт вирішено.
       
      Вважаю багаторівневе делегування корисним, бо нерідко ми знаємо людину, яка не є експертом по питанню, але знає таких і ми розраховуємо на те, що вона краще розібралася у тих людях за нас.
      Це майже те саме, якби ця людина порадила нам кому делегувати свій голос по цьому питанню. Звісно, порада таки краща, але забирає час у обох сторін, а довіра через делегування його економить обом.
      3 Oct
      функція "порадити експерта", або "запросити експерта" - зовсім відмінна від делегування. Ще раз - делегування зло. Не можна деперсоналізувати прийняття рішення, волевиявлення. Але треба дозволити оцінювати ідеї, та пропонувати свої: аналог like. тільки різний за вагою.
    • Якщо та особа втратила Вашу довіру, можете передати свій голос іншій людині, або проголосувати за питання напряму (якщо є допуск).
  • Підтримка трьох типів голосування
    3 Oct
    • відкрите (всім видно хто як проголосував)
      3 Oct
      Унікальність і непідробність голосів забезпечується цифровим підписом.
    • таємне
      19 Jun
      Таємність забезпечується процедурою, яка має назву "сліпий підпис".
      Варіант реалізації протоколу такого голосування описано у цьому відео.
    • змішане (делегування таємне, делегат голосує відкрито)
  • Завжди відкрите динамічне голосування
    18 Nov
    Голосування може бути не обмежене в часі і в будь-який момент кожен хто проголосував може змінити свій голос на користь іншого варіанта, або запропонувати новий.
    15 Feb
    Если есть голосование без ограничения времени, то нужно предложить и другую крайность - одномоментное голосование. Все желающие проголосовать по вопросу должны сделать это в определённое время, в течении 5 мин(например). Это будут и показателем количества людей, которых этот вопрос интересует по настоящему.
    19 Apr
    "голосование без ограничения времени" — згідно цього голосування буде введення обмеження в часі на голосування, після його рішення буде прийнято на основі наявних голосів.
     
    Завжди відкрите голосування — це про те, що якщо з часом людина змінює думку, або ситуація по задачі міняється, то людина завжди може змінити свій голос і якщо буде змінено достатньо голосів, то і прийняте рішення може бути змінене.
     
    Задати час голос у 5 хв — не проблема, але ж неважко передбачити і наслідки такого обмеження :)
    7 Dec
    про "5 хвилин" - цікаво було б на такий випадок зробити поза системою (окремо, але в межах вікна) сервіс відеоконференції. Наприклад використати фрейм ooVoo (безкоштовно до 12 учасників). Таким чином ми маємо живу нараду малої групи з рішенням захищеного інструменту відкритого чи скритого голосування.
    7 Dec
    Живе обговорення — це прекрасно, але на мою думку краще коли від обговорення є слід, по якому потім можна шукати, цитувати і вказувати на слова з цифровим підписом — тоді людина буде відчувати що за слова потрібно відповідати.
  • Системи голосування
    15 Apr
    • Проста більшість
      7 Jul
      • Проблеми
        7 Jul
        • Парадокс Кондорсе
          7 Jul
          • Популярно о парадоксе Кондорсе (стаття на Хабрі)
            7 Jul
            Можно голосовать не за тех, кто нравится, а за тех кто не нравится по методу убывания, тогда действительно останется сильнейший. Это может изменить ход голосования.
      • Критика
        7 Jul
        Victor Semenov:
        Голосование как способ принятия решений - самый худший из всех возможных методов принятия коллективных решений. Даже выбор решения простым подбрасыванием монеты, и то в среднем даёт лучшие результаты. Но существуют и более эффективные методы.
        —> Гліка дискусії у FB-групі
    • Метод Шульце
      17 Feb
      Реалізовано і використовується для голосування за кандидатів на посади, за пріоритети фіч для реалізації, тощо.
      Гарна штука, але є проблема з візуалізацією результатів — важко зрозуміти, чому саме такі позиції. Над цим треба щоб більше голів попрацювало ніж одна.
      17 Feb
      З обговорення у FB (12.02.16):
      Dmytro Ivakhnenko:
      Знайшов таку обгрунтовану пропозицію:
      > As the trust in the ranking method is a bit stressed now, I am working
      > on a visualization of the voting result that makes the used Schulze
      > method a bit more approachable. However, I failed to find a detailed
      > description of the used method beyond the actual code in core.sql. I am
      > aware of the page [2], but I have some questions:
      I just added a paragraph to page [2]:
      "Note: There are different proposals how to define the strength of a
      pairwise link for the Schulze method. We use a measurement primarily by winning votes and secondarily by the opposing votes as recommended in chapter 6 of Markus Schulzes paper linked below."
      m-schulze.webhop.net/schulze1.pdf [5]
      Джерело — http://dev.liquidfeedback.org/pipermail/main/2012-October/000228.html
      Наскільки я розумію, автор пише про те, що варто відображати кількість переможних голосів та кількість голосів проти.
      Юрій Бабак
      Дякую за такий грунтовний комент!
      З наведеної переписки я дізнався що є два підходи до вирахування результатів: в одному використовуються лише win-голоси N[e,f], а в іншому (рекомендованому в основному документі) використовується ще додатково вирахування голосів проти, тобто сили зворотного шляху N[f,e]. Але я таки не розумію ключову фразу в тому документі "some voters cast only a strict weak order because of strategic considerations", не вистачає приклада такого голосу.
      Хотілось би знайти приклади голосів, які дають різні результати при застосуванні цих двох підходів, тоді я би перевірив як працює та бібліотека, яка зараз використовується.
      Але, повертаючись до суті задачі, ті неявні голоси проти (бо людина формує один рейтинг) використовуються виключно для розрахунку результатів і взагалі не фігурують у самих результатах. У результатах є кількість виграшів у парах кожен-з-кожним, я кількість програних пар це завжди кількість усіх пар мінус кількість виграних пар.
      То ж ще один з можливих варіантів рішення — показувати прямо те що видає метод, кількість виграних пар. Зараз додам тоді…
    • Жеребкування
      7 Jul
      Есть ещё один способ голосования - жеребьёвка. Это очень неплохой способ для выбора технических должностей, судей и пр. из зруппы заявленных кандидатов.
      7 Jul
      Жеребёвка не всегда соответсвует принятию правильного выбора и в случае с судьями не должна браться за основу. В идеале судья должен устаривать каждую из сторон и только перебрав все варианты, чтобы не идти по кругу, необходимо использовать жребий. К примеру при голосовании за мирового судью мы голосуем за тех кто нам не нравится, отбраковывая их, тем самым выбирая пару или трио которые не нравятся меньше всего, а только потом можно кинуть жребий.
      7 Jul
      Так, але при умові, що кандидати більш-менш рівні по професійному рейтингу.
      7 Jul
      Конечно. Например, судей, экономистов, конкретных специалистов
    • Пропозиції:
      15 Apr
      • Решение принимается при достижении консенсуса нескольких ведущих экспертов из числа всех участников (Victor Semenov)
        15 Apr
        Victor Semenov:
        Мне представляется идеальной такая процедура, в которой могут участвовать все желающие (кому интересно, кого затрагивает вопрос). Но решение принимается при достижении консенсуса нескольких ведущих экспертов из числа всех участников. (Не общий консенсус, а только ведущих экспертов, в пределе может быть даже решение одного эксперта).
        Процедура должна выбрать, выделить ведущих экспертов в данной теме, в данном конкретном вопросе, а не вообще "экспертов по всем вопросам". Предыдущие рейтинги могут учитываться как вспомогательные. Но в идеале процедура должна ранжировать экспертов в каждом данном вопросе заново, как бы с чистого листа.
        Ранжирование (рейтингование) экспертов - расстановка их по порядку убывания их компетенции, опыта, квалификации в данном решаемом вопросе. Ранжирование основывается только на взаимных оценках экспертов, и ни на чём кроме взаимных оценок. Это важный принцип, дающий некоторую степень объективности. После проставления взаимных оценок должен использоваться алгоритм (в виде компьютерной программы), который очистит массив оценок от субъективизма, от "договорняков" и от популизма, максимально насколько возможно очиститься от популизма. Некоторая доля популизма всё равно останется, это свойственно социальному поведению человека, и никакой алгоритм не отделит до конца популизм от объективного мнения. Но в значительной степени популизм можно отфильтровать алгоритмически.
        После такого ранжирования, голосование экспертов (тем или иным известным методом) даст максимально возможную объективность решения.
        Ранжировать экспертов будут эксперты. Такой алгоритм "самооценки" экспертов может быть вполне рабочим.
        Представим себе, что идёт обсуждение темы, и в ней высказались, обозначили свою позицию N человек. Предположим, это число 50 < N < 500
        После нескольких дней обсуждения все принципиальные мнения высказаны, аргументы за/против выложены и приняты/отвергнуты участниками.
        По итогам прений каждый участник оценивает экспртный уровень (компетентность, опытность) других активных участников. (Неактивные слушатели/зрители не участвуют в оценивании). Получается матрица 500х500. Эта матрица обрабатывается алгоритмом и выявляются несколько супер-экспертов, самых влиятельных в данной дискуссии. Это будет три-четыре человека, ну иногда 5.
        Эти лидеры дискуссии между собой договариваются и приходят к консенсусу, или если договориться не удаётся, применяется одна из известных процедур голосования.
        Оценивание экспертов - это промежуточный рабочий момент, я всё время подчёркиваю, что экспертами они называются и оцениваются только в рамках текущего решаемого вопроса. Это НЕ усреднённый рейтинг, а местный, по случаю, ad hoc.
        Результатом этой процедуры будет не рейтинг, а РЕШЕНИЕ вопроса, проблемы. Частным результатом могут быть оценки идей, селекция и синтез идей. Это всё входит в как частности, но главный результат, на мой взгляд, всё таки решение. Есть интересный пример: Риззома Сергея Жигинаса. Там собраны все идеи и разложены по полочкам. Но там нет решения в явном виде, каждому предлагается самому сделать выбор и принять решение. Система не имеет субъектности.
        Мне думается, что ранжирование экспертов - важный и необходимый шаг к субъектности. А иначе это всё не имеет значения. Царь горы никому не интересен, если он не решает проблему.
        —> Це коментар у FB з повним обговоренням
        15 Apr
        Толкова конкретна пропозиція алгоритму.
        На мій погляд її не важко буде реалізувати і задіяти в якості експерименту. В системі вона буде жити в якості опції, щоб в межах групи, чи для окремих задач можна було вибрати саме такий шлях відбору рішення.
        Те що в нас зараз рішення приймаються загальним голосуванням — це звичайно ж лише початок, хто читав наш концепт-документ, той в курсі.
        5 Jun
        Ми також працюємо над подібною моделлю - багато чого, беремо з Социократії 3.0 - https://sociocracy30.org/_res/posters/S3-Intro-Posters-ru.pdf
      • Wright system (PR-STV)
        15 Apr
        А може хтось сформувати список переваг і недоліків цього підходу?
      15 Jul
      • Консенсус
        16 Jul
        принятие решения на основе общего согласия, если против него никто не выступает, либо при исключении мнения немногих несогласных участников. Например: Единогласно минус два (или Е-2) не позволяет двум индивидуумам блокировать решение, но в таком случае разрешить противоречие удаётся быстрее. Несогласная пара может представить на рассмотрение своё альтернативное мнение о том, чем, плохо решение. Паре даётся возможность найти общий базис и склонить на свою сторону третьего участника, чтобы блокировать решение. Если в течение установленного времени третий к ним не присоединяется, их аргументация рассматривается как неубедительная.
      • Консент
        15 Jul
        как в Википедии, когда один участник предлагает свой вариант, другие участники могут его менять, дополняя, меняя или оставляя в изначально предложенном варианте - последняя актульная версия всегда будет считаться окончательным решением, принятым методом Консента (без возражений).
    17 Feb
    Количество голосов у одного голосующего при рейтенговом голосовании предлагаю сделать равным N+1, где N - количество вариантов решений. Тогда визуализация должна идти от сравнения поданных за вариант голосов к общему возможному числу от количества проголосовавших.
    17 Feb
    • Чому саме N+1?
    • Чим такий метод кращий за метод Шульце?
    20 Feb
    N+1 не позволит всем вариантам отдать одинаковое количество голосов. Хоть один вариант должен будет выделен как особый.
    28 Feb
    Ещё один из способов - присоединение к мнению эксперта. Несколько экспертов дают своё заключение по тому или иному варианту решения, а голосующие присоединяют свои голоса к выводу того или иного эксперта.
    15 Jul
    для этого нужны экспертные группы/команды.
    Типа делегирования
  • Рейтинги експертів
    20 Dec
    • В системі буде створена відповідна задача і кожен зможе запропонувати своє рішення. А рішення за яке проголосує більшість буде реалізовано в системі.
    Базова пропозиція:
    Пропонується можливість підтверджувати професійний рівень інших людей з метою виявити більш компетентних людей по різного роду питаннях.
    Ці рівні впливають на те, чи буде людина мати право прямого голосу у питанні де встановлений допуск по рівню професійності.
    Визнання найвищого рівня професійності може бути отримане лише від учасників системи з середнім рівнем у цій же професії, середній від початківців, а рівень початківця може вказувати кожен учасник системи. Вага визнання отримана від професіоналів вища за визнання від початківців. Таким чином підвищується адекватність визнання професійних рівнів.
    28 Jan
    Лично я не согласен с такой постановкой вопроса. Должен быть предложен спектр вариантов и возможно, что профан предложит такой вариант, котрый эксперты никогда не увидят. Другое дело, что должно быть "экспертное сито" паредварительного голосования на соответсвие основным китериям.
    7 Jul
    • Детальніше про задачу відбору експертів
      18 Apr
      Victor Semenov (тут):
      Резюмирую кратко, в виде теоремы:
      >> "экспертом" по любому вопросу я готов считать любого гражданина, независимо от его регалий и базового образования, кто предложит наилучшее решение рассматриваемого вопроса
      19 Apr
      Это абсолютно не обязательно, чтобы быть экспертом. Возьмем 10 архитекторов - если один из них победил в конкурсе, остальные что, перестали быть архитекторами? Завтра может победить другой из той же 10-ки.
      Чтобы все стало на места - достаточно слово "наилучшее" заменить на "компетентное" или "правильное".
      15 Feb
      Поддержу Юрия. Порой не профессионал может предложить лучшее решение на стыке отраслей знания.
      А кто оценивает предложенные решения и выбирает НАИЛУЧШЕЕ ? Вот и опять без экспертов никак не обойдёмся, и опять мы упираемся в проблему: кто тот самый главный эксперт, который отбирает экспертов?
      Доказательство теоремы:
      Сколько бы вы не кружились вокруг темы, неизбежно придёте к следующему:
      • Необходима процедура общественного отбора экспертов из большого числа претендентов.
        18 Apr
        Також потрібно визначити хто і як може стати претендентом.
        21 Apr
        Victor Semenov: По мне так никаких ограничений быть не должно. Любой кто не бот и зарегистрировался под настоящим своим именем может участвовать в рейтинговании экспертов, изначально все участники равны.
        15 Feb
        Поддерживаю Семёнова. Кроме его условия. Считаю, что в рейтенговании могут участвовать все, выразившие желания быть кандидатом в эксперты.
      • Отбор лучшего эксперта должны произвести другие эксперты, а поскольку мы отбираем лучшего, то все остальные по определению менее компетентны чем отбираемые.
        18 Apr
        Як бути на початку, коли ще немає жодного експерта, і є лише претенденти (це якщо механізм висування претендентів не потребує погодження експертів)? Звідки мають взятися перші експерти для оцінки претендентів?
        21 Apr
        Victor Semenov: Исходно нет различия эксперта от кандидата в эксперты. Поэтому для простоты будем считать экспертами (первого уровня) всех зарегистрированных. Процедура отбора должна быть работоспособна на очень большой численности участников, например десятки тысяч захотят участвовать в решении.
        28 Jan
        В итоге всёрвно появится пул экспертов, котрые будут предлагать решения, котрые могут в период обсуждения компелироваться и итоговые несколько будут представлены на голосование. Как на мой взгляд надо не браться за такое масштабное и глобальное предприятие, как заставить семь миллиардов решать какого цвета должен быть стульчик у дочки Мери Попинс. Есть разные уровни делегирования и принятия решений, от этого и надо отталкиваться. Многокомнатная квартира - Подьезд - Многоквартирный дом - Тер.громада - Рай.громада - Обл.громада - Высший уровень. Для каждого уровня должны быть разичные правила игры.
      • Менее компетентные в принципе не могут объективно оценивать более компетентных, иначе они сами были бы лучшими.
        18 Apr
        Об’єктивно в принципі не може оцінювати ніхто. Будь-яка оцінка є суб’єктивною апріорі.
        22 Jan
        Абсолютно объективных оценок не бывает, все оценки субьективны. Но есть более и есть менее субьективные.
        Якщо з твердження забрати слово "объективно" то воно стає дуже сумнівним, тому що не є важко визнати, що хтось краще за тебе розібрався у питанні, і для цього не треба бути кращим експертом.
        22 Jan
        Вы можете только догадываться о том, насколько кто то лучше вас разбирается в задаче. Допустим, он владеет знаниями в бОльшем обьёме чем вы. Но вы не знаете насколько важны и существенны те знания, которыми он владеет, а вы не владеете. Тем более вы не можете оценить практический опыт, которым вы лично не владеете. Поэтому оценка более компетентного эксперта всегда очень приблизительна. Наоборот, тот кто более компетентен чем вы, может оценить ваш уровень компетентности с более высокой точностью и объективностью.
        Відповідно це твердження можна забрати зі списку.
        21 Apr
        Victor Semenov: Согласимся что нет полностью объективных оценок. Будем говорить об относительно объективных. В таких терминах я настаиваю, что эксперт относительно низшего уровня не может дать точную оценку эксперту более высокого уровня, то есть в этой ситуации оценка недостоверна. А в обратную сторону - может, и такая оценка сверху вниз будет более объективна.
        17 Feb
        Да, менее компетентный не сможет оценить в баллах более специалиста более высокого ранга, но каждый может всегда указать какой спец круче его. Т.е. дать ответ на вопрос: "Я слабее кандидата А?" может каждый.
        22 Jan
        Да, может. Вот я могу признать, что Сергей Дацюк лучше меня разбирается в философии. И что? Ценность такого признания => 0.
        А обратно, Дацюк может оценить мои философские способности с очень высокой точностью и надежностью.
        22 Jan
        Ценность идеи (особенно в общественных вопросах) мало зависит от квалификации "экспертов", даже очень хорошие ученые ограничены научным методом
        22 Jan
        в системе которого работали десятки лет
        и им трудно придумать что-то НОВОЕ, которое за этими рамками
        22 Jan
        называется "профессиональный кретинизм"
        .
        17 Feb
        Пропонується, що наприклад професіонал 3 рівня може оцінювати інших в межах 1-4 рівня, тобто в межах своєї компетенції. Мається на увазі, що така людина не може якісно відрізнити професіонала 4 рівня від 5.
        22 Jan
        Предлагаю посмотреть сериал "Черное зеркало" Сезон 3 эпизод 1 "Пикирование", где очень хорошо показаны взаимоотношения людей в условиях массового использования социального рейтинга.
        22 Jan
        Есть там и взаимное повышение/понижение рейтинга друг другу
        22 Jan
        Так, вона справді гарно показує, як примітивна загальна
        22 Jan
        в узком кругу специалистов конкуренция часто более жесткая, чем в обществе
        рейтингова система може перетворити життя людей в пекло.
        21 Apr
        Тут ключовим вважаю слово "точную". Точну оцінку експерт нижчого рівня справді не може дати. Тому я і пропоную, щоб експерти нижчого рівня могли підтверджувати вищий рівень з обмеженням (людина 1 рівня може більш-менш достовірно підтвердити учасників 2-3 рівня), інший шлях — може вказати будь-який рівень від 1 до 5, але вага такої оцінки буде відповідна (чим більша різниця рівнів тим менша вага такої оцінки).
        Які будуть ще пропозиції що до оцінки знизу вверх? Заборонити ставити вищі оцінки не можна, бо тоді не буде звідки взятися експертам вищих рівнів.
        21 Apr
        Victor Semenov:
        >людина 1 рівня може більш-менш достовірно підтвердити учасників 2-3 рівня
        Чем больше разность уровней, тем меньше достоверность, (или я бы сказал относительная объективность оценки). Но мы не знаем априори эту разницу и не можем оценить достоверность оценки.
        Алгоритм нужно строить от предположения, как если бы мы уже имеем относительный рейтинг экспертов. Поэтому мне кажется лучше не устанавливать условные уровни от 1 до 5, а строить относительный рейтинг в виде нумерованного списка от 1 до N.
      • Эксперт может достаточно точно оценить своего коллегу близкого по экспертному уровню, то есть по опыту, квалификации, мастерству.
        18 Apr
        Тут згоден. Але вважаю, що експерти також можуть легко розпізнати і дилетанта, а не тільки близького по рівню експерта.
        Тут також бачимо що пропонується такий термін як "експертний рівень" і що він ділиться на складові: досвід, кваліфікація, майстерність.
        Питання:
        1. потрібен вичерпний набір цих складових;
        2. потрібно визначити, які значення може набувати кожен параметр;
        3. для ранжування зручно виводити узагальнене значення "експертний рівень" базуючись на складових, як це робити? Можна просто сумувати, брати середнє значення, і можна вводити % впливу кожної складової на це значення.
        15 Feb
        Можно заставить каждого претендента в эксперты оценить знакомых ему специалистов по отношениию к себе. Если мой уровень = 0, то кандидат А слабее меня= -1, а кандидат Б сильнее меня = +1
      • Статистически такие оценки могут быть выделены из большого массива взаимных оценок, и на их основе можно построить правдоподобный рейтинг экспертов в некоторой сфере практической деятельности (в профессии или специализации).
        18 Apr
        Як бути з недобросовісними учасниками, які не дають, або занижують оцінки тим кого вважають своїми потенційними конкурентами?
        21 Apr
        Victor Semenov: Эта проблема снимается если использовать двухсторонний балансирующий алгоритм расчета. Недобросовестный эксперт сам себя опускает, и вносимое искажение уменьшается, становится малозаметным.
        21 Apr
        Є десь описаний такий алгоритм?
        21 Apr
        Victor Semenov: У меня была попытка построить такой алгоритм, но он не показал хорошую сходимость. Полагаю, что причина неудачи не в качестве алгоритма, а в том что рейтинг экспертов по своей природе не плоский, он плохо выстраивается в линейный список. Мне удалось построить пронумерованный по порядку список, но при малейшем изменении исходных данных многие эксперты передвигаются на несколько позиций вниз-вверх по списку. В целом алгоритм работоспособен. Но мне такой результат кажется неудачным.
        Что до вопроса о недобросовестных экспертах, то на реальных примерах получается так: одна заниженная оценка слабо влияет на позицию оцениваемого, но заметно понижает оценивающего. Завышенные оценки слабо влияют на результат.
      • Невозможно доказать, что построенный по такому методу рейтинг является объективным, потому что в основе рейтинга лежат субъективные оценки. Но можно предполагать, что такой рейтинг будет более эффективен для решения практических задач, чем референдум или выборы.
        19 Apr
        по такому принципу изобрели гильотину, чтобы жертва меньше мучалась. )
        Если референдум или выборы не решают поставленную задачу - надо от них отказаться, а не улучшать "нерешения".
      18 Apr
      Саме через те що це є краще ніж те що маємо зараз і ведеться робота в цьому напрямку.
      Для початку в нашій системі буде реалізовуватися простіша схема без складових (досвід, кваліфікація, майстерність), тільки загальна оцінка рівня експерта числом від 0 до 5.
      При цьому будь-хто може заявити про себе, що він є наприклад експерт 4 рівня у певній галузі, і також буде можливість вказати детально аргументацію (посилання на публікації, наукові роботи, виступи, тощо) — так з в'являються претенденти. Але без підтвердження іншими ця самооцінка нічого не значить (або майже нічого), це тільки орієнтир і сигнал для інших учасників дати свою оцінку цій людині.
      В результаті подальших взаємооцінок формується середнє значення (або медіана) рівня експерта для кожного учасника у кожній галузі в якій він себе засвітив.
      Буде введено просту стратегію обмеження: будь-хто може підтвердити (оцінити) людину лише як експерта 1-2 рівня (людина цікавиться, давно цікавиться і щось пробує — це не важко будь-кому підтвердити). Далі ця група експертів 1-2 рівня може вже між собою оцінювати вищого рівня експертів (3-4), і вже ці останні зможуть між собою оцінювати рівні (4-5). В зворотному напрямку немає обмежень, навіть більше, якщо експерт 4-5 рівня оцінює когось, то вага такої оцінки значно вища за оцінку учасників системи нижчого рівня (це може допомогти опускати накручені рейтинги).
      Отримані рівні експертів будуть використовуватися для встановлення допуску до голосування по певним питанням. Також вони можуть бути використані для розрахунку ваги кожного голосу (вищий рівень — більша вага).
      4 Feb
      Для інформації гляньте цю статтю "Сказ царя Салтана о потенциале лапласиана"
      Там математика, але суть зрозумієте, що це є базовий алгоритм, який може забезпечити адекватність ваги голосів і захист від накруток.
    • Критика рейтинга
      21 Apr
      Dmytro Ivakhnenko (тут):
      В современной модели нет и не может быть некого единого централизованного "рейтинга" экспертов. Об уровне экспертизы судят, исходя из неформальной репутации, личных, человеческих оценок сведущих в проблемной области людей. И тут важнее не процедура отбора, а прозрачность диалога, и обоснованность аргументов, по поводу экспертизы.
      Поэтому, на мой взгляд, прежде всего стоит начать с прозрачности, обеспечив способы, с помощью которых можно было бы легко узнать, на основании каких именно критерииев, и исходя из каких достижений, те или иные люди считают того или иного человека экспертом.
      21 Apr
      А є пропозиція методу більш прозорого і надійного ніж той який я поклав в основу системи (децентралізація з повним доступом для кожного учасника мережі)?
      Там при оцінці людини треба буде аргументувати чому і за що, і відповідна перегляд цієї оцінки буде доступний кожному.
      Що до "прежде всего" — багато хто мені радив не паритися з p2p, а зробити просто сайт, але для мене принципово щоб система будувалася саме на основі прозорого методу ведення бази даних, тому я таки пішов непопулярним шляхом і не жалію.
      21 Apr
      Dmytro Ivakhnenko:
      Описаний Вами метод перегукується з системами на зразок "Відкритих відзнак" Мозілли
      , які є дуже перспективними. Саме такі розподілені системи вибудовують прозорість як підгрунтя довіри.
      И обязательно разделить экспертную оценку и принятие окончательных решений
      21 Apr
      А як саме розділити? Можете розписати механізм?
      Наприклад якщо експерти видають тільки оцінки і заключення, а голосують усі люди, то треба врахувати, щоб для читання і розуміння результатів праці експертів потрібно володіти певним багажем знань, і в більшості людей його немає.
      21 Apr
      Dmytro Ivakhnenko:
      Мені, наприклад, подобається ітеративний підхід у Клімат Колаб http://climatecolab.org/about при якому експерти дають свої зауваги та поради для другої ітерації розробки пропозицій.
      Загалом розробка пропозицій - кропітка праця, якою займаються не випадкові люди. На платформі збираються люди, які розбираються в темі. Тому, коли експерти надають аргументовані зауваги, з якими усі можуть ознайомитись, то загальне голосування учасників може призводити до прийняття високоякісних рішень.
      21 Apr
      >коли експерти надають аргументовані зауваги, з якими усі можуть ознайомитись, то загальне голосування учасників може призводити до прийняття високоякісних рішень
      Ну не вірю я в це. Простий реальний приклад: потрібно обрати шлях генерації пари приватний-публічний ключ для використання в межах системи. Є різні бібліотеки, алгоритми, довжина ключа, параметри стійкості, вразливість до колізій, нагрузка на CPU тощо… Є експерти які розібралися у цьому всього і можуть запропонувати що вибрати. Тепер увага: якими словами мають описувати своє рішення ці експерти, щоб моя мама, як учасник системи, могла адекватно проголосувати за певне рішення?
      Значно простіше обмежити доступ до голосування як мінімум технарям і не заставляти експертів тратити свій час на те, щоб обгрунтувати своє рішення у формі зрозумілій для домогосподарок (і не підходящій для технарів, тобто в ідеалі доведеться 2 описи робити).
      Якщо стоїть задача загального плану, яка не вимагає спеціальних знань — то і не ставиться обмеження по доступу і всі спокійно приймають участь у голосуванні за рішення. Все дуже залежить від задачі. Але казати, що не варто НІКОЛИ обмежувати коло людей для прийняття рішення — хибний шлях, на мою думку.
      22 Apr
      Вже майже два роки працюємо без обмеження права участі на Просторі злагоди - ніяких негативних наслідків не було. Консенсусне прийняття рішень вільне від тих спроб зловживання, які виникають при голосуванні.
      22 Apr
      А яким чином ви знаєте, що рішення прийнято консенсусом? Певно з того, що ніхто не висловився проти, тобто не проголосував проти, і не висунув чи проголосував за альтернативне рішення. Консенсус це просто один з результатів голосування, коли всі голоси зійшлися на одному рішенні.
      23 Apr
      Різниця в тому, що при голосуванні позиції не змінюються, а при консенсусі - змінюються назустріч одна одній.
      23 Apr
      >при голосуванні позиції не змінюються
      Це не так, якщо голосування є завжди відкрите.
      23 Apr
      яке відношення має відкритість голосування до формулювань пропозицій?
      Чи можна додавати свої формуліровки? Якщо так, то чи легітимні ті голоси, які з’явилися до зміни формулювань?
      25 Apr
      "Відкрите" в смислі, що в будь-який момент можна змінити свій голос (якщо з’явилася нова аргументація, чи хтось переконав когось у чомусь і це вплинуло на Ваш вибір, позицію).
      Можна додавати альтернативні варіанти рішення і тоді голоси можуть перетікати з попередніх рішень до нового, більш якісного.
      В даному проекті пропонується саме таке.
      21 Apr
      Dmytro Ivakhnenko:
      Коло людей для прийняття рішення обмежується природньо, - люди, яких не цікавить проблемна тема, просто не беруть участь в обговоренні.
      Якщо виникне така необхідність, досить легко обмежити коло, наприклад, провівши невеличку перевірку обізнаності людини по розглядуваному питанню. Та, наскільки мені відома світова практика, такі перевірки дуже мало де проводять, хоча і мають таку можливість.
      За моїм досвідом, введення різниці в статусах погано впливає на згуртованість спільноти, - одразу ж виникає невдоволення. Учасники, що отримали нижчий статус, почасту одразу ж покидають спільноту. Тому в таких заходах важлива делікатність та обережність.
      Так, експертам доводиться докладати зусиль, щоб зрозуміло пояснити свої зауваги. Дійсно, це важка робота. Та прозорість аргументів - необхідна передумова створення "колективного інтелекту".
      21 Apr
      Oleg Shvachich:
      >А як саме розділити? Можете розписати механізм?
      с позиций народовластия это выглядит так: 1. в зерносеящем районе на районном сайте выдвинуто предложение построить, к примеру, элеватор. Люди обсудили, есть сторонники и строить, есть и возить зерно в соседний район...2. создали РГ (рабочую группу) из желающих в нее войти по проработке данного вопроса. РГ опрашивает экспертов и граждан "в теме" по данному вопросу. Это специалисты - а. экологи б. экономисты в. сметчики г. строители д. руководители (плановики, бухгалтера), зерносеящих предприятий. Все плюсы и минусы строительства элеватора РГ выставляет на сайт для голосования, граждане, проживающие в районе, голосуют. Как-то так
      22 Apr
      >Коло людей для прийняття рішення обмежується природньо, - люди, яких не цікавить проблемна тема, просто не беруть участь в обговоренні.
      Це працює для вузьких маловідомих робочих груп. На масштабі національної системи прийняття рішень, якщо висунути на обговорення питання рівня податків, рівня зарплати на певній відповідальній посаді, тощо, то результат буде близький до того, що ми спостерігаємо у коментах до новин на цю тему на загальновідомих сайтах новин.
       
      23 Apr
      Dmytro Ivakhnenko
      Чи потрібна централізована національна система прийняття рішень на одному сайті? Це приблизно як організм людини складався б з однієї клітини. Вона б тоді недовго прожила.
      На мій погляд, більш перспективне об'єднання через протоколи та метадані. Тобто, наприклад, робоча група з ел-ідентифікації проводить обговорення, воно картується у дерево з доводами за та проти, і це дерево доступне для широкої спільноти. Людина, що не прийняла участі в обговорені, навряд чи обізнана щодо пропозицій та доводів, і тому їй навряд чи варто голосувати.
      Ті ж метадані дозволять краще розповсюджувати відомості про те, хто, де, і над чим працює, і завдяки цьому залучати до обговорення компетентних людей з усього світу.
      Щодо сайтів новин - то мене дивує, чому вони не використовують більш якісні рушії для коментарів, а натомість самі пишуть щось недолуге. Є гарний вибір кращих варіантів:
      http://www.hongkiat.com/.../3rdparty-comment-discuss.../
      http://en.wikipedia.org/wiki/Blog_comment_hosting_service
      Схожим чином, і для обговорення суспільно-важливих питань вже є набагато кращі рішення, ніж лінійна невпорядкована стрічка висловів читачів.
      Окремі гілки великого дерева обговорення цілком можуть рости на окремих сайтах, за участю відповідних спільнот.
      23 Apr
      >Чи потрібна централізована національна система прийняття рішень на одному сайті?
      Ні, не потрібна. Це саме те чого я стараюся уникати перш за все.
      Я ж пропоную децентралізовану платформу, яку ще й можна підняти у будь-якій окремій групі — це абсолютно протилежна концепція.
      >більш перспективне об'єднання через протоколи та метадані.
      Порівняно з єдиною платформою це є ускладнення якого можна уникнути, бо платформа передбачає наявність протоколу і доступ до всіх даних, включаючи метадані.
      >метадані дозволять краще розповсюджувати відомості про те, хто, де, і над чим працює
      Наведіть приклад, і уточніть краще за що саме.
      25 Apr
      Dmytro Ivakhnenko:
      >Порівняно з єдиною платформою це є ускладнення якого можна уникнути, бо платформа передбачає наявність протоколу і доступ до всіх даних, включаючи метадані.
      Для розвитку необхідно різноманіття платформ.
      Скажімо, один державний Ощадбанк - це простіше, ніж розмаїття банків, але при цьому уповільнюється розвиток.
      >Наведіть приклад, і уточніть краще за що саме.
      Приклад об'єднання дерев обговорень:
      https://github.com/KnowledgeGarden/IBIS-Server
      Приклади технологій метаданих "семантичної павутини":
      http://uk.wikipedia.org/wiki/RDF
      http://microformats.org/
      http://www.wired.com/2011/12/occupy-facebook/
      Це значно краще, ніж теперішня ситуація, коли про щось стає відомо хіба що через соціальні мережі або першу сторінку результатів пошуковика.
      25 Apr
      >один державний Ощадбанк - це простіше, ніж розмаїття банків, але при цьому уповільнюється розвиток
      Певний банк — це ж є приклад сайта а не платформи…
      , - благодаря этому роль эксперта перестанет быть привилегией, а станет трудной обязанностью. Карьеристам и властолюбивым людям станет незачем пробиваться на эту временную, и требующую отдачи роль. Тогда вместо вопроса об отборе экспертов возникнет вопрос о том, где вообще брать таких компетентных людей, и как их вознаграждать, чтобы они согласились на такую непростую временную работу.
      21 Apr
      Oleg Shvachich (тут):
      Вполне согласен с паном Дмитро и приведу 2аргумента по теме
      1. когда решили прокладывать трассу через Химкинский лес, граждане, не согласные с таким решением, представили 11 (одиннадцать), вариантов трассы, не требующих вырубки. Этих авторов проектов можно считать экспертами? Несомненно..."по делам их узнаете их"(с); и не нужны регалии и прочий "отбор" - они заявили о себе как об экспертах;
      22 Apr
      Ніщо би не завалило цим людям заявити про себе як про експерта скажімо середнього рівня і навести лінк на рішення, яке пропонується. Якщо рішення адекватне, то в адекватному середовищі людину легко приймуть в ряди експертів середнього рівня і дадуть доступ до обговорення і прийняття рішень по цьому питанню.
      Відбір потрібен чисто для технічного відсіювання неадекватів
      22 Apr
      винахідники завжди сприймаються сучасниками, як "неадеквати" - тому можуть не пройти через такий фільтр
      22 Apr
      Справді таке буває, але далеко не завжди.
      23 Apr
      Це не дуже втішує, як сказати про наші Вибори, що не завжди ж обирають таких як Янукович
      23 Apr
      Коли суспільство хворе, то багато що не втішує. Тобто проблема не в самій системі фільтрації, а проблема в людях.
      23 Apr
      Якщо проблема в людях, то чи допоможе взагалі система фільтрації і голосування?
      Подивився кількість голосів в системі "Меритократ" - десь 3-5 голосів на питання.
      і флуду коментів пропозицій і рішень.
      Коли питання невелике і зачіпає невелику кількість людей, то звичайно такої проблеми немає і кожному можуть дати можливість висловитися, але тут ми пробуємо знайти рішення, яке би працювало для сотень тисяч учасників.
      22 Apr
      в мене є викрутка де можна ставити будь-яку біту, але зазвичай користуюсь звичайними
      За універсальність треба завжди чимось розраховуватись.
      Потенційно у Вашому випадку вони би могли видати 111 рішень і знову постане проблема відбору з цих рішення і тих хто і як буде відбирати.
      2. По данным Ю. Латыниной, 8 наших НИИ выдали за 2012 или 2013 год 5 (пять), запатентованных изобретений, при этом 1 международное (это "отобранные эксперты", лучшие из лучших). Компания гугл за этот-же год выдала 5000 патентов, все международные. Пора отходить от "выбора экспертов"...и повторю - задача эксперта - не принять решение; задача эксперта - осветить вопрос со всех сторон, и "за", и "против".
      22 Apr
      Dmytro Ivakhnenko:
      Введение некого единого рейтинга экспертов - первое простое решение, которое приходит в голову. На практике оно имеет недостатки, и подходит далеко не всем сообществам.
      Хорошие руководства по разработке систем репутации, на английском:
      http://bokardo.com/.../social-design-patterns-for.../
      http://bokardo.com/.../social-design-patterns-for.../
      http://books.google.com/books?id=Mk81XgHfh1cC&pg=PA3...
      http://books.google.com/books?id=MXJ5iB7BS_0C...
    • Критика глобального рейтинга
      7 Jul
      Andy Shapovalov
      Было бы очень интересно прочитать мнение Виктор Семенов (Victor Semenov) о суммировании/переходе оценки специалиста за конкретный проект в его "глобальный" рейтинг профессионализма?
      7 Jul
      Victor Semenov
      специалисты широкого профиля - это очень ценные специалисты, но по моему мнению глобальный рейтинг специалиста не существует. Было бы очень полезно в системе отмечать способность специалиста ориентироваться в нескольких областях знаний. Но из этого не возникает "глобальный рейтинг". Не существуют специалисты во всех областях знаний, только тов.Сталин был большим учёным во всех науках. После него таких больше нет.
      Но тут есть интересный ход конём. Профессионализм высокого уровня обычно сочетается с высокой ответственностью. Высокая ответственность проявляется прежде всего в работе, специалист высокого класса просто не может быть безответственным в делах, связанных с его профессией. Не всегда такую ответственность он демонстрирует за пределами профессиональной деятельности. Мы видим примеры, когда талантливые режиссёры, актёры оказывались не очень порядочными в жизненных делах, а сколько "крымнаш" оказалось среди них -не счесть. Тем не менее, привычка к профессиональной ответственности часто распространяется и на общечеловеческие отношения, переходит в гражданскую сферу. Я это называю интеллигентностью.
      Глобальный рейтинг гражданской ответственности был бы полезен. Только как его определить, как выявить?
      Рейтинг участника сети вполне можно подсчитывать, но обобщённый рейтинг - это как средняя температура пациента за три последних месяца. Это очень слабый и неэффективный способ регулировать право высказывать своё мнение и участвовать в выработке решений. Наилучший ( в каком то смысле идеальный) рейтинг - это уровень профессионализма, образования, компетентности и ответственности участника сети в данном конкретном решаемом вопросе. И неважно как он участвовал в сотнях других дискуссий.
      7 Jul
      Andy Shapovalov
      Я должен пояснить свой вопрос.
      Я сейчас говорю о только о профессиональных рейтингах и разделю их на групповой и общесетевой. К примеру, в рамках малой группы единомышленников человек может получить очень высокую оценку своих навыков, но это никак не означает, что вне группы, на широкой выборке, этот рейтинг будет адекватен- оценка малой аудиторией будет означать, что он самый профессиональный в этой группе, не более того.
      И в принципе, это касается всех категорий по которым будет осуществляться рейтингование?
    • Хороша дискусія про рейтинги експертів
    17 Feb
    Михайло Петелицький: не зрозуміло на якій підставі комусь присвоюють "професійний рівень" чи рівень знань з того чи іншого питання.?
    17 Feb
    В ідеалі на основі того що є на руках: особистий досвід співпраці, робота у проектах, певні наукові роботи, дисертації, книжки, активна участь у конференціях, тощо — те що доступне публічно і можливо перевірити.
    25 Dec
    У психології прийнято послуговуватись поняттям компетенції, а рівень компетенції визначається кваліфікацією (дипломи і сертифікати визнаних інституцій), та досвідом.
    Отже, коротка формула така: кваліфікація + досвід = компетенція
    25 Dec
    Тобто Ваша пропозиція назвати це "рівень компетенції". Мені особисто подобається. Треба буде винести на голосування і прийняти відповідне рішення, якщо не буде кращи пропозицій.
    Спроби присвоїти рейтинг без аргументів обертаються зниженням рівня смій людини, а такий рейтинг анульовується.
    17 Feb
    Михайло Петелицький: поняття "рейтинг" взагалі є дискримнаційним і неприпустимим в питанні самоврядування.
    17 Feb
    В тому і непорозуміння, що невідомо, для яких спільнот розглядається рішення, а єдиного для всіх - не знайдемо, бо вимоги протирічать одна одній.
    Рейтинг завжди можна накручувати (способів багато - і підкуп, і популізм, і використання ТБ).
    Не може бути жодної мови про когось "рейтинговішого" коли мова йде про голоси, які за визначенням є рівними.
    13 Jan
    Можна ввести поняття СД-рейтинг (або СД-підтримка, СР-рівень) і відійти від слова, що має так багато значень і викликає різні асоціації. І його вжевизначити строго.
    17 Feb
    Не згоден. Тут наші погляди сильно розходяться.
    17 Feb
    якщо мова йде про професійну спільноту - тут я згоден, рейтинг потрібен. (Не може студент 5-курсник стояти на одному рівні з професором). Але коли мова йде про вибори, то тут не може бути жодних переваг між делегатами.
    18 Feb
    Між делегатам — це інша ситуація, там рівні справді недопустимі (за умови відсутності обмежень по допуску до голосування).
  • Можливість встановлення допуску до голосування
    20 Dec
    Це можуть бути вимоги до:
    • професійного рівня
    • рівня довіри
    • рівня активності у системі
    • інші характеристики
    Усі параметри також голосуються.
    20 Dec
    Пропоную для голосувань зробити розбиття результата на групи. Перед голосуванням можна визначити яка група є основною (наприклад 10% найбільш рейтингових учасників визначають результат)
    20 Dec
    Це суперечить принципу рівноправності. Допуски доцільні лише коли локальні рішення приймають локальні спільноти
    20 Dec
    В коментарі Романа йдеться про розбиття на групи. До чого тут Ваш коментар. Таке враження що він десь не тут мав бути.
    20 Dec
    @Юрій Бабак Вже час зробити реструктуризацію обговорення, бо хаос зашкалює.
    21 Dec
    :) є таке…
    ще до цього доберемося, зараз просто інші пріоритети.
    . Голосувати можуть всі учасники і можна бачити по групах результати: як проголосували 10% найрейтинговіших, 20%, 50% і тд. Також вибірки по різних категоріях (коли вони будуть підтримуватися).
    Тобто, результат визначається заданою категорією, але всі інші також можуть висловити свою позицію.
    20 Dec
    Так стратегій може бути багато. Думаю треба буде вибрати кілька для реалізації.
    20 Dec
    Михайло Петелицький: не зрозумілим і не достатньо описаним є питання "допуску". Хто буде "допускати" одних і "не допускати інших"? які критерії?
    20 Dec
    Це питання ще не опрацьовано детально.
    Найпростіший приклад: до створеного питання допуск можуть встановити персони з рівнем довіри не менше 4/5 (4 бали з 5 можливих). Наприклад вони встановлюють допуск по рівню не менше 2/5, тоді автоматично персони у яких рівень довіри менший ніж 2/5 не зможуть проголосувати по питанню.
     
    У dev-preview буде лише один-два елемента допуску, решту будуть виноситися на обговорення у подальшій роботі. Це справді складна тема.
    20 Dec
    Дадам: в умовах професійної спільноти - це нормально і мабуть корисно. Але, коли ми говоримо про вибори чи вирішення певного питання на місцевому рівні громади (місцевий референдум), то це вже буде називатися "дискримінація".
    20 Dec
    Все залежить від питання, яке вирішується.
    20 Dec
    Чи буде система переналаштовуватися в залежності від питання, хто це буде робити? Монтян у відео добре показала важливість вибору алгорітму і його вплив на результати голосування
    20 Dec
    Найперше параметри і алгоритм підрахунку голосів задаються автором питання (метод Шульце, проста більшість, чи інші, які закласти залежно від набору варіантів). Але вважаю, що потрібно закласти можливість змінити ці параметри голосуванням,
    20 Dec
    вибір параметрів та способу голосування може перерости у проблему, більшу, ніж саме питання. До речі, мало людей хочуть займатися цим, тому решта вирішить, що воно того не варта.
    20 Dec
    Цілком можливо. Надіюсь, що тестовий період застосування це виявить.
    бо автор міг просто вибрати непідходящий алгоритм по даному питанню. Кому саме давати можливість голосувати за зміну параметрів — відкрите питання, але точно не всім підряд.
    Якщо питання загального характеру, яке стосується кожного і кожен в змозі чітко висловити своє ставлення до певного рішення, то і немає смислу вводити якісь обмеження. А якщо питання вимагає певних знань у певній галузі, то дозволяли будь-кому його вирішувати — теж не правильно. Висловлюватися — будь-ласка, але не вирішувати.
    Так це дискримінація, але хто сказав, що це виключно погане явище? Якщо не дискримінувати по рівню знань і можливостям, то і не буде стимулу вчитися і розвиватися. Коли беруть людину на роботу то теж дискримінують усіх, хто не пройшов співбесіду і цим порушують їх конституційне право на працю (Конституція України, розділ 2, стаття 43).
    20 Dec
    На етапі обговорення Експерти можуть створювати альтернативні ініціативи, якщо вважають початкову ініціативу хибною або недосконалою, і якщо перший ініціатор не вдосконалює свою ініціативу відповідно до отриманих відгуків. Тоді час на обговорення автоматично збільшується а на голосування виносяться кілька альтернатив. Але голосввати усеодно повинні мпти право всі дотичні учасники.
    20 Dec
    Андрію, дана гілка про допуски і критерії, а Ваш коментар в основному про створення альтернативних ініціатив. Відкоригуйте його по темі, або перемістіть, якщо воно випадково попало не в ту гілку.
    20 Dec
    Теоретизувати можна до безкінечності. Але треба розуміти, що умови повинні бути виписані рівні для усіх, щоб кожен мав рівні права і можливості доступу до вирішення питань. Буде дискримінація - значить не буде жодного шансу на впровадження схожої системи.
    20 Dec
    Я за те, щоб усі мали рівні права до можливості отримати право вирішувати питання.
    Але я не маю права останнього голосу, тому такі важливі моменти будуть вирішуватися також голосуванням. Я спробую тільки створити інструмент, який буде мати такі можливості.
  • Майже всі параметри самої системи теж можуть бути змінені голосуванням
    16 Dec
    • Це для саморегуляції і підвищення адекватності самих параметрів системи.
    • З технічної сторони це є дуже болюче місце системи, бо при зміні певних важливих параметрів, система має опрацювати величезний об’єм даних з метою актуалізації їх стану згідно нових умов.
    • Приклади
      16 Dec
      Наприклад, якщо змінюється значення кількості днів періоду протягом якого персона має проявити активність, щоб зберегти статус активного учасника мережі.
    • Пошук рішень
      16 Dec
      >Ти не думав на підходом який використовується в блокчейні? дерево Меркла и та ін?
      Чому біткоін не завмирає коли обраховується вся історія кожної копійчини, яка зберігається в базі даних: тому що кожна нова транзакція фактично фіналізує все що було в минулому. тому обчислювальні ресурси потрібні лише на обробку поточних даних. Не варто при обробці звертатися до плоза минулих записів. але перевірку на їх відповідність робити сам деревом меркеля
      Основна задача у біткоіні — підбивати баланс по адресі, основна задача у нашій мережі — трекінг активності усіх учасників в межах певних спільних сущностей, як от голосування, обговорення, тощо + ця активність може впливати на роботу мережі, змінюючи алгоритми. Ці задачі по складності відрізняються на порядок, тому певні рішення, які успішно працюють в біткоіні не підходять у нашому випадку.
       
      Дерево Меркла класно вирішує задачу: як з мінімальними затратами ресурсів обслуговувати баланс певної адреси (гаманця). Для цього дійсно достатньо тримати заголовки блоків і лише ті частини дерева, у яких фігурує транзакція з цією адресою. І дійсно для перевірки нових транзакцій достатньо лише поточного балансу, тобто всі попередні транзакції можна почистити для економії місця. Питання: навіщо тримати якісь ще блоки, якщо для перевірки достатньо просто значення балансу? Це потрібно для випадку коли знайдеться ланцюг з більшою кількістю блоків, ніж є поточний, тоді треба перераховувати баланс по адресі.
       
      А тепер додамо гіпотетичну фічу у мережі біткоін: якщо за добу користувачі біткоіна зробили рівно 777 транзакцій, то система анульовує усі комісії у всіх транзакціях за участю адрес, які попали у ці 777 транзакцій. Отож в момент настання такої цікавої події уже недостатньо мати лише баланси усіх цих адрес, а доведеться пошуршати по повній базі з усіма даними по транзакціях, знайти усі потрібні, порахувати суму комісій по кожній адресі і нарахувати на ці адреси повернення коштів у розмірі суми транзакцій. Ніякий блок новий при цьому не генерується, це просто обробка даних, яку має провести кожна нода у мережі і змінити відповідні кінцеві баланси. Коли є подібна фіча у системі, то думають над оптимізаціями: наприклад можна разом з балансом кожної адреси вести ще баланс усіх комісій по транзакціях з її участю, так можна позбутися пошуку в базі і обробки старих даних. Тобто можна використати певну стратегію кешування певних даних для оптимізації, але це теж не безплатно, бо в результаті повні ноди будуть тримати замість однієї цифри для адреси дві, тобто це вдвічі більше даних треба постійно підтримувати у актуальному стані. Якщо ще ускладнити умови фічі, наприклад що повертаються комісії тільки у транзакціях, які були зроблені у такий же день тижня, що і момент настання умови про 777, тоді вже не достатньо буде тримати лише суму комісій біля кожної адреси, але потрібен детальний масив комісія + день тижня для кожної транзакції (або погрупувати по днях тижня, якщо оптимізовувати далі), а це вже значно більше даних, ніж одна циферка, особливо, коли транзакцій багато. І тоді постає питання, а що по ресурсах ефективніше буде: постійно підтримувати в актуальному стані величезний масив даних по кожній адресі, чи просто в момент настання події Х пошуршати по базі і віднайти усі потрібні транзакції і порахувати ті комісії? Питання ускладнюється тим, що подія Х може взагалі ніколи не настати. А тепер уявимо собі, що таких фіч може бути необмежена кількість і всі вони зі своїми умовами про те, що шукати, і що рахувати (тобто для кожної такої фічі потрібно розробляти свої стратегії кешування, якщо обрати цей шлях).
       
      Те що я описав вже дещо ближче до того з чим доводиться мати справу в Силі Довіри, ніж до того, що є у біткоіні. Тут теж, коли людина просто голосує по питанню, в 99% випадках просто миттєво збільшиться один каунтер в мета-даних по голосуванню, але якщо цей голос був вирішальним для прийняття рішення, а це рішення ще й таке, що впливає на певні параметри системи, отоді починається робота по аналізу і зміні усіх відповідних параметрів персон, задач, балансів, тощо. Саме така ціна динамічності системи. Я надіюсь просто що такі важливі параметри устаканяться досить швидко і просто не будуть мінятися з часом, або будуть раз на пару років (це як зміни в Конституції).
       
      Буду тільки радий, якщо я помиляюся і якщо хтось придумає, як дерево Меркла може допомогти у таких ситуаціях.
    29 Nov
    @Юрій Бабак Якщо система не розвиватиметься, тоді її автоматичне самоналаштування можливе в рамках заздалегіть розроблених конфігураційних параметрів.
    Але якщо необхідне людське втручання для розробки частини нового функціоналу, тоді виникає необхідність регламентувати процес розробки системи, унеможлививши вплив люського фактору на об'єктивність функціонування системи.
    8 Dec
    Зміни в системі будуть складним процесом. Процес встановлення оновлень програми мусить захищати від зловмисників які захочуть встановити свої версії спеціально модифіковані для захоплення системи.
    На технічному рівні всі оновлення потрібно підписувати учасниками системи які гарантують що версія надійна. Ці учасникі мусять мати відповідний рівень довіри. Загальне правило - скачувати оновлення лише від тих кому довіряєш. Також системи мусить включати свій "оновлювач системи" який перевірить підписи нової версії програмного забезпечення.
    29 Jan
    Может я чего-то непонимаю, только, есть пример онлайн игр, в которых есть центральный сервер и программа с физикой у каждого на компьютере. Центральный сервер занимается синхронизацией и рассылкой обновлений. Почему, в итоговом варианте, не совместить p2p c пунктом цетрального управления, котрый будет выполнять чисто технические функции и в целом вляиние его на общую систему будет ограничено.
    4 Feb
    Тому що будь-який централізований елемент стає слабким місцем і ціллю для атак, зловживань, чи впливу.
    8 Dec
    Про це якраз йдеться у наступному розділі.
  • Функціонал самої системи можливо буде розширювати "на льоту"
    29 Nov
    Буде закладений механізм прийому патчів:
    1. формується патч, підписується автором (будь-хто може запропонувати патч). Зазвичай це буде хтось з ядра розробників з високим рівнем довіри;
    2. прийняття патча з його описом і поясненням потреби виноситься на загальне голосування;
    3. якщо 50+% учасників системи
      29 Nov
      Допуск до голосування будуть мати лише учасники з хорошим рейтингом довіри і з зі знаннями у галузі ІТ, всі решта будуть змушені делегувати свій голос одному з таких експертів.
      29 Nov
      як решта може оцінити компетентність делегата, як не мають знань у галузі?
      9 Dec
      Це складне питання. Однознаяної відповіді немає . Тут потрібно покладатися на розім, інтуіцію та відчуття. Юридочного обгрунтування що це можливо ніколи не буде. Але життя показує що це цілком можливо і досить гарно працює.
      Хороший приклад це веб-сайт habrahabr.ru .
      9 Dec
      Це дуже спеціфічне середовище, зовсім не схоже на широкий загал. Механізми, що працюють на habrahabr.ru - ЗОВСІМ не працюють в суспільстві (не мають там критичної маси, щоб працювати хоч якось).
      Сме на ньому діє найкраща рейтингова система чку я коли небудь бачив. І саме там я чітко можу бачити чи автор статті розбирається в своїй темі чи ні. Навіть якщо я в тій темі не розбираюся. Таке відчуття складається на основі самої статті, коментарів до неї та рейтингів на статтю та коментірі . Тобто, всі разом складають чітку картину про статтю та відповідно автора.
      Так само може працювати в нас
      29 Nov
      Цього від них не вимагається. Достатньо, щоб була довіра до людини. Якщо немає прямої довір, то делегувати голос по рекомендації друга, або делегувати своєму другу на переделегування і тд.
      Тому ця система й отримала свою назву.
      По суті це те ж саме, що вибирати абстрактних депутатів/міністрів/президентів, без розуміння особливостей їх діяльності, різниця лиш у тому, що це не на 4-5 років, або до майдану, а до моменту дискредитації і втрати довіри делегатом, тоді голос переделеговується. Саме в цьому якісна відмінність системи.
      голосують за його включення в систему
    4. проголосований патч розходиться по мережі штатним шляхом синхронізації як обов’язковий для встановлення (кожна нода зможе перевірити, що існує голосування в якому йдеться саме про цей патч і що його треба встановити, перевірити його цілісність по чексумі).
    5. якщо патч не встановити — нода випадає з мережі.
    Це одна з можливих стратегій, тож питання залишається відкритим поки що.
  • Учасники мережі
    24 May
    • Стати учасником мережі можна буде тільки по запрошенню від кількох учасників
      24 May
      Основні дані людини при цьому задаються саме у запрошенні і не можуть бути змінені пізніше навіть самою людиною, тільки доповнені. Це для забезпечення коректності даних кожної особи.
      Одна група не буде мати можливість запрошувати необмежену кількість людей. Це для ускладнення заведення віртуалів у мережі і проти затягування певною групою лише собі подібних.
      Ідентифікація учасника після реєстрації відбувається по його публічному ключу, бо кожна дія учасника супроводжується його цифровим підписом (RSA).
      24 May
      Кирничний Анатолій про дану процедуру реєстрації:
      Персональні запрошення обов'язкові. По-перше, вони накладають відповідальність на того, хто дає запрошення і повинен буде отримати необхідний мінімум інформації про претендента, по-друге, той хто дає ключ, буде нести персональну відповідальність за запрошеного і може понести певне покарання аж до недовіри і вилучення з Системи.
      Хто з легкістю увійшов, той не буде особливо переживати про прийняте рішення в голосуванні.
      Система створюється для думаючих людей.
      Пройти реєстрацію складно тому, хто не бажає думати, або у кого IQ<70. І ті й інші навряд чі потрібні Системі.
      Дорогу здолає той, хто йде, а натиснути на кнопку "Зареєструватися" зможе і дитина. Ускладнювати треба систему реєстрації, а не упрощать
      25 May
      Самой большой проблемой вижу маргинальность системы. Преодолевать трудности хорошо если есть сильная мотивация, иначе можно иметь IQ хоть 170 — и отказаться от входа в систему.
      Какая мотивация в данном случае?
      25 May
      Поки що з мотивацією є проблема. Вона буде вирішена з часом різними методами. Ми працюємо над цим.
      , тоді потрапляти в Систему будуть розумні люди. Виникли складності при реєстрвції - набери номер телефону або напиши на e-mail
      24 May
      Добродію Анатолію, я правильно зрозумів, що Ви за те, щоб обмежити та ускладнити доступ у систему таких верств населення як:
      - "бабушки" та "гуманітарії", яким у наслідок їх складу мислення часто важко не те що встановити додаток, а взагалі користуватися не-базовими функціями смартфонів?
      - людей, що мають певні труднощі у спілкуванні з незнайомими людьми, і взагалі не схильні до спілкування, але які, часто, бувають восокваліфікованими спеціалістами у своїй галузі?
      24 May
      На стадии разработки это решение верное, но система, как я понимаю, разрабатывается для того, чтобы в будущем ею могли воспользоваться все граждане.
      28 Dec
      • Приход новых людей в систему
        25 Dec
        Вот нашел человек в интернете ссылку на систему, никого из участников не знает
        25 Dec
        кстати, где он может познакомится со списком участников?
        и его никто не знает — и что, от ворот поворот? А ведь таких будет большинство.
        26 Dec
        Нам цікаві
        28 Dec
        Не получается ли, что система делается не для людей
        28 Dec
        и динамика роста участников скорее подтверждает это наблюдение
        , а для "нас" — узкого круга людей, близкого к основоположникам ("своим")?
        28 Dec
        Ні не получається. В спільноті вже є певна кількість людей, які зібралися через спільні інтереси, а не через близькі знайомства. До того між собою ми не були знайомі.
        28 Dec
        Это понятно, так создается любая секта/клуб, но они такими и остаются. Это узкий круг людей, живущий/действующий по специфическим правилам.
        активні люди. Таким не важко буде долучитися наприкла до групи у FB і там висловити бажання познайомитися зі спільнотою та зареєструватися в мережі.
    • Анонімність
      24 May
      Можливість введення анонімних аккаунтів технічно є, але вона несе з собою на мій погляд більше мінусів ніж плюсів. Як буде більше видно в цьому потребу — винесемо питання на голосування, побачимо детальну аргументацію.
    • Проблема фіктивних акаунтів
      24 May
      Заведення паралельних аккаунтів (віртуалів) технічно є, але ми стараємося максимально її ускладнити і зробити невигідною. Для цього у нас витрата енергії на дії, запрошення, перевірка Вартовими. Якщо попадаєшся — блокують тебе, тих хто допоміг тобі створити і тд.
      Щоб справлятися з потоком нових реєстрацій ми динамічно будемо збільшувати кількість Вартових і збільшувати вартість запрошень та кількість потрібних запрошень. Додатково є можливість введення умови, щоб одне з запрошень було від Вартового, це проти дії груп по зговору.
  • Саморегуляція спільноти
    18 Nov
    Учасники можуть висловлювати недовіру іншим учасникам до рівня, що ті в результаті не зможуть ні писати, ні голосувати у системі, аж поки не виправляться, або не сплатять штраф.
  • Посади
    19 Apr
    У системі реалізована можливість обрання персон на посади. Для цього створюється спеціальне голосування у якому замість рішень, можна подавати свою кандидатуру на посаду.
    Завдяки завжди відкритому динамічному голосуванню, завжди можна змісти з посади одну кандидатуру і віддати повноваження наступній по рейтингу. Кількість потрібних посадовців визначається окремим голосуванням. Коли буде зроблена фінансова система, посадовці отримуватимуть оплату за виконання своїх обов’язків.
     
    Посади служать для вирішення певних задач у мережі, а саме:
    • перевірка достовірності персональних даних учасників;
    • слідкування за дотриманням правил спільноти;
    • вирішення конфліктів, накладання санкцій
     
    Додатково:
    • Розділ довідки про посади
    • Посади у групах, ієрархія посад
      24 May
      Вартові, чи інші посади можна буде створювати на різних рівнях з відповідними повноваженнями (загальна мережа, група, підгрупа…).
      Можливо буде працювати підпорядкованість нижчого рівня вищому, по аналогії з регіональністю (країна - область - місто).
  • Фінансова система
    18 Nov
    Фінансові операції це:
    • винагороди
    • штрафи
      4 Mar
      Кого винагороджувати і за що штрафувати? Навіщо узагалі вплутувати в систему прийнняття рішень гроші?
      5 Mar
      Для підвищення якості обговорення. Наприклад банити і штрафувати тролів, неконструктивну критику, емоції замість аргументів, тощо.
    • загальне фінансування певних проектів, виконання робіт.
      4 Mar
      Це краудфандинг. Навіщо писати ще одну систему, коли уже є Велика Ідея?
      5 Mar
      Наприклад, організація прибирання берега річки не тягне на Велику Ідею, в межах такої системи це може бути зручно (на скільки я собі уявляю: скинутися на приладдя, назначити відповідальних, організувати місце та час — усе відкрито і за невиконання обов’язків зменшення рейтингу у системі).
      Це тільки один приклад. Їх потрібно буде придумати більше.
    Криптовалюти — це єдиний фінансовий інструмент, який дає можливість робити прямі транзакції між учасниками, їх прослідкувати і перевірити.
    5 Mar
    А навіщо приховувати походження та обіг коштів? Здається що цей процес, навпаки, повинен бути максимально прозорим, щоб можливо було завжди прослідкувати скільки коли і скільки (пожертви можутть бути анонімні) надійшло коштів, а також коли, скільки, куди і ким було використано в конексті і рамках розвитку системи.
    P.S. Вибачте, якщо пишу не там, де дозволено. Не знайшов описаних правил колаборації. Якщо дискусія доцільна в іншому місці прошу перенести мої запитання. Дякую.
    29 Nov
    Ви певно неуважно прочитали. Якраз навпаки, ніякої анонімності. Біткоін дозволяє як робити анонімні транзакції, так і навпаки 100% публічні — саме відкритість і планується використати (можливість прослідкувати і перевірити).
    Дискусію поки що ведемо, де зручно для учасників. Я тільки переніс цей комент ближче до контексту (він відноситься саме до останньої фрази).
    1 Dec
    Використання біт-коін має високий поріг розуміння для практичного його використання, що ускладнюватиме ергономіку і відштовхуватиме користувачів. Система буде популярною, якщо матиме продуманий і простий інтуїтивний інтерфейс легкодоступний для усіх хто користуюється інтернетом, від дітей до пенсіонерів.
    3 Dec
    Біткоін дуже важкий для розуміння, але простий у користуванні. Як на мене то простіший за Webmoney, Yandex.Money, які уже є досить поширеними. Проблема з біткоіном зараз — це коливання курсу і обмеженість шляхів його покупки. З часом обидві мають по-троху вирішуватися.
     
    Для фінансової частини системи я не бачу інших варіантів, ніж криптовалюти (якщо серйозно думати про перспективи системи).
     
    Простий інтуїтивний інтерфейс системи від біткоіна не залежить ніяк.
    5 Mar
    Треба розрізняти етап впровадження системи (де все має бути якомога просто і звично) і етап розгортання у повному обсязі (де мають місце "навороти").
    Без успіху на першому етапі - другий можна не сильно обговорювати.
    6 Mar
    Але при такому підході порушується цілісність концепції.
    Для Вас це "наворот", а на мою думку це базовий функціонал.
    6 Mar
    але ж це не для себе, мабуть, а щоб хтось користувався
    25 Aug
    Застаріле: "буде базуватися на використанні криптовалют (Bitcoin на початку, Ripple як варіант)".
    Будемо пробувати ввести свою крипто-валюту, щоб не залежати від сторонньої мережі і не примушувати користувачів заводити гаманці у ній.
    4 Oct
    Різні економічні ідеї та теорії — це дуже цікава тема. І ми в нашій мережі будемо з цим експериментувати, коли набереться достатня кількість учасників і коли буде сформована експертна група економістів. Тоді будуть виноситися на обговорення конкретні пропозиції, будуть голосування і конкретні рішення по втіленню.
    Будемо також експериментувати з системами податків і фінансів.
    Ось наприклад одна з ідей, яка буде втілюватися для фінансів.
    https://youtu.be/Ph9EyFe-ylo
    15 May
    Цікавим є проект "GEO - економіка взаємообміну".
    Це є фінансова система і ціла економічна модель з цікавими властивостями і деталями, яка теж буде будуватися на основі децентралізованої мережі. В основі проекту теж довіра між учасниками.
    Можна буде розглянути варіанти і взаємодії між мережами, і можливість запуску подібної економічної моделі всередині нашої мережі. Хлопці теж хочуть зробити розробку відкритою.
    Матеріали:
  • Поширення системи
    3 Oct
    • Формат
      3 Oct
      Це може бути як архів, який просто потрібно розпакувати і запустити один файл (крос-платформенне рішення), або може бути інсталятор (для звичної процедури у Windows). Не буде потрібно жодних налаштувань.
      3 Oct
      Здається WebRTC
      3 Oct
      Як Ви бачите використання WebRTC в такому проекті?
      3 Oct
      Я не технічний спеціаліст. Я помітив, що це питання частково розкрите в розділі Децентралізація.
      WebRTC можна використати для спрощення простоти використання безпосередньо з браузера, а не качаючи та розпаковуючи архіви, втсновлюючи софт для Windows, качаючи патчі...
      3 Oct
      По суті можна обійтися лише браузером, але в цьому випадку систему буде сильно зав’язана на конкретній реалізації браузера і обмежена його функціоналом. Будуть складності і в розробці і у підтримці, яких можна уникнути.
      Для вседоступності програми її підтримка потрібна необхідна лише трьома клієнтськими платформами: Web + Android + iOS. А доя початку вистачить і просто Web.
      3 Oct
      Інтерфейс буде працювати саме через web-клієнт (відкриватися у браузері).
      Тонкий клієнт (без власного бекенда, залежний від сторонньої ноди) можна буде відкрити на будь-якій платформі, яка має на борту нормальний браузер. Буде створено тонкі клієнти для усіх основних платформ. Там ніби не буде багато роботи, я вже цікавився.
      3 Oct
      Як тонкий клієнт буде працювати із приватним ключем? Якщо це виключно веб рішення то як будуть шифруватися транзакції? очевидно що ключ має зберігатися в локальній файловій системі. При вході в систему (веб-сайт) потрібно вибрати ключ із файлової сисеми і він буде в памяті до кінця сесії?
      Тут є ризик зламу коли веб-сайт чере який працювати із системою буде "модифікований" зловмисником. Мона викрасти ключ.
      3 Oct
      Я вже над цим дума. Рішення полягає у контейнері, який містить встроєний браузер. З браузера немає доступу до рівня контейнера, де знаходиться ключ, а навпаки є, тобто ключем можна буде підписувати дії, сформовані у браузері, не передаючи у браузер сам ключ (передавати вже підписане повідомлення).
      це іноваційне, перспективне та універсальне рішення для різних клієнтських платформ. Теоретично можливе створення повністю розподіленої системи без єдиного сервера, що убезпечить систему від впливу сторонніх інститутів.
    • Заохочення
      3 Oct
      Для підвищення мотивації участі у системі і її поширення буде сформовано фонд, з якого кожен день певна сума фінансового заохочення буде розіграна між активними учасниками системи (більше активності = більше шансів на виграш). Люди, які долучатимуться до формування такого фонду, отримають статус спонсора громадянського суспільства і будуть мати доступ до голосувань по питаннях величини винагороди, тощо.
      Всі фінансові операцію будуть проводитися виключно через Bitcoin з рекомендацією використовувати спеціальні сервіси для захисту від знецінення (https://bitreserve.org) та обміну криптовалюти на гривні (http://e-btc.com.ua).
      3 Oct
      Я не думаю що потрібна фінансова мотивація. Система потрібна щоб змінити країну і люди які хочуть її міняти мають необхідну мотивацію.
      3 Oct
      насправді, зараз страшений мотиваційний голод і зневіра, люди, що хочуть змінити країну - швидко відходять в сторону, якщо треба зробити щось трохи більше, ніж 1-2 коменти в ФБ. Через кілька тижнів або місяців - більшість проектів через це вмирає.
      3 Oct
      Від людей, які хочуть змінити країну, очікується, що вони стануть спонсорами у системі і заохотять тих, хто пасивні і нейтральні, хто без заохочення максимум раз зайде в мережу. Це ж не раз на 4 роки підняти дупу і сходити в найближчу школу, тут потрібна буде регулягна активна участь (реально як мінімум раз в тиждень-два запускати клієнт і голосувати, або делегувати голос, вислвлювати ставленн/довіру/недовіру, тощо). Мало хто таке осилить, особливо на початку, коли система ще не стала на ноги.
      3 Oct
      Попахує уже лохотроном "сайт який платить гроші". Це ідея для окремого порталу, але не для системи прийняття рішень. Можете показати успішні аналоги?
      3 Oct
      Аналогами не цікавився, але вони не обов’язкові для подібного впровадження. Про "лохотрон" не зрозумів, хто тут кого за лохів по-вашому має?
      Що не так з винагородою за активну участь у суспільній діяльності?
    • Потенційні користувачі
      3 Oct
      • Громадські організації
      • Партійні організації
      • Місцеві спільноти
      • Всеукраїнські спільноти
      • Експертні спільноти
      17 Jun
      Кто сейчас реально пользуется?
      17 Jun
      Зараз ніхто, система ще в розробці.
  • Сервіси на платформі:
    3 Oct
    Сервіс — це є певний набір можливих дій у системі, об’єднаний під однією назвою, що служить для вирішення конкретної задачі чи ряду задач.
    Ми віримо в децентралізовані сервіси як новий етап розвитку взаємодії через інтернет, самоорганізації.
    За рахунок повної децентралізації і криптографії усуваємо у сервісах зав’язаність на певних організаціях, персонах, продуктах щоб запобігти узурпації, цензурі, корупції, вразливості. Забезпечуємо: надійність, прозорість, доступність, довіру.
    Під враженням від біткоіна та різних систем, які зараз будуються на блокчейні ми втілюємо наше рішення для самоорганізації громадянського суспільства, в основі якого лежить довіра.
    Сервісів на платформі у перспективі має бути багато, реалізовуємо ми їх згідно голосування за пріоритети.
    Учасник мережі може використовувати будь-яку кількість сервісів незалежно, або може взагалі жодного не використовувати, обмежень чи вимог немає.
    Перелік можливих сервісів:
    • Для суспільства
      3 Oct
      • Платформа для прийняття якісних рішень
        3 Oct
        • організація прозорих непідробних обговорень, голосувань, виборів
      • Форум
        3 Oct
        Задачі:
        • Служити площадкою для публікацій, обговорення та збереження різних матеріалів.
        • Формування рейтингу публікацій так, щоб учасникам Форуму він дійсно допомагав швидше знаходити більш корисні та якісні матеріали.
        Набір дій:
        • Можливість запропонувати публікацію
        • Голосування за підтримку публікації
        • Голосування за якість публікації
        • Коментування публікацій
        • Формування рубрикатора
        Матеріали:
      • Блоги
        3 Oct
        Децентралізована площадка для блогерів, інтеграція з існуючими.
        Задача — місце для ведення персонального блогу. Організація взаємодії між авторами і читачами.
        Набір дій:
        • Створення публікацій
        • Коментарі до публікацій
        • Блокування певних коментаторів
        • Відключення коментарів до публікації
        Завдяки особливостям платформи "Сила Довіри" такий сервіс для публікацій отримує наступні переваги над існуючими:
        • відсутність ботів, спамерів, анонімів у коментарях (забезпечується особливістю реєстрації у системі, Вартовими, витратою енергії на дії, тощо);
        • гарантія захисту даних від модифікації (публікації підписані цифровим підписом автора, тому захищені від модифікацій сторонніми особами; кожен читач перевіряє цифровий підпис автора на публікації, звичайно ж прозоро і неявно для користувача);
        • багато резервних копій публікацій (мережа працюватиме на великій кількості розкиданих по світу серверів, на кожному з яких буде знаходитися повна копія усіх публікацій автора, що гарантує надійне збереження; якщо автор і у себе запустить систему — то і на його машині буде повна копія усіх його даних);
        • захист від dos-атак (знову ж таки децентралізація забезпечує відсутність центрального сервера, який би можна було атакувати);
        • відсутність цензури (якщо публікація не порушує правила узгоджені спільнотою, то ніхто не може її видалити чи приховати, немає жодної ланки, чи адміна через які можна би було це зробити);
        • публікації не обвішуються навколо рекламою і на них не заробляє ніхто, крім автора (це завдяки тому, що система створена громадянами для громадян);
        • замість лайків довіра яка має вагу у системі;
        • розробка платформи ведеться згідно побажань користувачів через відповідні голосування.
        Подумаємо над можливістю інтеграції з існуючими площадками для блогів, форумів і коментарями, щоб було точно видно автора і легко можна було йому віддячити, чи втихомирити бурного коментатора.
      • Групи
        17 Jul
        Платформа обговорення питань і прийняття рішень, яка може бути запущена в будь-якій по розміру групі.
        Задачі:
        • Можливість об’єднання учасників мережі для спільної діяльності
        • Можливість створювати закриті обговорення і голосування, доступні лише учасникам групи
          3 Oct
          Функціонал створення закритих питань/обговорень робиться чисто з практично необхідності: якщо його не зробити люди будуть змушені використовувати сторонні інструменти, а нам краще, щоб більше користувалися системою, знаходили недоліки, привикали. В ідеалі робочі групи будуть старатися лише мінімум обговорень і рішень приймати таємно, бо лише відкриті матеріали, дії вливають на видимість, на вагу/рейтинг групи/учасника у загальній мережі.
        Набір дій:
        • Створення групи
        • Запрошення персон до групи
        • Створення голосувань і обговорень в межах групи
        • Обрання певних посад в межах групи
        Матеріали:
      • Сервіс глибокого, структурованого колективного обговорення різних текстів і тем (аналог Rizzoma)
      • Платформа для організації і підтримки діяльності громадських організацій, територіальних громад, партій, ОСББ
        3 Oct
        • членство
        • колективна розробка статутів, програм
        • збір коштів на діяльність, прозоре управління ними
        • внутрішні прозорі вибори для посад, для висування кандидатів
      • Робота експертних спільнот над документами
        3 Oct
        візії, реформи, проекти
      • Поради перевірених експертів
      • Сервіс експертних передбачень (prediction market)
        3 Oct
        Коли очікуються певні суспільні, політичні, економічні та інші важливі події (не розважальні, як от спорт, чи шоу-бізнес), то сервіс має давати можливість зробити ставку на певний вихідний результат, але не просто ставку, а обов’язково доповнену аргументами.
        Така конкуренція аргументованих поглядів, підкріплена грошовими ставками, може стати дуже цікавим полем для аналізу і полем для взаємодії експертів.
        Коли результат настає — виявляється переможець, до якого переходять ставки тих, хто помилився у передбаченнях, а всі аргументи, які були використані переможцем при ставках, можуть служити навчальним матеріалом для усіх інших, хто цікавиться даною галуззю.
        Більше того, регулярна успішна, чи не дуже участь у таких передбаченнях буде впливати на експертний рівень учасника у відповідній галузі.
      • База знань (wiki), довідники, соціальні мапи
        17 Jul
        Народна база досвіду і знань, де будь-хто може задати будь-яке побутове питання і отримати відповіді, які згодом оцінюються усіма і таким чином формується рейтинг пропозицій.
        Будемо пробувати стимулювати наповнення цієї бази знань
        17 Jul
        Для прикладу нараховувати бали суспільної активності, які можуть враховуватися роботодавцями, будуть брати участь у вікторинах, можуть служити допуском до певної функціональності на платформі, тощо.
        .
      • Площадка для ЗМІ
        3 Oct
        • всі рівні + фільтр у вигляді незалежної експертної спільноти
        • організація чисто громадських ЗМІ (фінансуються і контролюються спільнотою)
      • Каудфандинг, DAO (інвестиціі, проекти)
        3 Oct
        • організація проектів, акцій, заходів
      • Сервіс реалізації проектів
        3 Oct
        • Розбиття проекту на задачі
        • Планування
        • Групування учасників по командам
        • Комунікація
        • Фінансові потоки
      • Благодійність
        3 Oct
        • збір коштів на лікування, допомогу, тощо
        • всі люди і реквізити перевірені
      • Open data, надійні реєстри для публічної та приватної інформації
        3 Oct
        • освіта, медицина, статистика
        • реєстри прав, договорів, фактів, тощо
      • Чесні лотереї, вікторини
        3 Oct
        • неможливо вплинути на результати
      • Децентралізована площадка для важливих загальних повідомлень і приватних шифрованих повідомлень між учасниками.
        3 Oct
        Усі такі сторонні сервіси будуть використовувати маршрутизацію мережі і основну базу даних, але не будуть навантажувати її, а будуть тримати дані у своїх окремих базах.
        А такі речі, як приватні повідомлення будуть зберігатися лише в учасників переписки.
    • C2C, P2P
      3 Oct
      Мережа довіри, де люди можуть дізнатися одне про одного.
      • Дошка оголошень
        3 Oct
        Задача — місце для публікації інформації про потреби і пропозиції
        Набір дій:
        • Створення оголошення
        • Можливість контакту що до оголошення
        • Формування рубрикатора
      • Аукціони
      • Біржі
      • Мікрокредитування, страхування (без посередників)
      • Відгуки про компанії, товари, послуги
    • B2B
      3 Oct
      • Реєстрація організацій (статут, кілька засновників)
        3 Oct
        • В системі можна буде реєструвати організації і взаємодіяти з ними
          3 Oct
          • Організацію має реєструвати власник, або уповноважена особа.
          • Організація не має права голосу, але може приймати участь у конкурсах на виконання завдань, проектів.
          • На сторінці організації у системі буде відображено напрямки її діяльності, та рейтинг отриманий від учасників мережі.
          • Благодійні, громадські організації зможуть збирати кошти на свою діяльність.
          • Для фінансових операції в організації з кількома власниками можна використати систему загального гаманця.
            3 Oct
            Комбінований пароль, якщо люди можуть часто зустрічатися, або спеціальні сервіси, наприклад copay.io (http://youtu.be/3Qjf9GQSiyU)
          3 Oct
          • Повідомлення у робочій FB-групі: "Спробую ще раз детально пояснити функціонал реєстрації/представництва організацій (по суті компаній) у мережі на прикладі"
            19 Apr
            Уявіть собі майбутнє, коли мережа Сила Довіри вже є по розміру як Фейсбук. Тоді у власників бізнесу появиться інтерес якось взаємодіяти з цією аудиторією. Єдиний прямий спосіб це зробити буде через представництво кожної компанії у мережі. Саме для цього власник, будучи учасником мережі, матиме можливість створити спеціальну сторінку свого бізнесу (по суті зареєструвати організацію) і природньо, що він буде автоматично являтися власником цієї сторінки і зможе керувати нею.
            Уявімо, що Ви є власником мережі піцерій по Україні. Для чого Вам реєструвати свою компанію у мережі Сила Довіри?
            • Щоб збільшити видимість бренда: у Вас вже є сторінки у всіх інших соц-мережах, то чому б не створивши сторінку ще й тут.
            • Щоб отримувати чесні відгуки, пропозиції та рейтинги від клієнтів: у всіх соц-мережах це реалізовано, але в Силі Довіри особливістю є те, що тут справді живі люди, а не різні боти, чи віртуали. Тож прискіпливі клієнти з часом будуть більше дивитися на відгуки і рейтинги саме в цій мережі, а не в інших, де ця проблема не вирішена.
            • Щоб повідомляти підписників про новинки та акції компанії.
            • Щоб проводити між підписниками опитування, розіграші (100% чесні), тощо.
            А тепер уявіть собі, що Ви ще й такий власник бізнесу, який любить прозорість діяльності та цінує ініціативу працівників. Тоді Сила Довіри дає Вам можливість додати в організацію всіх працівників компанії з усієї України і публічно виносити на обговорення цікаві питання і приймати спільні рішення в межах компанії (по суті робоча група). Ви при цьому залишаєтеся власником і маєте всі відповідні повноваження в межах організації.
            Тоді, маючи таку групу, наприклад можна підняти задачу “як оптимізувати [певний процес]” і працівники з усіх регіонів, які знають ці процеси безпосередньо можуть реально запропонувати дуже креативні рішення, а інші зможуть їх підтримати голосуванням і тд. Або наприклад проводити ті ж голосування за звання “працівника місяця”, чи проводити підвищення по кар’єрній драбині публічно з аргументацією, а не мутно, по знайомствах і симпатіях.
            Таким чином виграють усі:
            • власник може отримати потужні ідеє для покращення ефективності роботи бізнесу;
            • ініціативні працівники заслуговують репутацію і винагороду за корисну активність;
            • зі сторони завдяки публічності таких процесів така компанія легше отримає працівників на ринку праці, бо люди будуть вибирати між компаніями про які вони нічого не знають, або знають по чуткам, і між компанією, діяльність якої видна як на долоні і видно, що думки працівників там цінують, що є відкриті шляхи для росту і побудови кар’єри;
            • молоді працівники отримують портфоліо, в якому вони можуть вказати що ось в цій і в цій компанії, хоч я і був офіціантом, мої ідеї по менеджменту були високо оцінені і навіть взяті на озброєння — і щоб перевірити ці факти не потрібно буде дзвонити у компанію, а достатньо просто буде пройти по лінку в мережі про яку ти знаєш, що там нічого підробити не можна;
            • клієнти і партнери при виборі можуть надавати перевагу таким відкритим прозорим компаніям, тощо.
            Звичайно тут традиційно всі починають думати про конкуренцію, ноу-хау, і що такі всякі процеси прийняття рішень мають бути закритими, то задумайтеся про те, що є інший підхід — повна відкритість. Згадайте наприклад, як компанія Ілона Маска спеціально відкриває патенти і деталі проектів для усіх, щоб всією спільнотою зацікавлених покращувати їх і реалізовувати різними компаніями — в результаті виграють усі і має місце вже конкуренція конкретних реалізацій замість монополії на технологію, ідею. Ну а з іншої сторони згадайте про війни патентних тролів і тд.
            Для чого це децентралізованій мережі?
            Наша платформа має служити хороши прикладом і грунтом для появи таких відкритих компаній і допомагати їм отримувати перевагу над закритими. Цим вона здобуватиме цінність в очах усіх учасників, і здобуватиме нових прихильників.
            Звучали ідеї, що це вже реалізовується іншими сервісами, або що краще хай це буде окремий додаток — на мою думку краще, коли все буде в єдиній мережі, тоді всі ці можливості і деталі збільшують її цінність і потенціал. Нам потрібно придумувати і створювати все більше і більше стимулів для того, щоб нові люди зацікавилися мережею і прийняли рішення зареєструватися у ній.
            Звучали застереження, що певно важко буде перевіряти, чи людина дійсно є власником певної компанії — це буде окрема задача зі своїми рішеннями.
            Чи актуально це зараз у проекті — на мій погляд ні, це про майбутнє.
            Чи завадить такий функціонал у системі — не бачу чим, але бачу що додасть цінності.
            Що до “конфлікту” з прихованням і вільним створенням задач
            Як тільки ми прийдемо до того, що пора впроваджувати представництва організацій у мережі — автоматично в межах цього буде реалізовано власника/засновника компанії і його відповідні повноваження. Без варіантів, бо це має бути відображенням фактичної ситуації у компанії.
            Повноваження власника є невід’ємною частиною функціоналу реєстрації компанії/організації. Тому голосування “«Власник організації» та його особливі повноваження. Чи варто створювати такий функціонал?" не є коректним. Коректним може бути хіба голосування про те, чи реалізовувати можливість створення представництва компаній (по-іншому: реєстрація організації).
            Надіюся, тепер зрозуміло, чому це голосування по-хорошому має бути прихованим: бо воно не є коректним і не несе користі, а не те, що я щось там собі придумав, хочу це протягнути і стараюся приховати все що цьому суперечить, чи заважає.
            Оскільки що до приховання є розбіжності, то буде створено адміністративне голосування що до цієї ситуації.
            А що до створення функціоналу для реєстрації організації/компаній, то фактично згідно оцих проведентих голосувань вже прийнято рішення, що цього функціоналу не потрібно. З чим усіх і вітаю.
            Маю надію, що з часом ми ще повернемося до цього питання. А поки що питання по факту закрите, робимо просто демократичні групи.
        • цифрові ключі (база публічних ключів організацій) — можливість укладання договорів з цифровими підписами між учасниками
        • публічний рахунок з multi-signature
        • можливість випуску акцій
      • Публічна репутація партнера
      • Проведення тендерів
      • Третейські суди
    • B2C
      3 Oct
      Представництво організацій (аналог сторінки у Facebook)
      3 Oct
      • якісний фідбек від користувачів (ніяких анонімів і фейкових акаунтів)
      • проведення акцій, вікторин
Мета: створити можливість організації відкритої колективної системи прийняття рішень по будь-якому питанню, включаючи вибір персони на відповідальну посаду.
На мою думку це буде об’єктивно краще, ніж те, що маємо зараз (прийняття рішень за закритими дверима, прийняття рішень простою більшістю голосів).
Зауваження, критику, доповнення можете залишати тут, або на yura.des@gmail.com
По проекту:
13 Jun
  • Для поширення та участі:
    24 Jul
  • Словник термінів і понять:
    19 Apr
    • Ідеї проекту:
    • "Платформа", "мережа", "система" і "робоча група"
      1 May
      Платформа "Сила Довіри" — це назва технічного рішення (протокол і реалізація) для об’єднання людей.
       
      А мережа — це люди, які об’єднані за допомогою цієї платформи, запущеної на комп’ютерах учасників.
       
      В межах такої мережі учасники використовують слово система, коли мають на увазі запущену реалізацію платформи на своїх комп’ютерах, де вони є зареєстровані як учасники, і куди вони заходять щоб робити різні дії (бути в системі, в мережі).
       
      Первинну таку мережу ми називаємо: громадська мережа "Сила Довіри".
      І в цій мережі між такими об’єднаними людьми можуть утворюються різні спеціалізовані робочі групи (або просто групи).
       
      На даній платформі можна організувати й інші незалежні мережі і всередині у них будуть групи і тд, але такі мережі вже мають мати іншу назву, ніж "Сила Довіри". Ця назва думаю буде закріплена за первинною мережею, створеною на даній платформі.
    • Сервіси на платформі (сервіси у системі)
    • Енергія, бали активності
    • Рівень довіри
      22 May
      В системі можна буде висловлювати довіру/недовіру іншим учасникам. На основі таких суб’єктивних оцінок буде вираховуватися результуючий показник рівня довіри персони у системі.
      Залежно від рівня довіри персоні будуть доступні/недоступні деякі дії (наприклад голосування у деяких питаннях, можливість запрошувати інших людей в мережу), чи право займати певні посади.
      Люди з високим рівнем довіри можуть мати більшу швидкість відновлення енергії і тд.
      Варто пам’ятати про те, що довіру дуже важко здобувати, і дуже легко втратити.
    • Експертний рівень
      24 May
      Гілка документу — "Рейтинг експертів".
      Учасники мережі матимуть можливість оцінювати професійність одне одного в тій чи іншій галузі.
      На основі таких суб’єктивних оцінок за спеціальним алгоритмом зважування буде виводитися результуючий рівень експертності персони у кожній з вказаних нею галузей.
       
      У деяких складних голосуваннях може встановлюватися допуск по професійному рівню, тож рішення у таких задачах буде залежати від професіоналів.
    • Ще є "Детальний довідник" системи, де описані деякі інші сутності.
    • Технічне рішення:
    • Повний клієнт системи (full client)
      24 May
      Це є програмний комплекс, який потрібно скачати з сайта або репозиторія проекту, та встановити на персональному комп’ютері, або сервері.
      Для повноцінної підтримки мережі клієнт має працювати постійно і бути підключеним до інтернету.
      При першому запуску такий клієнт підключається до активних нод мережі і відбувається синхронізація бази даних (триває вже біля години на Windows і біля 5хв на Linux).
      Повний клієнт складається з 4 основних компонентів:
      • інсталятор
      • база даних
      • ядро (підтримує з’єднання, обробляє всі повідомлення в мережі згідно заданої логіки)
      • веб-клієнт (будує інтерфейс і дозволяє взаємодіяти з ядром)
    • Легкий клієнт (lite client, ще має бути розроблений)
      24 May
      Це має бути додаток, який встановлюється на телефон, планшет або персональний комп’ютер.
      По суті це є браузер з деяким додатковим функціоналом для збереження та використання персональних ключів.
      При запуску такий клієнт під’єднюється до активних нод і працює використовуючи їх ресурс.
      Легкі клієнти не мають ні бази даних, ні логіки обробки повідомлень. Завдяки цьому вони швидко встановлюються, швидко запускаються і не потребують очікування синхронізації з мережею — вони зразу готові до роботи.
    • Нода (node), супернода (supernode)
      24 May
      Нодою називається комп’ютер, на якому встановлений повний клієнт системи.
      Ноди виконують базові функції підтримки роботи мережі: перевірка, збереження та поширення інформації про дії учасників.
      Всі активні ноди стараються тримати постійний зв’язок між собою і моментально обмінюються повідомленнями про кожну нову дію. Таким чином відбувається синхронізація єдиної бази даних між усіма нодами. Чим більше є активних нод у мережі, тим вона стабільніша і надійніша для учасників з точки зору захисту бази даних від підміни та підтримки системи в робочому стані.
      Для прикладу роботу мережі криптовалюти Bitcoin підтримують біля 6000 активних нод (станом на 2016-2017рр).
      Супернодою називають комп’ютер, який знаходиться постійно онлайн і у якого правильно налаштовані порти для вхідних з’єднань. Певна кількість супернод потрібна для згладження ситуацій, коли інші ноди періодично включаються-виключаються. Тобто вони забезпечують той мінімум нод до яких завжди можна підключитися для роботи в мережі.
      Основна маса нод мережі — це будуть комп’ютери користувачів, які зазвичай включені в робочий час і вимикаються на ніч, тому вони не є супернодами.
    • База даних (database)
      24 May
      Інформація про кожну дію учасників, а також додаткова метаінформація зберігаються у єдиній базі даних.
      Фізично база даних знаходиться на кожній ноді, вона є компонентом повного клієнта.
      База даних з часом росте у розмірі і займає все більше місця на диску.
      На кожній ноді зберігається ідентична копія бази даних.
  • Статус проекту:
    17 Jan
    Зараз в процесі (оновлено 12.11.2022):
    *тут у списках пункти закреслені на стільки, на скільки вони завершені, дата в кінці рядка — це дата завершення пункту
    • Виправлення проблем та помилок:
      17 Jan
      • Виправлення великої кількості накопичених помічених дрібних проблем
      • Випралення проблем згідно списку по пріоритетах.
      • При синхронізації час "до завершення", який відображається дуже сильно відрізняється від реального
      • деякі виправлення 12.11.22
      • виправлення проблем та покращення в робочій та тестовій мережі (публікація) 15.02.22
      • виправлення деяких помилок у робочій мережі (публікація) 24.11.21
      • виправлення деяких помилок у робочій мережі 17.11.20
      • виправлення проблем з процесом реєстрації у робочій мережі 07.11.20
      • перероблено загрузку та ініціалізацію, щоб вирішити проблему великого початкового об'єму даних для завантаження; покращено плавність переходів. 16.09.20
      • зроблено 7 виправлень і 16 покращень у коді та інтерфейсі 29.07.20
      • зроблено 8 виправлень і 5 покращень у коді та інтерфейсі 22.07.20
      • зроблено 3 виправлення і 10 покращень у коді + оновлення 2 базових бібліотек 21.07.20
      • зроблено 10 виправлень і 13 покращень у коді та інтерфейсі 01.06.20 (публікація)
      • Зміни в інтерфейсі, додано дорожню карту 19.05.20
      • зроблено 12 виправлень і 6 покращень у коді 15.05.20
      • додано 11+ покращень і 18+ виправлень у коді 26.04.20 (публікація)
      • зроблено 11 виправлень і 8 покращень у коді 14.04.20
      • виправлення проблем відображення голосів у деяких задачах, та проблему з вкладкою системи, якщо її залишити на деякий час 12.04.20
      • виправлення проблем синхронізації 27.03.20
      • Оновлення компонентів системи 24.07.19
        24 Jul
        • По максимуму оновити gems
        • Добитися проходження всіх тестів
        • Добитися синхронізації в демо-мережі
        • Добитися синхронізації в робочій мережі
        • Оновити скрипт встановлення ноди на Linux
        • Оновити всі робочі і демо ноди, перевірити новий скрипт
        • Оновити інсталятор для Windows
        • Вирішення серйозної проблеми з новою версією Ruby (report)
        • Вирішення проблеми з MongoDB коли є крилиця в шляху
        • Додати релізи на GitHub, оновити лінки на сайті
        • Перехід на новішу версію MongoDB після вирішення блокуючої проблеми
        • Додати обробку оновлення яке потребує скачування інсталятора
        • Оновлення в демо-мережі
        • Оновлення в робочій мережі
      • ще виправлення для синхронізації 24.05.19
      • виправлення проблем синхронізації 23.05.19
      • виправлення проблем при відновленні ключів 19.05.19
      • виправлення деяких проблем 23.04.19
      • виправлення помилок які назбиралися у Sentry 07.01.19
    • Реалізація функціоналу згідно визначених спільнотою пріоритетів:
      5 Jan
      • Базовий легкий клієнт (ітерація 2)
        17 Apr
        • зробити таблицю різниці роботи з повного клієнта і роботи через браузер
        • взаємодія з трьома нодами
        • додавання надійного ключа
        • відновлення надійного ключа при втраті
      • Розробка сервісу Робочі групи (ітерація 2) (голосування за пріоритети у розробці)
        27 May
        • виправлення помічених помилок
        Наступна ітерація (коли сформується хоч одна група з 20 осіб)
        27 May
        • Реалізація функціоналу "Безпека" (приватні задачі у групі)
        • у групах свої параметри і свій аналіз активності учасників
        • Ієрархія груп
          27 May
          Надзвичайно неефективно впроваджувати даний функціонал на даному етапі розробки, якщо він вимагає багато роботи.
          27 May
          Так, цей функціонал буде на пізніших ітераціях.
        • Тести
          27 May
          • створення - full_sync - partial_sync
          • membership - partial_sync
          • важливі повідомлення у групі
          • позначення прочитаним
          • нарахування балів активності
        27 May
        Привіт, Юра! Поки ми вирішуємо питання з кооперативом, в мене є ще група людей, більш ніж з 20 осіб. Вони теж хочуть впроваджувати нові технології у суспільному саморегулюванні. Ось сайт, де можливо буде розгорнути платформу для голосувань: https://mgukraine.org
        27 May
        Гарно, але як я вже казав на інтеграцію я погодився лише один раз. Тим більше це виглядає як проект у напрямку громадянського суспільства. Тому їм ми можемо порадити просто завести групу у нашій мережі для вирішення своїх питань. Якщо їх таке цікавить — хай контактують, ми допоможемо, відповімо на питання.
        27 May
        Дякую, Юра, а можна в двух словах - як їм "завести групу", які кроки перші, другі, треті?
        27 May
        Для початку хай спробують створити тестову групу тут — http://power-of-trust.net/ua/demo
        Як створити думаю розберуться, а про додавання учасників є така інструкція — https://checkvist.com/checklists/621826/tasks/27998535
        Завершено
        27 May
        • організація фінального тестування
          27 May
          • підготувати публікації для поширення
          • створити детальний план тестування
          • доступ до інформації по тестуванню
          • створити 3 скрінкасти 09.05.18
            27 May
            • знайомство з тестовою мережею
            • знайомство з групами
            • приклад тестування певного пункту
          • створити текстовий+голосовий сервер на Discord 02.05.18
          • доробити демо-сторінку
          • зробити інсталятор для демо-мережі
          • виправити проблему початковї синхронізації
          • система збору помилок при тестуванні 18.04.18
            27 May
            • спробувати Sentry
            • JS
            • Ruby
            • завершити налаштування
            • можливість додати повідомлення при виникненні помилки
            • оновленя основної і тестової мережі
        • спробувати реалізувати деструктори 01.04.18
        • виправлення проблем з запуском усіх тестів разом 29.03.18
        • індикатор нових учасників чи заявок у групі 16.03.18
        • неактивність персони в базовій мережі не має впливати на врахування голосу людини в групі 08.03.18
        • при модифікаціях змінюються каунтери для типів і регіонів 27.02.18
        • коли ховають групу — теж зменшувати каунтери 27.02.18
        • редагування групи працює і в контексті групи через правий клік по тайтлу 27.02.18
        • виправлення проблем редагування опису 27.02.18
        • правильне редагування опису групи 23.02.18
        • десь показувати опис групи 23.02.18
        • Вартовий має мати можливість змінити назву групи
        • Лише Вартові можуть змінювати регіон, тип і опис групи
        • перевірка недопустимих символів у назві групи згідно правил
        • Вартовий може ховати групи
        • Сторінка правил для груп
          27 May
          Створення "правил для груп"? В децентралізованій мережі кожна одиниця має право приймати участь в створенні загальних правил. Нав'язування будь-яких правил - це внесення елементу централізації в діяльність групи. Намагання внести власні (так-звані "загальні" правила) в діяльність поєднаних децентралізованих нод - це не допустиме перебільшення повноважень. Це одна із причин, чому цей проект буде погано сприйматися. Не повинно бути жодного елементу, чому цей проект має погано сприйматися. Виробленням правил для груп мають займатися лише самі групи і їх учасники. Всі інші "правила" треба hardcode (по суті те, що закладено в коді це і є єдині правила, які може нав"язувати розробник). Це черговий елемент централізації, який неправомірно і помилково Юрій Бабак вносить в цей проект. Все сказане мною прошу сприймати, моєю особистою думкою.
          27 May
          Без правил для груп можуть появитися групи, які порушуватимуть чинне законодавство країни і цим будуть дискредитувати всю мережу
          27 May
          наличие в сети групп-нарушителей никак не дискредитирует сеть (инструмент не несет ответственности за то, как его используют)
          27 May
          Від контенту і активності яка відбувається в мережі залежить її репутація в народі. Саме тому у соцмережах та сервісах є спеціальні люди
          27 May
          это в централизованых сетях, а кто будет содержать здесь "специальных людей"?
          27 May
          Всі учасники мережі через внески.
          , які моніторять і закривають певні групи, видаляють контент. І при перевірках вони керуються певними правилами, які були встановлені.
          .
          Зараз вже є загальні правила мережі, правила для Форуму, аналогічно будуть і для груп.
          Згодом ці всі правила будуть редагуватися і вдосконалюватися колективно, коли доробимо відповідні інструменти. А поки що, оскільки ніхто з учасників спільноти не запропонував ніякої версії правил (відповідний докумен я ще 3.03.2017 створив для колективного редагування), мені доведеться самому формувати базову версію цих правил.
        • Загальна інформація про сервіс груп
        • додаткові підказки на початку роботи з групою
        • коректний підрахунок енергії та балів активності при роботі в групі
        • Голосування за виключення учасника з групи
          27 May
          • спеціальний тип голосування
          • персона має пропадати зі списку учасників
          • для персони спеціальне відображення статусу в групі при виключенні
          • перевірка статусу учасника при діях
          • повідомлення учаснику про його виключення
          • ситуація, коли вартового виключили з групи
          • делегат має ставати неактивним
          • не приймати повторні заявки на приєднання до групи, якщо є діюче рішення про виключення
          • аналіз усіх задач групи на досягнення кворуму, бо змінилася кількість активних учасників
          • тести
        • Замерджити мастер і зробити рефакторинг вікон і форм груп
        • Простіший інтерфейс створення задачі
          27 May
          • випадаючий список доступних для голосування змінних
          • позбутися вибору типу, бо він відомий для кожної змінної
          • локалізація змінних групи
          • Для деяких типових задач заголовок та опис заповнюються автоматично
          • кращий вибір для: "що визначає" і "тип голосування"
          • переклад термінів
          • корекція роботи в основній мережі
        • Зміна параметрів групи голосуванням учасників групи
          27 May
          • голосування за зміну назви групи
          • кількість потрібних запрошень для нового учасника
          • вибір Вартового групи
          • повноваження Вартового мають діяти лише в межах групи
          • кількість Вартових
          • % голосів учасників групи для прийняття рішення
          • аналіз усіх задач при зміні ціього параметра
          • застосування рішення проти зациклення
          • повідомлення у групі про зміну значення параметра
        • коректне оновлення інформації в групі коли учасник покидає групу
        • Розширена робота Вартових
          27 May
          • можливість блокувати певні дії користувача
          • інтерфейс блокування
          • повідомлення про блокування
          • блокування групи дії
          • перевірка роботи блокування для усіх дій і груп дій
          • коректна робота в групі
          • коректна робота в базовій мережі
          • у картці персони показуються заблоковані дії і термін
        • Параметр початкової кількості запрошень
          27 May
          • залежність від кількості активних учасників групи
        • повідомлення про активність у групі має бути в межах групи
        • Позбутися зайвого кроку при реєстрації, якщо подавалася заявка і отримано достатньо запрошень
        • Географічна прив’язка груп
        • Список існуючих груп
          27 May
          • дерево типів
          • вигляд списку
          • вкладки
          • деталі
        • Вікно створення групи
          27 May
          • дерево типів
          • скорочення і повна назва типу
          • лише Вартовим дозволяти редагувати дерево типів (бо там спеціальних формат і складності в UI)
        • Власне створення групи
          27 May
          • перевірка прав при операціях з типами груп
          • перевірка, чи тим з правильного дерева
        • Пункт у головному меню
        • Задачі в межах групи
          27 May
          • правильно відображати кількість учасників у задачі відносно учасників групи
          • Створення задачі в групі
          • Список задач групи
          • При усіх діях в задачах перевіряти, чи персона належить до групи
          • Рубрикатор групи
          • Перевірка прав при роботі з рубриками
          • Індикатори, повідомлення, динамічна поява задачі
          • Коректна робота індикаторів непрочитаного
          • Позначення всього прочитаним через контекстне меню по індикатору
        • Реалізація вимоги до початкової кількості учасників
        • Повідомлення про отримані запрошення
        • Контекст групи (перегляд групи)
          27 May
          • відображення ієрархії
          • меню
          • список учасників групи
          • список запрошених
          • список заявок на приєднання
          • свій робочий стіл
          • дропдаунт участі у групі
        • Можливість запросити до новоствореної групи
          27 May
          • діалог запрошення
          • запрошення в один клік згідно заявки
        • Можливість приєднатися до існуючої відкритої групи
          27 May
          • заявка на приєднання
          • відкликання заявки на приєднання
          • приєднання якщо є достатньо запрошеннь
        • Можливість покинути групу
      • Розробка сервісу Форум (ітерація 2)
        25 May
        редагування рубрики публікації
        • редагування типу і походження публікації
        • можливість додати аннотацію до запропонованої публікації
        • підписка на появу нових матеріалів
        • персональні повідомлення про появу нових матеріалів по підписці
        • Посилання на публікації автора у картці персони
      • Розробка сервісу База знань на основі сервісу Форум
        25 May
        • правила
      • Сервіс повідомлень на email — 80%
      • Висловлення довіри/недовіри — 30% (обговорюються варіанти формули)
      • Розробка сервісу Передбачення (ітерація 1)
        5 Jan
        • Сервіс запрацював у робочій мережі 31.12.2021 (публікація)
        • Базова робоча версія (MVP) почала працювати у тестоій мережі 03.11.20
      • Базова фінансова система
        13 Mar
        • Баланс на рахунку
          13 Mar
          • власне зміна балансу сторін при поповненні
          • спеціальний новий постійний запис для транзакції
          • доробити необхідні перевірки при транзакціях
          • спрощення виводу грошових сум
          • Відображення балансу в інтерфейсі
          • відображення у картці персони
        • Вікно рахунку
          13 Mar
          • Кнопка поповнення
          • Активні заявки
          • індикатори непрочитаного при оновленні по заявці
        • Поповнення рахунку
          13 Mar
          • Діалог поповнення
          • Вибір фін-менеджера, фільтр
          • Показувати доступні резерви
          • Підбір менеджера по резерву якщо треба
          • динамічне оновлення резервів
          • формування і перевірка запису заявки на поповнення
          • обмін приватними повідомленнями у заявці
          • отримання різних повідомлень про оновлення по заявці
          • зарахування коштів на рахунок
        • Виведення коштів з рахунку
          13 Mar
          • Діалог виведення
          • Реквізити для переказу
          • Кошти заблоковані для виведення
          • Зміна балансів
          • Блокування коштів при виведенні
          • Додаткові перевірки на допустимість сум
        • Задача з рейтингом методів переведення коштів
        • Посада фін-менеджера
        • Вікно заявки на поповнення
          13 Mar
          • показується вікно
          • приходять реквізити від фін-менеджера, перевіряєтья публічна чексума
          • зміна статусів: створено, реквізити відправлено, кошти відправлено, завершено, скасовано
          • усі типи повідомлень
          • усі кнопки
          • усі підказки відносно поточного статусу
        • Кабінет фін-менеджера
          13 Mar
          • Список заявок
          • Індикатор появи нової заявки, позначення прочитаним, push-повідомлення
          • Відображення балансу резервів
          • Прийняття заявки
          • Відправка шифрованих реквізитів
          • Збереження реквізитів для методів переведення коштів
          • Шифрування для збереження даних
          • Робота шифрування у легкому клієнті
          • оновлення реквізитів
          • позначення реквізитів неактивними
          • видалення реквізитів
        • Приватні шифровані повідомлення (потрібні для комунікації сторін)
          13 Mar
          • Розібратися з потрібною криптографією
        • Транзакції між учасниками
          13 Mar
          • Діалог переказу
          • Вибір персони
          • Показ останніх транзакції з обраною персоною
          • Список транзакцій у вікні рахунку
          • Створення транзакції і зміна балансів
          • персональне повідомлення про переказ
          • індикатор непрочитаного переказу біля рахунку, біля транзакції
        • Спільний Фонд
          13 Mar
          • Сплата внесків
          • Діалог внесення коштів
          • Створення транзакції і зміна балансів
          • Індикатор сплаченого внеску за поточний місяць і передоплата на наступні
          • Повідомлення про успішну/неуспішну сплату
          • Окрема обробка місцяця який передує першому стягненню внесків
          • Відображення балансу фонду
          • Вікно фонду
          • Список транзакцій
          • Індикатор непрочитаних транзакцій
        • Обробка ситуацій типу коли фін-менеджер втрачає посаду
        • Обмежена можливість руху коштів Вартовим
        • Голосування за зміну аналізу активності на сплату внесків
        • Блокування деяких дій для неактивних персон
        • Виправлення деяких візуальних проблем
        • Добитися проходження тестів
        • Додаткове тестування різних сценаріїв синхронізації з новими діями
        • Перше тестування у демо-мережі
        • Адаптувати функціоналу для легких клієнтів
          13 Mar
          • персона
          • поповнення
          • p2p переказ
          • виведення
          • Фін-менеджер
          • поповнення
          • виведення
          • Захист від XSS
          • Push-повідомлення
        • Адаптувати нові діалоги для мобільних
          13 Mar
          • вікно рахунку
          • поповнення
          • виведення
          • переказ
          • вікно діалогу заявки
          • кабінет фін-менеджера
          • внески
          • спільний фонд
        • Виправлення помилок
        • Покриття тестами
        • Перевірка кандидатури Вартовими
        • Добитися проходження усіх тестів
        • Добитися синхронізації у робочій мережі
        • Фінальні перевірки і виправлення
        • Оновлення в робочій мережі
        завершено 9.03.2020
      • Базовий легкий клієнт (можливість працювати з браузера, без необхідності скачувати і встановлювати систему на комп'ютер)
        17 Apr
        • реліз базового легкого клієнта у робочій мережі
          17 Apr
          • перевірити ще раз проходження всіх тестів після мерджа у мастер 14.04.19
          • налаштування сервера 14.04.19
          • вибір домена 14.04.19
          • виправлення виявлених проблем 15.04.19
          • зміни на сайті проекта 16.04.19
        • виправлення знайдених помилок 14.04.19
        • тестування у тестовій мережі 12.04.19
        • тестування фугкціоналу груп 12.04.19
        • добитися, щоб проходили усі тести (9/9) 03.04.19
        • виправлення критичної проблеми при синхронізації 28.03.19
        • робота груп у легкому клієнті і вигляд на моб
          17 Apr
          • вигляд контексту групи 24.03.19
          • вікно списку членів групи 24.03.19
          • попап запрошення в групу 24.03.19
          • вікно списку груп 25.03.19
          • діалог створення групи 25.03.19
          • кнопка статусу в групі 26.03.19
          • автоматичне приєднання при наявності заявки 26.03.19
          • робота усіх повідомлень як і для повної ноди 27.03.19
        • ще виправлення 20.03.19
        • ще виправлення 19.03.19
        • пачка виправлень 18.03.19
        • повна адаптація роботи з задачами на моб
          17 Apr
          • Коментарі до задачі 12.03.19
          • перегляд рішення 12.03.19
          • коменти і голоси до рішення 13.03.19
          • аргументи за і проти (вкладки) 13.03.19
          • вигляд елементів вікна задачі 13.03.19
          • коменти до аргументів і голоси за аргументи (вкладки) 14.03.19
          • робота фокусування з повідомлення на усі типи елементів 14.03.19
          • вікно створення задачі (усі типи задач) 16.03.19
          • вигляд задачі яка очікує підтримки 16.03.19
          • вигляд діалогу розподілу уподобань 17.03.19
          • виправлення проблеми з жестом закриття 17.03.19
        • виправлення помилок по репортах 11.03.19
        • адаптація вигляду правил для моб і виправлення помилок 08.03.19
        • заявка на відновлення ключів має працювати на моб для усіх учасників 07.03.19
        • поправити вигляд усього процесу реєстрації на моб 05.03.19
        • імпорт існуючих ключів 05.03.19
        • виправлено одну критичну помилку та кілька дрібних 01.03.19
        • виправлення деяких ситуацій 28.02.19
        • пачка виправлень 27.02.19
        • виправлено зламані теги до задачі і часту помилку при створенні задач з рішенням 26.02.19
        • є проблема, що на деяких девайсах сторінка не грузиться 25.02.19
        • виправлення пачки візуальних проблем на моб 25.02.19
        • пачка виправлень 24.02.19
        • відлагодити роботу повідомлень на мобільному 24.02.19
        • пачка виправлень 23.02.19
        • знайдено рішення для неприємної проблеми на Android 22.02.19
        • пачка виправлень 21.02.19
        • інтеграція нового домену на демо-сторінці 21.02.19
        • пачка виправлень 20.02.19
        • повідомлення про можливість отримання повідомлень 20.02.19
        • опція для відключення автоматичного ховання повідомлень 20.02.19
        • у налаштуваннях можливість актвувати/диактивувати підписку на моментальні повідомлення 20.02.19
        • виправлення проблем у інших браузерах 19.02.19
        • зробити нормальний вигляд і тексти для push-повідомлень 18.02.19
          17 Apr
          • події що стосуються мене (половина) 17.02.19
          • важливі події в мережі 18.02.19
          • деякі індикатори
          • повідомлення у загальному чаті
          • заявка на запрошення
          • реєстрація персони
          • нова задача
        • виправити ворнінги які появилися після переходу на нову версію Ruby 16.02.19
        • спробувати зробити, щоб позначення прочитаним працювало без відкриття вікна (пізніше зробимо) 14.02.19
        • коректна робота відкриття повідомлення, коли вікно закрите 14.02.19
        • спробувати push notifications 12.02.19
        • добитися роботи модулів на Ruby 2.5 на локалі і на новому сервері 10.02.19
        • проблема з застарілим Ruby і Debian на сервері, потрібен переїзд на новий сервер 10.02.19
        • розібратися з Periodic background sync 08.02.19
        • жест закриття верхнього діалогу + підказка 07.02.19
        • індикатори відстутності інтернету і з'єднання з сервером 04.02.19
        • вирішено проблему з Sec-WebSocket-Extensions: permessage-deflate 04.02.19
        • базова робота offline 01.02.19
        • виправлення проблем з продуктивністю 01.02.19
        • виправлення роботи деяких діалогів при відсутності конекта 01.02.19
        • додати підтримку Sec-WebSocket-Extensions: permessage-deflate 22.01.19
        • basic PWA 17.01.19
        • випралення проблем з індикаторами в групі 13.01.19
        • при створенні запрошень вони мають зберігатися локально, а не на сервері 10.01.19
        • індикатори непрочитаного в контексті групи 10.01.19
        • в певних ситуаціях розсилати повідомлення не усім підключеним браузерам, а лише конкретним користувачам 10.01.19
        • Заявки на запрошення 09.01.19
        • у налаштуваннях має бути кнопка щоб скинути свої непрочитані індикатори 09.01.19
        • Важливі події у системі 07.01.19
        • MyChoise 07.01.19
        • Події що стосуються мене 07.01.19
        • помилки знайдені при тестуванні груп 23.12.18
        • репорти що назбиралися у Sentry 22.12.18
        • налаштувати адміністрування суперноди 8.12.18
        • реєстрація
          17 Apr
          • налаштування сервера для роботи базового легкого клієнта 06.12.18
          • забезпечення роботи у всіх основних браузерах 05.12.18
          • піддомен для супер-ноди для легких клієнтів у демо-мережі 02.12.18
          • організація ключів адміна супер-ноди 30.11.18
          • добитися повної роботи публічної ноди по https (wss) 26.11.18
          • відновлення ключа з резервної копії 25.11.18
          • перевірка збереженого файла тимчасового ключа 23.11.18
          • робота з тимчасовим ключем 22.11.18
          • генерація ключів 22.10.18
          • генерація ключів з набору слів 22.10.18
          • пінкод 02.11.18
          • збереження ключа в мережі 02.11.18
          • спрощено процес реєстрації 05.11.18
          • ще спрощення процедури реєстрації 18.11.18
          • можливість зберегти резервну копію тимчасового ключа 21.11.18
        • для тестування зробити можливість реєстрації у демо-мережі 06.12.18
        • алгоритм створення дії в мережі 05.12.18
        • працює створення складної дії, як от задача з кількома рішеннями 20.11.18
        • накладання цифрового підпису на дії у браузері 19.11.18
        • робочий приклад використання бібліотеки 02.11.18
        • вибір JS-бібліотеки для криптографії у браузері 15.10.18
      • Сторінка діяльності посадовців 12.10.18
      • Створення демо-сторінки і тестової мережі
        5 Aug
        Завершено
        5 Aug
        • Зміни на сайті проекту 03.08.18
        • Сторінка для доступу до веб-інтерфейсів 26.04.18
        • Окремий інсталятор клієнта для можливості скачати і зареєструватися
        • Певна кількість робочих нод (3/5 користувачів)
        • Сформувати пак на основі гілки з групами
        • Свої оновлення мають бути
        • Створити задачі для визначення базових параметрів і вартового
    • У фоновому режимі:
      8 Jul
      • Інтеграція сервісу голосування з проектом Tech Generation
        7 Oct
        • необхідне api з їх сторони
        • спеціальна модифікація нашої системи
        • автоматична реєстрація на основі даних від /api/get_user_data
        • правильно показувати індикатори непрочитаного
        • додаткові параметри у конфігу
        • зміни в інтерфейсі
        • модифікація алгоритму прийняття рішення у деяких задачах
        • тестова інтеграція
        • виправлення проблем
        • формування окремого пакета зі своїми оновленнями
        • налаштування на роботу з новим доменом по https
        • фінальна інтеграція і запуск
      • репозиторій на GitHub — 80%
        21 Jul
        • refactoring — 63%
          21 Jul
          • розбиття найбільшого файла 20.07.20
          • спрощення scss 15.07.20
          • оптимізація локального запуску нод для пришвидшення розробки та тестування 19.11.19
          • перевірка роботи всіх існуючих тестів 19.11.19
          • перехід на нову версію монго-драйвера 20.06.19
          • добитися, щоб поточні тести проходили 12.08.18
          • переробити щоб запрошення працювали як звичайні плаваючі записи, а не оброблялися окремо 07.08.18
          • заміна старих контролерів і обробників дій на нові 05.08.18
          • класи контролерів для взаємодії між модулями
        • integrated dev tools — 71% (останні зміни 12.07.20)
        • Ractive.js
          17 Apr
          • перехід на Ractive 0.8 — 100%
          • оновлення гілки Groups до Ractive 0.8 — 100%
          • перехід на Ractive 0.9
        • Ruby
          28 Jun
          • Основні модулі
          • Ruby 2.0 (02.2015) → Ruby 2.5.5 (03.2019)
          • Ruby 2.5.5 (03.2019) → Ruby 2.6.3 (04.2019)
          • Dev tools
          • Ruby 2
        • Sinatra
          28 Jun
          • v1.4.5 (April 08, 2014) → v1.4.8 (January 30, 2017)
          • v1.4.8 (January 30, 2017) → v2.0.5 (December 22, 2018)
        • Thin web-server
          28 Jun
          • v1.6.3 (October 02, 2014) → v1.7.2 (July 08, 2017) — більше не оновлюється станом на 28.06.19
        • EventMachine
          28 Jun
          • v1.0.7 (February 10, 2015) → v1.2.7 (May 12, 2018) — більше не оновлюється станом на 28.06.19
        • Mongo
          17 Apr
          • MongoDB
            18 Jul
            • v2.0.9 (04.2013) → v4.0.10 (31.05.2019) — лише на сервері (виявилося, що тулзи працюють надто довго, через що в кілька разів сповільнилися тести — report)
            • v2.0.9 (04.2013) → v3.2.22 (26.12.2018) — для розробки
            • v3.2.22 (26.12.2018) → v4.2.0-rc2 (18.07.2019) — лише на локалі
          • Ruby driver
            28 Jun
            • v1.10.2 (05.2014) → v2.9.0 (20.06.2019)
            • боротьба з погіршенням продуктивності
        • Slim
          17 Apr
          • v2.1.0 —> v3.0.9
        • NW.js
          21 Jun
          • v0.12.1 / Chromium v41 (13.04.2015) → v0.39.1 / Chromium 75 / Node 12.3.1 (18.06.2019)
        • jQuery
          21 Jul
          • v2.1.1 (May 1, 2014) → v3.5.1 (May 5, 2020)
        • jquery.svg
          21 Jul
          • v1.4.5 (28 Apr 2012) → v1.5.0 (2 Nov 2014) — більше не оновлюється станом на 21.07.20
      • Формування бази знань проекту та цього концепт-документу (останні доповнення 28.11.17)
      • Робота з матеріалами (11.06.18)
      • інсталятор для OS X — 85% (призупинено, потрібен розробник під OS X)
      • технічна публікація на http://dou.ua — 10% (призупинено до готовності репозиторію)
      • Інтеграція сервісу груп для кооперативу E-Sprava
        15 May
        Призупинено, очікуються необхідні зміни на їх стороні.
        • продумування інтеграції
        • налаштування середовища розробки
        • спеціальна модифікація нашої системи
        • правильно враховувати енергію поточної персони
        • правильно показувати індикатори непрочитаного
        • автоматичне фокусування на групі
        • зміна інформації про систему
        • формування окремого пакета зі своїми оновленнями
        • зміни на їх стороні
        • фінальна інтеграція і запуск
        • підготовка навчальних матеріалів
        17 Apr
        Додаткова інформація:
    Повідомлення про оновлення публікуються у нашій групі — Громадська мережа "Сила Довіри"
    Архівний лог роботи над проектом (19.10.2014 - 05.01.2016):
    10 May
    05.01.2016 - Створено сайт http://power-of-trust.net/. Публікація у групі E-Democracy in Ukraine (2'100+ учасників).
    30.12.2015 - Поширення у невеликих спеціалізованих групах
    28.12.2015 - Створено інсталятор системи для Windows.
    20.12.2015 - Заповнено розділи "Правила" та "Допомога".
    14.12.2015 - Дороблено картку персони.
    08.12.2015 - Зроблено внутрішні повідомлення про важливі зміни у системі, окремо повідомлення про події що стосуються персони.
    27.11.2015 - Вдалося вже приховати службові процеси під Віндою, що зробило запуск системи легким для звичайних користувачів. (99% dev-preview)
    25.11.2015 - Додано більш зрозумілий для користувачів екран синхронізації з ознайомлюючими текстами про систему.
    15.11.2015 - Покращено швидкість і стабільність процесу синхронізації.
    08.11.2015 - Працює трекінг важливих події у системі у вигляді повідомлень для користувача.
    01.11.2015 - Реалізовано базову систему трекінга непрочитаних елементів. Без цього було дуже важко слідкувати за активністю учасників. (98% dev-preview)
    29.09.2015 - Додано рубрикатор для задач. Виявилося, що навіть у невеличкій групі, без рубрикатора список задач перетворюється в кашу, тому було прийнято рішення зробити його вже на цьому етапі. (97% dev-preview)
    15.09.2015 - Варті надано повноваження приховувати нехороші, або непотрібні записи.
    08.09.2015 - Вдалося підняти ноду на міні-компутері ODROID C+ (з ARM-процесором, 32bit)
    10 May
    Це є один з аналогів більш відомого Raspberry Pi
    . Уже постійно працють 4 суперноди (готуємося до dev-preview ;).
    25.08.2015 - З деякими ручними поправками система запускаєтсья на Mac OS X 10.9+
    16.08.2015 - Робоча версія під Linux (Ubuntu/Debian) без інтегрованого nw.js. Тепер на Лінуксі постійно працюють 2 суперноди. (96% dev-preview)
    25.07.2015 - Спробували в роботі обрання персон на посади. Працюють базові повноваження, різні для посад.
    19.07.2015 - Додані системні змінні для двох перших посад, які визначають кількість потрібних посадовців. (95% dev-preview)
    19.07.2015 - Працює подання/відкликання своєї кандидатури на посаду. Враховується неактивність кандидата.
    12.06.2015 - Реалізовано голосування по методу Шульце за кандидата на посаду. Враховується делегування, неактивність персон.
    24.06.2015 - Реалізовано делегування голосів (зараз тільки на рівні задачі). (93% dev-preview).
    11.06.2015 - Запрацювала лотерея в тестовому режимі (переможці отримують спеціальні бонусні бали які можна тратити на спеціальні можливості). (91% dev-preview).
    08.06.2015 - Тимчасова централізована система оновлення (89% dev-preview).
    29.05.2015 - Працює нарахування балів активності за дії і всі параметри (зараз це %) можна виносити на голосування (87% dev-preview).
    17.05.2015 - Працює голосування, визначення системних змінних і їх динамічний вплив на систему, визначається активність учасників, визначається чи прийняте рішення по питанню, є можливість запропонувати нове рішення задачі (85% dev-preview).
    19.04.2015 - Підключив NW.js щоб не залежати від дефолтового браузера користувача  (80% dev-preview).
    11.04.2015 - Багато виправлень по зауваженням, сильно перероблено вікно задачі (78% dev-preview).
    31.03.2015 - "Передчасна оптимізація" — зроблено.
    08.03.2015 - Другий етап тестування синхронізації пройшов досить вдало. Якщо є бажання спробувати — приймаю заявки по емейлу (єдина вимога — OS Windows). Це тестування буде тривати аж до запуску dev-preview.
    01.03.2015 - Перші тести на синхронізацію у вузькому колі
    28.02.2015 - Зроблено приклад загального чату на основі платформи (77% dev-preview)
    27.02.2015 - Покращено синхронізацію, розпізнаються елементарні конфліктні ситуації (75% dev-preview)
    20.02.2015 - Голосування за силу аргумента, динамічне сортування аргументів по зменшенню сили (73% dev-preview)
    07.02.2015 - Плюси/мінуси варіантів рішення, коментарі і відповіді на коментарі (70% dev-preview)
    22.01.2015 - Develper-preview 60% - створення задач з варіантами рішення
    10.01.2015 - Develper-preview 50% - готова базова синхронізація, маршрутизація, реєстрація по запрошеннях (цей пробний варіант має на меті створення платформи для обговорення розробки самої системи, кінцевий код буде опубліковано на github).
    17.11.2014 - Публікація цього першого базового документа.
    06.11.2014 - initial commit (proof of concept, dev-preview, локальна розробка).
    19.10.2014 - Поява ідеї щось робити у цьому напрямку.
  • Інструкції:
    26 Jul
    • Як запустити свою незалежну мережу використовуючи даний софт
      5 Mar
      Запуск нової мережі робиться так:
      1. Потрібно інсталювати систему в окрему папку, але (!) не запускати зразу після інсталяції;
      2. У файлі app/add_peers.txt потрібно видалити рядки з IP адресами супернод (так досягається що наша нода не скачає базу існуючої мережі, а буде мати свою чисту);
      3. Раз запустити систему, щоб пройшло оновлення;
      4. Можна визначити початкові значення змінних у app/SystemParams_mod.rb;
      5. Якщо хочеться щоб ця система працювала паралельно з іншою на одному компі, то потрібно поміняти порти у файлі app/conf_base.rb, інакше треба буде спочатку закрити одну і тільки потім запускати іншу;
      6. Запустити систему, зареєструватися у якості першого учасника. Оскільки це буде єдиний учасник то запрошення не потрібні;
      7. Якщо хочеться запрошувати інших у свою мережу (тобто це буде не тестова, а реальна мережа для певної спільноти), то:
      • Потрібно підняти десь суперноду (щоб працювала цілодобово, бажано кілька);
      • ІР цієї ноди прописати у app/add_peers.txt
      • Далі потрібно сформувати архів папки системи з усіма зміненими файлами і роздавати друзям такий архів.
      • Важливо, щоб у архіві була порожня папка personal_secret_keys і щоб у add_peers.txt були адреси супернод нової мережі.
      5 Mar
      >Як на рахунок "брендингу"
      З брендингом гірше, бо можна поміняти певні файли і розповсюдити систему у зміненому виді, але оновлення може ці файли переписати. Хіба що відключити оновлення, з усіма відповідними наслідками.
      Згодом коли буде децентралізоване оновлення, то кожна мережа зможе мати свої оновлення і такої проблеми не буде.
    • Запуск кількох нод на Linux
    • Як ділитися посиланнями на задачі/публікації в системі
      19 Apr
      Корисна інформація для учасників мережі.
      Коли вас питають, "а як ваша система виглядає?", чи "які ви там питання вирішуєте?", то пам’ятайте про оцю сторінку:
      https://ua.power-of-trust.net/ — основний екран
      https://ua.power-of-trust.net/#all_tasks — зразу відкриває список задач з рубрикатором
      Що це є за сторінка/сайт? Це є такий же клієнт який кожен з нас запускає у себе, але він запущений на сервері і працює цілодобово. Відрізняється він тим, що у ньому немає зареєстрованої персони, тож замість імені у верхньому правому куті там знаходиться назва сервера.
      Також якщо ви знаходитеся десь не за своїм робочим комп’ютером, або просто коли система у вас виключена, то через оцю сторінку ви можете легко бачити останню активність у мережі, чи мати швидкий доступ до своїх задач, тощо. Але опублікувати через цей сайт нічого не вийде, він тільки для читання.
      Якщо ви не пам’ятаєте адресу цієї сторіноки, тоді робіть так:
      В Google дайте пошук "сила довіри", на першому місці у результатах має бути наша стартова сторінка — відкриваєте її на тій сторінці є велика зелена кнопка "Подивитися, що зараз відбувається у системі" — вона відкриє оту сторінку з активністю в мережі.
      І ще одна корисна порада. Якщо Ви комусь хочете надіслати сторінку з певною задачею, чи публікацією у мережі, то потрібно на тій сторінці активності відкрити задачу/публікацію і далі клікнути лівою кнопкою мишки по заголовку — тоді в буфер скопіюється заголовок і посилання на задачу у такому вигляді:
      • для задачі:
      Визначаємо переклад для терміну "Link"
      https://ua.power-of-trust.net/#task:20170202-112311-DPfL
      • для публікації на Форумі:
      Для лідерів дійсно демократичних груп. "Експансія та стагнація розвитку демократичних груп".
      https://ua.power-of-trust.net/#forum/post:20170211-203942-tgzr
      З буфера його можна вставити кудись в текст комбінацією клавіш Ctrl+V або через контекстне меню Paste/Вставити.
  • Як можна допомогти проекту, які люди потрібні проекту:
    10 Jun
    Оновлено 10.06.17
    • Потрібна перевірка роботи системи, ручне тестування
      25 May
      Будь-хто якщо володіє комп’ютером/ноутбуком може це робити.
      Потрібно:
      • встановити систему
      • пройти складну реєстрацію
      • приймати участь у голосуваннях які вам цікаві
      • пробувати писати/голосувати на Форумі
      • слідкувати за оновленнями які публікуються у групі, коли вони виходять — запускати систему і пробувати чи все працює, як очікується
    • Потрібен програміст для написання автоматичних тестів (unit tests, UI tests)
      25 May
      Задача: покриття функціоналу системи тестами
      • потрібно знати: Ruby, Rspec, Selenium/Watir WebDriver, JS, HTML, CSS
      • особисті якості: терпіння, уважність, делікатність, вміння передбачати проблемні ситуації
    • Потрібен технічний письменник (technical writer)
      25 May
      Проекти:
      • документація абстрактного протоколу роботи мережі
      • дасть можливість долучитися іншим командам розробників до створення альтернативних реалізацій
      • використовуючи інші мови програмування
      • інші технологіях (інші бази даних наприклад)
      • документація API ядра ноди
      • дозволить створювати різні сторонні утиліти/віджети для взаємодії з системою, дозволить інтегрувати систему з існуючими системами, наприклад:
      • віджет коментарів на сайтах
      • віджет логіна через акаунт в мережі Сила Довіри
      • документація API веб-клієнта
      • дозволить будувати різні інтерфейси для роботи з системою
    • Потрібен спеціаліст по кібер-безпеці (security)
      8 Jun
      Потрібно:
      • виявляти вразливості, неточності, конфлікти у логіці системи, у коді платформи у компонентах та технологіях, які використовуються;
      • виявляти потенційні слабкі місця в інфраструктурі для захисту від DoS-атак
    • Потрібен спеціаліст по базах даних
      8 Jun
      Потрібно придумати стратегію збереження даних мережі.
      Інформація про дії в мережі постійно накопичується і потрібно продумати стратегію її збереження так щоб не було проблем з масштабуванням на велику кількість користувачів на багато років вперед.
      Зараз в системі використовується MongoDB тому що для збереження даних про різні дії гарно підходить саме документо-орієнтована БД.
    • Потрібен криптограф
      8 Jun
      Потрібно вибрати адекватну технологію асиметричного шифрування з правильними налаштуваннями.
      • Важливо досягти хорошого балансу між швидкістю роботи системи і безпекою.
      • Важливо також, щоб ключі могли працювати на мобільних девайсах.
    • Потрібен спеціаліст по алгоритмам
      19 Apr
      Потрібно підібрати найкращі з відомих алгоритми:
    • Потрібні люди для формування ядра експертів системи
      25 May
      Це люди, які добре орієнтуються у всій інформації про систему яка є опублікована, або була озвучена на конференціях.
      Що потрібно робити:
      • відповідати на питання новачків
      • доповнювати новою інформацією цей документ
      • слідкувати за всіма змінами у проекті, бути в курсі всіх прийнятих рішень, поточних пріоритетів, планів на найближче майбутнє.
    • Потрібен аналітик/експерт по схожим системам
      25 May
      Потрібно:
      Для прикладу потрібна людина яка би розібралася з eGaaS. Ось детальна задача по цьому.
    • Потрібні психологи, соціологи
      8 Jun
      Задачі:
      • формування правил, санкцій мережі, які не будуть відлякувати, а будуть дійсно служити на благо спільноті
        8 Jun
        Тут слід вияснити критерії, по котрих можна відрізняти правила котрі: не будуть відлякувати, будуть дійсно служити на благо. Бо врешті решт все зводиться до 2 етичних систем, котрі можна умовно назвати капіталістичною і соціалістичною. Тобто коли насильство неприйнятне, або коли воно прийнятне, якщо так проголосує більшість. В першому випадку існує тільки одне право - приватне, а в іншому випадку існує 2 права - приватне, коли судяться 2 особи, і суспільне, коли особа судиться з якоюсь організованою групою осіб, спільнотою.
      • придумування стимулів для заохочення до активної участі в житті мережі та її поришенні
      • продумування особливостей мережі так щоб уникнути потенційних конфліктів і проблем в майбутньому (тобто чи варто взагалі вводити енергію, довіру/недовіру, рейтинги, різні оцінювання і тд)
    • Потрібні юристи
      8 Jun
      Для формування чітких, однозначних, доступних розумінню загальних правил мережі та правил окремих сервісів.
    • Потрібні програмісти що спеціалізуються на створенні мобільних додатків
      8 Jun
      WebView vs React Native vs Native Script vs Native ?
      • Android
      • iOS
      • Windows
    • Потрібен спеціаліст по MacOS
      25 May
      Задача: створення і підтримка інсталяційного пакета
    • Потрібен спеціаліст по Linux
      25 May
      Задача: створення і підтримка інсталяційного пакета (для серверів і для десктопа)
    • Потрібен спеціаліст по штучному інтелекту (machine learning, нейро-мережі)
      10 Jun
      Задачі:
      • потрібно створити хорошого віртуального помічника, який би відповідав на будь-які питання по користуванню системою, користуючись нашою базою знань.
        10 Jun
        Найперша задача, яка випливає з практики — це відповіді на питання про систему типу "як редагувати свій коментар", "чому я не можу проголосувати", "як відновити доступ до акаунта". Зараз доводиться відповідати кожному окремо, що є сумно… Тож хочеться сформувати базу знань, і по ній робити дуже розумний пошук на питання у різних формах так щоб працювало не гірше за відповіді живої людини.
        На скільки мені відомо, то розбір і смисловий аналіз текстових речень — це одна з галузей у якій застосовують нейро-мережі.
        У цьому напрямку мені відомо про отаку платформу від гугла:
        Cloud Natural Language API — Powerful Text Analysis
        https://cloud.google.com/natural-language/
        - reveals the structure and meaning of text
        - extract information about people, places, events and much more, mentioned in text documents, news articles or blog posts
        - Filter inappropriate content, classify documents by topics, and build relationship graphs of entities extracted from news or wikipedia articles
        - розпізнавання типів об’єктів що згадуються
        - person, organization, location, events, products and media.
      • динамічне виявлення коментарів, які можуть порушувати правила (спам, флуд, образи).
      • надалі потрібно буде розширювати компетенцію помічника відповідно до росту нашої бази знань.
    • Потрібні потужні мізки для проведення досліджень, для пошуку рішень складних задач
    • Потрібні толкові люди для різних задач на майбутнє
      25 May
      Приклади задач:
    Якщо Ви відчуваєте в собі сили взятися за один або кілька пунктів — пишіть тут в коментах, або контактуйте напряму з учасниками проекту (дивіться хто активний у робочій Facebook-групі), або пишіть на контактний емейл.
    У даного проекту немає ні замовників ні спонсорів — все робиться на волонтерських засадах на спільне благо з метою побудови здорового громадянського суспільства.
  • Зауваження:
    13 Jun
    • До ідеї:
      14 Oct
      • Я мрію побачити повний набір елементів та принаймні загальний опис проекту в цілому
        7 Jul
        Найширший з описів який є, без вдавання у деталі, — це ось ця презентація.
        Можна сказати, що метою платформи є створення великого набору сервісів які будуть вирішувати певні задачі для людей, то в цій презентації є досить широкий список сервісів.
        А от в якому порядку їх реалізовувати — це вже вирішуємо разом і курс будемо коригувати по ходу
        7 Jul
        Бачення інших учасників
      • Робота над подібним проектом у Росії
        13 Jun
        До речі, у Росії над схожим проектом децентралізованої системи працюють разом програмісти, філософи, футорологи та інші спеціалісти.
        http://forklog.com/komanda-daylight-sozdast-gosudarstvo-na-blokchejne/
        У нас же поки що не вдається зацікавити майже нікого. Може хто розгадає в чому причина?
        13 Jun
        Сверхусилия по обеспечению безопасности привели к тому, что система ЗАМУРОВАЛА СЕБЯ живьем.
      • Це рішення виглядає надто загальним. Може потрібна більш простіша електронна система для голосування?
        13 Jun
        Михайло Петелицький: мені чомусь вбачаєься, що для голосування потрібна простіша електронна система. Загалом Ви створили щось значно більш масивне, аніж необхідно для простого опитування громадської думки або голосування.
        13 Jun
        Для простого опитування і навіть не простого уже є достатньо сервісів. Мені наприклад сподобалися http://просвіт.укр/, http://nr.org.ua/.
        Метою цього проекту є створення мережі довіри з можливістю колективного прийняття рішень.
        13 Jun
        Той, хто хоче, аби за нього голосували, буде намагатися всіма засобами втертися у довіру до людей, так само як це роблять звичайні шахраї. Голосування робить довіру товаром, який коштує конкретну суму грошей (досить велику).
      • Можливий ризик олігархізації системи
        13 Jun
        - реєструються в системі 20-50-500 засланих козачків (спочатку один, а потім він запрошує решту підставних осіб, елементарно).
        - далі вони накручують один одному рейтинги, а конкурентам/опонентам зрізають рейтинг і навіть відсилають самих активних в бан.
        - далі ця група активно нарощує свою кількість і встановлює свої рівні допуску і монополізує владу по ключових питаннях.
        - після цього система вже буде "клепати" ті рішення, які потрібно очільникам цих груп.
        Ось вам короткий опис схеми олігархізації системи... в якій реальна влада належить кільком особам, які смикають за ниточки (олігархам).
        13 Jun
        Так система запрошень ускладнює такий сценарій, але не унеможливлює. Якщо буде запропонована дієвіша система захисту, можна буде ще більше ускладнити.
        Але гарантувати тут нічого неможливо, ризик завжди буде.
        13 Jun
        Власне, тому в "Система. Версія 2.0" я привязався до живих людей і живого (паперового) делегування у співвідношенні 1:10.
      • Делегування у нашій країні поза законом
        13 Jun
        Михайло Петелицький: найголовніше, що всі ці наші ідеї є простим романтизмом, який не має нічого спільного з нашою реальністю, бо законодавчо не закріплено право делегування, натомість вибори є ПРЯМИМИ. Тобто делегування свого голосу заборонене як таке.
        13 Jun
        І що Ви пропонуєте? Скласти руки і чекати поки така "пряма" демократія перетворить руїну на сміттєзвалище? Чи чекати, поки всі громадяни стануть свідомими і таки "випрямлять" ту демократію, яка є.
        13 Jun
        Я пропоную лобіювати сам принцим делегування голосу. Щоб можливість делегування голосів була закріплена в Конституції. Яким це делегування буде - паперовим, чи "електронним" це вже інше питання. Але допоки голосування шляхом делегування голосів не закріплене законодавчо, змін не буде.
        Потрібно: 1) на законодавчому рівні запровадити поняття "делегат". 2) внести зміни в Конституцію, де має бути записано, що голосування може бути прямим або непрямим (тобто дворівневим із делегуванням голосів).
        13 Jun
        А чим принципово відрізняється "наше делегування" від делегування на звичайних Виборах?
        13 Jun
        Я тільки за закріплення такого права конституційно, але не бачу реальних можливостей досягти таких змін, принаймні найближчим часом. У далекому майбутньому все може бути.
        Це добре, що є люди, які готові йти таким важким шляхом.
      • Не розкрито що ми маємо зробити з усіма, у кого компютерна грамотність наближається до нуля
        13 Jun
        Михайло Петелицький: у вас не розкрито що ми маємо зробити з усіма, у кого компютерна грамотність наближається до нуля... ??? і як вони повинні делегувати свої голоси і кому?
        13 Jun
        Варіанти є: від створення інститутів для примусового навчання до повного ігнорування. Все залежить від нас.
        Мені подобається шлях стимуляції через прив’язку до певних благ — http://youtu.be/PBi-vJYrEV4?t=1h25m39s (про тиблів)
        13 Jun
        Ігнорування = дескримінація. Ви не вистоїте проти 13 000 000+ пенсіонерів... і ще там кількох мільйонів "тиблів". Вони просто задавлять вас масою.
        13 Jun
        Щось досі вони нікого так не задавили, живучи за межею бідності.
        13 Jun
        Ну драсті, не задавили... на кожних виборах вони визначають як нам жити. І саме пенсіонери і "тибли" своєю масою обирають владу.
        13 Jun
        Я в даному випадку буквально прийняв слово "задавити" :)
        Участь цих людей у такого роду системі — це відкрите питання.
        13 Jun
        Непогано було б зібрати "відкриті питання" окремим списком, щоб розуміти "на якому світі ми знаходимось".
        Це би було дивом, якщо би така "маса" осилила такий інструмент.
        13 Jun
        З досвіду видно, що всі, хто ставить такі питання, розглядають голосування в наймасштабнішому вигляді, беручи за зразок існуюче "всенародне" голосування. Новітні системи прямої демократії будуть розвиватися поступово, та на перших порах свого розвитку аж ніяк не будуть всенародними. Але вони будуть вседоступними. Це означає, що право голосувати має бути в кожного громадянина. Кожному пенсіонеру та будь-якому громадянину пропонується вибір - або приймати участь в спільному житті - або ні. Рано чи пізно, з розвитком систем самоврядування, люди почнуть розуміти, що вигідніше долучатися до суспільних процесів. Навчитися може кожна людина, якщо вона при своєму розумі. Стівен Хокінг он - інвалід, що не може рухатися і при цьому творить великі наукові знахідки. Тим паче майже кожен пенсіонер може навчитися при бажанні. Просто такого бажання і наміру немає. І якщо його зараз немає - то і нічого. Неорганізовані люди мають малу силу на щось впливати в суспільному житті, тож поки вони не навчаться користуватися сучасними інструментами, то вони будуть союзниками нінішньої корупційної антисуспільної системи. Задача представників прямої демократії - навчати таких громадян. На це будуть виділятися певні кошти, створюватися відповідні фонди та визначатися спільно, яка частка спільного бюджету має йти на навчання не свідомих громадян.
        13 Jun
        Алексей, это и есть тот первичный уровень компетентности, который я упоминал в нашем обсуждении, только в физическом мире.
        Система должна обеспечить сервис для выявления/продвижения активных граждан с первого "физического" уровня (соседи, родители, пенсионеры, не подкованные друзья и тд.).
        Помочь им получить доступ к знаниям, экспертам, ресурсу.
        Кроме этого, как мне кажется может быть разработана "ламерская" версия со списком голосования и двумя кнопками "вкл" и "выкл"
        13 Jun
        Так, я теж задумувався про "лайт" версію нещодавно, з мінімалістичним інтерфейсом та адаптацію для смартфонів. Як раз Юрій Бабак зараз замислюється над створенням веб-браузерної ланки, яка буде дозволяти користуватися платформою без завантаження дистрибутиву. До розповсюдження серед більшості ми маємо пройти ще довгий шлях, коли хоча б значна кількість людей, що вже приймають спільні рішення або потребують цього зможуть залучитися, навчаться створювати свої групи та отримувати користь від спільної діяльності.
      • На мій погляд, проект має найбільш реальні шанси запрацювати в організаційному середовищі
        9 Oct
        Так, я теж погоджуються і не тільки я, що система на початку найефективніше може показати себе у певних замкнутих спільнотах об’єднаних певною метою/тематикою. Саме тому я позиціоную даний запуск як спеціальний для ентузіастів тематики електронної демократії для вироблення якихось рішень у цьому напрямку, навіть нехай не пов’язаних з даною системою. Тобто використати дану систему чисто як інструмент, заодно перевірити її і покращити згідно потреб.
        Я дійсно не позиціоную даний продукт як готовий для широкого застосування.
      • Контакти та персональні дані учасників мережі можуть бути використані в особистих цілях будь-кого хто переглянув історію (наприклад, розсилка спаму чи реклами від третіх сторін)
        9 Oct
        В даній системі у користувача вимагається надати мінімум персональних даних, які в більшості і так доступні публічно, тому не вважаю це проблемою. Можете знайти відповідне голосування, де моя позиція, що потрібно крім повного імені ще максимум рік народження і може місяць і місто проживання, все решта — реально не потрібно для надання функцій. Це все вказано у постановці даної задачі "Які дані про особу зробити обов’язковими при реєстрації"
      • Зловмисник зможе відслідковувати усі дії інших учасників
        9 Oct
        >Навіть якщо зловмисник не зможе нічого зробити, він чи вона зможе відслідковувати усі дії інших учасників. Користувачі почуватимуть себе у небезпеці. Одна з причин успіху соц мереж в тому, що вони дають відчуття безпеки і контролю над даними
        Тут не соціальна мережа де публікують свої статки і машини, тут ведуться обговорення і приймаються рішення. Якщо Ви про переслідування за ідеї і переконання, то така мережа нічого тут не додає нового, адже ідейні люди і так скрізь публікуються, їм не притаманно боятися і мовчати. Те що тут є інформація про місто проживання людини, не сильно впливає на ситуацію, бо при бажанні і без такої публікації все можна дізнатися. Тай взагалі ті хто переживають за переслідування — не наша цільова аудиторія.
        10 Oct
        Да не нужны мы никаким "зловмистникам" и не будем нужны во веки веков. А я вот переехал на другой комп, и чтобы восстановить доступ в СД — столько гемморою, что "игра не стоит свеч".
      • Ріст мережі є проблемою
        9 Oct
        Повністю згоден. Це природно для будь-якої нової а тим більше серйозної мережі, чи інтелектуального продукту взагалі.
        Масовість — це не наша ціль. Наша — згуртувати толкових людей довкола гідного для колективної роботи інструменту.
      • Так і не зрозумів, навіщо це потрібно
        14 Oct
        Мета: створити можливість організації відкритої колективної системи прийняття рішень по будь-якому питанню, включаючи вибір персони на відповідальну посаду.
        По суті — це є інструмент, а навіщо інструмент потрібен уже вирішують учасники мережі.
    • До ведення проекту, формування команди:
      7 Jul
      • Для появления команды нужен формализованный манифест проекта, общие задачи и персональные обязательства на основании полезности для проекта, а не личной заинтересованности отдельных участников.
        13 Jun
        >Вы знаете о проекте Пандора и точь в точь поаторяете его путь, даже не пытаясь формализовать свой план и привлечь людей в команду.
        Посмотрите последний опрос-голосование, он очень показателен.
        "формализованный манифест проекта, общие задачи и персональные обязательства на основании полезности для проекта" — будь-ласка, наведіть приклад де це гарно зроблено, бо я не дуже уявляю як воно має бути. Буду пробувати щось таке зробити, бо я ж не проти, просто я не сильний в цьому ділі.
        >Взгляните здесь. Это логика того документа о котором я говорю.
        Пройшовся по вказаним матеріалам (бізнес-план розробки комерційної платформи сервісів і аналіз статистики пошуку початкових інвестицій).
        У нас все ж таки не комерційний проект по своїй суті, а суспільно-організаційний (має в першу чергу допомагати людям краще взаємодіяти). І ця специфіка відіграє важливу роль. На мою думку нам немає чого запропонувати інвесторам, крім як фрази що "проект можливо допоможе об’єднати громадянське суспільство у країні, і можливо допоможе певним група активних людей взаємодіяти ефективніше і швидше вирішувати якісь свої задачі, реалізовувати спільні проекти". А з таким варто йти хіба до фондів та благодійників. Я пробував, мій результат — нульовий. І в мене воно займає надто багато енергії, тому поки що більше не маю бажання пробувати.
        Я більше хотів знайти у матеріалах приклад де є якась хороша ідея, є розробники і їм вдалося організувати навколо ідейного проекту людей інших спеціальностей: "общие задачи и персональные обязательства на основании полезности для проекта". Цього я не знайшов.
        Для мене прикладом такої організації є проект eGaaS, хоча мені важко судити, як там зараз хто задіяний.
        На мою думку в нашому проекті з часом просто природньо появляться задачі для інших учасників, коли появляться інструменти для організації груп, для ведення проектів, для фінансових транзакцій. Але це вже буде наступний етап розвитку проекту. Зараз у нас рівень розробки фундаменту, дуже вузький технічний і мало кому зрозумілий.
        Щоб у проекті такого плану і на такому етапі появилася команда — це потрібно організувати репозиторій з кодом хорошої якості, і з детальною специфікацією + треба буде поширювати проект серед програмістів.
        Робота в цьому напрямку ведеться.
        Суть та ідеї проекту викладені у презентації та концепт-документі, тому створення ще якогось маніфесту мені видається надлишковим.
        Що до постановки задач і проблем спочатку — то на мою думку основні проблеми/задачі які вирішуються вже від початку були визначені. І кожен з вас їх бачить і відчуває, бо інакше не розумію чому слідкуєте за цим проектом/групою.
      • Проект майже не пристасований до розширення іншими програмістами
        7 Jul
        Абсолютна більшість задач - функціонал проекту. Все інше - другорядне. І як раз для основних задач використовується лише один програміст. Це далеко не найефективніший підхід. Пояснень - чому так - немає.
        7 Jul
        У статусі проекту є пункт "репозиторій на GitHub" по якому ведеться робота у фоні. Причина одна — це є довгий процес.
        7 Jul
        Коли хтось почне використовувати репозиторій проекту на GitHub це не обов'язково буде означати, що "Сила Довіри" отримає нових програмістів для роботи над функціоналом. Скоріше це буде означати, що хтось почне вибудовувати окрему гілку розвитку, окремий варіант мережи, окреме продовження.
        7 Jul
        Загально доступний репозиторій — це одна з необхідних умов для організації спільної роботи над кодом, можливість форкнути проект — це лише побічний ефект від цього.
        Мова ж йде про те, чому для розвитку саме "Сили Довіри" була обрана менш ефективна стратегія - використовувати роботу лише одного програміста?
        7 Jul
        А хто сказав що щось таке було кимось обрано? Я вже пояснював на конференції що історично склалося, що мені на початку не вдалося нікого зацікавити розробкою проекту — саме тому розробник лише один. Це не якась там обрана стратегія, це сумні реалії.
        Якщо планується створити революційний продукт світового масштабу, то далекоглядніше було б розглядати (і розробляти) структуру коду з огляду на можливість розширення для роботи безлічі програмістів, чи не так?
        7 Jul
        Структура коду якраз не сильно впливає на можливість спільної роботи
        8 Jul
        Це твердження повністю протилежне декларованому раніше про те, що мій зразок структури коду начебто не підходить для спільної роботи. Я бачу що іноді обираються протилежні варіанти мислення над одним і тим же аспектом в залежності від обставин. Це знижує рівень довіри.
        8 Jul
        Не треба перекручувати мої слова. Мої зауваження в тій ситуації не були що до саме спільної роботи, а були що до розуміння іншими програмістами. У твоєму випадку принципи за якими ти формуєш структуру коду є незрозумілими для інших, саме тому структура виходить невалідна.
        Якщо хочеш продовжувати тут обговорення тієї ситуації, тоді доведеться опублікувати нашу приватну перепису, щоб усі могли побачити, на основі чого ти зробив свій висновок "Це знижує рівень довіри".
        8 Jul
        Скоріш не "іншими" програмістами, а одного "іншого" програміста. Не треба перебільшувати, начебто відбулося опитування серед багатьох програмістів. Мова йшла лише про один аспект коду - а саме використання наслідування. Це та річ, як можна запросто змінити по-бажанню. Прибрати наслідування, і в моєму випадку змінити пару строчок коду в самих класах. Наприклад в моєму нинішньому проекті наслідування майже немає. На виправлення того випадку пішло б декілька хвилин. На те, щоб використовувати наслідування по мінімуму, або обговорювати його доцільність з іншими учасниками - лише одне речення, одне прохання, одна настанова. А якщо розглядати цю ситуацію загалом - то мова йде саме про структуру коду. А в тому випадку, нерозуміння структури коду - те що було причиною не прийняття - і є зв'язок із спільною роботою, це стосується взаємодії між програмістами в команді. Не треба робити вигляд, начебто структура коду не сильно впливає на можливість спільної роботи. Виглядає так, що в той момент як раз сильно вплинуло. І раз зараз ти стверджуєш зворотнє, то це ще раз підтверджує мою думку, що істинною причиною не прийняття моєї структури могла бути інша обставина та іноді моїм опонентом у дискусії обираються протилежні погляди для підсилення позиції в тих чи інших питаннях.
        12 Jul
        >не "іншими" програмістами, а одного "іншого" програміста
        Я консультувався з колегами, тому не одного.
        >На те, щоб використовувати наслідування по мінімуму
        Я не казав, що маю щось проти наслідування. Моє зауваження стосувалося того, як це наслідування робиться.
        >… сильно впливає на можливість спільної роботи
        Я надто загально висловився і це породило непорозуміння тут.
        Поясню. Є проекти з досить монолітною структурою без жодних передбачених механізмів для розширення (типу системи плагінів, чи гарної ієрархії класів) і всеодно над ними працюють різні люди чи певна команда, бо ж можна розділити зони відповідальності при роботі над кодом, особливо, якщо проект великий.
        Тобто, якою би не була структура завжди можна домовитися про організацію спільної роботи над кодом.
        13 Jul
        Не з "колегами" а з "колегою". Ти працював з однією людиною на той момент по твоїм же словам. Тому або тоді була сказана не вірна інформація, або зараз. У нас був серйозний намір організувати спільну роботу, а ти його зупинив, бо не захотів знайти шлях, як вирішити різність поглядів на лише один аспект із багатьох. Не побачив елементарної можливості домовитися щодо організації наслідування для проекту, встановити правила, яких би я міг дотримуватись. Не зрозумів, що я усвідомлюю і погоджуюся із класичним підхідом до наслідування незважаючі на свої погляди до розширення його можливого застосування. І тепер кажеш, що завжди можеш домовитися про організацію спільної роботи над кодом? Я тобі не вірю в цьому питанні, і в загалі не відчуваю твоєї щирості.
        Якщо хтось крім Юри це читає - раджу не приймати моє ставлення як основу для своєго відношення до можливої спільної роботи по розбудові системі самоуправління. Впевнений - більшість бажаючих без проблем зможуть взаємодіяти з Юрою та робити спільну справу.
        . Було би бажання — можна розібратися в тому що є і доповнювати, покращувати. Просто бажаючих поки що немає.
        Якщо обране Open Source програмування, то воно має бути *максимально* пристасоване для розширення, правда? Але схоже що при стовренні "Сили Довіри" це взагалі не бралося до уваги.
        8 Jul
        Я не бажаю занурюватися в код і прямо впливати на нього, змінювати його шукаючи місяця в ньому, різні місця, щоб вставити свій код, щоб втілити ту чи іншу задумку. Мені потрібна система, при якій я маю перелік доступних і зрозумілих класів до яких я можу звертатися із окремого js файлу, який і є моїм доповненням і який можна легко прибрати або додати або вручну або з допомогою елементарного інтерфейсу. Якщо такої можливості немає - то таку можливість необхідно створити, щоб такі як я отримали шанс шось зробити для проекту. І варто дослуховуватися до бажань єдиної людини, яка на нинішньому етапі, після двох років буття проекту висловлює якісь наміри стостовно прямого доповнення функціональних елементів проекту.
        8 Jul
        Це звучить як система плагінів/модулів.
        Поки що я не знаю як на поточній кодовій базі створити таку систему. Можливо пізніше це стане можливо, а може швидше появляться інші реалізації проекту, де це буде зроблено.
        Я ж не проти щоб можна було легко створювати модулі, але зараз у тому коді який є це не зроблено, бо це є складний для мене функціонал, який у моєму розумінні не входить у MVP.
        Але ще раз кажу: модулі це не єдина можливість спільної роботи над кодом.
        12 Jul
        Хоч це не єдиний можливий спосіб загалом, але єдиний востребований на даний момент. Для виконання цієї умови необхідно лише, щоб основна структура коду була побудована на класах. Все інше - другорядне. Якщо в побудові такої можливості вбачаються складнощі - це скоріш означає що структура основного коду не побудована на класах (чи на хоча-б на системі об'єктів, якщо работа ведеться за застарілими стандартами) чи не так? Побудова на класах означає, що будь-який код, крім деяких викликів належить до того чи іншого методу класу, а не те, що деякі або навіть більшість коду належить до методу класу. Якщо так, і код не побудований на класах, то звужуються можливості і для інших підходів для спільної роботи. І додавання кожного нового програміста до проекту тоді буде ще більше ускладнювати розуміння коду новими та існуючими програмістами.
        Отже питання такі:
        • чи є уявлення про системний підхід та про стратегію для спільної роботи над проектом?
          12 Jul
          Якесь є. Але досвіду в цьому багато не маю, тому не все получається так як би хотілося.
        • Чи побудований код на класах, які можна наслідувати і які пристасовані для наслідування?
          12 Jul
          Заглянь у папку app там усі відповіді. Але не кожен функціонал додається наслідуванням якогось класу, зараз в більшості потрібно творити нові класи.
        • Чи існує загальна схема структури проекту, яку можна переглянути і яка значно допоможе будь-якому сторонньому програмісту, який забажає побачити опис структури проекту?
          12 Jul
          Схеми ще немає. Структура проекту ще дуже сильно змінюється при розробці, тому немає смислу її описувати. Саме через це код не публікується на GitHub, бо я вважаю що його потрібно доробити і місцями переробити і тільки тоді публікувати і документувати.
    • Що до пошуку фінансування розробки:
      13 Jun
      • Даже некоммерческий проект должен иметь заказчика…
        13 Jun
        >Даже некоммерческий проект должен иметь заказчика.
        13 Jun
        Нет не должен. У нас прямого заказчика нет, но люди которым инструмент интересен и нужен — есть. Для них и стараемся.
        Вы ведь не думаете, что в сети мало тех, кто желает "помогать людям лучше взаимодействовать"?:)
        19 Apr
        Есть много таких, которые делают это с целью заработать на пользователях, или на данных пользователей (FB например). Фокус у них — прибыль. Тех же, что делают такое с фокусом на самих людях, их нуждах и проблемах — увы, единицы (мы стараемся следить за такими проектами здесь).
        13 Jun
        >А почему Вы уверены, что предлагаемый Вами сервис будет сфокусирован на нуждах и проблемах людей?
        13 Jun
        Что делать и когда делать в проекте ми стараемся определять исходя из нужд, которые видим вокруг себя. Именно поэтому сейчас работаем над функционалом для групп, а не над площадкой для дебатов например, та как потребность в первом участники проекта видят больше вокруг.
        Прибыль - это не цель. Прибыль - это как раз таки мера осознания нужд и проблем людей.
        13 Jun
        Давайте говорить конкретно. Под прибылью в нашем проекте я понимаю разницу между сумой взносов пользователей сервиса за его использование и сумой расходов по поддержанию работы данного сервиса (зп разработчикам, зп модераторам и прочим должностям, стимулирование хостинга системы на серверах и т.п.). В нашей сети прибыль всегда будет равна нулю. Если взносов будет больше чем нужно, участники проголосуют что делать: либо уменьшить суму взноса, либо направить излишки на что-то еще, например на популяризацию платформы, то есть превратить в существующую или новую статью затрат.
        Суть в том что на нашей платформе прибили не будет. Значит ли это, что сервис никому не нужен — конечно же нет. Единственный показатель здесь — количество пользователей.
        Если человек согласен платить за избавление от нужды, значит нужда (проблема, задача) действительно есть. Если платить никто не согласен - проект несостоятелен.
        13 Jun
        Согласен. Именно на основании этого в платформе со временем будет введен обязательный взнос для пользователей.
        Это в полной мере относится и к некоммерческим проектам, ведь за содержание бездомных животных, например, тоже кто-то платит
        Допускаю, что проект удастся запустить как некоммерческий, но со временем он всё равно обрастёт коммерческим функционалом (сеть должна хорошо продавать эксперта, иначе у эксперта не будет мотивации к качественной работе в сети).
        13 Jun
        У нас другая стратегия. У нас будут сервисы, инструменты, которые могут быть использованы бизнесами и экспертами для взаимодействия. Бизнес сможет заказать решение своей проблемы за вознаграждение, а эксперты (или группы экспертов) будут конкурировать между собой предлагая решения. В идеале все прозрачно и публично. Авторы лучшего решения получат вознаграждение + репутацию и запись в реестре об участии. Именно это и будет мотивировать экспертов к качественной работе в сети.
        Платформа при этом не выступает как посредник, а скорее как открытая площадка. За пользование такой площадкой обе стороны будут платить взноси, которые будут направляться на обслуживание и разработку платформы (а это всегда будут волонтеры, которые хотят этим заниматься). Какого-то конкретного бенефициара у платформы нет и не будет. Да при такой стратегии нет гарантии эффективной и быстрой разработки, но только так можно гарантировать, что целью проекта не станет заработок на пользователях.
        А если это так, то бизнес-модель экспертной сети (как бы она не называлась) должна быть разработана уже сейчас.
        В принципе, совсем неважно о каком проекте идёт речь - и коммерческие, и некоммерческие проекты имеют один и тот же трёхшаговый алгоритм запуска - и там, и там надо чётко выделить ключевую проблему, найти заказчика, максимально заинтересованного в её решении, и предложить ему инструмент решения.
        13 Jun
        Нет, есть и другие пути. Особенно для некоммерческих проектов.
      • Брать деньги на развитие сети с самих пользователей — не слишком удачная бизнес-модель (мягко говоря). Она даже менее удачна, чем ставка на рекламодателей
        13 Jun
        На кого делается ставка — для того и делается продукт.
        Если сравнить убогие функциональные возможности групп в Facebook с тем, какие инструменты там же созданы для рекламодателей, то зразу становится понятно, куда направлены силы разработчиков компании.
        Вот всего несколько экранов с Фейсбука если вы пробуете рекламироваться через него:
        Чувствуете разницу?
    • До технічної реалізації:
      16 Oct
      • Про збереження копії бази даних на кожній ноді і про збереження деяких персональних даних
        9 Nov
        • Сервер така ж одиниця як і кожен учасник - це значить що кожен учасник зберігає всю повноту даних про дії кожного іншого учасника? Тобто я знесу прогу і відновлю абсолютно все якщо в мережі є хоча б один учасник онлайн?
          9 Nov
          Саме так, але за винятком деякої персональної інформації (як от позначення що вже є прочитаним), така інформація зберігається у кожного своя і не передається іншим.
          Але потрібно уточнити, що у мережі немає такого поняття як "сервер" є ноди. Кожен учасник є нодою, якщо він використовує повний клієнт.
        • Це дуже великий масив даних. Хіба середньостатистичний українець має тримати вдома пам'ять на терабайти й більше?
          9 Nov
          Звичайно що ні. І не потрібного цього. З часом великий масив застарілих даних осяде лише на певній кількості архівних нод, які будуть великі і ми всі разом оплачуватимемо їх підтримку для збереження історії всіх даних і обробки рідких запитів до цих даних.
        • Я передбачаю висування пропозицій десятками мільйонів громадян — це ж величезний об’єм даних!
          9 Nov
          Я би хотів щоб так було, але на жаль 95% людей дуже пасивні і ніколи не пропонують ні рішень, ні навіть не коментують нічого. Таке можна спостерігати у вже існуючих групах, де учасників тисячі, а пишуть максимум 1-2 десятки. Але тим не менше даних у базі з часом буде дуже багато.
      • Проблема росту бази даних
        3 Jul
        Ріст розміру бази даних з часом буде приводити до її збереження на все меншій кількості нод, через що страждає децентралізація і відповідно надійність. Тож треба робити все можливе, щоб розмір бази ріс якнайповільніше. А графіка порівняно з текстом важить значно більше і не підлягає компресії, тому картинки в першу чергу потрібно зберігати окремо.
        3 Jul
        • Можливість використання IPFS (https://ipfs.io)
          3 Jul
          Сьогодні цілий день розбирався з IPFS. Це є система розподіленого збереження і доставки файлів, яку планується використовувати у таких сервісах як Форум для вставки картинок у публікаціях. Ця система підходить, так як доступ до файлів відбувається по чексумі а не імені, що унеможливлює підміну даних.
          Виявилося що цей проект ще у дуже активній розробці (500+ відкритих issues, 1000+ закритих). У роботі системи є значні незручності і навіть баги, через які поки що не виходить її використовувати (.
          Тож наразі доведеться обходитися без неї, закидаючи картинки на сторонні сервіси. Встроювання картинок прямо у текст публікації (таке працює у задачах) на Форумі буде заборонене через сильний вплив на збільшення розміру бази даних.
        • Про різні типи клієнтів
          3 Jul
          Це ж який розмір БД буде при 1000 користувачів коли кожен зберігає кожне?
          Я думав інформація фрагментована, типу юзер зберігає все пов'язане з тими, з ким він взаємодіяв. Тобто якщо я нічого не підписував і не коментував - то інфа про мене є тільки у сервера (про профіль і про реєстрацію), відповідно якщо я переписувався з вами, чи голосував вашу ініціативу - то зберігаємо інфу про це ми обидва однаково.
          3 Jul
          > Це ж який розмір БД буде при 1000 користувачів коли кожен зберігає кожне?
          Як і у інших децентралізованих мережах (типу Біткоін) розмір буде рости з часом (у них уже 100GB десь і це за 8 років). Найближчий рік-два розмір бази для нашої мережі не буде проблемо. А за цей час будуть реалізовані рішення, які називаються "легкий " та "середній" клієнти (зараз те що встановлюється називається "повний" клієнт). "Легкий" — це взагалі буде браузер, який використовує ресурси одного з багатьох публічних серверів, а в себе тримає лише ключі для підпису (саме на цьому етапі появиться можливість працювати у системі з планшета, чи навіть мобільного), а в другому випадку зберігається певний об’єм найсвіжіших робочих даних системи і копія усіх важливих для користувача даних, решту даних при потребі будуть підтрягуватися з інших нод. Це є гібридне рішення, яке дозволяє обійти проблему росту бази. Але це все буде пізніше і там вже буде економічна модель для заохочення ентузіастів запускати і тримати супер-ноди з повною базою.
        • Свої дата-центри?
          3 Jul
          Гілка у FB
          Nataly Bezmen: Один из вопросов к проектам такого рода - объем информации, который нужно где-то хранить и обрабатывать. Как только это перестает быть чем-то небольшим и локальным... Значит, это или аренда мощностей, с соответствующими затратами и вопросами к безопасности. Затем логично должен быть поставлен вопрос о строительстве собственных дата-центров. Под этот проект. С расходами, вопросами охраны их в реале - и выводами о том, что кто контролирует все это "железо" тот и контролирует саму систему.
          3 Jul
          Зауваження дуже правильне, але треба враховувати, що у децентралізованих системах є свої особливості і стратегії для вирішення цих питань, порівняно з класичними централізованими (для яких зазвичай будують дата-центри).
          Це насправді зараз у нас є не просто відкрите питання, а ще й відкладене на майбутнє. З часом у проекті буде і більша кількість учасників і більша кількість технічних спеціалістів, тоді і потреба виникне у вирішенні цих питань і буде достатньо ресурсів для їх вирішення.
      • Потрібен продуктивний бекенд. Інакше не можливе масштабування, якщо система не може опрацьовувати сотні тисяч юзерів, я не бачу перспектив.
        13 Jun
        Поки що я роблю проект сам і роблю як вмію. По моїм замірам він буде справлятися з нагрузкою десь до 20-40 запитів на секунду. Якщо враховувати, як часто один користувач всередньому робить дії у системі, і що 80% активності генерують 20% користувачів, то такої продуктивності вистачить десь на 50-100 тисяч зареєстрованих користувачів (при гарячих ситуаціях будуть пробуксовки, але це має бути рідко). А коли в проекті буде така кількість користувачів, то на нього вже думаю звернуть увагу серйозніші розробники, ком’юніті і навіть цілі компанії, які мають потужний ресурс. Тоді вони маючи отакий робочий прототип і розуміння що воно потрібно, зможуть досить швидко розробити імплементації на інших технологіях (C++, Erlang, Go, Rust, Java, .NET та ін).
        Наявність реалізацій коду на різних мовах і технологіях, є одним з ключових пунктів побудови децентралізованої платформи з точки зору надійності та безпеки.
        Моя задача зараз — це MVP, тому питання опрацювання сотень тисяч юзерів сюди не входить.
      • Без блокчейну - нічого не буде. Та навпаки - якщо там буде блокчейн - гарантую багато зацікавленості.
        13 Jun
        Це є дуже спірне питання. Якщо розглянути потенційних користувачів то на мою думку певно для 95% абсолютно байдуже які технології використовуються у системі. Для них важливо щоб система 1) працювала стабільно, 2) справлялася зі поставленими задачами, 3) щоб від знайомих технарів можна було почути що системі варто довіряти. А тепер розглянемо ті решту 5% людей. Якщо вони розібралися що таке блокчейн, то їм не буде важко зрозуміти, чому у нас він не використовується і при цьому не знижується рівень захищеності даних (а по суті буде вищий, бо атаку 51% буде провести значно важче завдяки впливу рівнів довіри на ноди в майбутньому). Якщо ж я помиляюся, то в певний момент знайдеться блокчейн-експерт, який доведе що нашу мережу можна зламати так і так, а якщо використати блокчейн, то проблема зникне. От тоді ми візьмемо і використаємо блокчейн. Щоб ти розумів, технічно будувати надійну децентралізовану мережу без блокчейну значно важче, ніж на ньому (просто з ним появляються майнінг, proof-of-stake, цензура та інші негативні штуки, які мають схильність приводити до централізації). А поки що ні від кого не постувало ніяких конкретних технічних зауважень.
      • У вас не використовується blockchain, а жаль…
        7 Jul
        А цей "жаль" чимось аргументований? Можна старатися бути в тренді і ліпити блокчейн до всього підряд, а можна ж підбирати адекватні рішення.
        Можна ж спробувати поставити систему і на основі досвіду роботи з нею зробити висновок, що "от блокчейн би допоміг їй вирішити цю і цю проблему…".
        Я не перший раз чую цей "жаль", але кожен раз без аргументації…
      • ПК є частиною ідентифікації особи
        9 Oct
        >ПК в мережі є невідомими (наприклад, це може бути тестовий ПК, де пробується все) і ставлення до особистої безпеки користувачів є невідомим (наприклад, люди можуть залишати ПК друзям не виходячи зі свого юзер акаунта). А в цьому разі, ПК є частиною ідентифікації особи, оскільки юзери не мають фізичного носія їхніх електронних підписів (наприклад, не вставляють ай-ді картку щоб проголосувати)
        Хибне твердження. На це питання теж відповідав уже там де абзац починається зі слів "доступ к моему аккаунту должен …"
        Використання ID-карток — не проблема запровадити такий доступ, а проблема, щоб люди виросли до цього рівня. Це при становленні системи зверху вниз таке гарно працює, а в нашій ситуації, більше реальним бачу в момент генерації ключі просити ставити флешку і далі просити ставити ту ж флешку на початку кожного сеансу роботи. Я взагалі за опції, щоб підтримувалися різні носії ключа, і кожен обрав собі підходящий, а по замовчуванню зробити середньої надійсності/складності (ще буде голосування про це).
      • Як що до підтримки існуючих методів електронної ідентифікації (ЕЦП, BankID)?
        16 Oct
        Про державний ЕЦП серйозно. Ви розумієте, що це є інструмент системи? Так він визнається державою, але в той же час ніщо не заважає системі "нагенерувати" будь-яку кількість потрібних голосів для "корегування" волевиявлення народу. З BankID ще гірше, бо там ще більше гравців мають можливості генерити мертві душі. І у нас немає жодних можливостей перевірити справжність голосів і виявити таку підставу. Хіба організація паралельного голосування і аналіз розбіжностей.
        Для тих, кому цікаві деталі, то в нашій системі кожному новому учаснику генеруються його персональні ключі для цифрового підпису (які він сам вибирає де зберігати: на компі, на флешці, на пластиковій карті і тд, це на розсуд людини). А оскільки база учасників відкрита, то в нас є гарантія відсутності отаких вбросів, бо немає якоїсь точки, де би цей вброс можна було непомітно здійснити — у нас всі дії публічні і завжди буде видно кожну спробу і хто її ініціював.
        Так наш цифровий підпис не визнаватиметься державою, але нашою метою має бути те, щоб його визнавали в першу чергу учасники мережі, і коли таких учасників буде достатньо багато
        17 Oct
        а коли це буде? і чи буде взагалі?
        , тоді всі будуть змушені так чи інакше враховувати такі голоси. Грубо кажучи з часом появляться депутати, які будуть його визнавати і коли таких депутатів у парламенті стане більше 225 — тоді можна буде вже почати говорити про невизнання державного ЕЦП, як застарілого централізованого інструменту з усіма його недоліками.
        Державний ЕЦП, чи BankID, можуть бути використані при верифікації людини у нас, а далі при реєстрації людина отримую нову пару ключів для цифрового підпису у системі.
        3 Jan
        Використання ЕЦП може мати сенс для авторизації користувачів (наприклад, виставити всім нодам без авторизації за допомогою ЕЦП нульову довіру). Але в такому разі з'являється організація-емітент ЕЦП...
        3 Jan
        Перенесено в гілку обговорення ЕЦП
    • До пріоритетів:
      3 Oct
      • Я би зосередився на практичних сценаріях використання. Без успішних кейсів застосування воно ніколи не взлетить.
        13 Jun
        Звичайно, це всі розуміють. Тому ми в групі і на онлайн-конференціях обговорюємо, кому може бути потрібен подібний продукт, хто може стати першими користувачами. І саме через отакий підхід всі проголосували за те щоб в першу чергу робити функціонал груп, що дозволить будь-якій спільноті використовувати платформу для вирішення своїх конкретних задач, а не приймати участь у незрозумілих загальних голосуваннях яких повно зараз у системі.
        Але це тільки початок, бо для того щоб задачі переходили у проекти і їх реалізацію потрібно ще розробити фінансову систему і функціонал ведення проектів (від постановки задачі до реалізації через підрядників/виконавців). А щоб усім цим могла користуватися широка аудиторія, мають бути вже готові легкі клієнти для мобільних.
        От коли ці 4 компоненти будуть зроблені — тільки тоді появляться успішні кейси застосування платформи з конкретними результатами в реалі.
      • Нереально швидко це все втілити
        3 Oct
        Увесь комплекс описаного в документі функціоналу є нереальним для швидкого втілення малими ззусиллями
        3 Oct
        Швидкого втілення і не вимагається. Тим більше суспільство ще не готове… потрібен буде час
        3 Oct
        приблизно який час?
        3 Oct
        Для суспільства певно років 5-10 (щоб електронні системи дійсно пішли в маси).
        Для розробки системи треба десь рік-два, щоб розгорнути функціонал по максимуму, але вже за пару місяців уже буде що пробувати тестувати у мінімумі.
        Але це тільки мої прогнози, а я з прогнозами не дружу :)
        3 Oct
        Розробка та розвиток нових продуктів це тривалий процес в якому важко передбачити реакцію користувачів на нововведення.
        Писати відразу щось масштабне нерозумно, бо високий ризик випустити на ринок щось абсолютно непотрібне користувачам. Тому спочатку розробляється Minimum Value Product - повністю працюючий продукт але з обмеженим функціоналом (лише з найважливішими функціями). MVP розробляється швидко і відразу запускається в люди для тестування і збору відгуків. Таким чином аудиторія і продукт розвиваються паралельно і народжується новий ринок.
        Погляньте на Facebook. Це складний програмний сервіс. Навіть мені айтішнику важко і "влом" викати в деталі великого сервісу, яким я раніше не користувався. Але у Facebook мільйони користувачів і більшість з них прийли туди в той час, коли соц-мережа мала значно меншу к-ть функціоналу. Навички користувачів еволюціонували разом з самою системою.
        Тож для старту не потрбно відразу весь продукт. Достатньо лише його найважливішого функціоналу, але з програмною архітектурою придатної для маштабування.
        на поширення/просвітлення.
        3 Oct
        Підхід називається Release Planning :)
        Можна запланувати поетапне нарощення функціоналу і зосередитися лише на на найважливішому першому етапі, бо інакше втонемо в роздумах і так нічого і не зреалізуємо
        3 Oct
        Вже є дещо реалізовано (дивіться стан проекта).
        . Тільки розробка технічних специфікацій може зайняти місяці. Гнучкий підхід до розробки дозволить нарощувати функціонал поступово, паралельно отримуючи відгуки від користувачів.
        В моїх роздумах "платформа колективного прийняття рішень" це той найбільш необхідний функціонал (MVP) який потрібно запускати першим і на розробку якого цілоком реально зібрати гроші методом спільнокошту (crowdfunding)
        3 Oct
        Якщо би цим хтось зайнявся — було би добре. Бо я зайнятий розробкою.
        3 Oct
        1. Перший крок - визначити мінімальний функціонал, необхідний для запуску MVP. Дуже допоможе підхід, описаний в статті How to build great products
        3 Oct
        Дуже хороша стаття (RethinkDB додано у кандидати на заміну MongoDB).
         
        Пропоную особливості перелічені у цьому документ які можливо розкинути по категоріям:
        • інноваційні
        • обов’язкові
        • незначні
         
        Ось дві таблиці, одну заповніть Ви, а іншу заповню я.
        Ваша версія (якщо немає доступу до редагування, то додайте тут комент зі своєю таблицею. це є віджет Simple Table):
        Моя:
        2. Другий крок - User Experience
        3. Третій - дизайн
        4. Маркетинг
        3 Oct
        Кому можна продати безплатний опенсорсний продукт? Варіанти є, але тільки після доробок, які я поки не планую.
        Коли буде смачна картинка, яким буде софт, тоді буде легко продемонструвати ідею та залучити кошти на розвиток, розробку і підтримку системи.
        3 Oct
        Легко не буде. Але якщо хтось за це візьметься і залучить кошти, то за таку роботу звичайно отримає частину з залучених коштів.
        Якою має бути частка на Вашу думку (у % наприклад)?
        . Делегування, безпека та інший ф-онал може нарощуватися поступово.Проста інтуїтивна ситема, яка б дозволила учасникам ініціювати пропозиції, обговорювати і вдосконалювати їх, формувати альтернативи та голосувати в рамках локалізованих груп уже необхідна різним громадським організаціям та соціальним ініціативам. А в першу чергу, вона потрібна для прозорого прийняття колективних рішень з подальшого розвитку даної системи учасниками даної ініціативи. Чи не так?
        3 Oct
        Саме так. Найперше бойове хрещення система має пройти на основі обговорення і розробки самої себе :) Це і є найперша ціль для досягнення.
        3 Oct
        Тоді Per-to-Per має низький пріоритет. За нами поки-що ніхто не полює ;)
        Можна розпочати зі звичанойї веб-платформи прийняття рішень.
        3 Oct
        Підніміть тоді http://liquidfeedback.org/ у себе і пробуйте. У мене задача побудови саме децентралізованого рішення, цим і займаюся.
        3 Oct
        Я не програміст. Роковий недолік liquidfeedback - інтерфейс. Нашим продуктом, умовно кажучи, повинна з легкістю користуватися бабуся, що помідори продає на ринку. Інакше його чекає дуже мала кагорта прихильників, жодного вірусного ефекту і провал.
        3 Oct
        Хтось знайомий з проектом "Нарада" nr.org.ua ?
        3 Oct
        Так. Він уже не розвивається, або дуже повільно розвивається.
        Ось на цій сторінці повідомлення жовтим — http://nr.org.ua/pages/liquid_democracy
        Воно там уже давно.
         
        Проект показав, що нікому е-демократія не потрібна. Як мінімум централізована в наших реаліях, так точно.
        3 Oct
        Хибний висновок. Просто проект не мав достатньо функціоналу і не ніс для більшості мінімально необхідних цінностей
        3 Oct
        Ініціативи є, обговорення є, голосування є. Чого на Вашу думку не вистачало? І про які цінності йде мова?
    • Різне:
      14 Oct
      • Про задачу створення поля для співіснування та взаємодії різних поглядів
        13 Jun
        (з обговорення питання оцінювання текстів на Форумі)
        Gennady Shkliarevsky:
        Вы ставите интересную и очень сложную задачу. Сложные задачи решаются одним образом: их подразделяют на более простые и решают каждую задачу отдельно, а потом уже собирают в единое целое.
        Я посмотрел Вашу страничку. Если я правильно понимаю, то Вы стараетесь создать платформу и найти техническое решение, которое сделает возможным участия большого числа людей и сообществ в общественно-политическом практике, в частности в принятии коллективных решений. Принятие решений это вообще сложный и многоходовый процесс. Он становится особенно сложным в тех условиях, которые Вы формулируете, то есть, ситуации, когда мы имеем дело с самыми разными взглядами и мнениями.
        Решения никогда не формируются на пустой почве. Решения всегда подготавливаются путём создания общего поля, которое может допускать различия, но в то же время создаёт условия, в которых эти различия определённым образом сосуществуют и обогащают друг друга.
        13 Jun
        Мені не зрозумілий термін "общее поле" в даному контексті. Можете пояснити, як це виглядає на практиці, навести якісь приклади?
        По нашому скромному досвіду ми вже прийняли багато рішень без окремого явного створення якогось поля. Чи значить це, що згадане поле вже існувало, або було створено неявно?
        Мне кажется создание такого поля с помощью технических средств есть Ваша первая и пожалуй самая сложная задача.
        Сложность задачи состоит прежде всего в том, что в этом общем поле прежде всего необходимо сохранить различия между мнениями и точками зрения, то есть мы ставим своей задачей не нахождение консенсуса, а именно нахождение таких рамок, где самые разные позиции могут продуктивно сосуществовать.
        13 Jun
        У нашій системі немає процесу знаходження консенсусу. У нас всі думки, всі запропоновані різні рішення завжди видно у списку пропозицій, до них йде аргументація і голосуванням люди висловлюють свою підтримку тим чи іншим пропозиціям. Тобто у нас різні пропозиції справді співіснують.
        Більше того, завдяки тому, що голосування ніколи не завершуються, як тільки певна пропозиція здобуде більшу підтримку ніж та, що була прийнята раніше — в цей же момент система перебудовується відносно нового прийнятого рішення.
        Тобто є суттєва відмінність від голосувань, які закриваються після прийняття рішень: у них, як тільки рішення прийняті, то у багатьох опускаються руки і їм доводиться змиритися з протилежною думкою на певний термін, або починати йди в опозицію і готуючи реванш до моменту наступного голосування (часто це через багато років). У нас же, є смисл продовжувати боротьбу незважаючи на прийняте рішення, продовжувати працювати з людьми, бо при більш якісному рішенні є всі можливості для швидкого отримання більшої підтримки і зміни прийнятого рішення.
        Ведь именно различия являются источником новых и более мощных образований. Одними техническими средствами без новых подходов в общественно-политической практике здесь не обойтись. Прежде всего участники должны понимать, что именно сохранение различий увеличивает мощность целого. Они также должны понимать, что создание общего поля, включающего разные точки зрение, это такая задача, которая потребует от них значительных творческих усилий, то есть, они должны будут создавать нечто новое, что до того, как они вступили в контакт, не существовало. Для осуществления этой задачи им также потребуется выработка определённого морального отношения: они должны принимать и уважать автономию других участников, а это значит, что они не должны стараться убедить партнёров в своей правоте.
        13 Jun
        На нашій платформі правилами заборонено голе переконування. Якщо написати до певного рішення коментар типу "це рішення не буде працювати, краще зверніть увагу на рішення B з ним все буде як по маслу" — то це буде порушенням пункту 2.4 правил, і такий заклик буде видалено, а автор отримає санкції.
        Потрібно або аргументувати опираючись на факти, або явно вказувати на суб’єктивність твердження.
        Они должны стараться создать такие рамки, где все мнения и взгляды имели бы место как частные случаи. Это существенно отличается от нашей современной практики, где мы стараемся либо убедить друг друга в правильности какой-либо позиции, либо найти компромисс. Менять модель привычной практики всегда сложно и к сложностям перехода нужно быть готовым. Однако, так как творчество всегда приносит удовольствие, творческие усилия по созданию общего поля для принятия решений тоже станет источником удовольствия для участников, что должно облегчить процесс перехода от одной практики к другой.
        Если мы имеем дело с сообществами (спільнотами), то я думаю, что процесс выработки общего поля будет проходить намного легче, если сообщество будет представлено общей позицией всех своих членов, а не их индивидуальными мнениями, тем более, что эти мнения будут учтены при создании общей позиции сообщества.
        13 Jun
        "намного легче" — на мою думку немає сильної різниці між тим, коли людина особисто приймає участь у голосуванні, або ж делегує свій голос певній спільноті до якої вона належить, чи її лідеру.
        Останнє у нас уже реалізовано, тобто лідер спільноти приводить роботу між учасниками і вони або голосують відповідно, або ж делегують свій голос цьому лідеру.
        Якщо ж обмежити участь до голосу лише спільноти, то мінусом такого підходу буде втрата думок певних індивідів, які можуть бути дуже навіть цінні.
        Тогда общее поле будет уже вырабатываться в процессе взаимодействия между сообществами, а не индивидуумами. В противном случае, могут возникнуть существенные трудности по координированию взглядов и мнений огромной массы людей.
        13 Jun
        Не бачу складності в тому, що кожна людина або проголосує за існуюче рішення, або делегує свій голос певному лідеру своєї спільноти, або ж запропонує своє рішення — все це є та чи інша одна дія.
        Єдине що може бути — це генерація великої кількості пропозицій рішень. Тоді якщо це дійсно якісні пропозиції — то це не проблема, а навпаки дуже хороший результат. А якщо більшість рішень будуть неякісні, то вони будуть на дні рейтингу, або навіть будуть видалені модераторами, через порушення пункту 2.1 правил.
        Этих трудностей можно избежать без ущерба для индивидуальных точек зрения с помощью постадийности.
        Хотя создание такого поля не является само по себе выработкой решений, оно ставит определённые рамки для процесса принятия решений, что может быть и максимум, что может быть достигнуто в случае участия большого числа людей (скажем членов гражданского общества). Мне кажется, что к большему и не нужно стремиться. В конце-концов существуют политические партии, которые могут сформулировать общие мнения и волю гражданского общества в политическую программу. Есть законодательные и исполнительные органы, которые выработают на основании таких программ решения, которые воплотят эти мнения и волю в конкретные меры.
        Конечно, для того, чтобы осуществлять эту модель, должна быть политическая партия или партии, которые бы опирались на гражданское общество и полагались бы на его поддержку. Таких партий сейчас пока не существует. Поэтому создание такой партии может быть первым важным решением гражданского общества и сообществ, входящих в него. Для этого можно подготовить съезда гражданских организаций,
        13 Jun
        З’їзди це вчорашній день, як на мене.
        который бы и сформулировал бы политическую программу и выбрал бы политических лидеров, которые бы руководствовались в своей деятельности этой программой.
        Я уверен, что данный пост далеко не является исчерпывающим. Я также уверен, что живая практика даст много нового и детализирует разные аспекты такой модели.
        13 Jun
        Можете спробувати описати чіткіше запропоновану модель і винести у нас на голосування. Як тільки така пропозиція отримає підтримку більшості — наша система перебудується на такий формат роботи. І тоді зможете спробувати її на практиці.
        Однако этот пост может стать началом для дальнейшего обсуждения этой проблемы, в которых можно перейти к оценке текстов.
        "Як би Ви запропонували вирішити проблему оцінювання публікації людьми з протилежних спільнот"
        Во первых, нужно определить какое аксиоматическое представление лежит в основе публикации, то есть, что принимается авторами как самоочевидная истина. Нужно также знать какие аксиоматически истины служат основой вашим собственным взглядам. Если Ваш взгляд включает аксиоматическое положение публикации другого сообщества, то естественно, что тот взгляд что шире, а следовательно и мощнее должен быть разделён обеими сторонами. Если аксиомы обоих сообществ просто не совместимы, то нужно построить такие рамки, которые бы включали все аксиомы как частные случаи. Вам это понятно? Сообщества гражданского общества должны постоянно строить более широкие рамки видения реальности, что обеспечивает большее число возможностей, определение новых проблем и нахождение решений этих проблем. Это важная часть того, что я вижу как новая социально-политическая практика. У меня есть ряд статей на английском языке. Если интересуетесь могу сбросить.
        13 Jun
        Це все зрозуміло, але Ви пишете про те що було би добре, щоб не було протилежних спільнот, а щоб усі і кожен мав настільки широкі погляди, щоб кожна зі сторін могла адекватно оцінувати будь-які публікації.
        До цього потрібно прагнути, але поки що це далека перспектива, а зараз маємо те що маємо.
        Я дуже радий, що у Вас є ряд статей. Але зрозумійте що ми шукаємо людей, які на основі отаких статей, теорій та ідей вже мають що запропонувати конкретно для практичного втілення. У розробників немає ресурсів, щоб ознайомлюватися з усіма можливими теоріями…
        Якщо розглянути те що Ви запропонували (на основі Ваших статей та теорій) як пропозицію вирішення поставленої задачі, то на практиці Ваше рішення виглядало би приблизно так:
        1) Людина читає публікацію, доходить до кінця.
        2) В кінці бачить і жме на кнопку "Оцінити"
        3) Їй показується питання: "Вы определили, какое аксиоматическое представление лежит в основе публикации?". Кнопки "Так", "Ні" або навіть вибір варіанта на перевірку правильності. Якщо людина відповіла "Ні" або неправильно оприділила — все, діалог завершується і людині не надається права оцінити публікацію. Якщо людина відповіла "Так" — переходимо до наступного кроку.
        4) Людині показується питання "Вы знаете, какие аксиоматически истины служат основой вашим собственным взглядам?" Варіанти "Так"/"Ні". Якщо ні — до побачення, якщо так — йдемо далі.
        5) Показується питання "Ваш взгляд включает аксиоматическое положение данной публикации?" і кнопки відповіді.
        Якщо "Так" — переходимо до останнього кроку: показується форма з можливістю поставити оцінку публікації по шкалі від 1 до 5 балів.
        Якщо "Ні" — фініш з повідомленням "Вам нужно построить такие рамки, которые бы включали все аксиомы как частные случаи. Удачи".
      • Як бути з підкупом лідерів думок і простих виборців?
        2 Aug
        На жаль людського фактору повністю не уникнути, саме тому особливістю системи будемо пробувати зробити доступ до важливих голосувань по рівню довіри. Якщо людину запідозрять у продажності (наприклад буде опубліковано певне розслідування), то люди висловлюють їй недовіру і її голос втрачає силу у всіх голосуваннях, де вона прийняла участь.
      • Де якісь тестові обговорення не системи, а реальних проблем?
        14 Oct
        Дивіться п. 2.2 правил мережі. Саме через нього в силу наших можливостей зараз працюємо виключно над задачами навколо системи. Як будуть розширюватися наші можливості, наприклад як появиться якась невелика громада в системі, тоді вони зможуть вирішувати вже більше реальні задачі.
  • Пропозиції:
    7 Jul
    • По структурі цього документу
      25 May
      Хотілося б побачити зверху сторінки:
      1. Яка мета проету? Гасло так би мовити. Стилсо.
        25 May
        Гаслом служить заголовок, а мета вказана зразу після переліку особливостей (додав виділення)
        25 May
        Що спільного між відкритістю і доступом лише за запрошеннями?
        25 May
        Відкритість — це про відкритий код і про те, що всі записи зберігаються публічно, тобто що немає чорних ящиків.
        Мету раджу підняти в самий верх. І скоротити заголовок.
      2. Які переваги саме цього рішення. Технології НЕ Є первагами.
        25 May
        Технологія + особливості і є перевагами.
        25 May
        Ні. Жодна технологія чи особливість сама по собі не є перевагою. Вона є перевагою або вадою тільки в рамках певних вимог, обмежень і контексту.
        Наприклад, візьмемо першу ж особливість: Open Source.
        1. По-перше, де лінк на цей самий source у open репозиторії?
        2. По-друге, я за своїй роботі за останні 6 років бачив багато і закритих, і відкритих проектів. І у динаміці open source не гарантує нічого. Ні якості, ні популярності, ні зрозумілості, не захищеності, ні розвитку проекту. Є багато мертвих open source проектів, які колись були класними і популярними, але ними зараз ніхто не користується.
          25 May
          Згоден, не гарантує. Тому ніде таке не заявляється.
        3. Я підозрюю, що Ви мали на увазі, що цей проект:
        1. безпечний - в тому плані, що все по чесному - він прозорий для аудиту - кожен може перевірити, що все працює, як заявлено
        2. відкритий до співпраці - кожен може зробити свій внесок
        25 May
        Саме так. Це є просто необхідний мінімум, щоб проекту можна було хоч трохи довіряти і щоб він не був намертво зав’язаний на одному розробнику.
        оці дві речі і є реальними перевагами проекту. І саме їх і треба вам вказувати. Навіть ще більше їх конкретизувати. Щоб навіть бабця могла зрозуміти, в чому плюси цього проекту.
        І так по всім пунктам.
        4. Я написав "я підозрюю" бо явно це ніде не прописано.
        Я до чого:
        1. Ви з таким описом цю систему нікому не "продасте".
        2. Я готовий Вам помогти сформувати нормальне NABC - сам робив такі самі типові помилки.
        3. Але Вам доведеться визначитись з цільовою аудиторією. Або, принаймні, з приорітетною цільовою аудиторією.
        25 May
        Тільки підтримую таку ініціативу.
         
        На різних етапах і різні сторони проекту матимуть різну цільову аудиторію. Проект багатогранний.
         
        Зараз цільова аудиторія:
        1. ІТ спеціалісти, які можуть оцінити, або допомогти з технічною реалізацією задуму, щоб в результаті можна було сказати, що ІТ-спільнота довіряє такому технічному рішенню;
        2. різного роду активісти громадянського суспільства, які шукають інструменти електронної демократії та самоорганізації; люди які не розбираються в технічній частині, але з радістю прислухаються до ІТ-спільноти у питанні довіри до платформи.
      3. Плани реалізації цих переваг (можно у згорнутому вигляді, Кому треба - натисне кноку і розгорне).
        25 May
        План розвитку динамічний, визначаються спільнотою через голосування
        25 May
        Це круто, але людям потрібна певність: коли у вас буде те, що їм треба.
        25 May
        Це ж не краудфандинг з обіцянками суппортерам. Все робиться по мірі можливостей.
        Принаймні, Вам варто регулярно вказувати поточний статус фіч проекту. Щоб було видно динаміку.
        Якби source code лежав десь відкрито, таку динаміку хоча б опосередковано можно було б простежити.
      4. Лінк на Github чи Gitlab, якщо це дійсно проект з відкритим кодом, а не пуста декларація. Створити там репозиторій - рівно 5 хвилин. А шаніс на підтримку - набагато більше.
        25 May
        В першій особливості вказано що код буде на GitHub. Хочеться трохи його підготувати до публікації.
        Великий лінк на код знаходиться на сторінці проекту — http://power-of-trust.net
        Кому цікаво той вже давно читає сорси, бо вони легко доступні.
        25 May
        "легко доступні" - це лінк на Github?.
        25 May
        Ні. Мається на увазі, що після встановлення системи, всі коди доступні у папці app на локальному диску. Жоден з компонентів не компілюється, про що чітко сказано в системі у розділі "Допомога" - "Про систему" першим же пунктом.
        "Великий лінк" - це який? Там де написано Github, питає пошту і нічого не відбувається? Чи у мене в Chore що не те?
        25 May
        Повторюю, код готується до публікації на GitHub. На сайті зроблена можливість підписатися на відповідне повідомлення.
    • Що до пріоритетів
      13 Jun
      • Я би радив знайти сценарій та модель викоирстання цього в ICO і класичних корпоративних організаціях – це не є "е-дем", але ця сфера дуже швидко розвивається – тобто більше шансів реалізувати "успішні історії" використання програми.
        13 Jun
        Ми робимо проект з фокусом на побудову громадянського суспільства, тому в напрямку корпоративного застосування стараємося не дивитися, хоча в деяких учасників є такі побажання.
      • Проект треба робити одразу із орієнтиром на міжнародне застосування, чи точніше закордонне. Будь чесним перед собою - які шанси що це взлетить в Україні?
        13 Jun
        Якщо в Україні не взлетить, тільки тоді думаю будемо пробувати закордоном. Або паралельно, якщо хтось за цей напрямок візьметься.
      • Англійська версія має бути по дефолту
        13 Jun
        Код пишеться з англійськими коментами, репозиторій теж будемо старатися на англійській підтримувати, сайт теж буде на різних мовах, там зараз просто робиться перенаправлення на /ua/.
        Буде так, що якщо скачувати клієнт зі сторінки що на англійській — то там дефолтова мова буде звичайно ж англійська. Але це все пізніше буде.
    • Що до пошуку фінансування розробки:
      13 Jun
      • Я бачу можливість виходи на ICO (почитай новини, як проекти зараз збирають мільйони за 15 хвилин виходу на ринок).
        13 Jun
        Для організації ІСО треба щоб:
        - або в проекті була внутрішня валюта, яка згодом має торгуватися на біржах і всі держателі перших монеток розраховують на те, що її вартість буде рости за часом
        - або ж це мають бути типу акції (чи токени), а проект має генерувати прибуток, який розподіляється між цими акціонерами.
        У нашому проекті не буде ні внутрішньої валюти, ні генерації прибутку (в ідеалі, бо думки що до цього є, але не хочеться перетворювати проект у комерційний). Це є особливості нашого проекту, якими він вигідно відрізняється від інших саме для простого користувача (його не заставляють купляти непонятні монетки на вході).
        У нас будуть інструменти для інвесторів, але пізніше, коли вже буде фінансова система.
        29 Jan
        Є голосування, де вирішено, що у нашому проекті не буде внутрішньої валюти? Здається знову Юра за своє. То громада має вирішувати такі питання, а не ти один.
        29 Jan
        Емісія своєї валюти зразу переводить проект у статус «поза законом», тому поки що таке не планується. І якщо би щось таке проголосували учасники — я зразу вийду з проекту і продовжу гілку без валюти.
        29 Jan
        "Поза законом". Це каже людина, що створює систему, в якій люди самі можуть обирати собі закони.
        Токени, як засіб обміну за послуги в системі явно не є порушенням "закону".
        29 Jan
        Читай тут:
        30 Jan
        Бачу декому приклади Aragon та інших не є зразком. Зате "могутнім" зразком, на який орієнтуєшся - це деструктивні порядки, що встановлені нинішньою "адміністрацією".
        31 Jan
        Валюта не обовязково має називатися "валюта". Просто назвати "токени" або "енергія" як зараз. Звязок із законом миже виникнути коли хтось комусь продасть ці токени за реальні гроші. А до того часу це не проблема.
        Крім того, валюту найлегше реалізувати із блокчеейном. А він в свою чергу має багато додаткових фічей які пригодяться.
        Я за те щоб перевести базу на блокчейн (блокчейн + теперішня база) . Че покращись секюрність системи.
        Коротше ти хвилюєшся, що за таке тебе захочуть "прикрити". Це є обмеженням і ми маємо серйозно поставитись до цього, чи хоче спільнота вцілому приймати це обмеження і наскільки довго. Те, що ти захочеш зробити з фінансовою системою на основі гривні - це минулий вік. Ти якби захищаєш старе та те, що не має перспективи. А якщо твоя гривнева фін. система буде вбудована в "Силу Довіри" жорстко, а не як плагін, то це дуже погано.
        31 Jan
        На рахунок "То громада має вирішувати такі питання, а не ти один" . Мені здається такий підхід не буде працювати. В мережі не можна когось змусити щось робити. Можна лише заборонити щось робити. Але як саме кожен учасник діє для досягнення загальних цілей - це його проблема. Люди придумують якісь проект і його реалізовують. Інші учасники можуть приєднатися або проголосувати проти або проігнорувати.
        Це стосується і розробників. Розробник пропонує своє бачення. Мережа можу прийняти оновлення системи а може і не прийняти якщо не подобається. Розробників може бути декілька.
        В майбутньому буде потрібен механізм оновлення системи. Де буде показано хто саме підготував оновлення (із підписуванням оновлення учасникам(и) мережі. І прийнти чи ні.
        Кожен мусить мати можливість додати своє оновлення коду
        31 Jan
        Думаю такі речі стосуються учасників, а раз так - то ми маємо право проголосувати і дізнатися думку більшості. Як при цьому буде діяти розробник - то вже річ інша. Тобто рішення можуть розділитися на те, що треба більшсоті і те, як хоче зробити розробник і як він зробе. Звісно, кінцеве рішення приймає розробник. Тепер залишилося прислухатися до думки користувачів системи також.
        31 Jan
        Так. Розробник ввикористовує побажання більшості як орієнтир. Він може задовільнити більшість, або своє бачення. А більшість вирішує чи його бачення підійде.
        29 Jan
        Зрозумій, що якщо token sale буде успішним, то ці обмеження "поза законом" можна буде обійти набагато ефективніше, та розвиток системи значно, значно б прискорився. Але зновуж таки - не вистачає гнучкості мислення в декого (не буду тикати пальцем).
    • Перехід на Ethereum
      25 May
      > Зараз з'явився новий блокчейн-проект Ethereum, який гарно підходить для таких проектів, як ваш.
      Ethereum дійсно дуже потужний і гнучкий проект. Але він надто глобальний і надто універсальний (своя мова, на якій можна реалізувати будь-що), через що він мене дещо відлякує. А те, що для участі в цій мережі на всі дії витрачається Ether, який хтось має закупити і ним розпоряджатися (або в гіршому випадку кожен учасник має мати гаманець і купити трохи Ether) — то це взагалі ставить під сумнів його перспективи у цій галузі, принаймні зараз. З іншого боку наша система цього недоліку немає.
      Доповнення:
      Щоб усі розуміли: якщо блокчейн чужий, то швидше всього усе що ви би на ньому не організували — буде платно для вас і для усіх ваших користувачів. В кращому для всіх випадку організатор буде оплачувати всі транзакції, а в гіршому організатор буде вимагати від учасників заводити гаманці і купляти відповідну криптовалюту — що є взагалі фантастикою навіть у довгостроковій перспективі. Вартість буде залежати від курсу криптовалюти, стабільність якого може зіграти проти усіх учасників. Окремо має вирішуватися задача ідентифікації учасників.
      Тому я поки не розглядаю варіанти інтеграції з будь-яким чужим блокчейном. Хіба періодично зберігати в них певну метаінформацію чисто для надійного бекапа чи можливості щось звірити/довести.
    • Спочатку визначити делегатів "першого рівня" "паперовим" шляхом
      25 May
      Михайло Петелицький: це було б непогане технічне рішення, системи делегування.. але вже на другому етапі, після того як народ визначить делегатів "першого рівня" "паперовим" шляхом. у своїй концепції я більше наголошую на створенні основи для розвитку таких от ідей як Ваша.
      25 May
      Не бачу можливості найближчим часом щось змінити у цьому питанні правовим шляхом. А от запуску мережі ніби нічого не заважає (поширенню заважає багато що). І якщо мережа покаже свою життєздатність, то на основі неї доведеться творити партію і йти в парламент (надіюсь знайдуться охочі).
      25 May
      все треба рахувати, скільки буде охочих. Щось будувати на надіях ніхто не заважає, але наявна статистика доводить, що вони майже ніколи (а в складних ситуаціях - строго ніколи) не збуваються.
      25 May
      Але іншого шляху як іти правовим шляхом просто нема. Інакше така система не вийде за рамки професійних спільнот.
      25 May
      Ну значить не вийде — це теж буде результат.
      25 May
      Думаю, всі ці наші обговорення мають єдину мету - якщо шлях тупіковий, зрозуміти це якмога раніше, і не витрачати сили (і автору, і тим, хто помагає), а шукати інші шляхи. Заощаджені сили і час - ото тоді і буде результатом обговорення.
    • Що до поширення
      7 Jul
      >Чи не могли б ви приїхати до нас презентувати свою систему?
      Ще треба попрацювати, щоб було що презентувати…
      А ще краще, якщо би люди пробували що є, і якщо буде потреба я би їхав уже обговорювати конкретні питання, зауваження, стратегії. Просто їхати переказувати те що є доступно на нашій сторінці у мене немає бажання.
      >Але ж так і відбувається популяризація ідеї
      Я ж розробник… їздити і розказувати — це не моє. Якби була у команді відповідна людина — це інше діло.
  • Питання та відповіді:
    14 Oct
    • чи є реальний запит на таку систему?
      9 May
      Я заходив на кілька майданчиків з системами голосування - там завжди дуже мало людей.
      До речі, яка мінімальна кількість учасників такої системи (щоб відчути переваги та особливості, чи для випробування)?
      9 May
      Не знаю. Я не мав ще нагоди спробувати щось подібне, тому будемо формувати власний досвід.
    • чи варта вдосконалювати демократію
      9 May
      Чи приймаємо демократію як ідеальний та єдино можливий устрій? Може демократію треба не вдосконалювати, а змінити на іншій устрій, бо демократія має дуже багато недоліків: О демократії тому всі наши зусилля можуть бути марними.
      9 May
      Якщо врахувати вплив запланованого механізму делегування голосів та допуску персон до голосування по певних критеріях, то отримуємо щось ближче до меритократії/ноократії.
      9 May
      рейтинг прив’язується до людини, але я можу бути фахівцем в одній галузі і ніким в іншій.
      Але в деяких питаннях збережеться можливість дозволити голосувати напряму і з необмеженим допуском (пряма демократія). Хто буде це визначати? Певно найактивніші учасники системи, які заслужити певний професійний рейтинг і рівень довіри.
      9 May
      Мета — створити адекватну систему для прийняття якісних рішень, а не реалізувати певний відомий термін і намертво прив’язатися до нього (демократія/меритократія/ноократія тощо).
      9 May
      То, може, треба навчитися, як приймати якісні рішення (постановка задачі), а вже потім думати про алгоритми та реалізацію?
      9 May
      Це задача вже для кожного окремо, бо кожному доведеться це робити.
      9 May
      якщо кожен буде робити це окремо - то буде це робити на окремому для кожного сервісі або на звичайних Виборах
      9 May
      Кожен ІТ проект має певні стадії, без яких його не зробити. На хлопський розум:
      1. Збір та аналіз вимог (цим ми тут і займаємось)
      2. Розробка User Experience та описання базових специфікацій
      3. Розбиття проекту на задачі (WBS), пріоритизація і планування перших релізів
      4. Ітеративна розробка (дизайн, верстка, код, тестування, фікси)
      А без проектного підходу проект не уявляю. І взагалі бажано спочатку зосередитися лише на найбільш важливих функціях і викатати мінімальний вартісний продукт (MVP), а не цілитися відразу на весь функціонал, бо це завідомо провальний шлях, перевірено багато разів.
      9 May
      Правильно все кажете… але чому тут? Тут йдуть коменти про демократію в загальному і про проблему прийняття рішень для кожного. До чого тут стадії розробки проекта?
      Якщо комент не буде переміщено у відповідну гілку, або прив’язано до контексту, то при наступній чистці його буде видалено звідси.
      9 May
      @Юрій Бабак треба переносити помилково розміщені коментарі та хоч деколи робити реструктурізацію топіка
      9 May
      Я ще вчуся. Спочатку пропоную людині виправитися, бо може я щось не так зрозумів. А згодом перенесу/реструктуризую.
      А розробка інструментів це окрема задача.
      9 May
      розробка вимагає постановки задачі
      9 May
      вона є поставлена, просто неявно
      9 May
      вона має бути явно записана, жоден програміст не буде щось розробляти, доки цього немає (хіба що він сам собі замовник, але ж ми хочемо зробити щось для суспільства)
      Одне іншому не заважає.
    • чому так мало людей долучаються до "Сила довіри"?
      9 May
      Вже досить багато часу мережа працює, чому так мало користувачів? В чому причини?
      10 May
      На маю думку є кілька причин:
      1. Заскладна реєстрація. У наш час для системи, яка в бета-версії вимагати відкористувача стількох зусиль, особливо коли в інших місцях достатньо логіну з соцмережі -- це занадто. ! Доречі, як щодо впровадження BankID?
        9 May
        А як Ви собі технічно уявляєте впровадження BankID в децентралізованій системі?
        Він може використовуватися, але не так як би хотілося… не для самостійної реєстрації.
        9 May
        Э варанти. Найпростіший - як альтернативний логін для веб-доступу (без десктопного клієнта)
        10 May
        Немає альтернативного доступу. Для кожної дії потрібен цифровий підпис. Єдине що потрібно для нього — це ключі, і BankID тут нічим не допоможе.
         
        BankID можна використати лише для верифікації персони і лише за межами системи (окремий сервіс), бо у системи немає центра, який би можна було налаштувати під BankID.
      9 May
      На мою думку: ми не можемо завершити перший крок - зібрати мінімальну кількість людей із якими можна зробити якусь акцію "на вулиці". Десь напевно до 50 людей не із одного міста, які готові "вийти із віртуального простору в реальний".
      9 May
      Акции в "реальном" мире гораздо менее эффективны, особенно когда это касается хоть сколько нибудь сложных вопросов. Люди послушают, скажут "молодцы" и через 5 мин. выбросят это из головы.
      9 May
      Робити акції в реальному світі потрібно щоб знайти нових однодумців. 99 людей забуудуть за 5 хвилин а один зверне увагу на нову організацію яка щось робить без грошей олігархів і відвертого бажанн потрапити у владу на наступних виборах.
      Мені здається так мало би працювати.
      9 May
      Це статистика, реклама в інтернеті сьогодні дає результати, що вищі на кілька порядків, ніж в "реалі".
      9 May
      Це залежить від того яку мету ставити. Якщо розкручувати партію зроблену під себе то підходи одні. В нашому випадку мета інша - об’єднати людей які готові зробити всій внесок у модернізацію країни.
      я не знаю наскільки ефективною буде реклама. Я часто бачив раніше рекламу "інтернет партії", або 5.10 часто мелькає. Але я на це не ведуся.
      9 May
      це типова помилка - люди не такі, як кожен із нас, тому не можна розраховувати, що навіть цільова аудитирія буди робити щось так само, як ти.
      Мені знається що потенційні учасники мережі (руху) також скептийно ставляться до такого типу реклами.
      Хоча варіант із рекламою самої платформи як нового типу соціальної мережі поже дати деякий ефект, привабити нових зацікавлених осіб . але без політики чи якихось закликів
      Щоб зібрати цих перший людей потрібен час та персональні зусилля. З людьми потрібно переговорити декілька раз.
      Коли 2 роки назад ми обговорювли ідею системи, то враження були що вона дуже затребувана. Нас 2-є в одному офісі мають однакові погляди і для нас було очевидно що тільки така меережа може спрацювати.
      Але із того часу ми не знайшли інших людей яким це також очевидно. Всього декілька чоловік, менше 0.
      Наша теперішня тактика - це особисті зустрічі та презентації системи реальним активістам (а не фейсбук аудиторії). Хоча, як показує досвід, частина реальних активістів також живуть у своєму внутрішньому світі і об’єднання їм не потрібне. Так само як і для дейких волонтерів для армії. Вони отримують свою порцію кайфу від процесу і переходити на якись інший рівень не бажають.
      Але , все таки, хочеться вірити що серед 40 мільйонів є ще 50-100 таких як ми, які можуть створити початкове ядро . І це ядро потім почне притягувати більше людей
      9 May
      Мне кажется, что нужно начинать с уже имеющейся группы. Например с вашей группы в ФБ.
      Для начала можно упростить регистрацию - все кто в группе резистрируются принудительно
      9 May
      • любые принудительные действия сейчас только отталкивают людей
      • возможно стоит отключить (хотя бы временно) рекомендации
      9 May
      Я не бачу ніяких проблем із теперішньою системою реєстрації по 2-х запрошеннях. Поки набереться 50 ми роздаємо запрошенн всім зацікавленим. Якщо забрати запрошення то нареєструється 100 людей які після реєтрації забудуть і не повернуться в систему. Потрібні лише дійсно зацікавлені. Мінімум, щоб реально потестувати
      9 May
      Тестування в колі максимально мотивованих осіб - НІЧОГО не каже про реальний стан речей. Треба тестувати в найбільш наближених до реалій умовах, інакше буде продукт для самих його розробників.
      9 May
      Невелика група активістів може показати яскравий приклад
      9 May
      У книзі Леонор Остром "Керування спільним" дуже багато дуже яскравих прикладів, але "інші" просто цим не цікавляться.
      до якого потягнуться інші.
      , а потом уже каждый там размещённый может/должен оценить остальных или некоторых участников.
      9 May
      На мою думку участь у такій мережі — це реальна робота, бо треба вникати у питання, приймати рішення, висловлювати аргументи і все це публічно. Ці всі дії реально породжують відповідальність за наслідки. А людей, які хочуть працювати і нести відповідальність за свої дії — є справді мало.
      9 May
      Не згоден. В принципі, ці голосування ні на що реальне не впливають. І в будьякий момент можна просто піти. То ж, на мою думку, головна проблема -- зависокий барьер ознайомлення з системою.
      Занадто багато треба зробити, щоб залищити щонайменший коментарій. А навіть найменший коментар може бути важливим.
       
      А враховуючи що все робиться через зовсім новий механізм, то і кількість учасників відповідна, бо це є значний бар’єр, стимулу долати який ще
      9 May
      є надія, що ситуація стане іншою? а КОЛИ і ЧОМУ?
      практично немає, бо мережа маленька
      9 May
      розгляд певного питання збере невелику кількість людей (так, це робота), навіть якщо мережа буде великою.
      . Отакий виходить замкнутий круг, доводиться справді з людьми контактувати індивідуально.
    • а можлива реалізація пакету, як одночасно незалежного і невпливаючого на інші, такі самі, для використання одного комп’ютера для трьох, наприклад, незалежних мереж (нод)?
      19 Dec
      Я не певний, що правильно зрозумів питання. Участь у кількох різних мережах з одного компа можлива, але найбільша користь і сила платформи буде тоді, коли вона об’єднує різні групи на одному полі і дає можливості взаємодіяти, а не коли наплодити багато різних незалежних груп. Тобто кожна група у мережі буде мати певну свою під-мережу, але зберігається можливість взаємодії з іншими групами.
      19 Dec
      Alexandr Mitin:
      Попробую пояснити - я психолог та маю мережу зв’язків по спеціалізації, член підводного спортивного клубу, та голова профсоюзу печників, одночасно. Кожну людину не цікавлять задачі інших напрямків, а тільки "свої" групи, клуби, люди,тощо. А якщо узагальнити, - не вийде у нас великого поля, якщо не почнуть створюватися малі, багато, які будуть рости та об’єднуватись. Це процес зрощування спільноти, а не всенародне рішення долучитися до "незнаю кого чи чого". Малі групи (малі спільноти) психологічно не готові до об’еднанного інформаційного простору. Тому навіть неможливо запустити процесс масово (кругова недовіра в суспільстві). Це не вина технічних засобів. Але ж я бачу рішення впровадження через інтереси малих закритих груп.
      19 Dec
      >Кожну людину не цікавлять задачі інших напрямків, а тільки "свої" групи, клуби, люди,тощо.
      Це насправді погано, потрібно створювати умови і можливості щоб люди розширювали кругозір.
      >А якщо узагальнити, - не вийде у нас великого поля, якщо не почнуть створюватися малі, багато, які будуть рости та об’єднуватись.
      Дивіться, наша пропозиція це аналогія: що є один Фейсбук і різні люди на фейсбуці можуть створювати свої групи по інтересах зі своїм колом учасників і працювати у них.
      Так і ми хочемо створити платформу у якій можна організувати роботу різних спільнот відносно незалежно і розділено, при цьому платформа єдина. Тобто люди для взаємодії не творять кожен раз новий фейсбук, а реєструються один раз на платформі і використовую свій аккаунт для доступу до різних груп.
      На нашій платформі зараз можна зареєструватися, але ще немає можливості започаткувати свою групу — цей функціонал вже заплановано, але ще не розроблено. Зараз справді є лише набір загальних питань і голосувань у яких можна прийняти участь — все це зараз пов’язано з процесом розробки системи.
      Я веду до того, що Ваша фраза "та об’єднуватись" значно краще може бути реалізована саме на єдиній платформі, ніж коли це будуть повністю незв’язані мережі.
      Якщо ж Вам не подобається ідея єдиної платформи, а є бажання запускати різні Фейсбуки для кожної з груп, тоді ось є така інструкція для нашої системи.
      19 Dec
      Alexandr Mitin:
      Мені подобається ідея єдиної платформи. Це ідеал, але поки що недосяжний. Я маю на увазі актуальний стан української спільноти. Психологічно, майбутні користувачі, коли рееструються в ФБ - готові підписатися Цукенбергу що вони ніхто, згодні на все, і на те що їх забанить зграя з Останкіно, чи ще щось. Ні ви, ні я їм не зможемо пояснити, що тут система діалогу та голосувань краща, або непідвластна якомусь центру. Та й тому у ФБ, навіть у закритих групах не вирішують критичних до мінімальної конфіденційності питань ніякі громади, партії, профсоюзи. Котики, випуск пару, розваги. Все. .... - Є складність психологічного барьеру для впровадження на цьому єфекті, а потім вже технічна. Якщо йде мова про розвиток платформи тут і зараз - була б чудова сотова система з можливістю об’еднання в майбутньому, якимись механізмами, шлюзами. Де спільнота окремої мережі могла б своїм рішенням поєднуватись з іншою мережею (сота до соти). Не знаю як це грамотно технічно сформулювати.
      19 Dec
      "сота до соти" — це звучить красиво, але що на логічному, що не технічному рівні, така ідея породжує дуже багато запитань. Наприклад який статус надати людині з іншої соти, якщо вона не проходила ніякі перевірки, які передбачені у нашій соті.
      У технічному плані значно більше питань, бо це все будуть незалежні бази даних, тощо…
      19 Dec
      Alexandr Mitin:
      Так, це складне питання. Воно має вирішуватись так, як і в реальному фізичному просторі, коли об’єднуються (увага, - чи розмежовуються!) якісь соціальні групи. Я не уявляю технічного рішення, то може народ щось вигадає. Бо це динамічна система довіри груп. Хочеться реального поширення та застосування такого чудового інструменту для рішення нинішніх проблем\задач.
      19 Dec
      >Я не уявляю технічного рішення, то може народ щось вигадає.
      Зі своїм досвідом і знаннями я би за таке не взявся…
      >"увага, - чи розмежовуються!"
      Оце технічно якраз елементарно робиться, бо кожна з відділених груп має повну копію поточного стану системи і від моменту розділення вони вже по-різному її модифікують (залишають лише потрібних людей, задачі, тощо) не втрачаючи накопичені дані і мета-дані.
      19 Dec
      Alexandr Mitin:
      А якщо піти по старому шляху долучення людей, тільки наприклад долучення груп? Нода має при виконанні якихось умов виконати допис переліку людей, статусів, тобто все з іншої бази до першої, з якимось додатковим ідентифікатором для скасування?
      19 Dec
      Така стратегія можлива, але тут звичайно ж мало би вже бути не 2 запрошення, а загальне голосування. Просто маю відчуття, що будуть нюанси і конфлікти, на вирішення яких може піти надто багато ресурсів.
    • Хто може підіймати питання на обговорювання та голосування?
      25 Jun
      Варіанти:
      • Будь-хто, але питання спочатку попадає у список неактивних і має набрати певну кількість прихильників, щоб попасти у загальний список активних питань.
      • Будь-хто, але питання спочатку має назбирати певну кількість підписів людей, які його підтримують і тільки тоді попадає у загальний список активних питань. Різниця від попереднього в тому, що немає списку неактивних питань, а людина особисто звертається до певних людей і просить підписатися під своєю ініціативою (доступ до якої у системі є по унікальному лінку).
    • Як будуть прийматися рішення при поступленні повністю протилежних пропозицій?
      25 Jun
      https://www.facebook.com/groups/power.of.trust/permalink/1845448765698191/
      • Скажіть будь-ласка а що буде коли двоє чи троє покажуть концепції які є "ворожими" одна до одної? Яка концепція буде взята на озброєння СД?
        25 Jun
        "Покажуть" — це лише початок. Є ще обговорення, аргументи за/проти, можливість внесення поправок, і вкінці зважене голосування, яке має виявити підтримку учасників тієї, чи іншої концепції.
      • Конкретний приклад
        25 Jun
        >Конкретный пример, бизнес, который, например, финансирует группу, хочет уменьшить налоги и снизить зависимость от профсоюзов, лидеры профсоюзов хотят наоборот, вместе со сторонниками социал-демократов:)) каков механизм удовлетворения сторон?
        25 Jun
        На мою думку такі складні питання мають вирішуватися експертними групами (економісти, фінансисти, соціологи). Від них мають поступити варіанти рішень, аргументація і прийнято зважене остаточне рішення.
        Наприклад працівники під зниженням податків зможу побачити аргументацію, що це покращить інвестиційну привабливість країни, і таким чином створить нові робочі місця, знизить безробіття, покращить стабільність національної валюти і таким чином кожен з нас відчує покращення рівня життя, тощо. Або у пропозиції про підвищення податку бізнес зможе прочитати, що це є критично для підтримання інфраструктури і порядку у країні, це посприяє спрощенню веденню бізнесу, тощо. Якщо рішення буде адекватне, то воно буде прийняте нормально.
        Ще можна прив’язати конкретне рішення до прогнозу певних показників і якщо прогноз не справдиться — це має вплинути на експертний рівень усіх тих експертів, які відповідальні за прийняття цього рішення. Наприклад через півроку проаналізувати рівень безробіття, рівень інфляції, залучені інвестиції, створені робочі місця, рівень бюрократії при веденні бізнесу — якщо показники не покращилися (і не було форс-мажору) тоді робиться висновок про те, чи рішення виявилося вдалим і про кваліфікацію експертів…
        Якщо ж буде спроба прийняти рішення явно неадекватне (під тиском олігархів), то активні громадяни зможуть висловити недовіру таким експертам (ті втратять право голосу у питаннях) і будуть надіятися, що їх місце займуть більш адекватні, менш продажні, тощо.
        25 Jun
        >проблема есть в том, что следует различать у организаций, представительские и экспертные функции. На уровне мировой модели в профсоюзной и работодательской среде это обеспечивается репрезентативностью. Нужно понимать, кого представляет эксперт. Он может представлять только себя, а не социальную группу и его выкладки могут быть субъективны, а может быть "репрезентативным", т.к. за ним будут стоять сформированные интересы некой социальной группы. Как решить эту проблему? Что касается индикаторов, то многие показатели собираются раз в год, а увидеть позитивные изменения в социальной сфере, вообще можно через несколько бюджетных циклов.
        25 Jun
        > его выкладки могут быть субъективны
        В ідеалі експерти мають бути незалежними і отримувати за свою роботу винагороду від системи вцілому. Але як завжди все буде впиратися та ідеали та апетити окремих людей. Комусь тої винагороди буде достатньо, а комусь ні…
        25 Jun
        >Честно говоря, присутствует некий смысловой конфликт. В группе будет присутствовать достаточно жесткий регламент для участников. И это правильно, что бы трафик не загружать. Насколько я понял из предыдущих обсуждений, вопрос ценностей предполагает отсев тех, кто эти ценности не соблюдает. Таким образом, исходя из этих двух пунктов, предполагается достаточно закрытая группа со своим набором ценностей, терминологией и т.д. Я правильно понял?
        19 Apr
        >Насколько я понял из предыдущих обсуждений, вопрос ценностей предполагает отсев тех, кто эти ценности не соблюдает.
        Зараз кожен може приєднатися до мережі, якщо його запросять троє учасників. Обмежень немає. Є пропозиції обмежувати, але такі пропозиції поки не підтримані більшістю.
        Ось відповідні голосування:
        Але було таке, що послупала заявка, але людина не отримувала достатню кількість запрошень і не могла зареєструватися.
    • Яку систему правління ви реалізовуєте у проекті?
      14 Oct
      Система будується без прив’язки до конкретної форми правління, і ми разом маємо обрати курс. В межах груп так само має бути можливість вибрати хто має право голосу, право займати посади, тощо.
      Ви вже помітили, що я не є прихильником "прямої демократії", я схиляюся більше до "меритократії".
      А те що про що Ви згадуєте як "привілеї" я називаю "відповідальністю" (займати певну посаду, брати участь у прийнятті певних специфічних рішень) — це зовсім інший підхід. При такому підході люди спільно погоджуються для прикладу, що оце питання є дуже складне і його варто доручити найкращим з нас у цій галузі, яким ми довіряємо. Навіть делегування тут ніякого не потрібно, просто група експертів під нашим контролем.
    • Почему не сделать редактирование в половину цены за сам комментарий и минус два балла активности?
      25 Jun
      Примітка: на момент даного питання у системі діяли параметри:
      • Створення коментаря — забирало 4 енергії, приносило 2 бали активності.
      • Редагування коментаря — забирало 10 енергії, приносило 1 бал активності.
      Пропонується зробити:
      • Редагування коментаря — щоб забирало 2 енергії, і забирало -2 бали активності.
      Якщо так зробити, є ризик, що тоді ніхто не буде виправляти свої помилки.
      Бали активності значно цінніші за енергію, і їх важко здобувати, а енергія постійно відновлюється, вона нічого не варта. Виправлення помилки — це краще, ніж залишити помилку, тоді логічно, що за це варто давати хоча б мінімум балів активності. Зараз дається 1 (10% від 10 енергії).
      Тепер чому коментар забирає 4 енергії, а редагування 10. Тут має працювати стимул перечитувати свій текст перед публікацією, бо якщо допустити помилки — то піде багато енергії на редагування. Енергії, яку можна було би витратити на щось більш конструктивне. Тобто редагування бере більше енергії щоб показати, що це є неефективне використання енергії, що краще помилок не допускати, ніж їх виправляти.
    • відповіді на різні коментарі
      5 Jan
      • Коменти у FB (04.01.17)
        5 Jan
        Ви написали цілу публікацію про еліти, їх контроль і про індивідуалізм проти суспільства.
        Варто було спершу задати уточнюючі питання, тому що у нас немає жодного зі згаданих явищ:
        1) У нас немає еліт, у нас кожен може винести задачу, проблему, чи питання на обговорення та голосування. Згодом коли учасників буде дуже багато, то будуть введені обмеження, наприклад що для винесення задачі потрібно буде зібрати N підписів однодумців, або що потрібно буде мати певний рівень довіри у спільноті.
        2) У нас ніяк обмежується діяльність груп, спільнот. Якщо людина не хоче брати участь індивідуально — це її вибір, вона тоді в системі виступає як учасник певної групи, спільноти і її думка буде також почута. І навпаки, ніхто не заставляє людину бути часткою якоїсь групи, а завжди є можливість виступити індивідуально.
        3) Технічні засоби ніяк не відміняють особисті зустрічі, просто на практиці особисті зустрічі будуть проводитися в більшості локально, і дуже рідко будуть якісь з’їзди, тому що це дуже затратно. Частіше будуть проводитися аудіо та відео конференції між певними групами для ефективної роботи, обговорення.
        5 Jan
        Gennady Shkliarevsky:
        Юрий!
        1. Прежде всего, Вас всегда будут понимать так, как Вы пишете. Если у Вас что-то важное не прописано, то те, кто Вас читает, сделают вывод, что это для Вас и не важно;
        2. Элит у Вас может и не быть, но иерархии будут. Если Вы не знаете, что с ними делать, то они очень быстро станут элитами.
        3. Выдвигать предложения может каждый и при либерально-демократическом режиме, но это не расширяет их роль в формировании дискурса.
        4. Теоретики гражданского общества--такие как, например, Юрген Хабермас—много писали о том, что и как происходит в гражданской сфере, или как Хабермас это называет Lebenswelt (жизненный мир). Если Ваш проект действительно намеревается ввести какую-то новизну в социально-политическую практику, а не просто поставить её на новую техническую основу, то было бы полезно ознакомиться с этими работами, или поговорить с теми, кто знаком с теорией гражданского общества.
        5. Если Вы думаете, что главным являются хорошие намерения, а всё остальное произойдёт само собой, то подумайте ещё раз. Хабермас много писал, что гражданское общество может быть легко захвачено особыми интересами и людьми преследующими свои интересы. Где у Вас размышления на эту тему и какие меры у Вас есть, чтобы противопоставить этой тенденции?
        6. Люди не могут общаться с обществом в целом. Они как правило образуют группы и сети (или Ваши спільноти). Как Вы выстраиваете переход от таких сообществ к общему решению, которое бы выражало общую точку зрения всего гражданского общества?
        7. И наконец, Вы сами написали, что съезды потеряют своё значение. Как прикажете ещё Вас понимать?
        И наконец последнее, Вы обратились к членам этой группы за советом. Я и другие дают Вам нашу точку зрения. Чего же Вы ожидали? Что Вас погладят по головке и скажут, что всё хорошо, за исключением каких то деталей? На мой взгляд, теоретическая часть Ваших планов продумана мало. Многие вопросы Вы даже не поставили. Я говорю именно о теоретической части, касающейся общественно-политической практики. Что касается технических деталей проекта, то их я оставляю на суждение других членов, намного лучше меня знающих эту область.
        5 Jan
        >Если у Вас что-то важное не прописано, то те, кто Вас читает, сделают вывод, что это для Вас и не важно
        Ну як сказати, я з різними людьми спілкуюся то люди поділяються на тих, хто дофантазовує і тих, хто виясняє все що важливо за 5хв. Ми не писарі і не в силах гарно розписати усе що у нас на умі, ми зразу робимо.
         
        >Элит у Вас может и не быть, но иерархии будут. Если Вы не знаете, что с ними делать, то они очень быстро станут элитами.
        Будуть і ми знаємо, що з ними робити. Вони в результаті будуть працювати на благо спільноти. Якщо цікавлять деталі — читайте наш документ уважно і глибоко, а не поверхнево. Або можна організувати якусь аудіо-конференцію і вияснити все за 20хв.
         
        >Выдвигать предложения может каждый и при либерально-демократическом режиме, но это не расширяет их роль в формировании дискурса.Роль залежить лише від самої людини. При бажанні кожен учасник може досягти відповідного йому рівня впливу, правда доведеться працювати багато і не переоцінювати свою важливість і можливості.
         
        >Если Ваш проект действительно намеревается ввести какую-то новизну в социально-политическую практику, а не просто поставить её на новую техническую основу, то было бы полезно ознакомиться с этими работами, или поговорить с теми, кто знаком с теорией гражданского общества.<
        Ми працюємо над технічним рішенням і одночасно шукаємо людей і моделі, які разом будемо пробувати втілювати. Це є співпраця між учасниками. Дякую що хоча б вказали на якісь роботи звернути увагу, будемо вчитися, раз більше немає на що розраховувати.
         
        > Хабермас много писал, что гражданское общество может быть легко захвачено особыми интересами и людьми преследующими свои интересы. Где у Вас размышления на эту тему и какие меры у Вас есть, чтобы противопоставить этой тенденции?
        Це є проблема для якої якраз шукаються, придумуються і закладаються механізми в основу платформи.
        От ви читали наш документ, а може хтось з вас, панове, чітко відповісти на питання, чому проект називається "Сила Довіри"? Якщо зможете, то і побачите, що ми працюємо над озвученими проблемами дуже грунтовно.
         
        >Люди не могут общаться с обществом в целом. Они как правило образуют группы и сети (или Ваши спільноти). Как Вы выстраиваете переход от таких сообществ к общему решению, которое бы выражало общую точку зрения всего гражданского общества?
        Я вже описував шлях такої участі. Її можна ще краще оформити і зробити зручнішою, але це ще тільки в планах.
         
        >Вы сами написали, что съезды потеряют своё значение.
        Я писав, що з’їзди це вчорашній день, так як сучасні засоби комунікації дають значно більше шляхів для ефективної комунікації майже без втрати якості. От пропоную практикувати відео та аудіо-конференції. Чи Вам все ж простіше прилетіти до нас з Нью-Йорка на кілька-годинний з’їзд?
         
        >На мой взгляд, теоретическая часть Ваших планов продумана мало. Многие вопросы Вы даже не поставили.
        Ми чекаємо, щоб у нашій групі появилася людина яка цим би зайнялася, бо між собою ми одне одного розуміємо і не потребуємо викладення цих матеріалів. Але потреба у викладенні є, це факт. Очікуємо людину, яка горить такими ж ідеями (які виясняються усно певно, бо читання бачу не працює).
         
        >Я думаю идет спокойный поиск у всех сторон, в данном случае, нашей беседы.Никто никого не учит, не осуждает, тем более, а только вскрывает возможности.
        Це дуже точно сказано. Ми дивимося на реакції, на пропозиції (теорій, моделей) і якась з пропозицій буде у нас реалізована технічно.
         
        >Я правда посетил их сайт и пока ничего не понял. Но может быть это я.
        Все що ми робимо і як ми робимо дуже не схоже на все що існує, через це багато непорозуміння. Але якщо приділити нам трохи часу, то все розкладається по полочкам.
         
        >понял что сайт в разработке и "все будет"
        Не правильний висновок. Сайт не в розробці. Сайт це взагалі тільки візитка проекту, там більше нічого не буде. Читайте концепт-документ, дивіться на те як працює сама система (її не важко знайти, якщо потратити 5хв).
    • Що до технічної реалізації:
      25 Jun
      • Чи використовується у проекті blockchain?
        7 Jul
        На даний момент ні.
        Блокчейн з PoW чи PoS для нашого проекту не дуже підходить бо вони мають схильність до централізації у руках ти, хто має більше ресурсів — тому в проекті реалізується інший підхід, який дасть змогу широкому колу людей бути рівноправними учасниками мережі.
        Bockchain вирішує проблему консунсусу у trustless мережі (коли всі аноніми і нікому не можна довіряти), у нас же мережа конкретних людей і це дає можливість обійтися без майнінга, тобто для нас блокчейн надлишковий виходить. Але якщо впремося у проблеми, то певно доведеться перейти на нього.
        Детальніше у інших розділах:
      • Питання по синхронізації даних між учасниками (нодами)
        3 Jul
        Аяхов Олексій
        Чи обов'язково потрібна для функціонування мережі присутність в постійному онлайні ноди, що встановлена не на комп'ютері учасника, а на сервері, ноди що вимагає спеціальних знань для встановлення?
        Чи можливо функціонування окремої мережі, якщо ланки будуть встановлені виключно на комп'ьютерах учасників та не буде існувати постійно працюючої в онлайні ланки?
        Чи можливо організувати мережу без ланки, встановленої на сервері і якщо одна або декілька ланок на комп'ютерах учасників будуть постійно онлайн, то шоб тоді була синхронізація у реальному часі, як це відбувається зараз?
        — Так, можливо
        25 May
        Так, система може повноцінно функціонувати завдяки запущеним нодам лише на машинах учасників, але тільки якщо виконуються 2 умови:
        1. Певна мінімальна кількість учасників завжди має бути онлайн.
        2. В учасників відкритий для доступу з інтернету робочий порт мережі.
          25 May
          По замовчуванню у нас це є порт 7733.
          У більшості користувачів цей порт по замовчуванню є закритий, і є потреба дещо змінювати у налаштуванні мережі. В більшості це
          • форвардинг порта на раутері
            25 May
            Інструкція легко знаходиться в інтернеті запитом виду "<модель раутера> port forwarding"
          • або налаштування брендмауера/фаєрвола.
          Система при запуску також пробує відкритий цей порт автоматично тимчасово для роботи, використовуючи UPnP. Але на практиці воно рідко спрацьовує.
          Про результат спроб можна дізнатися з файла node.log:
          • Там буде або позитивний результат: info: UPnP router 192.168.0.1 is forwarding 7733 to 192.168.0.102:7733
          • Або негативний: warn: No UPnP root devices found
           
          Щоб відключити ці спроби, потрібно у файлі conf_my.rb прописати рядок: upnp: 'no'
        25 May
        Тож ноди на серверах запускаються саме для того, щоб забезпечити цю мінімальну кількість цілодобово працюючих нод з правильно налаштованими портами.
        Якщо такий мінімум не забезпечити, то можуть часто бути ситуації, що учасник запускає у себе систему а йому каже, що немає жодного з’єднання, або що з’єднань недостатньо для роботи.
        25 May
        Мітін Олександр
        Можливо при малій кількості нод складно веріфікувати підробку якщо наприклад 2 і 2 ноди аідрізняються за даними?
        — Саме так
        25 May
        В системі в налаштуваннях навіть є персональний параметр min_peer_connections_to_sync, який по замовчуванню рівний 3.
        Він задає мінімальну кількість різних джерел, до яких система має під’єднатися перш ніж почати звірку даних і синхронізацію. Оптимально зараз тримати цей параметр на рівні 5-6.
      • Скільки ця система може витримати запитів користувачів (приблизно)?
        25 May
        Зараз ще рано таке заміряти, багато що треба ще оптимізувати. Ну і запити є різні: є запит-дія (коли вносяться зміни в базу і тут багато залежить від того, що за дія), а є запити-читання, які легко витримуються у великій кількості саме завдяки розподіленості системи на багато серверів-нод.
      • Технічно можуть бути встановлені дві окремі ноди на ПК?
        25 May
        Це можливо зараз якщо точно виключати одну і перед тим як запускати іншу, а для паралельної роботи обох треба дещо змінювати налаштування одної.
        В майбутньому має бути так зручно як описував Роман, що у вікні буде можливість просто вибрати з якою мережею працювати, або просто 2 різні вікна завжди мати.
      • Як що до використання ЕЦП та BankID?
        25 May
        Про державний ЕЦП серйозно. Ви розумієте, що це є інструмент системи? Так він визнається державою, але в той же час ніщо не заважає системі "нагенерувати" будь-яку кількість потрібних голосів для "корегування" волевиявлення народу. З BankID ще гірше, бо там ще більше гравців мають можливості генерити мертві душі. І у нас немає жодних можливостей перевірити справжність голосів і виявити таку підставу. Хіба організація паралельного голосування і аналіз розбіжностей.
         
        Для тих, кому цікаві деталі, то в нашій системі кожному новому учаснику генеруються його персональні ключі для цифрового підпису (які він сам вибирає де зберігати: на компі, на флешці, на пластиковій карті і тд, це на розсуд людини). А оскільки база учасників відкрита, то в нас є гарантія відсутності отаких вбросів, бо немає якоїсь точки, де би цей вброс можна було непомітно здійснити — у нас всі дії публічні і завжди буде видно кожну спробу і хто її ініціював.
         
        Так наш цифровий підпис не визнаватиметься державою, але нашою метою має бути те, щоб його визнавали в першу чергу учасники мережі, і коли таких учасників буде достатньо багато, тоді всі будуть змушені так чи інакше враховувати такі голоси. Грубо кажучи з часом появляться депутати, які будуть його визнавати і коли таких депутатів у парламенті стане більше 225 — тоді можна буде вже почати говорити про невизнання державного ЕЦП, як застарілого централізованого інструменту з усіма його недоліками.
      • Робота системи у вигляді веб-додатку
        25 May
        > А чисто у вигляді-веб додатку систему не можна зробити?
        > З p2p клієнтом на JavaScript і зберіганням історії десь у кукіз чи ще десь?
        Повноцінну систему — ні. А от легкі клієнти так і будуть працювати (сторінка, екстеншин, мобільний додаток), все як з клієнтами для Біткоін.
    • Що до використання системи:
      25 Jun
      • що заважає застосовувати?
        25 Jun
        Які проблеми зараз є найактуальніші? Що заважає застосувати цю систему на практиці?
        25 Jun
        1) Систему потрібно ще зробити (роботи багато)
        2) Підняти рівень розвитку громадян. Поріг входження для роботи з системою таки значний і це проблема, потрібно проводити роботу по роз’ясненню з цільовою аудиторією.
        25 Jun
        Поріг входження - задача юзабіліті, яка вирішується грамотним UX
        25 Jun
        Можливо варто почати з однієї ключової функції і потім нарощувати функціонал разом зі спільнотою користувачів?
        Minimum Viable Product, MVP
        25 Jun
        Зараз готується базовий функціонал: реєстрація, винесення питань, можливість обговорення і голосування по питаннях.
        І далі вже маючи таку систему, за допомогою неї будемо спільнотою вирішувати що робити далі.
        25 Jun
        Якщо зауваження стосувалося деякого конкретного функціоналу, то голосування за змінні — це базова функція, система оновлень теж життєво необхідна, посади потрібні для порядку у системі, а лотерею просто було не важко зробити… Ну і запуск під Лінуксом критичний для підіймання нод на різних хостингах.
         
        Цікаво, яку би "одну ключову функцію" обрали Ви?
      • де планується застосовувати цю систему?
        25 Jun
        Сфера застосування нічим не обмежується. Система може бути корисною у різних сферах життя, у різних масштабах, різних галузях.
         
        Для прикладу:
        • у економічній: прийняття складних рішень на рівні держави, області, міста кваліфікованими економістами, організація відкритих дискусій по економічних питаннях тільки між професіоналами, без тролів;
        • у соціальній: винесення на обговорення різних суспільно важливих питань, ініціатив, прийняття рішень;
        • у політичній: голосування за обрання людини на певну відповідальну посаду, обговорення проектів законів, голосування за їх прийняття і за поправки;
        • у духовній сфері: знову ж таки, обговорення важливих питань і проблем, прийняття певних рішень.
         
        Особливість цієї системи, що це не є якийсь форум по інтересах, це максимально публічна площадка з жорсткими правилами
        25 Jun
        хто здійснює контроль за дотриманням правил?
        25 Jun
        Власне ніхто не здійснює (тобто жодна особа). Контроль здійснює система автоматично
        25 Jun
        це як?
        25 Jun
        Приклад: якщо людина вводить неправильний пароль до поштової скриньки, то її не пускає, а якщо введе певну кілька разів неправильно, то її заблокує на певний час, щоб не пробувала підібрати. Працює закладений алгоритм, без втрачання людини.
        25 Jun
        це захист від некоректних дій, а як щодо захисту від некоректного контенту?
        25 Jun
        Людину дружньо забанять.
        25 Jun
        Ну а як система буде вдосконалюватися? Люди ж розробляють специфікації, пишуть код, фіксають баги. Як унеможливити узурпацію програмістами? ))
        25 Jun
        Хороше питання, але воно вже глибше, тому я його спочатку не включив у базовий документ. Тепер додав пункт "Функціонал самої системи можливо буде розширювати "на льоту""
        .
        саморегуляції. Це як публічна тема у Різомі, але без модераторів, з можливістю встановлення порогу допуску до коментування
        25 Jun
        це не йде на користь дискусії, так втрачаємо ідеї та думки
        25 Jun
        Якщо людина має що сказати, при бажанні вона зможе це зробити.
        Так, деякі індивідуальні думки будуть загублені разом з усім можливим спамом і думками некомпетентних.
        25 Jun
        те, що людина може "літати" - багато століть сприймалося, як верх некомпетентності - важко оцінити ідею навіть коли вона вже висказана (вже не кажучі про допуски)
        25 Jun
        Колективна саморегулюча система оцінки адекватності та важливості коментарів дозволить розмежувати популярні на непорулярні коментарі.
        По суті це голосування за коментарі, як на хабрі з додатковими можливостями.
        і з можливістю забанити неадекватного учасника
        25 Jun
        тут знаряддя для того, щоб "грати в суперника, а не в шайбу", зведення рахунків, "війна правок" (див. в Вікі) тощо.
        25 Jun
        Щоб забанити, потрібна буде воля багатьох учасників, а не певної особи, чи відносно невеликої групи.
        Тих, хто буде зводити рахунки забанять швидше (всі дії публічні).
        , і не залежна від стороннього сервіса у якого є власники і свої суб’єктивні погляди.
      • чи не буде складність правил, які ще й змінюються динамічно перешкодою для користування системою?
        25 Jun
        Будемо старатися робити так, щоб загальна складність системи не впливала на базовий функціонал, який має бути простим у користуванні.
        25 Jun
        люди зіштовхуються із загальною складністю, базовий функціонал - це більше цікавить розробників.
        25 Jun
        Якраз навпаки: більшість користувачів буде використовувати лише базові функції системи (прості дії, які потрібно робити часто: проголосувати, висловити недовіру, тощо) і ніколи не зіштовхнуться з загальною складністю (можливість реєструвати організації, створення фондів, підписання документів через ключі, висування питань на загальне голосування, висування адекватних варіантів, участь у зміні правил роботи системи тощо).
        "базовий функціонал - це більше цікавить розробників." — ні, розробників зовсім не це цікавить (я це кажу, як розробник).
        Але зробити систему статичною — це значить обмежити її термін придатності.
        25 Jun
        Я над цим думав наодинці, доки не наткнувся на даний документ ))
        Уявіть собі ГО діяльність якої регламентована і рішення в якій приймаються за допомогою даної системи, а учасниками являються ті, хто скинувся на її розвиток. Така ГО може офіційно найняти девелоперів, підписати з ними договір і делегувати завдання з розробки функціоналу системи.
        25 Jun
        Краще, коли в системі для її підтримки є внутрішнє комюніті розробників, яким довіряють решта учасників мережі, ніж коли це люди зі сторони, у яких зацікавленість тільки фінансова.
        25 Jun
        На практиці, власне ком'юніті розробників - не головне для ГО. А от фінансова зацікавленість розробників - це дуже важливо. Краще коли розробник і замовник чітко відокремлені і мають чіткі договорні стосунки.
        25 Jun
        Та очевидно що так. Проте мені складно уявити написання складної системи "на колінці".
        Якщо громада готова забезпечими програмістам ринкову зарплатню для виконання ними публічного контракту, то краще всій команді іти на фул-тайм для написання нової системи і служінню державі та народу, а не приватним структурам. Вікіпедію пишуть та утримують за гроші зібрані з пожертв.
        25 Jun
        Я тільки за, щоб громада забезпечувала… Але от громада ще не готова до такого, тому з нею і будемо ще працювати в цьому плані.
        25 Jun
        Громада готова. Вже можна назвати десятки українських високотехнологічних проектів, які фінансуються на пожертви. Але конкуренція за ресурсии досить велика, бо тисячі проектів залишаються без фінансування.
        25 Jun
        Підтримую. Краудфандинг в україні забезпечує армію! Просто потрібен грамотний маркетинг.
        25 Jun
        Що таке армія і для чого вона потрібна знає кожен. А що таке демократія, тим більше електронна і в чому її відмінність від того, що маємо зараз, доведеться пояснювати практично кожному.
        25 Jun
        Якщо я правильно зрозумів, то Ви за те, щоб сформувати якусь команду для розробки подібного проекту, розтрубити про це, попросити грошей у громади, підняти якісь гранти, кошти міжнародних спонсорів, тощо… І тоді вже видати хороший якісний продукт і забезпечити його підтримку.
         
        Будь ласка, пробуйте.
         
        Мені от не вдається залучити близьких толкових друзів навіть до обговорення ідеї…
        Я тільки за, якщо хтось інший візьметься і це все реалізує, я допоможу чим зможу.
        25 Jun
        Якраз хотів це запропонувати :)
        25 Jun
        Буду радий підтримати ініціативу, але з того, що я бачу, у нас різне бачення проекта вцілому: бо з одного боку я не все роз'яснив детально, а з іншого боку Ваше бачення (що достатньо зробити LiquidFeedback з кращим інтерфейсом).
        Поки бачення не співпадають — співпраці не вийде.
      • Чи можемо ми заборонити іншим використовувати цю платформу для організації своїх мереж (наприклад мережі для чогось нелегального)?
        25 May
        Код проекту відкритий, а це значить, що будь-хто може запустити паралельну мережу і ми ніяк не можемо на це вплинути/заборонити.
        Але система заточується саме на відкритість, тобто саме у відкритих групах її використання даватиме максимальний ефект, синергію і тд…
  • Обговорення конкретних проблем, технічних рішень, алгоритмів, стратегій:
    3 Jul
    • Можливі проблеми з запуском:
      9 May
      • Під Windows
      • При інсталяції система перепитує чи справді Ви хочете запустити файл скачаний з інтернету. На Win7 потрібно нажати OK, а на Win8 потрібно вибрати More info - Run anyway (Детальніше - Продовжити). Це попередження зникне, як тільки у Microsoft буде достатньо статистики завантажень цього файла).
      • При першому запуску операційна система спитає чи дозволити процесу доступ до мережі — бажано дозволити.
      • Є проблема, що антивірус Avast версій 10.x при запуску просто без жодних повідомлень блокує файл. Якщо файл перевірити ним, то скаже, що все чисто. Проблема вирішується встановленням новішої версії антивіруса (v11). Схожа проблема є з DrWeb — він блокує файл це при скачуванні і теж не дасть запустити, можна хіба відключати його тимчасово, або додати певні файли у білий список.
    • Алгоритми прийняття рішень
      9 May
      Пропозиція Андрія Рожило
      9 May
      1. Створення ініціативи. Будь який учасник може створити нову ініціативу. Напротязі визначеного терміну ініціативу можна лайкнути, або діслайкнути. Якщо ініціатива набирає достатно лайків - вона переходить в наступний етап.
        9 May
        Припустимо, що система стане поширеною. Тоді може бути таке, що кожного дня будуть появлятися сотні нових ініціатив (чи не будуть?). Що можна зробити, щоб люди могли серед такого потоку підтримати певні ініціативи?
        9 May
        Согласен. Некогда будет лайкать все поступающие.
        Может быть попробовать метод "проявления"?
        1. Инициатор пищет своё Предложение на своей странице.
        2. Предложение не публикуется (проявляется) пока не пройдёт процедуру проверки.
        3. Проверка заключается в направлении этого Предложения случайно выбранным участникам сообщества, которые и должны лайкануть или контрлайкануть его. Количество этих "экспертов" первого фильтра - задано решением Сообщества.
        4. Если лайков экспертов больше антилайков Предложение публикуется (проявляется) на странице Инициатора.
        5. Доступное для обозрения опубликованное Предложение не может комментироватся. Только оцениватся лайканием.
        6.Как только количество лайков превысит определённый уровень (например 10% от просмотревших это Предложение) оно (Предложение) переносится на страницу Обсуждения и Голосования.
        9 May
        Так, саме в різних рівнях фільтрації може бути рішення цієї проблеми. Які саме рівні потрібні і скільки — це буде виноситися на обговорення і голосування при dev-preview запуску.
        Можуть бути і спеціально створені колегії, роботою яких буде оцінка ініціатив.
        9 May
        Конечно, без экспертов не обойтись при рассмотрении конкретных Задач. Но это будут эксперты в области жизни, в которой выносится инициатива. Первый "фильтр" я бы поручил делать обычным людям, которые оценивали бы эту инициативу только по критерию нравится- не нравится, тупость- дурость, атуально - пока не нужно.
        9 May
        Согласен, это может разгрузить экспертов от явного бреда.
      2. Обговорення ініціативи. Ініціатива обговорюєть усіма бажаючими в деревовидних коментарях (або у модулі від Різоми) напротязі певного терміну
        9 May
        Обґрунтуйте потребу в обмеженні обговорення терміном.
        Я так зрозумів, що поки цей термін не пройде, то не можна буде проголосувати.
         
        В чому на Вашу думку основна різниця між варіантами:
        1) Голосування по питанню стає доступне тільки після обов’язкового певного періоду обговорення
        2) Голосування доступне одразу і є можливість змінити свій голос, якщо нова інформація у обговоренні вплинула на Вашу думку.
         
        Який на Вашу думку варіант кращий за інший і чому?
        . Коментарі теж можна лайкнати або діслайкати за принципом Хабрахабра, щоб відслідковувати рівень підтримки висловлювань громадою.
      3. Оновлення версій ініціативи. Ініціатор може врахувати думки громади і опублікувати нову версію ініціативи, тим самим подовживши час на обговорення.
      4. Висунення альтернатив. Якщо ж думки громади не враховані, новий ініціатор може висунути альтернативу (алтернативну ініціативу), подовживши час обговорення. Альтернативи також обговорюються і мають версійність.
      5. Голосування. Після обговорення відбувається голосування за усі альтернативи. Приймається ті альтернативи, які набрали більше половини всіх учасників системи.
        9 May
        Результати голосування — це не проста тема. Більше половини голосів — це тільки один з можливих варіантів, при чому важкий, бо часто жодна з ініціатив не набере стільки.
        Для початку буде проста більшість голосів, а згодом можна буде вибирати умови для визначення результатів голосування (50%+1, 2/3, консенсус тощо).
      Ось коротка презентація LiquidFeedback.pdf
      9 May
      В даному алгоритмі йдеться про голосування за ініціативу та її альтернативи.
      Для початку я пропоную структуру "Задача — варіанти рішень". В даному випадку ініціатива і її альтернативи виступатимуть варіантами рішення певної об'єднуючої їх задачі (ініціатива — це один з можливих варіантів рішення).
       
      Різниця в тому, що у Вашому алгоритмі все починається з генерації рішень (див. презентацію), а постановки задачі/проблеми немає. Вона певно присутня неявно, і певно причиною є те, що в назві системи йдеться тільки про "прийняття рішень", тому я вирішив тут прояснити, що постановка задачі/проблеми буде і явна.
       
      9 May
      Варто розрізняти поняття "задачі" і "проблеми". Якщо це задача, то для неї вже є засоби і відомий спосіб вирішення, а якщо проблема, то такий спосіб потрібно ще знайти, або створити.
      9 May
      >Якщо це задача, то для неї вже є засоби і відомий спосіб вирішення
      Не можу погодитися. Є задачі при розгляді яких може виявитися, що задача не має рішення. Деколи так і кажуть "знайти рішення, або довести, що рішення немає". Прикладом є геометрична задача яку найперше вдалося знайти — "Чи завжди можна провести коло через задані 3 точки", яка не має рішення, якщо всі точки знаходяться на прямій.
       
      Якщо розглянути Вашу схему, то у лівій частині замість задачі більше би підійшло слово "завдання" (на мою думку).
       
      Але це все деталі :)
      У мене задача була така: знайти більш-менш підходяще слово для заголовка розділу у якому піднімати питання на обговорення. Це слово має нормально сприйматися для таких фраз:
      - скільки запрошень потрібно для реєстрації (передбачає просто голосування за варіанти);
      - як спростити процедуру реєстрації (передбачає пошук рішення);
      - обираємо людину на посаду (передбачає висування кандидатів для початку).
      Заголовок "проблеми" тут явно не підійшов би.
       
      Але кожну з даних "задач" породила певна проблема, яка деколи навіть не озвучена, бо немає в цьому потреби:
      - проблема реєстрації віртуалів;
      - проблема низької кількості реєстрацій ймовірно через складну проблему реєстрації;
      - проблема збільшення кількості образливих коментарів зумовлена відсутністю модератора у системі.
      Але я можу помилятися і в ідеалі варто завжди би десь озвучувати і проблему.
       
      Зараз проблеми просто обговорюються поза системою і коли певна кількість людей погоджується, що варто щось з цим робити — підіймається вже сформована задача для пошуку рішень.
    • Що до гучних свіжих публікацій типу "Разработчик биткоина признал провал эксперимента с криптовалютой" / "The resolution of the Bitcoin experiment" (14.01.2016)
      9 May
      Оригінал скандальної публікації — "The resolution of the Bitcoin experiment", переклад — "Майк Хирн: “Я посылаю Биткойн к черту!”
      Для повноти картини бажано прочитати ще:
      Найперше що зробіть, переконайтеся що дійсно зараз всі нові блоки впираються в обмеження 1MB https://blockchain.info/ (колонка Size) — це факт.
      А тоді проведіть тест — просто зробіть невелику транзакцію. Ось моя для прикладу https://blockchain.info/tx/b9ab588832f64d98faf7abeefbb8c8ec2e7fc3b46f06cef4fa81e320c8a94c69
      Це є маленька (порівняно з іншими) транзакція зі сплаченою стандартною мінімальною комісією в 0.0001 BTC. Транзакція була прийнята в перший же знайдений блок, у який ввійшло всього 2440 транзакцій. А оскільки на цей блок мережа чекала 45хв (при середньому інтервалі в 10хв), то відбір транзакцій був досить жорсткий бо накопичилося вже багато транзакцій, бо на біржах зараз паніка (а вмістимість блока обмежена 1MB як пам’ятаєте). В такій ситуації майнери використовують своє право відбирати транзакції, які включити в блок (для цього є розроблені рекомендації, як розраховувати вагу транзакцій залежно від суми, розміру, комісії, віку монеток...), але звичайно основним критерієм для майнерів залишається те, яку комісію вони отримають якщо включать ту чи іншу транзакцію в блок. Саме через це якщо поставити близьку до 0 комісію, ваша транзакція може назавжди зависнути в мережі як unconfirmed.
      І я не єдиний, хто так само не мав проблем з проведенням дрібної транзакції у такій важкій ситуації (всі з цього ж блоку 393539 у який був жорсткий відбір):
      Так що те, що через це обмеження біткоін вже вмирає — це є міф, принаймні на даний час.
      Але от те, що з часом комісія буде тільки збільшуватися — це є факт і давно відомий, бо закладений ще при дизайні системи, підтримка мережі якої через кілька років має фінансуватися лише за рахунок комісій з кожної транзакції. Тому в майбутньому у біткоіні не буде мікро-платежів взагалі. Це є факт, будуть інші рішення. А ті хто публічно говорить про наднизькі комісії на транзакції у мережі без уточнення що до близького майбутнього — просто лукавлять або не розібралися в основах.
      Так само грішать ті, хто кажуть що роботу мережі біткоін забезпечують мільйони комп’ютерів по всьому світу, коли їх реально менше 6 тисяч і кількість падає, бо це стає все важче і важче з ростом розміру бази (а саме збільшення розміру блока напряму на це впливає).
      І це не є якась таємниця, це реальність і основні факти про систему. Я вже мовчу про тих, хто в голос каже, що курс біткоіна завжди росте…
      Повернемося до скандальної статті. Автор крім іншого заявляє:
      "Основной размер блока не изменяется. Компромисс по этому вопросу нулевой. В оптимальной, прозрачной среде открытого кода, должен был быть создан BIP … этого не произошло."
      Легко переконатися в брехливості слів "этого не произошло". Є створених аж 8 BIP (№100-107) у заголовку яких згадується вказана проблема — https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals
      Тож якщо буде досягнуто реального консенсусу у цьому питанні, такі зміни будуть зроблені. Ось сторінка, яка показує, що спільнота спокійно до цього йде, вибираючи найкраще з запропонованих рішень.
      Як би там не було у біткоіні, хочу нагадати, що наша система не використовує класичну схему blockchain для синхронізації і досягнення консенсусу, у нас використовується стратегія більше схожа до тої, що в мережі Ripple. Вона по суті не є гірша за blockchain просто вона не так розпіарена.
      • у нас немає блоків — відповідно немає обмеження по розміру блока, і пов’язаних з цим проблем;
      • у нас немає комісії на дії (транзакції) — відповідно немає проблеми росту комісій з часом, немає відбору транзакцій по вазі, а захист від спаму і флуду забезпечує спеціальний ресурс "енергія" який у всіх однаково витрачається і відновлюється + він регулюється просто голосуванням без жодних модифікацій у коді;
      • у нас немає майнерів — і відповідно немає проблем з централізацію потужностей в невеликому колі певних гравців.
      Якщо вам цікаво як це стало можливо відмовитися від майнінга — то відповідь проста: у нас немає емісії монеток, а це єдине, що дійсно неможливо робити без майнінга блоків. От і весь секрет.
       
      Тож ми просто з усмішкою дивимося на все те що всі зараз так жваво обговорюють і на що показують пальцем.
      І на завершення думка для роздумів: блокчейну уже 10 років скоро буде, прогрес уже пішов далі, а всі тільки от беруться вивчати цю технологію…
    • Проблема сильної затримки при деяких діях у системі
    • Ідея про спеціальний рахунок у кожного учасника з якого за голосування знімаються кошти
      9 May
      С Голосовательного Счёта гражданина должна списыватся определённая сумма при голосовании.
      9 May
      Если это не будут реальные деньги — большинство скорее всего не будет голосовать.
      9 May
      Ну, мы должны предложить систему, которая мотивировала бы людей участвовать в управлении государством. А управление - это распределение финансовых потоков. Потому что исполнение любого Проекта - это трата народных денег. А считать государственные деньги (народные) можно научится только считая свои.
      Счёт для голосований открывается государством каждому гражданину и на этот Счёт размещается какая-то сумма, всем одинаковая. Эту сумму можно тратить только на голосование. "За Предложение №1 я ставлю 100 рублей, а за Предложение №2 больше 10 не дам!"
      Деньги никуда не исчезают, а возвращаются опять в бюджет. Счёт гражданина уменьшается на эту сумму и на следующее голосование он может потратить только то, что у него есть на Счёте для голосования.
      9 May
      Идея понятная и тоже стоит вынесения на более детально обсуждение и голосование.
    • P2P relational DB sync (blockchain, генерація блока, розмір бази, деякі проблеми)
    • Процедура вынесения Инициативы, её обсуждение и голосования по ней (від Николай Коротич)
    • Алгоритм голосования с повышением рейтинга участников голосования (від Николай Коротич)
  • Суміжні документи:
По темі:
9 May