From 4bc442ac6c606846dd06b6370b3509bf717c1167 Mon Sep 17 00:00:00 2001 From: Dmitry Zuikov Date: Sun, 19 Feb 2023 08:54:25 +0300 Subject: [PATCH] pep-03 --- .fixme/config | 2 +- docs/drafts/pep-04.txt | 142 ++++++++++++++++++++++------------------- 2 files changed, 77 insertions(+), 67 deletions(-) diff --git a/.fixme/config b/.fixme/config index a3952eee..497dcd06 100644 --- a/.fixme/config +++ b/.fixme/config @@ -4,11 +4,11 @@ fixme-comments -- fixme-prefix FIXME: bugs issues fixme-prefix TODO: bugs issues -fixme-prefix PEP: proposals fixme-files **/*.hs docs/devlog.md fixme-files docs/pep*.txt +fixme-files docs/drafts/**/*.txt fixme-files-ignore .direnv/** dist-newstyle/** diff --git a/docs/drafts/pep-04.txt b/docs/drafts/pep-04.txt index c6383e9b..905b8957 100644 --- a/docs/drafts/pep-04.txt +++ b/docs/drafts/pep-04.txt @@ -4,7 +4,6 @@ PEP: pep-03-reference-update $$$ (set lang ru) ``` - Reference представляет собой адресуемую мутабельную ссылку на контент. @@ -19,93 +18,104 @@ Reference представляет собой адресуемую мутабе 2. Со ссылкой ассоциируются владельцы/информация о списке тех, кто может читать данные по ссылке / писать данные по ссылке - 3. Данные "ссылки" зависят от внешнего приложения и управляются - им + 3. Пир должен знать, как обрабатывать операции над ссылкой, а именно + Парсить, проверять полномочия - 4. Пир (hbs2-peer) отвечает только за обновление списка обновлений - ссылки и нотификацию внешнего приложения - - 5. Внешнее приложение запоминает обработанные обновления и не - должно обрабатывать их дважды - - 6. Повторная обработка обновлений желательно, что бы приводила к - тому же самому результату (зависит от приложения) + 4. Пир должен уметь обрабатывать команды изменения полномочий -Открытый вопрос: кто обновляет ACB? Это общий механизм и может быть -обработан пиром, но что делать, если обновление ACB правильное, а -обновление контента - нет? - -Логичным выглядит разделить команды обновления ссылки и обновления -ACB. Таким образом, команды обновления ACB можно реализовать отдельно -и позднее. - -С другой стороны, ACB --- часть данных ссылки. Если обновились ACB, то -точно так же надо рассылать уведомления об изменении ссылки. +Тезисы +====== -Со ссылкой ассоциирована следующая информация: + 1. При создании ссылки устанавливается первоначальный ACB + 2. При создании ссылки устанавливается список доступных для неё операций + 3. Операции над ACB являются предопределенными + 4. Остальные операции определяется типом ссылки + + +Структуры данных +================ + ``` - - [ reference - [acb-head] ; указатель на текущий ACB. каждый ACB ссылается на предыдущий acb - - [ref-hash] ; текущее значение ссылки для данного пира - (annotated merkle tree | blob) - - [ref-hash-prev] ; предыдущее значение ссылки - ] +Ref: + ACB ;; ссылка на ACB + Journal ;; ссылка на merkle tree текущего журнала операций + Head ;; ссылка на текущее (commited) состояние ссылки + Proof ;; потенциально -- тип proof. Как его сделать расширяемым + ;; пока что неизвестно, вероятно, это нечто, вычисляемое + ;; из текущего состояния. + ;; как оно вычисляется / в принципе может вычисляться пока не вполне + ;; понятно, поэтому на текущий момент это проверка ACL: + ;; хэш коммита >- принадлежит -> owners. ``` -Сама ссылка может являться как blob, так и annotated merkle tree (если -по какой-то причине мы хотим её зашифровывать, например, или указывать -какие-либо метаданные). - -Обновление ссылки +Команды протокола ================= +RefAddOwner : (STATE,BLOB) +---------------------------- -``` - [A] [B] - | announce-reference (co. hash) | - +---------------------------------->| 1. check-acb - | | 2. update-acb (?) - | | 3. download references - | | 4. add-blob-to-list - | | 5. notify-external-app - | | +acl: root + +добавить owner -``` +RefDelOwner : (STATE, BLOB) +---------------------------- + +acl: root + +удалить owner + +RefAddWriter : (STATE, BLOB) +---------------------------- + +acl: owner + +добавить writer + +RefDelWriter : (STATE, BLOB) +---------------------------- + +acl: owner + +удалить writer -Получение списка ссылок пира -============================ +RefAddReader : (STATE, BLOB) +---------------------------- -Публичные ссылки пира представляют собой файл -со списком хэшей ссылок (возможно, с описанием). +acl: owner + +добавить reader + +RefDelReader : (STATE, BLOB) +---------------------------- + +acl: owner + +удалить reader + +RefUpdateState : (STATE, OP, ARGS*) +----------------------------------- + +acl: writer -При создании ссылок пользователь указывает, добавляется эта ссылка в -список ссылок пира или нет. +RefCommit : (STATE, NEW-STATE, PROOF:PROOF-TYPE) +------------------------------------------------ -Если нет - то ссылка добавляется в локальное хранилище, откуда может -быть позже извлечена. - -Если да, то ссылка добавляется в merkle дерево публичных ссылок. - -Если ссылка однократно была опубликована, и кто-то её уже скачал, то -скрыть её существование не получится. - -Таким образом, мы можем повлиять только на анонсирование ссылки, но -не скрыть в принципе её существование. Если ссылка на что-то -является секретной, то лучше шифровать её метаданные или держать -её в закрытом рое (swarm) пиров, которые делятся информацией только -друг с другом. В любом случае шифровать, так как невозможно -застраховаться от утечки данных от ненадёжного участника роя. +acl: зависит от PROOF-TYPE +Обработка команд протокола +========================== + + +TODO: journal-types-implementation +