ZeroNet Blogs

Static ZeroNet blogs mirror

Infonesy.Blog

Мысли по проекту децентрализованной социальной системы. И вообще по p2p-социальным сетям.

У нас было 2 мешка травы, 75 таблеток мескалина, 5 марок мощнейшей кислоты, полсолонки кокаина и гора возбудителей, успокоительных и всего такого, всех цветов, а ещё литр текилы, литр рома, ящик пива, пол-литра эфира и две дюжины амила. Не то, чтобы это всё было нужно в поездке, но раз начал коллекционировать наркоту, то иди в своём увлечении до конца. Единственное, что меня беспокоило — это эфир. В мире нет никого более беспомощного, безответственного и безнравственного, чем человек в эфирном запое. И я знал, что довольно скоро мы в это окунёмся.

Как я ранее писал, разочарование в IPFS заставило искать иные способы георепликации. Плюс к этому — глюки Cloudflare, из-за которых пришлось отказаться от их кеширования, что привело к росту нагрузки на сервер и необходимости растаскивать нагрузку по нескольким серверам. Очевидное решение — Round Robin DNS. Но вылезает несколько мелких проблем:

  • Файлы, которые аплоадятся только на одну ноду, не появляются мгновенно на других при использовании любых средств синхронизации.
  • Автоматика получения и обновления сертификатов Let's Encrypt на Round Robin начинает буксовать.

Итак, у нас было три сервера:


  • Быстрый, основной, на Hetzner, с древними HDD, которых не хватает на высокую нагрузку
  • Быстрый, новый, на Scaleway. С SSD, но с малым объёмом диска, куда все аттачи тупо не влезут.
  • Тормозной, очень медленный VPS у Time4VPS, но с самым дешёвым терабайтом места.

​​​​​​​тут я замечу, что это [пока ещё?] не статья с точными инструкциями, а что-то типа блог-записи с мыслями. Может быть, со временем, доведу и до уровня статьи.

Задача.

Это позволит раскидать нагрузку по разным серверам и задействовать Round Robin DNS, когда одному доменному имени отвечают несколько IP.

Это решается, конечно, элементарно. Например, на NginX:

location ~ ^/forums/attaches/(\w\w/\w\w.*)$ {
    rewrite ^/forums/attaches/(\w\w/\w\w.*)$ <https://archive.attaches.forums.a0z.ru/$1> permanent;
}

location ~ ^/forums/attaches/((\d\d\d\d).*)$ {
    rewrite ^/forums/attaches/(\d\d\d\d)/(.+)$ <https://$1.f.a0z.ru/$2> permanent;
}

Вот дальше было хитрее.

Во-первых, синхронизация файлов между серверами. Я задействовал для этого Syncthing. Хотя он и тормозит при пересканировании, но его можно поставить очень редким (оставив свежее обновление по syncthing-inotify).

Во-вторых, syncthing даже при хорошей работе срабатывает не мгновенно. Задержка синхронизации бывает от секунд до десятков секунд. В это время обращения к серверам, куда файл ещё не пришёл, будет возвращать 404-ю ошибку.

Это проблему я решил NginX-проксированием на вторичных серверах. Если файл существует, то он показывается. Если нет, то идёт прокси-запрос к мастер-серверу:

server_name 2018.f.a0z.ru;
location / {
# ...
    try_files $uri @htz;
}

location @htz {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $host;
    proxy_pass <http://htz.wrk.ru;>
}

# ...

Таким образом, с любого вторичного сервера файл доступе даже когда синхронизация ещё не произошла.

Дальше — вопрос сертификата Let's Encrypt при использовании Round Robin DNS. Тут пришлось много возиться и экспериментировать. Я опущу все промежуточные проблемы и эксперименты и поделюсь итоговым решением.

На всех вторичных серверах нужно направить запросы с подкаталогу /.well-known/acme-challenge на мастер-сервер:

location /.well-known/acme-challenge/ {
    proxy_set_header    Host                $host;
    proxy_pass          <http://htz.wrk.ru;>
}

На мастер-сервере отправляем отдачу этого подкаталога из конкретного места сервера:

location ^~ /.well-known/acme-challenge/ {
    default_type "text/plain";
    root /var/www/html/letsencrypt;
}

Прописываем этот путь в настройках /etc/letsencrypt/cli.ini:

authenticator = webroot
webroot-path = /var/www/html/letsencrypt
post-hook = service nginx reload
text = True

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

./certbot-auto certonly -d 2016.f.a0z.ru

(продолжение следует)

Продолжая тему Проблемы с IPFS.

Разочарован :-/

Сделал несколько экспериментов по раздаче сколь-нибудь больших репозиториев (десятки гигабайт) и не смог обуздать аппетиты к памяти и процессору. Сервер, типа 32Гб оперативки и i7-4770 начинает жрать LA больше 20, всё тормозит:

load-week-ipfs-on.png (497x280)

cpu-week-ipfs-on.png (497x376)

Придётся искать для синхронизации файлов в Infonesy более традиционные методы :-/

Update 2018-2401:

anotherneko: Оно течет, если рестаровать периодически то более-менее юзабельно.

Оно само крешиться и перезапускается, если память в контейнере урезать (зелёненькое):

docker_memory-day.png (497x424)

Увы, всё равно жрёт ресурсов чрезмерно по отношению к отдаче. При чём когда-то давно раньше такого явно не было. Хоть экспериментируй с откатами на старые версии :)

Проблемы с IPFS

- Posted in Infonesy.Blog by with comments

IPFS в последнее время что-то совсем вразнос пошла. Сперва памяти стала жрать как не в себя. При чём в нескольких версиях, в последних из которых прямо пишут, что уменьшили потребление памяти. Ага, щаз, на машине с 16Гб мгновенно выжирает 8Гб. На VPS с 1Гб выжирает 700Мб, отправляя в аут MySQL и PHP. Ладно, эту проблему решил, засунув Docker-конейнер. Теперь на одном из серверов (VPS, 2Гб) и только на нём непрерывно занимается дисковым чтением на 50..100Мб/с. При чём в сеть это всё не идёт, сетевой трафик измеряется десятками килобайт в секунду. Думал, сперва, мало ли, переиндексация какая-то или оптимизация — но нет, уже половина дня прошла...

Затравка, буду понемногу расширять запись в рамках подхода «блоги как сайты».

Mastodon

Много японских (и японоговорящих) анимешников. Говорят, таким способом уходят от японских возможных проблем с законом.

RetroShare

Огромная масса параноиков. Каждый второй обвиняет друг друга в работе на ФСБ. Каждое четвёртое сообщение заканчивается припиской «товарищ майор, перелогиньтесь». Очень много мата и ругани. Правда, там есть функция игнора и после зачистки самых агрессивных пользователей, сеть становится заметно чище. Но и почти мёртвой. Хотя, поскольку это сеть f2f, можно формировать собственные круги друзей, «только для своих».

SSB Patchwork

Пользуюсь сетью мало. Но когда начал там размещать фотографии боевых самолётов, получил лёгкий наезд в духе «зачем Вы тут постите фотографии оружия — оно убивает людей, это не этично!». Иных, более активных конфликтов или культурных особенностей пока не встречал.

ZeroNet

Аудитория в целом очень усреднённая, без заметных перекосов. Почему лично я её и предпочитаю :) В основном относительно культурный IT-шный контингент, чем-то похоже на старое FIDO. Исключение — очень много китайцев. Похоже, для них это хороший способ выбраться за GFW. Ну и их просто в абсолютных числах много. Вот у них с технической культурой не очень. Например, они так и не восприняли идею, что заводить в общем англоязычном ZeroTalk массовые темы на китайском — не хорошо :)

Ссылки

shell-script: Всякие разные децентрализаторы предлагают по сути вернуться к файлику hosts, оборачивая его всякими хешами и большими алгоритмами. Поэтому и не взлетают пока все эти распределённые сети

  1. В том же ZeroNet активно используется NameCoin :)
  2. Доменные имена всерьёз никогда не способствовали популярности ресурса. Сперва был долгий период, когда ресурс просто нельзя было найти, не важно, с читаемым именем или нет, потом очень быстро наступил период, когда люди не помнят и не вводят вручную даже короткие доменные имена, кроме совсем очевидных случаев, типа vk.com или google.com :) Для продвинутых юзеров есть закладки, для основной массы — поисковая система в адресной строке браузера.
  3. Практически про каждую современную p2p-систему можно сказать, что причины отсутствия её популярности связаны не с перечисленным и не с чем-то общим, а, чаще, с индивидуальными особенностями.

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


RetroShare от роста популярности удерживает firend-to-friend система, совершенно убогий клиент с куцыми форумами, отсутствие нормальной обновляемой динамики и т.п. А хуже всего — отсутствие headless-серверной реализации, чтобы можно было поддерживать сеть не только с десктопной машины.

GNUSocial, Mastodon, Twister и прочую компанию тормозит то, что это только микроблоги. А потребителей одним микроблогов не так много. При чём первые два федеративные, а второй — на блокчейне, который даже сейчас, в отсутствии большой популярности, весит уже гигабайт.

SSB Patchwork просто не имеет каких-то особых киллерфич, чтобы заинтересовать много народа. При этом бедный по функционалу, и тяжёлый по базе данных и клиенту. И тоже нет серверной версии.

Что там ещё осталось для форумно-комментного общения? :) Я, в общем, оценивал разные p2p-системы в Infonesy.Talk...

Steemit. Ну, это фиаско с точки зрения децентрализации. Сделали распределённую систему, которую огородили и централизовали по самое не могу. Но вот у неё, как раз, шанс взлететь есть. «Майнинг написанием постов» многих может привлечь. Но это — не децентрализация.

А, ну да. Movim, Diaspora. Федеративные, а не децентрализованные. Только блоги. Разработчики Diaspora ещё и какие-то мутные :) Пиар был недолгий, быстро утихло, понемногу развиваются, но из-за отсутствия пиара не на слуху.

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

ZeroTalk → Infonesy

- Posted in Infonesy.Blog by with comments

Немного повозился с сабжем. Чтобы нормально разгребать структуру требуется не только транспорт сделать, но и абстрактное хранилище. Для удобства ручной работы — на файлах. Всё думал подключить в качестве такого бэкенда какой-нибудь flat-file форум, но всё, что пощупал, кривое и недоделанное. Плюнул, завелосипедил свой формат. Точнее, пока только рыбу формата.

Сейчас работает экспорт ZeroTalk в посты по топикам на файловой системе. Нужно привести в порядок все доступные поля и можно делать импорт этих данных в какой-нибудь из обычных Web-форумов. Например, в ту же Vanilla. И можно будет запустить начерно web-зеркало на манер www.zites.cf

Facebook → Infonesy

- Posted in Infonesy.Blog by with comments

Аналогично предыдущему драйверу Redmine делаю и более востребованный драйвер Facebook. Пока только для чтения. Стадия готовности очень ранняя. В свете последующих работ с драйвером Redmine, придётся ещё и интерфейсы немного править. Главная проблема — Facebook сильно лимитирует частоту обращений через API (200 в час), что требует много возни с групповой работой, чтобы одним запросом выдёргивать как можно больше. А это плохо ложится в унификацию интерфейсов. Пока делаю только чтение, но когда-то надо будет делать и запись, для двухстороннего синка.

https://github.com/Balancer/infonesy-driver-facebook

Redmine → Infonesy

- Posted in Infonesy.Blog by with comments

Возникла тут задача отконвертировать данные от Redmine (issues+wiki) и Trac в Phabricator. Готовых работающих решений не нашёл и пришлось писать своё :) Решил делать не прямую конвертацию одного в другое, а через промежуточное файловое сохранение. Ага, как раз в формате обмена данных Infonesy :)

https://github.com/Balancer/infonesy-driver-redmine


Это пока не работающий ещё драйвер, а отработка. Но уже экспортирует issues и юзеров в файлы Infonesy. Например:

---
Title: 'Отображение классификатора для «Участника проекта»'
UUID: ru.balancer.rm.issue.563
Author:
    Title: 'XXXXXXX'
    EmailMD5: 69489xxx04219adbd75663218bda8ce1
    UUID: ru.balancer.rm.user.1
Date: 'Mon, 12 Jun 2017 13:40:57 +0300'
Type: Issue
Modify: 'Mon, 12 Jun 2017 16:26:34 +0300'
---

# Отображение классификатора для «Участника проекта»

*Роль «Участник проекта»*

1\. Прошу, сделать таблицу в три колонки

| Полное название (Псевдоним)| Идентификатор | Описание |

Псевдоним – отображаем, разумеется, если он есть

2\. Убрать ссылки с названия объекта

3\. Добавить в название слово «Проектный»… должно быть «Проектный классификатор…»

4\. Добавить над таблицей, с выравниванием вправо текст «Всего объектов: (экспорт в XLS)»

Важно только правильно и единообразно согласовать, например, форматы полей пользователя. А то в разных системах есть много тонкостей (например, одни учитывают последний логин, другие — последний визит...).

Заодно отрабатываю единые интерфейсы для разнородных данных.

Ход работ

- Posted in Infonesy.Blog by with comments

Сейчас основное у меня направление — это гейтование с ZeroNet. Как закончится — так всё это будет и в Интернете доступно :) Ну, разве что ещё гейтование Facebook → Infonesy приоритетно тоже.

Я ещё к началу лета сделал (благо, это не сложно) экспорт ZeroBlog в Infonesy-файловый синк. Но потом дело притормозилось из-за кучи других забот. Сейчас возвращаюсь к экспериментам.

Решил совместить приятное с полезным — сделать из файлсинка импорт в HTMLy (вот тут писал выше). Очень уж удобный формат «базы» блогов.

Полезность же будет в том, что это будут «статические» блоги, которые смогут окучить поисковики. И контент ZeroNet появится в обычном Интернете. Легче будет искать.

Под всякие мелочи и технические моменты завёл тему в ZeroTalk: https://www.zerogate.tk/1F4WVHDpQYxuJL6xEY3EZTYkZds9TTjVHC/?Topic:28_1PniNzyi8fygvwyBaLpA9oBDVWZ5fXuJUw/Infonesy

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

HTMLy is an open source databaseless blogging platform. The Flat-File Blog and Flat-File CMS written in PHP.


Собственные впечатления по первым тестам:

  • В редакторе есть превью. Но нет синтаксической подсветки, автоматизации ссылок и т.п.
  • Категории. Сделаны достаточно удобно.
  • Многопользовательская.
  • Есть аплоад изображений.
  • Много разных категорий сообщения. Изображения, цитаты, видео, статические страницы...

Если сравнивать с Grav, то HTMLy легче и в целом из коробки много функциональнее. Фактически это сразу готовое к использованию решение с приличным видом. Grav нужно сильно допиливать и то не факт, что получится. Зато в Grav классный редактор. Метатеги в Markdown в нём сделаны по-человечески в виде YAML в шапке. А у HTMLy — в виде HTML-комментариев.