mirror of https://github.com/voidlizard/hbs2
112 lines
5.0 KiB
Plaintext
112 lines
5.0 KiB
Plaintext
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) пиров, которые делятся информацией только
|
||
друг с другом. В любом случае шифровать, так как невозможно
|
||
застраховаться от утечки данных от ненадёжного участника роя.
|
||
|
||
|