? Editing: Post:21.body Save Delete Cancel
Initial sync in progress...

Newest topics

Follow in NewsfeedFollowing
+ Start new topic
Loading...
stickied

Title

Body
^1 ^2 added ━ started by user_name
More topics

 

Follow in NewsfeedFollowing

Мысли о flatfile-форуме и блоге

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

Достаточно очевидное решение — хранить записи плоских файлах в Markdown. Их и вручную смотреть можно, и куча вьюверов есть. К тому же он набрал огромную популярность. Плюс Markdown позволяет хранить в себе и метаданные. А плоский файловый формат позволяет легко синхронизировать записи по сети, бэкапить, архивировать и т.п. Чем может быть полезен в Infonesy :)

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

Думаю, хранить данные в формате «один топик — один Markdown-файл». Картинки — в подкаталоге, чтобы в Markdown можно было использовать относительные ссылки. Пока не очень понятно, как делать разбиение на посты. Метаинформация топика — тут всё просто, привычный уже хедер Markdown в YAML. Наверное, посты надо выделить аналогичным способом. Что-то в духе:

---
Title: Тестовый топик
Date: 2018-05-07 10:12 GMT+03:00
Tags:
  - тест
---

========================================
Author: Balancer
Date: 2018-05-07 10:12 GMT+03:00
----------------------------------------

Это первый пост топика

========================================
Author: Balancer
Date: 2018-05-07 10:14 GMT+03:00
----------------------------------------

> Это первый пост топика

А это — ответ на первый пост

Жаль, что блоки метаданных стандартно отбиваются тройными минусами ---, отбивка более длинной линией улучшила бы читаемость исходника… Впрочем, всё равно встроенные блоки метаданных штука не стандартная, так что можно отбивать и длинно. Поправил предыдущий пример :) Хотя это тоже минус — стандартный парсер будет считать, что Date — заголовок… Хм. Тут надо ещё думать будет.

Топики хорошо раскидывать по датам создания. Правда, пока не придумал, в каком порядке лучше делить по датам и подфорумам.

Вариант YYYY/MM/DD/Theme/Topics.md позволяет легче оперировать с архивами по датам. А вариант Theme/YYYY/MM/DD/Topic.md позволяет проще выбирать подфорум. Наверное, второй способ правильнее, всё же.

^4 ^5 balancer73 posted on May 07, 2018
Please sign innew comment
Sign in as...
Submit comment
You are running out of your allowed space, please contact the site's admin at unknown to raise your limit.
user_nameadded ^1 ^2
Reply
Body
geeklesson May 09, 2018 ^1 ^2
Reply

gitcenter

Немного переделал.

Добавил эвристику: если есть доступ к contents.json, можно напрямую прочитать, есть ли нужный файл в оглавлении.

Всё равно работает немного не так, как хотелось бы. Асинхронный код надо будет переписать на свежую голову.

gitcenteron May 09, 2018 ^1 ^2
Reply

О, а теперь появилось сообщения о несуществующем файле.

gitcenteron May 09, 2018 ^1 ^2
Reply

geekless: Оффтопик, но раз уж все в этой теме, потестируйте, как автоматические запросы Cors работают:http://127.0.0.1:43110/19fZJhX7FGENeRRLB8ftgrziBJ5vsLtFog/

Картинки начинают загружаться, но только после F5. То есть Grant, долго ждем, ничего не происходит, жмем F5, загружается первая картинка (через пару секунд), ждем, ничего не происходит, жмем F5, загружается вторая каринка. Про ошибку так и нет сообщения.

gitcenteron May 09, 2018 ^1 ^2
Reply

geekless: Блокчейн? На текущей модели контента — сомнительно.

Почему блокчейн? Папки/зайты, в которые пользователи пишут сообщения.

geeklesson May 09, 2018 ^1 ^2
Reply

Оффтопик, но раз уж все в этой теме, потестируйте, как автоматические запросы Cors работают:
http://127.0.0.1:43110/19fZJhX7FGENeRRLB8ftgrziBJ5vsLtFog/

geeklesson May 09, 2018 ^1 ^2
Reply

gitcenter: Вопрос. Это ведь можно сделать прямо в ZeroNet?

Блокчейн? На текущей модели контента — сомнительно.

gitcenteron May 09, 2018 ^1 ^2
Reply

Вопрос. Это ведь можно сделать прямо в ZeroNet?

balancer73on May 09, 2018 ^1 ^2
Reply

bitcoren: Новых пользователей можно анонсировать в блокчейне

Это требует дополнительного инструмента-сущности. При чём самописного. В остальном-то у нас используются готовые сторонние решения :)

bitcorenon May 08, 2018 ^1 ^2
Reply

Новых пользователей можно анонсировать в блокчейне, например Emercoin, или Holochain (когда запустится).
Например, добавил тему в блокчейн и свой адрес Rslsync, значит кому интересно тебя добавят в читаемые.

x86128on May 08, 2018 ^1 ^2
Reply

calmaquesse: оформленные в pdf

Фотошопа нет под рукой сейчас чтобы текстуры наложить :D

geeklesson May 08, 2018 ^1 ^2
Reply

x86128: Тут есть подводный камень, SQLite что-то до сих пор русский язык в utf-8 ищет только как case-sensetive. Напоролись недавно когда мелкую базу для почтовки делали.

Собственно, поиск на главной странице ZeroHello вот так и ищет, неполноценно.

anothernekoon May 08, 2018 ^1 ^2
Reply

geekless: Все участники сети хранят content.json в полном объеме. Можно выполнить DoS системы, создавая из-под разных ID много content.json максимального размера.

Если не хранить в нем полезные данные, то можно сделать его максимально пустым.

x86128on May 08, 2018 ^1 ^2
Reply

Пагинация нужна и предпросмотр поста :D

  • просмотр для печати
  • просмотр одной страницей
  • просмотр в архивном режиме
  • постраничный просмотр
x86128on May 08, 2018 ^1 ^2
Reply

balancer73: Большая БД нужна для сложных запросов, типа выборки постов по каким-то критериям или, тем более, полнотекстового поиска…

Тут есть подводный камень, SQLite что-то до сих пор русский язык в utf-8 ищет только как case-sensetive. Напоролись недавно когда мелкую базу для почтовки делали.

balancer73: Впрочем, разбивка на темы тут может совершенно прозрачно быть. Просто у каждого юзера может быть много разных репозиториев с разными темами. И подписываться нужно не на всё, а на только интересные тебе темы.

Такого рода ZeroHello только для большого форума.

calmaquesse: Нет, серьёзно, какие-то варианты "белых списков" так или иначе придется делать с ростом сети.

Тут можно сделать форк ZeroID и назвать его "Паспорт гражданина [придумай сам]-ляндии" по которому будут пускать к постингу в наши форумы :D
Можно и в PDF раздавать :D

balancer73on May 08, 2018 ^1 ^2
Reply

x86128: для 5 млн. файлов надо строить индексы для быстрого просмотра последних сообщений топика. В таком случае придётся писать свою БД.

Для варианта именно распределённых форумов индекс в БД неизбежен, т.к. каждый топик будет собираться из множества репозиториев и сканировать всю ФС для просмотра будет накладно уже на сотнях топиков. Но чисто для просмотра/ответов хватит sqlite-кеша. Топиков относительно немного (у меня на форумах — 75 тысяч), так что таблица топиков будет небольшой.

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

calmaquesseon May 08, 2018 ^2 ^3
Reply

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

Целевые приглашения, оформленные в pdf и с персональной подписью :D
Нет, серьёзно, какие-то варианты "белых списков" так или иначе придется делать с ростом сети.

calmaquesseon May 08, 2018 ^1 ^2
Reply

balancer73: Я тут думал, думал в контексте сабжа и получилось очень интересно :) [...]

Балансер, вы просто гребаный гений.

x86128on May 08, 2018 ^1 ^2
Reply

balancer73: Кстати, разбиение на посты с целью борьбы с конфликтами автоматом избавляет от ситуаций, как у меня недавно в ZeroTalk посты пропали :) — ответил пару раз на форум, потом пересел на другую машину и ответил там. А на той машине не завершился синк и была старая версия JSON-файла. Он запостился и переписал обновлённый вариант с другой машины, предыдущие посты пропали :)

Ну вот. Меня сразу насторожило, почему система пишет что синхронизировано на 5/5 узлов, когда у тебя сайт лежит, например, у сотни узлов. Выходит, что нет от такой ситуации пока защиты.

balancer73: А если до конца дочитать

Виноват, да. Ну это темболее, для 5 млн. файлов надо строить индексы для быстрого просмотра последних сообщений топика. В таком случае придётся писать свою БД.

balancer73on May 08, 2018 ^1 ^2
Reply

Кстати, разбиение на посты с целью борьбы с конфликтами автоматом избавляет от ситуаций, как у меня недавно в ZeroTalk посты пропали :) — ответил пару раз на форум, потом пересел на другую машину и ответил там. А на той машине не завершился синк и была старая версия JSON-файла. Он запостился и переписал обновлённый вариант с другой машины, предыдущие посты пропали :)

geeklesson May 08, 2018 ^1 ^2
Reply

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

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

stre10kon May 08, 2018 ^1 ^2
Reply

geekless: Похоже, мы сейчас плейтекстовый вариант ретрошары с блекджеком изобретём. :)

Мне это пока напоминает помесь IDEC и ZeroNet :)

balancer73on May 08, 2018 ^2 ^3
Reply

geekless: Похоже, мы сейчас плейтекстовый вариант ретрошары с блекджеком изобретём. :)

«Антиретрошара». (Как и «антизеронет») — там пока тебя не авторизуют, ты не можешь получить доступ к сети. А тут ты можешь получить доступ на чтение по публичному ключу и никто в общем случае про это может не знать :)

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

Кстати, в «режиме федерации» на централизованном ресурсе получается интересная система авторизации. Ты можешь просто сообщить на сайт свой R/W-ключ в rslsync и этого хватит, чтобы тебя подключить в сеть :)

geeklesson May 08, 2018 ^2 ^3
Reply

Похоже, мы сейчас плейтекстовый вариант ретрошары с блекджеком изобретём. :)

balancer73on May 08, 2018 ^1 ^2
Reply

stre10k: Мы подписаны на пользователя А, он подписывается на пользователя Б и создает об этом файл в своем каталоге. Так из каталога пользователя А мы можем узнать о пользователе Б.

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

Я просто не совсем правильно понял комментарий, на который отвечал. Показалось, там речь о том, чтобы видеть, кто подписался на тебя :)

geeklesson May 08, 2018 ^1 ^2
Reply

stre10k: Мы подписаны на пользователя А, он подписывается на пользователя Б и создает об этом файл в своем каталоге. Так из каталога пользователя А мы можем узнать о пользователе Б.

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

balancer73on May 08, 2018 ^1 ^2
Reply

x86128: Как вы говорите что 7 Гбайт постов, а в виде файлов будет еще гораздо больше

А если до конца дочитать, то там следующим предложением идёт: «Конечно, средний объём сообщения получается около 1-2 кбайт и у нас на 4 кбайт-кластерах теряется 50-70% места, но даже 10-40Гб места для 5 миллионов сообщений за 20 лет — это терпимо»

Насчет вандалоустойчивости. Тут поднимается глобальная тема цензурирования. Либо есть цензура и тогда непонятно что делать с этим цензурятором который может начать превышать полномочия, либо её нет - тогда анархия получается.

А тут (в концепции Flatnesy) и нет никакого цензурирования. Просто никто тебя не заставляет подписываться на того, кто тебе не интересен. Это ни разу не цензура :)

stre10kon May 08, 2018 ^1 ^2
Reply

balancer73: Тут проблема в том, что пользователь может писать только в свой каталог. А мы на него заранее не подписаны. Можно создать публичные rw-каталоги для публикаций своих ключей. Но они будут подвержены вандализму — от спама до просто непрерывного удаления всего подряд. Я пока не вижу идеального автоматического решения.

Мы подписаны на пользователя А, он подписывается на пользователя Б и создает об этом файл в своем каталоге. Так из каталога пользователя А мы можем узнать о пользователе Б.

geeklesson May 08, 2018 ^2 ^3
Reply

x86128: Только тут более тонкая настройка нужна, сейчас "бан" работает per site, а нужно per user on site

Да. Там нужна связка между плагином Mute и ядом ZN. В принципе, ничего сложного.

balancer73on May 08, 2018 ^2 ^3
Reply

Черновой экспорт ZeroBlog'а:

Ключ в Rslsync: BPBISMAHDMR435FYIELW6UGFDUNOBBBJ6 (10Мб)

x86128on May 08, 2018 ^1 ^2
Reply

Так вот посудите:

Вполне себе читаемо. И искать можно.

x86128on May 08, 2018 ^1 ^2
Reply

geekless: А когда X и Y — одно лицо, цензурой это считать не получится. «Не хочу — не читаю».
Белые списки, которые пользователь сам себе составит, не являются цензурой по отношению к третьим лицам.

Совершенно согласен.

"Не хочу - не читаю" понимать как "Не хочу - не помогаю распространят ваш контент"
Только тут более тонкая настройка нужна, сейчас "бан" работает per site, а нужно per user on site

geeklesson May 08, 2018 ^2 ^3
Reply

x86128: Насчет вандалоустойчивости. Тут поднимается глобальная тема цензурирования. Либо есть цензура и тогда непонятно что делать с этим цензурятором который может начать превышать полномочия, либо её нет - тогда анархия получается.

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

Цензура — это когда персонаж X запрещает персонажу Y публиковать данные или получать доступ к данным.

А когда X и Y — одно лицо, цензурой это считать не получится. «Не хочу — не читаю».

Белые списки, которые пользователь сам себе составит, не являются цензурой по отношению к третьим лицам.

x86128on May 08, 2018 ^2 ^3
Reply

Бегло посмотрел в папку с ZeroTalk этого форума...

Уже всё лежит по полочкам. Каждому пользователю своя папка в которой лежит его честно нажитое - content.json, data.json и файлики аттачей.

Считаю, что можно всё сделать средствами ZeroTalk (насколько я понимаю):

  • Предусмотреть средствами UI возможность бана/разбана, которое запрещает/разрешает прием папки data этого пользователя
  • Предусмотреть экспорт как markdown plain-файлов постов пользователя, тем форума и треда средствами WebUI.

Бегло просмотрев исходники, заметил, что форум ZeroTalk раздает посты в виде json-ов которые суть текст, т.е. спокойно грепается при необходимости. Но на клиенте он все эти json-ы засовывает в SQLite cache из которого WebUI морда их дергает.

Поскольку всё лежит внутри json-ов можно предусмотреть офф-лайн экспорт скриптами как из самих json-ов так и из SQLite кэша. Схема базы SQLite лежит в корне форума.

Насчет импорта постов пользователей вопрос спорный, поскольку только пользователь может/должен решать как распоряжаться своими данными. Возможно, можно предусмотреть импорт своих сообщений на форум после их экспорта.

С версионностью связываться неохота, поскольку для форума это слишком огромный оверхэд. Снапшоты форума для личного пользования можно делать средствами файловой системы. Хотя тут как раз и на скриптах можно делать полный экспорт в длинный файл, но как тогда делать/смотреть diff остается не ясным. Как вы говорите что 7 Гбайт постов, а в виде файлов будет еще гораздо больше, поскольку там еще в файловой системе куча метаданных будет создаваться.

Насчет вандалоустойчивости. Тут поднимается глобальная тема цензурирования. Либо есть цензура и тогда непонятно что делать с этим цензурятором который может начать превышать полномочия, либо её нет - тогда анархия получается.

geeklesson May 08, 2018 ^1 ^2
Reply

balancer73: Вот в ZeroNet не получится забэкапить отдельного юзера и потом, если что, восстановить его данные чисто сторонними средствами, без доработок ZeroNet :)

Это точно. Вроде обещали снапшоты, но неизвестно когда и в каком виде.

balancer73on May 08, 2018 ^1 ^2
Reply

geekless: Это дело еще и резервировать надо будет. И контроллировать целостность. Довольно громоздко.

Это уже каждый сам для себя будет решать. Поэтому чужие данные не нужно контролировать. Резервирование сам rslsync на себя берёт :) Единственное, что он не спасает от порчи юзером своих файлов. Такая порча распространится и по всем копиям. Но тут уже особо ценных юзеров можно синкать иными способами, например, syncthing'ом с версионным бэкапом. Или просто тупо периодически архивировать. В любом случае прелесть ситуации в том, что этот вопрос никак не связан с нашей системой. Вот в ZeroNet не получится забэкапить отдельного юзера и потом, если что, восстановить его данные чисто сторонними средствами, без доработок ZeroNet :)

balancer73on May 08, 2018 ^2 ^3
Reply

geekless: Ммм... вроде это были частности конкретных движков.

В Markdown, конечно, нет жёстких стандартов, но шапка из YAML-метаданных — это формат, который понимают уже многие. И, главное, GitHub :) Так что можно считать стандартом де-факто.

У других форматов или свои способы записи метаданных, или отсутствуют. Конечно, добавить такую шапку можно к любому тексту, но это уже в общем случае будет не валидный документ :)

geeklesson May 08, 2018 ^1 ^2
Reply

balancer73: Я оцениваю по своим форумам Авиабазы. Там за 20 лет накопилось около 5 миллионов сообщений. ИМХО, это вполне подъёмное число для современных ФС с учётом масштаба архивов. Главное, что я сам первый же локально не будут подписываться на всё это безобразие, так что реальные объёмы будут меньше :) Конечно, средний объём сообщения получается около 1-2 кбайт и у нас на 4 кбайт-кластерах теряется 50-70% места, но даже 10-40Гб места для 5 миллионов сообщений за 20 лет — это терпимо. Один фиг, аттачей в разы больше :)

Это дело еще и резервировать надо будет. И контроллировать целостность. Довольно громоздко.

geeklesson May 08, 2018 ^1 ^2
Reply

balancer73: Во-первых, «шапка в YAML» — это не вопрос нашего формата, это стандартный формат метаданных Markdown

Ммм... вроде это были частности конкретных движков. YAML универсален так что, можно его использовать как шапку перед любыми текстовыми данными (аналогия — HTTP-заголовки). В генераторах статических сайтов YAML применяется, например, чтобы указать последующий формат документа (md, textile и т.п., хоть bbcode, если есть чем конвертировать), заголовок, теги, шаблон страницы и т.п. Благодаря метаданным YAML-а создаваемая страница выстраивается как дерево зависимостей.

balancer73on May 08, 2018 ^1 ^2
Reply

stre10k: При хранении пост - файл ожидается просадка производительности типовых ФС при большом кол-ве файлов и неэффективное использование места.

Я оцениваю по своим форумам Авиабазы. Там за 20 лет накопилось около 5 миллионов сообщений. ИМХО, это вполне подъёмное число для современных ФС с учётом масштаба архивов. Главное, что я сам первый же локально не будут подписываться на всё это безобразие, так что реальные объёмы будут меньше :) Конечно, средний объём сообщения получается около 1-2 кбайт и у нас на 4 кбайт-кластерах теряется 50-70% места, но даже 10-40Гб места для 5 миллионов сообщений за 20 лет — это терпимо. Один фиг, аттачей в разы больше :)

Ну а для локального использования это вообще не проблема. Если собрать всё, что я написал на всех форумах и блогах за всё время, едва ли 200 тыс. сообщений наберётся. Меньше 1Гб с учётом всех хвостов.

Когда пользователь подписывается на другого пользователя, он может создавать файл об этом. Таким образом другие могут видеть других пользователей. По подобию SSB/Patchwork.

Тут проблема в том, что пользователь может писать только в свой каталог. А мы на него заранее не подписаны. Можно создать публичные rw-каталоги для публикаций своих ключей. Но они будут подвержены вандализму — от спама до просто непрерывного удаления всего подряд. Я пока не вижу идеального автоматического решения.

balancer73on May 08, 2018 ^1 ^2
Reply

geekless: Система адресации, доставки и хранения контента […] инструментов в этой области полно. Не думаю, что нужно что-то еще придумывать.

Поэтому я и рассматриваю обмен данными отдельно. Можно пользоваться хоть флоппинетом. Но эксперименты сейчас веду с rslsync, потому что это самый простой способ предоставить r/o-данные по ключу.

Возможно, markdown под YAMLом не лучшая альтернатива, может быть, у кого-то есть еще идеи?

Это простой человекочитаемый текст. При чём на сегодня самый раскрученный формат. Думаю, сложно придумать что-то лучше по совокупности. Так-то, например, было бы неплохо задействовать какой-нибудь более богатый asciidoc, но его почти никто не поддерживает. К тому же встанет вопрос конвертации.

как конвертировать богатую разметку HTML в plaintext

А никак. Изначально всё заточено под markdown :) Львиная доля ресурсов (включая ZeroNet) или уже работают с ним, или имеют plain-text (Twitter/Facebook/etc). Есть, конечно, случаи с HTML (скажем, WordPress), но подобная разметка на 90% конвертится в Markdown корректно. Тонкости оформления теряются, но контент остаётся нормальный. Кстати, в случае доверия (например, для собственных ресурсов) можно и HTML оставить — это «подмножество» Markdown :) В смысле, при соответствующих опциях, HTML в Markdown отображается без экранирования, именно как HTML.

А может быть, под шапкой YAML может размещаться один из множества человекочитаемых форматов? Textile — неплохая альтернатива. Как насчёт LaTeX?

Во-первых, «шапка в YAML» — это не вопрос нашего формата, это стандартный формат метаданных Markdown :) Например, в asciidoc шапка в другом формате (простые «ключ-значение»). В Textile, по-моему, нет метаданных. В LaTeX, опять же, свой формат.

Движок или протокол, реализующий интерактивную систему поверх plaintext-а. У меня есть сомнения нужен ли он.

Иначе не получится распределённого форума :)

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

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

Форумный движок — это довольно много человекочасов, при том что форумных движков и так полно.

Для всяких наворотов можно по-прежнему оставить двухстороннюю трансляцию в рамках Infonesy :) Альтернативный форумный движок — это для автономной децентрализованной работы тем, кто хочет сохранить данные.

нужно чётко представлять: 1) какой у нас транспорт

В общем случае любой, но, как я заметил, я делаю ставку на rslsync, это сильно упростит работу по конвертации централизованных ресурсов. Достаточно будет пользователю приватно сообщить серверу свой R/W-ключ, чтобы на сервере можно было сделать репозиторий этого пользователя и переключиться на работу с ним. Хотя пока не знаю, насколько этот процесс можно автоматизировать, но и вручную задача не самая хитрая :)

2) какой формат хранения

  • Пост = Markdown-файл в формате, который у меня используется в обмене данными в Infonesy.
  • Топик = каталог с постами. Точные детали, типа метаданных буду решать на ходу, там мелочи.
  • Форумы, подфорумы — произвольная персональная структура каталогов-топиков.
  • Аттачи — наверное, вместе с постами же.

3) какая модель угроз и как она решается

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

stre10kon May 08, 2018 ^1 ^2
Reply

balancer73: Я тут думал, думал в контексте сабжа и получилось очень интересно :) [...]

Идеи интересные. Пара комментариев:
При хранении пост - файл ожидается просадка производительности типовых ФС при большом кол-ве файлов и неэффективное использование места.

Когда пользователь подписывается на другого пользователя, он может создавать файл об этом. Таким образом другие могут видеть других пользователей. По подобию SSB/Patchwork.

geeklesson May 08, 2018 ^2 ^3
Reply

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

При этом остаются существующие проблемы зайтов:

  • Все участники сети хранят content.json в полном объеме. Можно выполнить DoS системы, создавая из-под разных ID много content.json максимального размера.

  • Владелец ключа зайта имеет полный контроль забанить любого пользователя или грохнуть зайт целиком.

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

Уже на уровне форумов ZeroTalk он показывает свои недостатки. А делать на нём соцсеть — тупиковый путь.

geeklesson May 08, 2018 ^2 ^3
Reply

balancer73: Моя система решает проблему, которая не решена в ZN. У меня каждый сам решает, на каких юзеров подписываться и чей контент хранить.

Можно в ZN сделать так же. Я давно об этом говорил. Отдельный зайт — сама себе нода в социальной сети, которая хранит комментарии пользователя для контента с других нод и т.п. Надо непременно попробовать реализовать эту технику. Пока на деле не попробуешь, сложно оценить все преимущества и недостатки.

В теме 3 аспекта затронуто, я думаю, их надо разделить:

  1. Система адресации, доставки и хранения контента. ZN придумана как «интерактивный торрент», и в этом качестве она отлично работает. У нас есть обычные централизованные веб-сервера, есть децентрализованные ZN, IPFS, BitTorrent, так что инструментов в этой области полно. Не думаю, что нужно что-то еще придумывать.

  2. Вечный формат хранения данных. Самая важная тема. Возможно, markdown под YAMLом не лучшая альтернатива, может быть, у кого-то есть еще идеи?
    Пока что видна куча подводных камней, например, как конвертировать богатую разметку HTML в plaintext. В общем случае это задача не решается. Может статься, что конвертёр потребуется не просто под каждый тип движка, а под каждый конкретный сайт. (Условно говоря, под каждый отдельный блог на Вордпресс, где есть собственные нетривиальные стили.)
    А может быть, под шапкой YAML может размещаться один из множества человекочитаемых форматов? Textile — неплохая альтернатива. Как насчёт LaTeX?

  3. Движок или протокол, реализующий интерактивную систему поверх plaintext-а. У меня есть сомнения нужен ли он. Сначала идея была в создании вечно-читабельных коллекций данных. А занимаясь вместо этого созданием интерактивной системы, можно потратить много сил, при этом формат хранения останется непроработанным. Форумный движок — это довольно много человекочасов, при том что форумных движков и так полно.
    Хорошо продуманное flatfile хранилище имеет ценность само по себе даже без движка, как архив. А вот новый движок с непрождуманным форматом храннеи
    Если заниматься реализацией этого пункта, нужно чётко представлять: 1) какой у нас транспорт, 2) какой формат хранения, 3) какая модель угроз и как она решается.

balancer73on May 08, 2018 ^2 ^3
Reply

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

Ну, да, в этом случае получится отчасти похоже.

batwuson May 07, 2018 ^2 ^3
Reply

Это точно лучше чем ничего.
А вероятность остаться с ничего растет. Сука.

anothernekoon May 07, 2018 ^3 ^4
Reply

balancer73: Моя система решает проблему, которая не решена в ZN. У меня каждый сам решает, на каких юзеров подписываться и чей контент хранить. В ZN ты хранишь весь зайт.

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

balancer73on May 07, 2018 ^1 ^2
Reply

anotherneko: Поздравляю с изобретением схемы хранения файлов Zeronet

Я же писал выше, что у меня эдакий «ZeroNet наоборот» :) Идея похожая, но вывернута наизнанку. Не данные юзера в приложении, а данные приложений в данных юзера.

Моя система решает проблему, которая не решена в ZN. У меня каждый сам решает, на каких юзеров подписываться и чей контент хранить. В ZN ты хранишь весь зайт. У меня автоматически решается проблема спама и доверия пользователям, которая не решена в ZN. Плюс лёгкая возможность коллективной работы и совместимость с любым способом транспортировки файлов, потому что транспортируется не всё приложение со всеми юзерами, а только данные юзера, так что вопрос доверия решён заранее.

Грубо говоря, в ZN приоритет приложения. У меня — пользователя.

anothernekoon May 07, 2018 ^2 ^3
Reply

Поздравляю с изобретением схемы хранения файлов Zeronet. Тут тоже в рамках одного зайта у пользователя есть каталог, куда он может выкладывать свои файлы, которые будут RO для остальных. И да, тут файлы пользователя могут быть опциональными.

balancer73on May 07, 2018 ^1 ^2
Reply

Очевидно, что у каждого пользователя может быть множество репозиториев разного типа и разных типов. Скажем, в один я будут постить копии/бэкапы своего Твиттера, в другой — обширные статьи из Friendica. А другие читатели смогут выбрать, на что подписаться и в каком формате это смотреть. Одним потоком или в разных…

Вот что нужно решить — это вопросы кеширования больших объёмов. Скажем, полный архив текстов моего форума сейчас весит порядка гигабайт 7, если уже не больше. Если подписываться на всех и хранить всё, то никакой sqlite такое не потянет, да и для MySQL загрузка будет не для средних машин. Тут надо думать, наверное, нужно разбивать кеши по диапазонам дат и темам (форумам/подфорумам).

balancer73on May 07, 2018 ^1 ^2
Reply

В названии поста — обязательно дата в UTC. Она же будет использоваться для сортировки. Это, правда, оставляет некоторый простор для махинаций, но, если важно, то не внушающих доверие можно просто выкидывать из подписки :) А в критических случаях можно вообще синкаться через GitHub, тогда будет видно, что к чему.

balancer73on May 07, 2018 ^2 ^3
Reply

По структуре, в общем, тоже примерно понятно. Топик/контейнер однозначно определяется названием каталога, в котором лежат файлы-посты. Он включает в себя дату и, собственно, название. Иерархия поста может быть любой и даже у каждого своя. Хотя движок может давать советы об иерархии у других пользователей. Хотя тут могут быть неожиданные поведения при переименованиях… Значит, можно в каталог топика класть файл с реально уникальным UUID. Ещё элемент социальности, в данных топика можно показывать, под какими названиями он используется у других юзеров и предлагать переименование. Эдакое коллективное модерирование получается :)

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

Чёрт, мне эта идея всё больше нравится :)

balancer73on May 07, 2018 ^2 ^3
Reply

Я тут думал, думал в контексте сабжа и получилось очень интересно :)

  1. Я решил отказаться от формата один торпик = один файл. Это удобнее для чтения с файла и создаёт меньше нагрузку на ФС, но на этом преимущества и кончаются. Вариант один пост = один файл имеет много преимуществ:

  2. Можно не изобретать велосипеды форматов, будет стандартный Markdown с YAML-хедером, который понимает куча ресурсов, включая GitHub.

  3. Упрощается упорядочивание топиков — перенос постов между топиками превращается в простой перенос файла.
  4. Аттачи можно хранить под таким же именем как пост, рядом с ним, что тоже упрощает разбор.
  5. Нет проблем с хранением блогов/микроблогов.
  6. Отсутствуют конфликты при встречной модификации файлов на разных ресурсах при синхронизации (сколько мне такие конфликты крови попили при синке разных монолитных ресурсов!)

И вот по последнему пункту мои мысли полетели вскачь… Отсутствие конфликтов при синке = возможности легко писать на форум с разных мест. Типа, децентрализация. Можно обойтись без центрального сервера, пользуясь любым файловым синком от Rslsync/Syncthing до Dropbox/SparkleShare/GitHub. Получается бессерверная архитектура, привет p2p! Правда, получается проблема доверия авторам, ведь можно модифицировать чужие файлы… И, вот оно! А кто сказал, что все файлы должны быть в одной структуре каталогов? :) Внезапно вырисовывается такая картина:

  • Многие средства синхронизации позволяют публично отдавать контент в R/O. Это может быть Rslsync с публичным ключом только для чтения. Это может быть SparkleShare с Git-репозиторием…
  • Каждый пользователь заводит свой форум-репозиторий и отдаёт его другим участникам форумов.
  • Система собирает кеш-контент из каталогов-репозиториев пользователей, на которых ты подписан и показывает это всё как форумы или блоги.

Получается эдакий «ZeroNet наоборот». В ZN есть приложения, в которых хранятся R/O-данные пользователей. Тут получаются R/O-данные пользователей, опционально разбитые на приложения.

Бонусы:

  • Автоматически решается вопрос спама и лимитов. Мы просто не подписываемся на репозиторий спамера или флудера и не помогаем распространять такой контент. С игнором — аналогично. Прибил юзера и привет.
  • Легко реализуется коллективная работа. Несколько человек работают с одним R/W-ключом или Git-репозиторием.
  • Мы полностью независимы от транспорта. Работа хоть с флоппинетом становится автоматической :) Клиентская программа тоже получается произвольной, хоть вручную файлы пиши, хоть централизованным сервером.
  • Легко получается из одного флакона хоть публичная распределённая система, хоть приватный f2f.

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

Словом, прикольно всё это вырисовывается. Всё, кстати, в рамках идеи Infonesy, только там похожие принципы использовались как транспорт. А тут это сразу и бэкенд. И можно будет, наконец, мои многогиговые форумы в не просто в распределённую форму перевести, а в живую рабочую форму :)

Рабочее название системы — Flatnesy ;)

Попробую для начала и для простоты в таком виде свои блоги/микроблоги свести.

x86128on May 07, 2018 ^1 ^2
Reply

golova: Маленькое преимущество — несравнимая скорость :D Как потребуется что-то по тегу выбрать в хотя бы сотнях записей. plain-text ложится. Оно красиво работает только на крошечных объёмах и простых задачах.

Эти индексы делаются заранее (по требованию). Есть вот dokuwiki полностью plain-text wiki так она работает со скоростью света, причем там и обратные ссылки есть (показать все страницы которые ссылаются на эту страницу, ну или в терминологии форума - показать все посты данного пользователя)

golovaon May 07, 2018 ^1 ^2
Reply

anotherneko: На мой взгляд приемуществ реляционной БД для движка форума не так уж и много.

Маленькое преимущество — несравнимая скорость :D Как потребуется что-то по тегу выбрать в хотя бы сотнях записей. plain-text ложится. Оно красиво работает только на крошечных объёмах и простых задачах. Так что кеширующая прослойка из БД (как это сделано в ZeroNet для JSON -> SQLite, например) потребуется обязательно :) Но это как раз не проблема.

x86128on May 07, 2018 ^1 ^2
Reply

anotherneko: На мой взгляд приемуществ реляционной БД для движка форума не так уж и много.

Да и параллельно тянуть 2 сущности, которые выполняют одну и туже роль как-то неудобно.

Так и свалится к задаче "напишу еще одну свою БД" можно... :D Может быть так SQLite и начинался.

anothernekoon May 07, 2018 ^1 ^2
Reply

geekless: Тогда и преимущества реляционной БД сохраняются для движка сайта

На мой взгляд приемуществ реляционной БД для движка форума не так уж и много.

geeklesson May 07, 2018 ^1 ^2
Reply

balancer73: Эти файлы сами по себе будут бэкендом/базой данных. Модифицируемыми :)

ИМХО, их удобнее рассматривать как архив, чем как живую БД.
Например, если работает форум, он может хранить БД в своём родном виде, а во flatfile делать автоматический прозрачный экспорт.
Этот генерируемый flatfile можно выгружать в облако, заливать в git, бэкапить на флешку и так далее. Получается, с позиции читателя файла, это снимок состояния сайта.

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

balancer73on May 07, 2018 ^1 ^2
Reply

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

  • Описания форматов теряются
  • Часто форматы бывают столь неудобными, что фиг рука поднимется что-то писать под них
  • Писать под них ничего не будут простые смертные внуки, если не будут программерами :D
  • Все стандартные форматы не читаются с листа. А этого хочется, так как опыт подсказывает, что годы спустя это будет самый простой вариант быстро найти что-то :)
balancer73on May 07, 2018 ^1 ^2
Reply

geekless: Экспортёры из разных источников во flatfile хранилище

Да. В первую очередь — Telegram, Twitter и Facebook.

Интерактивный вьюер flatfile хранилища, типа веб-приложения или чего-то подобного.

Угу. Обычный PHP-форум для начала. В смысле, не только вьювер, но и полноценный форум для семейного общения. Собственно, я начал думать именно о таком форуме, чаты в Телеграме не всегда удобны, а потом подумал и о хранении и семейном архиве :)

Если прошло 20 лет, вьюер безнадежно устрел вместе с платформой, для которой предназначался, можно просто читать flatfile в любом блокноте.

Именно поэтому и хочется сделать формат одновременно достаточно удобный для работы приложений и легко читаемый «с листа».

Обратного преобразования flatfile -> интерактивный форум не предполагается.

Эти файлы сами по себе будут бэкендом/базой данных. Модифицируемыми :)

difrexon May 07, 2018 ^1 ^2
Reply

Тебе не нужен Markdown, тебе нужен org :)

calmaquesseon May 07, 2018 ^2 ^3
Reply

x86128: Фактически мы переизобретаем NNTP новости, там ведь и трэды были и цитирования и быстро всё работало. Каждый топик на диске лежал в виде длинющего eml файла где каждое сообщение просто аппендилось к концу и всё [...]

Да. очень было бы интересно увидеть такую штуку на современных технологиях.
Так что горячо поддерживаю :)
Еще бы сделать черно-зеленое оформление, чтоб как у дидов прям.

x86128on May 07, 2018 ^1 ^2
Reply

calmaquesse: А вот если Балансер хочет сделать что-то вроде ретро-USENET или такое импровизированное Фидо в ASCII, то... горячо поддерживаю!

Фактически мы переизобретаем NNTP новости, там ведь и трэды были и цитирования и быстро всё работало. Каждый топик на диске лежал в виде длинющего eml файла где каждое сообщение просто аппендилось к концу и всё

Работало же! :D и работало нормально ☭

x86128on May 07, 2018 ^1 ^2
Reply

calmaquesse: Если Балансер хочет сделать нечто "универсальное" к прочтению, что смогут, грубо говоря, прочитать цифровые археологи через тысячу лет - то, на самом деле, не вижу особо смысла, все популярные форматы сейчас хорошо задокументированы и не вижу причины, почему бы их не прочитать в будущем.

Дело в том, что те инструменты которыми задокументированы форматы канут в лету уже лет через 10 как и носители где эти форматы задокументированы. Теже флопики, CD-ROMы и ATA-диски.
Попробуйте открыть, например, новым вордом старый ворд, который под 3.11 виндовс был.

x86128on May 07, 2018 ^1 ^2
Reply

geekless: Обратного преобразования flatfile -> интерактивный форум не предполагается.

А почему бы и нет. Это же как сторадж. Если на "форум" зашел, то значит этот сторадж на экране показал. А значит и ответить на пост можно как в ZeroNet.

calmaquesseon May 07, 2018 ^1 ^2
Reply

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

А вот если Балансер хочет сделать что-то вроде ретро-USENET или такое импровизированное Фидо в ASCII, то... горячо поддерживаю! Банально из соображений ностальгии. Плюс, такой флэтбоард будет занимать очень мало месте на диске, и десятилетия переписки там можно будет сбросить на один жесткий диск - без картиночек, оформления простой текст будет занимать очень мало места.

В общем, очень интересная идея, но не совсем по заявленной причине.
Нет, серьёзно, очень хотелось бы увидеть такую борду без оформления, исключительно текстом.

geeklesson May 07, 2018 ^1 ^2
Reply

Интересная идея. Всякие архивы времён DOS-а и сейчас прекрасно читаются, чего не скажешь о многих современных базах знаний.

Если я правильно понял, планируется такая структура?

  • Экспортёры из разных источников во flatfile хранилище.
  • Интерактивный вьюер flatfile хранилища, типа веб-приложения или чего-то подобного.
    • Если прошло 20 лет, вьюер безнадежно устрел вместе с платформой, для которой предназначался, можно просто читать flatfile в любом блокноте.
  • Обратного преобразования flatfile -> интерактивный форум не предполагается.
x86128on May 07, 2018 ^1 ^2
Reply

Еще мне кажется большим плюсом flat-форума будет возможность делать приятные diff-ы и их читать, например с утюга. В виде digest-ов как раньше в USENET группах.

x86128on May 07, 2018 ^1 ^2
Reply

Если хранить на века, то вариант только один - текстовый формат. Поскольку его и через 60 лет прочитать можно будет спокойно. В первой строчке указать кодировку текста в кодировке ASCII, например как в питоне utf-8 , а дальше уже в бинарной utf-8 шарашить (как обычно).

Вообще предлагаю хранить в REN. Если с нуля делать то лучше в нем хранить. https://pointillistic.com/ren/ren-about.html

Просто, думаю, мешать данные с представлением это не очень хорошая идея, а markdown к этому подталкивает.

По поводу структуры - лучше хранить так как на форуме: Раздел/Подраздел/Топик.md причем дату создания файла заменить на дату создания топика, а дату модификации заменить датой последнего сообщения топика.

А по ночам, или чаще смотря как будет сделано и какой объем форума, строить индексы по типу как в dokuwiki сделано. Так даже получится backlink делать.

This page is a snapshot of ZeroNet. Start your own ZeroNet for complete experience. Learn More