mirror of https://github.com/voidlizard/hbs2
pep-03
This commit is contained in:
Dmitry Zuikov
parent
2a432d00d3
commit
4bc442ac6c
|
|
@ -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/**
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue