wip

docs/papers/hbs2-browser/intro.tex

@@ -1,11 +1,12 @@
+% vim: set textwidth=80:
 
 \chapter{Введение}
 
-Данный документ описывает цели, функции и дизайн компонента \term{hbs2-browser}{hbs2-browser},
-а также предпосылки к его разработке.
+Данный документ описывает цели, функции и дизайн компонента
+\term{hbs2-browser}{hbs2-browser}, а также предпосылки к его разработке.
 
-Основными единицами адресации в системе являются
-\term{block}{блок},  \term{mtree}{меркл-дерево}, \term{ref}{ссылка}.
+Основными единицами адресации в системе являются \term{block}{блок},
+\term{mtree}{меркл-дерево}, \term{ref}{ссылка}.
 
 \term{ref}{Ссылка} является изменяемым указателем на адресуемую единицу, обычно
 ассоциированная с публичным криптоключом.
@@ -14,99 +15,112 @@
 ссылку и в какой-то момент ссылок становится очень много, они рассеяны в разных
 источниках и крайне затруднительно их отслеживаеть.
 
-Таким образом, необходим некий иструмент просмотра этих ссылок и их метаданных
-и содержимого, без необходимости их запоминать. Аналогично тому,  как люди пользуются
-записными книжками в мобильных телефонах, не запоминая сами номера. Но если сколько-то
-номеров запомнить еще можно, то 256-битный публичный ключ подписи --- уже маловероятно.
+Таким образом, необходим некий иструмент просмотра этих ссылок и их метаданных и
+содержимого, без необходимости их запоминать. Аналогично тому,  как люди
+пользуются записными книжками в мобильных телефонах, не запоминая сами номера.
+Но если сколько-то номеров запомнить еще можно, то 256-битный публичный ключ
+подписи --- уже маловероятно.
 
-Таким образом, мы предлагаем инструмент, который возьмет на себя эту работу.
+Таким образом, мы предлагаем разработать инструмент, который возьмет на себя эту
+работу.
 
-Этим инструментом и предполагается \term{hbs2-browser}{hbs2-brower}.
+Назовём его \term{hbs2-browser}{hbs2-browser}.
 
 Следующим вопросом является --- делать ли отдельный браузер для каждого типа
 \term{ref}{ссылки}, или можно сделать какой-то общий инструмент.
 
-Отдельный браузер видится, на первый взгляд, более простым решением, но по факту в системе уже есть
-прецеденты, когда введение <<простых>> частных инструментов приводило к тому, что их приходилось
-практически клонировать это раз, а впоследствии удалять и заменять более общим решением, которое, не
-являясь значительно более сложным, было значительно более мощным и удобным.
+Отдельный браузер видится, на первый взгляд, более простым решением, но по факту
+в системе уже есть прецеденты, когда введение <<простых>> частных инструментов
+приводило к тому, что их приходилось практически клонировать это раз, а
+впоследствии удалять и заменять более общим решением, которое, не являясь
+значительно более сложным, было значительно более мощным и удобным.
 
-Задача \term{hbs2-brower}{hbs2-brower} может быть сформулирована так: брать данные из различных
-источников, соединять их, фильтровать и отображать в соответствии с заданными правилами.
+Задача \term{hbs2-browser}{hbs2-browser} может быть сформулирована так: брать
+данные из различных источников, соединять их, фильтровать и отображать в
+соответствии с заданными правилами.
 
-Следовательно, данные должны быть соединямыми, фильтруемыми и отображаемыми, но при этом,
-заведомо неизвестно какими (и видимо, это специфично для источника).
+Следовательно, данные должны быть соединямыми, фильтруемыми и отображаемыми, но
+при этом, заведомо неизвестно какими (и видимо, это специфично для источника).
 
-Тем не менее, известно множество примеров подобных данных и преобразований над ними: например, \[
-xml \xrightarrow{\text{xslt}} xml \], или любые данные в любые данные при помощи кода. Если браузер
-подразумевает текст или html, то, очевидно, конечное преобразование будет в них.
+Тем не менее, известно множество примеров подобных данных и преобразований над
+ними: например, \[ xml \xrightarrow{\text{xslt}} xml \], или любые данные в
+любые данные при помощи кода. Если браузер подразумевает текст или html, то,
+очевидно, конечное преобразование будет в них.
 
-Таким образом, что бы мы не просматривали, это должно иметь преобразование в упомянутые конечные
-форматы.
+Таким образом, что бы мы не просматривали, это должно иметь преобразование в
+упомянутые конечные форматы.
 
-Конечно, почти любые данные могут быть преобразованы в такой формат, но если он будет слишком
-специфичен, то \term{hbs2-brower}{hbs2-browser} придется о них знать --- это раз, и каждый инстанс
-\term{hbs2-brower}{hbs2-browser} должен будет выполнить работу по индексации самостоятельно, и
-прийти к результатам в зависимости от известных ему ссылок, так, что результаты для разных браузеров
-могут быть разные --- это два, индексация может быть довольно затратным процессом --- это три, для
-отображения нужны только отображаемые данные, а прочие не нужны --- это четыре.
+Конечно, почти любые данные могут быть преобразованы в такой формат, но если он
+будет слишком специфичен, то \term{hbs2-browser}{hbs2-browser} придется о них
+знать --- это раз, и каждый инстанс \term{hbs2-browser}{hbs2-browser} должен
+будет выполнить работу по индексации самостоятельно, и прийти к результатам в
+зависимости от известных ему ссылок, так, что результаты для разных браузеров
+могут быть разные --- это два, индексация может быть довольно затратным
+процессом --- это три, для отображения нужны только отображаемые данные, а
+прочие не нужны --- это четыре.
 
-Таким образом, для любого источника данных можно ввести источники метаданных, которые нужны для
-индексации и отображения. А так же стараться не проделывать повторно работу для построения
-метаданных из данных.
+Таким образом, для любого источника данных можно ввести источники метаданных,
+которые нужны для индексации и отображения. А так же стараться не проделывать
+повторно работу для построения метаданных из данных.
 
-Кажется, что при этом можно построить систему так, что бы различные её участники выполняли работу по
-индексации совместно, работа эта объединялась, при этом уже проделанная работа бы не делалась
-повторно.
+Кажется, что при этом можно построить систему так, что бы различные её участники
+выполняли работу по индексации совместно, работа эта объединялась, при этом уже
+проделанная работа бы не делалась повторно.
 
-Помимо некоторой оптимизации и масштабирования, данный подход выглядит и достаточно справедливым и
-децентрализованным, в отличие от подхода с \term{blockhain-explorer}{блокчейн-эксплорерами}, где они
-являются централизованными агентами и выполняют работу для всех участников сети, при этом становятся
-точкой отказа, но получают возможность манипулировать данными.
+Помимо некоторой оптимизации и масштабирования, данный подход выглядит и
+достаточно справедливым и децентрализованным, в отличие от подхода с
+\term{blockhain-explorer}{блокчейн-эксплорерами}, где они являются
+централизованными агентами и выполняют работу для всех участников сети, при этом
+становятся точкой отказа, но получают возможность манипулировать данными.
 
-Есть примеры сетей, где вместо данных сети приложения ориентируются на данные из этих эксплореров,
-что приводит к отказам, возможности цензуры и возможностям различных атак, что и происходило уже
-многократно, например, во всеми нами любимой многократно обосравшейся, но непотопляемой сети
-Ethereum.
+Есть примеры сетей, где вместо данных сети приложения ориентируются на данные из
+этих эксплореров, что приводит к отказам, возможности цензуры и возможностям
+различных атак, что и происходило уже многократно, например, во всеми нами
+любимой многократно обосравшейся, но непотопляемой сети Ethereum.
 
-Если мы решаем, что индексация контента будет происходить совместно, то появляются вопросы о степени
-доверия \term{oracle}{индексаторам} данных, или же \term{oracle}{оракулам}.
+Если мы решаем, что индексация контента будет происходить совместно, то
+появляются вопросы о степени доверия \term{oracle}{индексаторам} данных, или же
+\term{oracle}{оракулам}.
 
-Очевидно, что рано или поздно появятся вредоносные \term{oracle}{оракулы}, которые будут искажать
-картину в каких-то своих целях.
+Очевидно, что рано или поздно появятся вредоносные \term{oracle}{оракулы},
+которые будут искажать картину в каких-то своих целях.
 
 Таким образом, у нас должны быть механизмы для противодействия этому.
 
-Такие механизмы у нас есть: это \term{refchan}{рефчаны}. Рефчан это \term{gset}{CRDT G-Set}
-\term{transaction}{транзакций}, но с возможностью проверки прав публикации на основе ACL, как на
-уровне \term{peer}{пиров}, так и на уровне \term{author}{авторов}, а так же валидацией транзакций
-консенсусом онлайн.
+Такие механизмы у нас есть: это \term{refchan}{рефчаны}. Рефчан это
+\term{gset}{CRDT G-Set} \term{transaction}{транзакций}, но с возможностью
+проверки прав публикации на основе ACL, как на уровне \term{peer}{пиров}, так и
+на уровне \term{author}{авторов}, а так же валидацией транзакций консенсусом
+онлайн.
 
-Минимальным условием принятия \term{transaction}{транзакции} в \term{refchan}{рефчан} является
-наличие пира и автора в ACL рефчана, онлайн~валидация может быть подключена при желании.
+Минимальным условием принятия \term{transaction}{транзакции} в
+\term{refchan}{рефчан} является наличие пира и автора в ACL рефчана,
+онлайн~валидация может быть подключена при желании.
 
-В целом, кажется, что мы не хотим делать валидацию онлайн, вместо этого мы хотим сделать механизм
-проверки достоверности данных, и какие-то транзакции, которые отменяют/понижают достоверность для
-других транзакций. Это даст нам возможность оценивать пиров и авторов по достоверности публикуемых
-материалов, при этом не создавая большую нагрузку  по обработке запросов онлайн.
+В целом, кажется, что мы не хотим делать валидацию онлайн, вместо этого мы хотим
+сделать механизм проверки достоверности данных, и какие-то транзакции, которые
+отменяют/понижают достоверность для других транзакций. Это даст нам возможность
+оценивать пиров и авторов по достоверности публикуемых материалов, при этом не
+создавая большую нагрузку  по обработке запросов онлайн.
 
-Кажется, для онлайн-валидации достаточно будет проверить рейтинг пира. А при снижении рейтинга пира
---- в какой-то момент удалять его из ACL.
+Кажется, для онлайн-валидации достаточно будет проверить рейтинг пира. А при
+снижении рейтинга пира --- в какой-то момент удалять его из ACL.
 
-Стоит и остановиться на самих метаданных. Предыдущий опыт показывает провальность попыток дизайна
-сверху вниз, когда мы заранее  определяем все возможные структуры данных.
+Стоит и остановиться на самих метаданных. Предыдущий опыт показывает
+провальность попыток дизайна сверху вниз, когда мы заранее  определяем все
+возможные структуры данных.
 
-Тут мы во первых, понятия не имеем, какие структуры возникнут с течением времени, во вторых даже для
-имеющихся форматов, например, git, возможных метанных может быть больше, чем мы в состоянии сделать
-и даже описать.
+Тут мы во первых, понятия не имеем, какие структуры возникнут с течением
+времени, во вторых даже для имеющихся форматов, например, git, возможных
+метанных может быть больше, чем мы в состоянии сделать и даже описать.
 
-Следовательно, будем рассматривать это всё как заведомо неизвестную предметную область, и применять
-подход <<снизу вверх>> --- то есть, стараться брать как можно более атомарные факты, и делать
-возможным их соединение и группировку, а так же добавлять потом факты, которые соединяют и
-группируют другие факты.
+Следовательно, будем рассматривать это всё как заведомо неизвестную предметную
+область, и применять подход <<снизу вверх>> --- то есть, стараться брать как
+можно более атомарные факты, и делать возможным их соединение и группировку, а
+так же добавлять потом факты, которые соединяют и группируют другие факты.
 
-Допустим, на примере git. Для начала мы хотим просто дать возможность просмотра ссылок, которые
-являются репозиториями git. Для этого нам надо:
+Допустим, на примере git. Для начала мы хотим просто дать возможность просмотра
+ссылок, которые являются репозиториями git. Для этого нам надо:
 
 \begin{enumerate}
   \item Найти все ссылки типа \term{lwwref}{lwwref}
@@ -115,31 +129,33 @@ Ethereum.
         актуальную транзакцию, являющуюся \term{repohead}{головой репозитория}
 \end{enumerate}
 
-Найдя такую транзакцию, мы можем констатировать, что данный \term{lwwref}{lwwref} является
-репозиторием git, или по крайней мере являлся им, и содержит \term{repohead}{голову} с данным
-\term{manifest}{манифестом} и ссылками git.
+Найдя такую транзакцию, мы можем констатировать, что данный
+\term{lwwref}{lwwref} является репозиторием git, или по крайней мере являлся им,
+и содержит \term{repohead}{голову} с данным \term{manifest}{манифестом} и
+ссылками git.
 
-Некоторые из этих фактов могут, кажется, быть разбиты на еще более атомарные факты. Но в итоге мы
-можем их объединить, и сделать вывод  о репозитории git, при этом получив все данные, необходимые
-для его отображения.
+Некоторые из этих фактов могут, кажется, быть разбиты на еще более атомарные
+факты. Но в итоге мы можем их объединить, и сделать вывод  о репозитории git,
+при этом получив все данные, необходимые для его отображения.
 
-Также, кажется что большинство из таких фактов будут иммутабельны и многие достаточно будет извлечь
-один раз.
+Также, кажется что большинство из таких фактов будут иммутабельны и многие
+достаточно будет извлечь один раз.
 
-Далее, мы хотим добавить какой-то более интересный факт, например, автора, что бы иметь возможность
-выводить список авторов.
+Далее, мы хотим добавить какой-то более интересный факт, например, автора, что
+бы иметь возможность выводить список авторов.
 
-Мы можем считать \term{author}{автором} различные вещи, например, это может быть ключ рефлога
-форка репозитория. Тогда, что бы извлечь что-то полезное, например, имя --- нам бы надо иметь
-\term{sigil}{<<сигил>>}, который есть подписанный публичным ключом ключ шифрования и метаданные,
-например имя и email.
+Мы можем считать \term{author}{автором} различные вещи, например, это может быть
+ключ рефлога форка репозитория. Тогда, что бы извлечь что-то полезное, например,
+имя --- нам бы надо иметь \term{sigil}{<<сигил>>}, который есть подписанный
+публичным ключом ключ шифрования и метаданные, например имя и email.
 
-Такой \term{sigil}{<<сигил>>} тоже можно рассматривать, как факт, с которым можно соединить
-прочие факты, по публичному ключу, который мы берём из факта о том, что есть рефлог для
-\term{lwwref}{lwwref}, который является репозиторием. Таким образом, мы можем сделать вывод
-об авторстве.
+Такой \term{sigil}{<<сигил>>} тоже можно рассматривать, как факт, с которым
+можно соединить прочие факты, по публичному ключу, который мы берём из факта о
+том, что есть рефлог для \term{lwwref}{lwwref}, который является репозиторием.
+Таким образом, мы можем сделать вывод об авторстве.
 
-С другой стороны, мы можем считать <<автором>> то, что пишет git в информации о коммите, как-то:
+С другой стороны, мы можем считать <<автором>> то, что пишет git в информации о
+коммите, как-то:
 
 \begin{verbatim}
 commit 0cf82db731a6c30a81bc4d46fd43f30fc266e060 (HEAD -> dev-0.24.2)
@@ -149,21 +165,22 @@ Date:   Thu Mar 21 10:25:27 2024 +0300
     hbs2-git-oracle: the beginning
 \end{verbatim}
 
+мы, кстати, можем эти два факта тоже попытаться соединить по адресу электронной
+почты, но это выглядит, как плохая практика сразу по многим причинам.
 
-мы, кстати, можем эти два факта тоже попытаться соединить по адресу
-электронной почты, но это выглядит, как плохая практика сразу по многим причинам.
+Тем не менее, если мы пошлём на электронную почту некоторое секретное сообщение,
+и владелец адреса подпишет это сообщение своим приватным ключом, например, тем,
+что от рефлога --- мы можем установить связь электронной почты с рефлогом, и
+далее соединять коммитеров из лога гита с авторами рефлогов.
 
-Тем не менее, если мы пошлём на электронную почту некоторое секретное сообщение, и владелец адреса
-подпишет это сообщение своим приватным ключом, например, тем, что от рефлога --- мы можем установить
-связь электронной почты с рефлогом, и далее соединять коммитеров из лога гита с авторами рефлогов.
-
-Этим может заниматься какой-то специальный оракул, но в целом, проще добавить некое подписанное
-сообщение в коммит гита.
+Этим может заниматься какой-то специальный оракул, но в целом, проще добавить
+некое подписанное сообщение в коммит гита.
 
 Теоретически, можно попробовать даже использовать стандартные механизмы подписи.
 
-Таким образом, мы показываем, что можно добавить сначала один факт --- <<ссылка является
-репозиторием>>, а дальше добавить другой факт <<автор для данного репозитория --- X>>, и можно
-постепенно обогащать отображаемые метаданные фактами, начиная с наиболее необходимых.
+Таким образом, мы показываем, что можно добавить сначала один факт --- <<ссылка
+является репозиторием>>, а дальше добавить другой факт <<автор для данного
+репозитория --- X>>, и можно постепенно обогащать отображаемые метаданные
+фактами, начиная с наиболее необходимых.