diff --git a/docs/papers/hbs2-browser/intro.tex b/docs/papers/hbs2-browser/intro.tex index 2947c76d..9cac42fa 100644 --- a/docs/papers/hbs2-browser/intro.tex +++ b/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>>, и можно постепенно обогащать отображаемые метаданные +фактами, начиная с наиболее необходимых.