mirror of https://github.com/voidlizard/hbs2
reference pep draft
This commit is contained in:
parent
809a78e49a
commit
c1054b744d
|
@ -0,0 +1,111 @@
|
||||||
|
PEP: pep-03-reference-update
|
||||||
|
|
||||||
|
```
|
||||||
|
$$ (set lang ru)
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
Reference представляет собой адресуемую мутабельную
|
||||||
|
ссылку на контент.
|
||||||
|
|
||||||
|
Предпосылки
|
||||||
|
===========
|
||||||
|
|
||||||
|
|
||||||
|
1. Ссылка (Reference) представляет собой единицу адресации "потока"
|
||||||
|
блоков (топики, чаты, блокчейны, статический файл с обновлениями
|
||||||
|
и так далее)
|
||||||
|
|
||||||
|
2. Со ссылкой ассоциируются владельцы/информация о списке тех,
|
||||||
|
кто может читать данные по ссылке / писать данные по ссылке
|
||||||
|
|
||||||
|
3. Данные "ссылки" зависят от внешнего приложения и управляются
|
||||||
|
им
|
||||||
|
|
||||||
|
4. Пир (hbs2-peer) отвечает только за обновление списка обновлений
|
||||||
|
ссылки и нотификацию внешнего приложения
|
||||||
|
|
||||||
|
5. Внешнее приложение запоминает обработанные обновления и не
|
||||||
|
должно обрабатывать их дважды
|
||||||
|
|
||||||
|
6. Повторная обработка обновлений желательно, что бы приводила к
|
||||||
|
тому же самому результату (зависит от приложения)
|
||||||
|
|
||||||
|
|
||||||
|
Открытый вопрос: кто обновляет ACB? Это общий механизм и может быть
|
||||||
|
обработан пиром, но что делать, если обновление ACB правильное, а
|
||||||
|
обновление контента - нет?
|
||||||
|
|
||||||
|
Логичным выглядит разделить команды обновления ссылки и обновления
|
||||||
|
ACB. Таким образом, команды обновления ACB можно реализовать отдельно
|
||||||
|
и позднее.
|
||||||
|
|
||||||
|
С другой стороны, ACB --- часть данных ссылки. Если обновились ACB, то
|
||||||
|
точно так же надо рассылать уведомления об изменении ссылки.
|
||||||
|
|
||||||
|
|
||||||
|
Со ссылкой ассоциирована следующая информация:
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
[ reference
|
||||||
|
[acb-head] ; указатель на текущий ACB. каждый ACB ссылается на предыдущий acb
|
||||||
|
|
||||||
|
[ref-hash] ; текущее значение ссылки для данного пира
|
||||||
|
(annotated merkle tree | blob)
|
||||||
|
|
||||||
|
[ref-hash-prev] ; предыдущее значение ссылки
|
||||||
|
]
|
||||||
|
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
Сама ссылка может являться как blob, так и annotated merkle tree (если
|
||||||
|
по какой-то причине мы хотим её зашифровывать, например, или указывать
|
||||||
|
какие-либо метаданные).
|
||||||
|
|
||||||
|
|
||||||
|
Обновление ссылки
|
||||||
|
=================
|
||||||
|
|
||||||
|
|
||||||
|
```
|
||||||
|
[A] [B]
|
||||||
|
| announce-reference (co. hash) |
|
||||||
|
+---------------------------------->| 1. check-acb
|
||||||
|
| | 2. update-acb (?)
|
||||||
|
| | 3. download references
|
||||||
|
| | 4. add-blob-to-list
|
||||||
|
| | 5. notify-external-app
|
||||||
|
| |
|
||||||
|
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
Получение списка ссылок пира
|
||||||
|
============================
|
||||||
|
|
||||||
|
Публичные ссылки пира представляют собой файл
|
||||||
|
со списком хэшей ссылок (возможно, с описанием).
|
||||||
|
|
||||||
|
|
||||||
|
При создании ссылок пользователь указывает, добавляется эта ссылка в
|
||||||
|
список ссылок пира или нет.
|
||||||
|
|
||||||
|
Если нет - то ссылка добавляется в локальное хранилище, откуда может
|
||||||
|
быть позже извлечена.
|
||||||
|
|
||||||
|
Если да, то ссылка добавляется в merkle дерево публичных ссылок.
|
||||||
|
|
||||||
|
Если ссылка однократно была опубликована, и кто-то её уже скачал, то
|
||||||
|
скрыть её существование не получится.
|
||||||
|
|
||||||
|
Таким образом, мы можем повлиять только на анонсирование ссылки, но
|
||||||
|
не скрыть в принципе её существование. Если ссылка на что-то
|
||||||
|
является секретной, то лучше шифровать её метаданные или держать
|
||||||
|
её в закрытом рое (swarm) пиров, которые делятся информацией только
|
||||||
|
друг с другом. В любом случае шифровать, так как невозможно
|
||||||
|
застраховаться от утечки данных от ненадёжного участника роя.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue