voidlizard
/
hbs2
mirror of https://github.com/voidlizard/hbs2
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

pep-03

This commit is contained in:
Dmitry Zuikov 2023-02-19 08:54:25 +03:00
parent 2a432d00d3
commit 4bc442ac6c
2 changed files with 77 additions and 67 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.fixme/config
View File

@ -4,11 +4,11 @@ fixme-comments --
fixme-prefix FIXME: bugs issues fixme-prefix FIXME: bugs issues
fixme-prefix TODO: bugs issues fixme-prefix TODO: bugs issues
fixme-prefix PEP: proposals
fixme-files **/*.hs docs/devlog.md fixme-files **/*.hs docs/devlog.md
fixme-files docs/pep*.txt fixme-files docs/pep*.txt
fixme-files docs/drafts/**/*.txt
fixme-files-ignore .direnv/** dist-newstyle/** fixme-files-ignore .direnv/** dist-newstyle/**

142
docs/drafts/pep-04.txt
View File

@ -4,7 +4,6 @@ PEP: pep-03-reference-update
$$$ (set lang ru) $$$ (set lang ru)
``` ```
Reference представляет собой адресуемую мутабельную Reference представляет собой адресуемую мутабельную
ссылку на контент. ссылку на контент.
@ -19,93 +18,104 @@ Reference представляет собой адресуемую мутабе
2. Со ссылкой ассоциируются владельцы/информация о списке тех, 2. Со ссылкой ассоциируются владельцы/информация о списке тех,
кто может читать данные по ссылке / писать данные по ссылке кто может читать данные по ссылке / писать данные по ссылке
3. Данные "ссылки" зависят от внешнего приложения и управляются 3. Пир должен знать, как обрабатывать операции над ссылкой, а именно
им Парсить, проверять полномочия
4. Пир (hbs2-peer) отвечает только за обновление списка обновлений 4. Пир должен уметь обрабатывать команды изменения полномочий
ссылки и нотификацию внешнего приложения
5. Внешнее приложение запоминает обработанные обновления и не
должно обрабатывать их дважды
6. Повторная обработка обновлений желательно, что бы приводила к
тому же самому результату (зависит от приложения)
Открытый вопрос: кто обновляет ACB? Это общий механизм и может быть Тезисы
обработан пиром, но что делать, если обновление ACB правильное, а ======
обновление контента - нет?
Логичным выглядит разделить команды обновления ссылки и обновления
ACB. Таким образом, команды обновления ACB можно реализовать отдельно
и позднее.
С другой стороны, ACB --- часть данных ссылки. Если обновились ACB, то
точно так же надо рассылать уведомления об изменении ссылки.
Со ссылкой ассоциирована следующая информация: 1. При создании ссылки устанавливается первоначальный ACB
2. При создании ссылки устанавливается список доступных для неё операций
3. Операции над ACB являются предопределенными
4. Остальные операции определяется типом ссылки
Структуры данных
================
``` ```
Ref:
[ reference ACB ;; ссылка на ACB
[acb-head] ; указатель на текущий ACB. каждый ACB ссылается на предыдущий acb Journal ;; ссылка на merkle tree текущего журнала операций
Head ;; ссылка на текущее (commited) состояние ссылки
[ref-hash] ; текущее значение ссылки для данного пира Proof ;; потенциально -- тип proof. Как его сделать расширяемым
(annotated merkle tree | blob) ;; пока что неизвестно, вероятно, это нечто, вычисляемое
;; из текущего состояния.
[ref-hash-prev] ; предыдущее значение ссылки ;; как оно вычисляется / в принципе может вычисляться пока не вполне
] ;; понятно, поэтому на текущий момент это проверка ACL:
;; хэш коммита >- принадлежит -> owners.
``` ```
Сама ссылка может являться как blob, так и annotated merkle tree (если
по какой-то причине мы хотим её зашифровывать, например, или указывать
какие-либо метаданные).
Команды протокола
Обновление ссылки
================= =================
RefAddOwner : (STATE,BLOB)
----------------------------
``` acl: root
[A] [B]
| announce-reference (co. hash) | добавить owner
+---------------------------------->| 1. check-acb
| | 2. update-acb (?)
| | 3. download references
| | 4. add-blob-to-list
| | 5. notify-external-app
| |
``` 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)
список ссылок пира или нет. ------------------------------------------------
Если нет - то ссылка добавляется в локальное хранилище, откуда может acl: зависит от PROOF-TYPE
быть позже извлечена.
Если да, то ссылка добавляется в merkle дерево публичных ссылок.
Если ссылка однократно была опубликована, и кто-то её уже скачал, то
скрыть её существование не получится.
Таким образом, мы можем повлиять только на анонсирование ссылки, но
не скрыть в принципе её существование. Если ссылка на что-то
является секретной, то лучше шифровать её метаданные или держать
её в закрытом рое (swarm) пиров, которые делятся информацией только
друг с другом. В любом случае шифровать, так как невозможно
застраховаться от утечки данных от ненадёжного участника роя.
Обработка команд протокола
==========================
TODO: journal-types-implementation