reference pep draft

2023-02-17 08:53:43 +03:00 · 2023-02-17 08:53:43 +03:00 · c1054b744d
parent 809a78e49a
commit c1054b744d
1 changed files with 111 additions and 0 deletions
--- a/docs/drafts/pep-04.txt
+++ b/docs/drafts/pep-04.txt
@ -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) пиров, которые делятся информацией только
+друг с другом. В любом случае шифровать, так как невозможно
+застраховаться от утечки данных от ненадёжного участника роя.
+
+