К вопросу о децентрализации wiki

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

Как известно, Yggdrasil является децентрализованной сетью, что означает, что в ней нет необходимости в некоем центральном узле, мощном сервере, который будет являться критически важным, объединяющим, управляющим, распределяющим, содержащим настройки и т.п. Сеть самоорганизующаяся, маршрутизация работает автоматически, «из коробки», все узлы [условно] равны и это не является препятствием для нормальной работы сети, наоборот - в определенных условиях, является преимуществом. Хотя, у такого подхода могут быть некоторые недостатки, уязвимости, но в целом, концепция [с некоторыми оговорками] подразумевает, что устойчивость децентрализованной сети выше…

Периодически, в тематических чатах и на форумах, можно услышать мнение о том, что в децентрализованной сети все или большинство сервисов должны быть децентрализованными. В этом есть определенный смысл. Совместно работая над каким-либо ресурсом, люди могут опасаться того, что в какой-то момент узел, на котором хранится результат их работы может уйти в offline и не вернуться, труд окажется напрасным, собранная информация, знания окажутся недоступны, и всё сообщество в целом получит урон. Высокая вероятность того, что и школьник, и домохозяйка, воодушевившись, в какой-то момент могут открыть в развивающейся сети потенциально популярный ресурс, и разочаровавшись через две недели, закрыть его, не способствует снижению опасений. И это понятно. К слову, здесь публикуются, бэкапы всех статей wiki, которые может скачать любой желающий, но…

Да, было бы хорошо использовать децентрализованные решения. Однако, что в первую очередь приходит на ум, как ассоциация со словом «децентрализация» в этом контексте? Наверное, блокчейн - хорошо зарекомендовавшая себя в некоторых областях технология связанных блоков, которая используется, в общем случае, для хранения, прозрачного учета, контроля, защиты от подмены неких данных и их транзакций…

Саму технологию блокчейна тут обсуждать вряд ли стоит, не думаю, что найдется много пользователей, которые поспорят с тем, что блокчейн в его современной реализации не лишен недостатков и не очень хорошо подходит для создания на его основе универсальных децентрализованных баз данных, форумов, wiki… Хотя, кто знает? ) Для обсуждения и написан этот текст.

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

В общем, на данном этапе, проблема в том, что пока нет готовых решений для того, чтобы легко и просто организовать децентрализованную базу знаний в небольшой сети с равными узлами, но «разношерстными» пользователями ) Делитесь знаниями, если знаете о таких.

Ну, а поскольку удобных децентрализованных решений нет (или я/мы о них не знаем), используем то, что есть.

В мае 2020 г. была поднята эта wiki на базе движка dokuwiki. Наличие возможности подключать плагины, менять темы оформления, использовать различные способы хранения статей (СУБД / текстовые файлы), версионирование, Open Source, некоторая гибкость в настройках, скорость работы, «легкость» - это всё способствовало выбору именно этого движка. Кстати, некоторые считают, что хранение данных в текстовых файлах - это не серьезно, но я (тот, кто хостит этот ресурс) считаю, что использовать СУБД для этого ресурса в относительно небольшой сети, с малым числом активных пользователей - это, так сказать, небольшой overhead. Для несогласных сразу скажу, что поддержка СУБД в dokuwiki реализована в плагине и подключается без серьезных сложностей и проблем. Кроме того, существуют средства переноса статей из dokuwiki в другие wiki (MediaWiki, например).

Изначально предполагалось, что ресурс будет пользоваться популярностью, люди будут активно делиться знаниями, но по-факту, подавляющее число статей здесь написано парой человек (спасибо всем, кто принял участие :)). А в чатах периодически можно увидеть выражение недовольства чем-либо, включая то, что «всё должно быть децентрализовано»…

ОК. Что я, как админ ресурса, могу предложить на этот счет

«Костыльная» синхронизация каталогов с данными

Поскольку статьи пока хранятся в текстовых файлах можно использовать что-то типа Syncthing или rsync. C переходом на СУБД (если он когда-либо случится), можно использовать некоторые API для передачи изменений из одной базы в другую.

IPFS не подходит, т.к., не позволяет изменять файлы не там, где они были опубликованы, и распространять эти изменения.

В случае с упомянутыми выше средствами синхронизации файлов, технически всё просто (по крайней мере, так видится): желающий разворачивает у себя движок (там может быть своё оформление, тема, несвязанные с синтаксисом форматирования плагины и т.п.), даём новоиспеченному админу права администратора, настраиваем синхронизацию, публикуем ссылки. Всё. Пользователи могут пользоваться обеими ресурсами. Не проверял, но теоретически должно работать…

Чем это грозит

В качестве преимущества получаем децентрализацию со всеми её «плюшками», но есть, скажем так, нюансы:

  • Пока подобное не реализовывалось, возможно есть подводные камни, потребуются жертвы времени со стороны энтузиастов
  • Безопасность: децентрализация связана с передачей учетных данных зарегистрированных пользователей (включая зашифрованные пароли) (полагаю, перед тем, как что-то сделать, было бы справедливо опросить всех зарегистрированных пользователей на предмет отношения к передаче их данных одному/двум/трем и более людям, желающим стать администраторами, при наличии несогласных, данные передавать не этично). Кроме того, в зависимости от настроек узла, самый слабый (в плане защищенности) узел будет ставить под угрозу все остальные узлы.
  • Сложность настройки: на каждом узле придется добавлять новые узлы вручную
  • Средства синхронизации довольно надежные, но не исключено, что будут какие-то коллизии, которые придется каким-то образом сообща разрешать
  • Сам факт наличия нескольких администраторов: все мы люди разные с разным мнением по разным вопросам. Думаю, необходимо наличие согласованности мнений относительно, собственно, администрирования и модерирования. В противном случае, есть вероятность образования нескольких несвязанных ресурсов со всеми вытекающими…

Плагин синхронизации

Существует давно не обновлявшийся плагин, который позволяет синхронизировать содержимое двух и более экземпляров wiki.

У него тоже есть особенности. Он скорее подойдет для сбора статей в одно место с разных ресурсов, хотя может и отправлять и получать, но синхронизирует только статьи, настройки и пользователи не синхронизируются. Используется конкретный пользователь для создания статей, полученных с других ресурсов и отправки статей на другие ресурсы, т.е., авторство и история изменения разными людьми не сохраняется.

Желающие могут попробовать.

Страница плагина: https://www.dokuwiki.org/plugin:sync

Итого

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

Ну, и конечно, не возбраняется дополнять и корректировать саму статью :)

Обсуждение

Fyodor Ustinov, 2022/05/14 22:19
Как мне кажется - есть две проблемы, и решать их нужно по отдельности, хотя они и связанные.

1. Bus factor - что мы (пользователи howto.ygg) будем делать, если админа сайта переедет трамвай? Решается "распределенными бекапами" и/или "распределенным хранением". В том числе - организация R/O инстансов этого сайта. IPFS, как раз для этого подходит, как мне кажется (впрочем, хватит и обычного rsync).

2. "Мы все хотим быть немножко админами". Эта проблема не решаема без организации бюрократической системы. Причём даже бюрократическая система не отменяет варианта "вы все козлы! Я построю свою howto.ygg с преферансом и куртизанками". Либо мы изначально должны быть готовы к тому, что появится несколько разных howto.ygg с разным содержимым, и что это нормально и это приветствуется. Это приведёт к размыванию информации по разным сайтам, но при наличии распределенного/общедоступного бекапа этот вариант тоже просто реализуем.

Первую проблему сообщество решить вполне может. Для этого есть все технические возможности.
Вторую - нет.

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

newbie, 2022/05/15 01:08
RO instance уже сейчас может развернуть любой желающий. С учётом того, что изменения в статьях происходят [на данный момент] редко, для этого подойдут ежедневно публикуемые бэкапы. Более частую выгрузку можем настроить позже. IPFS или rsync - это не проблема. Кто возьмется, в первую очередь можете попробовать упомянутый выше плагин синхронизации.

Что касается учетных данных - предлагаю обсуждать уже предметно, когда появится рабочий инстанс и [если] возникнет необходимость. Просто раздать все учетки всем желающим не считаю правильным решением…

vpn.anon, 2022/05/17 12:31, 2022/05/17 13:08
Я бы всё таки рассмотрел вопрос о переходе на mediawiki.
Интерфейс у этой докувики ужасный. Это боковое меню постоянно обрезается, половину содержания не видно.

upd: кто-то поправил отображение бокового меню?)

newbie, 2022/05/17 13:06
Тут всё довольно гибко настраивается, кроме того, можно править стили вручную.
Отключил JS меню, длинные наименования будут переноситься на след. строку.

Если кто хочет развернуть mediawiki - я не против.

Fyodor Ustinov, 2022/05/20 08:53
Кстати, я тут мал-мал играюсь с IPFS - технически там можно сделать изменяемую копию. Имеет ли смысл копать глубже, или это не на столько интересно?

newbie, 2022/05/20 12:46
Какое-то время назад публиковал статичный сайт в IPFS.
Делается это примерно так:
- создается сайт
- в IPFS рекурсивно добавляется корневой каталог сайта с index.html и остальным содержимым
- в IPNS публикуется CID каталога, получаем ID (адрес), которым делимся с людьми, чтобы они получили доступ к сайту
- когда нужно что-то изменить в содержимом - меняем, добавляем изменения в IPFS, снова публикуем (адрес остаётся прежним), люди заходят, видят изменения

Проблемы в случае с предполагаемой децентрализацией wiki:
- c RO instance проблем нет, проблемы есть, когда в любом инстансе меняется контент и его нужно распространить на другие инстансы. Как это организовать с помощью IPFS я пока не знаю...
- упомянем малую популярность IPFS, необходимость использовать расширения для браузера или медленные гейты

Ну, и что касается, "нужно ли"...
К практической реализации, как я понимаю, никто пока не приступал. Поэтому, если не вам, то, видимо, и никому, несмотря на разговоры о том, что централизация - это плохо )

newbie, 2022/05/20 14:31
В общем, я думаю, IPFS подойдет разве что для распределенного хранения бэкапа в ней, в нашем случае. И из этого бэкапа можно доставать файлы для своего инстанса.
Но просто скачивание архива wget'ом будет значительно быстрее и потребует значительно меньше ресурсов )

Про Syncthing и rsync уже писал выше... Если кто захочет - можно попробовать.
Выгрузку или инициализацию обмена можно делать по событию - изменение статьи, добавление комментария и т.п.

cofob, 2022/06/06 20:33
Сделал ежедневный бэкап в сеть IPFS, подкреплённый Filecoin нодами. Работает по dnslink, для клиентов без IPFS есть gateway от Cloudflare.

Самообновляющийся бэкап: https://howtoygg.cofob.ru/
Текущий неизменяемый снапшот: https://ipfs.io/ipfs/QmUAMD6Xm3ucdYPBRhxWXjQFoPy9sk7XwcSdEMoJP9ioYC
Скрипт: https://pasta.deta.dev/bac9a49e-8cba-454c-955f-7d05866cc7aa

vpn.anon, 2022/05/20 21:32
На данный момент архив вики можно скачать через http. Думаю что пока этого более чем достаточно. Попробую развернуть зеркало у себя.

d4708, 2023/09/07 03:38
Думаю лучше всего выполнять запланированные снимки wget и размещать на FTP или что лучше - облачных ресурсах, например Mega предоставляет 20 Гб бесплатно, есть командные утилиты вроде синхронизации и тд, но я от этого решения отказался тк мега поедает половину ресурсов VPS. Поэтому с помощью yggdrasil организовал удаленное хранилище на внешнем диске raspbery pi по FTP и crontab.

Так или иначе, всегда есть альтернативные варианты восстановления, на примере сканеров webarchive, в сети Yggdrasil отчасти эту функцию реализовано в рамках проекта Yggo в виде snap снимков, поэтому каждую страницу можно восстановить от-туда, например для этой страницы есть снимок от 2023-08-06T01:33:33+00:00 http://[201:23b4:991a:634d:8359:4521:5576:15b7]/yggo/explore.php?hp=214836

Надеюсь, пока есть сообщество, будут живы и данные.

Спасибо всем, кто создал и поддерживает этот ресурс!

Только авторизованные участники могут оставлять комментарии.
wiki/decentralization.txt · Последнее изменение: 2023/10/10 18:06 — 127.0.0.1
 
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki