From c72f0d73d49a7781ecacd2d996fed0f0c097efbe Mon Sep 17 00:00:00 2001 From: Dmitry Zuikov Date: Thu, 21 Mar 2024 13:38:03 +0300 Subject: [PATCH] wip --- docs/papers/hbs2-browser/intro.tex | 169 +++++++++++++++++++++++++++++ 1 file changed, 169 insertions(+) create mode 100644 docs/papers/hbs2-browser/intro.tex diff --git a/docs/papers/hbs2-browser/intro.tex b/docs/papers/hbs2-browser/intro.tex new file mode 100644 index 00000000..2947c76d --- /dev/null +++ b/docs/papers/hbs2-browser/intro.tex @@ -0,0 +1,169 @@ + +\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 +Date: Thu Mar 21 10:25:27 2024 +0300 + + hbs2-git-oracle: the beginning +\end{verbatim} + + +мы, кстати, можем эти два факта тоже попытаться соединить по адресу +электронной почты, но это выглядит, как плохая практика сразу по многим причинам. + +Тем не менее, если мы пошлём на электронную почту некоторое секретное сообщение, и владелец адреса +подпишет это сообщение своим приватным ключом, например, тем, что от рефлога --- мы можем установить +связь электронной почты с рефлогом, и далее соединять коммитеров из лога гита с авторами рефлогов. + +Этим может заниматься какой-то специальный оракул, но в целом, проще добавить некое подписанное +сообщение в коммит гита. + +Теоретически, можно попробовать даже использовать стандартные механизмы подписи. + +Таким образом, мы показываем, что можно добавить сначала один факт --- <<ссылка является +репозиторием>>, а дальше добавить другой факт <<автор для данного репозитория --- X>>, и можно +постепенно обогащать отображаемые метаданные фактами, начиная с наиболее необходимых. + +