hbs2/docs/papers/hbs2-browser/intro.tex

\chapter{Введение}

Данный документ описывает цели, функции и дизайн компонента \term{hbs2-browser}{hbs2-browser},
а также предпосылки к его разработке.

Основными единицами адресации в системе являются
\term{block}{блок},  \term{mtree}{меркл-дерево}, \term{ref}{ссылка}.

\term{ref}{Ссылка} является изменяемым указателем на адресуемую единицу, обычно
ассоциированная с публичным криптоключом.

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

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

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

Этим инструментом и предполагается \term{hbs2-browser}{hbs2-brower}.

Следующим вопросом является --- делать ли отдельный браузер для каждого типа
\term{ref}{ссылки}, или можно сделать какой-то общий инструмент.

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

Задача \term{hbs2-brower}{hbs2-brower} может быть сформулирована так: брать данные из различных
источников, соединять их, фильтровать и отображать в соответствии с заданными правилами.

Следовательно, данные должны быть соединямыми, фильтруемыми и отображаемыми, но при этом,
заведомо неизвестно какими (и видимо, это специфично для источника).

Тем не менее, известно множество примеров подобных данных и преобразований над ними: например, \[
xml \xrightarrow{\text{xslt}} xml \], или любые данные в любые данные при помощи кода. Если браузер
подразумевает текст или html, то, очевидно, конечное преобразование будет в них.

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

Конечно, почти любые данные могут быть преобразованы в такой формат, но если он будет слишком
специфичен, то \term{hbs2-brower}{hbs2-browser} придется о них знать --- это раз, и каждый инстанс
\term{hbs2-brower}{hbs2-browser} должен будет выполнить работу по индексации самостоятельно, и
прийти к результатам в зависимости от известных ему ссылок, так, что результаты для разных браузеров
могут быть разные --- это два, индексация может быть довольно затратным процессом --- это три, для
отображения нужны только отображаемые данные, а прочие не нужны --- это четыре.

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

Кажется, что при этом можно построить систему так, что бы различные её участники выполняли работу по
индексации совместно, работа эта объединялась, при этом уже проделанная работа бы не делалась
повторно.

Помимо некоторой оптимизации и масштабирования, данный подход выглядит и достаточно справедливым и
децентрализованным, в отличие от подхода с \term{blockhain-explorer}{блокчейн-эксплорерами}, где они
являются централизованными агентами и выполняют работу для всех участников сети, при этом становятся
точкой отказа, но получают возможность манипулировать данными.

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

Если мы решаем, что индексация контента будет происходить совместно, то появляются вопросы о степени
доверия \term{oracle}{индексаторам} данных, или же \term{oracle}{оракулам}.

Очевидно, что рано или поздно появятся вредоносные \term{oracle}{оракулы}, которые будут искажать
картину в каких-то своих целях.

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

Такие механизмы у нас есть: это \term{refchan}{рефчаны}. Рефчан это \term{gset}{CRDT G-Set}
\term{transaction}{транзакций}, но с возможностью проверки прав публикации на основе ACL, как на
уровне \term{peer}{пиров}, так и на уровне \term{author}{авторов}, а так же валидацией транзакций
консенсусом онлайн.

Минимальным условием принятия \term{transaction}{транзакции} в \term{refchan}{рефчан} является
наличие пира и автора в ACL рефчана, онлайн~валидация может быть подключена при желании.

В целом, кажется, что мы не хотим делать валидацию онлайн, вместо этого мы хотим сделать механизм
проверки достоверности данных, и какие-то транзакции, которые отменяют/понижают достоверность для
других транзакций. Это даст нам возможность оценивать пиров и авторов по достоверности публикуемых
материалов, при этом не создавая большую нагрузку  по обработке запросов онлайн.

Кажется, для онлайн-валидации достаточно будет проверить рейтинг пира. А при снижении рейтинга пира
--- в какой-то момент удалять его из ACL.

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

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

Следовательно, будем рассматривать это всё как заведомо неизвестную предметную область, и применять
подход <<снизу вверх>> --- то есть, стараться брать как можно более атомарные факты, и делать
возможным их соединение и группировку, а так же добавлять потом факты, которые соединяют и
группируют другие факты.

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

\begin{enumerate}
  \item Найти все ссылки типа \term{lwwref}{lwwref}
  \item Найти рефлоги для таких ссылок
  \item Для каждого такого рефлога --- найти самую
        актуальную транзакцию, являющуюся \term{repohead}{головой репозитория}
\end{enumerate}

Найдя такую транзакцию, мы можем констатировать, что данный \term{lwwref}{lwwref} является
репозиторием git, или по крайней мере являлся им, и содержит \term{repohead}{голову} с данным
\term{manifest}{манифестом} и ссылками git.

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

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

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

Мы можем считать \term{author}{автором} различные вещи, например, это может быть ключ рефлога
форка репозитория. Тогда, что бы извлечь что-то полезное, например, имя --- нам бы надо иметь
\term{sigil}{<<сигил>>}, который есть подписанный публичным ключом ключ шифрования и метаданные,
например имя и email.

Такой \term{sigil}{<<сигил>>} тоже можно рассматривать, как факт, с которым можно соединить
прочие факты, по публичному ключу, который мы берём из факта о том, что есть рефлог для
\term{lwwref}{lwwref}, который является репозиторием. Таким образом, мы можем сделать вывод
об авторстве.

С другой стороны, мы можем считать <<автором>> то, что пишет git в информации о коммите, как-то:

\begin{verbatim}
commit 0cf82db731a6c30a81bc4d46fd43f30fc266e060 (HEAD -> dev-0.24.2)
Author: Dmitry Zuikov <dzuikov@gmail.com>
Date:   Thu Mar 21 10:25:27 2024 +0300

    hbs2-git-oracle: the beginning
\end{verbatim}


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

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

Этим может заниматься какой-то специальный оракул, но в целом, проще добавить некое подписанное
сообщение в коммит гита.

Теоретически, можно попробовать даже использовать стандартные механизмы подписи.

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