TODO: expose-all-new-rpc Вытащиь все новые RPC в библиотеку, так как нам нужны RefLogAPI и PeerAPI в клиенте TODO: detect-new-rpc-on-first-run первый раз при запуске пытаться обнаружить новый RPC если он не указан в конфиге. Предлагать записать его в конфиг (или просто писать его в конфиг?). TODO: local-config Смержить или заново сделать. Что бы конфиг брался из локального каталога. При генерации так же обновлять cookie для конфига. Таким образом, cookie станет идентификатором проекта, когда state станет общим для всех refs (скоро). TODO: save-objects-via-new-rpc Сохранять объекты через новый RPC. Удалить всё, что связано со старыми способами (HTTP, CLI) TODO: update-ref-via-new-rpc обновлять ссылку через новый RPC. TODO: git-group-key Указывать для ссылки (возможно, для git remote?) Перегенерировать, если ключ изменился. Кейс: изменения "в прошлом". Сейчас репо это сумма всех "логов", каждый "лог" - U(объектов из операции git push + установка ссылки). Соответственно, перегенерировать ключ **обязательно**, если авторы удалены из ключа. Если ключ перегенерировать время от времени, как планировалось, то возможна ситуация, когда нового автора в **старых** ключах не будет. И у него не будет доступа к каким-то "старым" объектам. А, в отличие от других примений, они ему нужны. Что делать? Даже если сгенерировать на каждый лог, где этот автор отсутствовал --- групповой ключ, то ссылка на него не будет доступна в старых сегмента, и при скачивании блоков, hbs2-git не будет знать, какой ключ использовать. TODO: support-metadata-in-git-log-tree Помещать метаданные в меркл-дерево журналов, при первом прогоне для каждой новой транзакции сначала обрабатывать метаданные, если они не обработаны, вторым проходом обрабатывать уже сами транзы. TODO: tools:generate-group-key-for-ref Добавить функцию генерации/перегенерации группового ключа по KeyInfo. 1. Ключ отсутствует 2. Ключ присутствует, KeyInfo expired 3. Ключ присутствует, KeyInfo не expired TODO: tools:list-group-keys Выводить имеющиеся ключи/шифрованные ссылки