--- url: /ru/getting-started/introduction.md --- # Rabbithole — зашифрованное децентрализованное хранилище под вашим контролем Rabbithole — файловое хранилище для тех, кому нужен привычный облачный диск, но без центрального владельца, которому приходится доверять файлы, права доступа и ключи шифрования. В обычном облаке ваши файлы, серверная логика, интерфейс и правила доступа живут в инфраструктуре оператора. Rabbithole устроен иначе: для вашего аккаунта создаётся отдельное хранилище на [Internet Computer](https://internetcomputer.org/), с собственным веб-интерфейсом, кодом, состоянием и правилами доступа. Internet Computer важен здесь не как модное слово про блокчейн. Это сеть, где приложение может работать целиком: фронтенд, серверная часть, состояние и пользовательские хранилища не нужно выносить в обычное облако. Благодаря этому Rabbithole создаёт для вас не просто запись в базе данных, а отдельную канистру хранилища, контроль над которой передаётся вам. [Канистру](https://docs.internetcomputer.org/concepts/canisters/) можно воспринимать как смарт-контрактное приложение: у неё есть код, состояние и собственный ресурсный баланс. В Rabbithole такая канистра хранит записи о файлах, права доступа и, в зависимости от режима хранения, сами байты файлов. Файл шифруется прямо в браузере, ещё до загрузки. Открытые данные не отправляются в серверную часть хранилища, а ключи не выводятся из пароля и не хранятся как мастер-ключ у Rabbithole. Технические страницы позже объясняют [vetKeys](https://docs.internetcomputer.org/concepts/vetkeys/) и способы хранения; для старта важно главное: контроль над хранилищем и криптография заложены в архитектуру, а не держатся только на обещании сервиса. Если термины Internet Computer пока незнакомы, начните со страницы [Основные понятия](/ru/getting-started/concepts.md). ## Как это работает за 30 секунд ```mermaid flowchart LR subgraph YB["Ваш браузер"] A[Ваш файл] --> B[Разбивка на фрагменты] B --> C[Локальное шифрование] end subgraph BC["Internet Computer"] C --> D[Ваша персональная канистра] end style YB fill:#f0f9ff,stroke:#0284c7 style BC fill:#dcfce7,stroke:#16a34a style C fill:#6c63ff,color:#fff style D fill:#22c55e,color:#fff ``` 1. Вы входите через [Internet Identity](https://id.ai), без отдельного пароля Rabbithole. 2. Rabbithole создаёт независимую канистру хранилища для вашего аккаунта. 3. Вы загружаете файлы через приложение. 4. Браузер шифрует файл до загрузки. 5. При скачивании браузер проверяет и расшифровывает файл локально. ## Ключевая идея Большинство облачных хранилищ просит поверить обещанию оператора: что он защитит серверную часть, правильно применит права доступа, сохранит сервис живым и не раскроет ваши файлы или ключи. Rabbithole старается перенести больше этого доверия в архитектуру. Владение хранилищем выражается через контроль над канистрой. Правила доступа живут вместе с канистрой хранилища. Файлы шифруются в браузере, а ключи выводятся сетью, а не из мастер-ключа, который Rabbithole хранит у себя. Это не магия и не отмена всех допущений. Ваш браузер, протокол Internet Computer и код Rabbithole всё ещё важны. Но центр тяжести меняется: продукт меньше опирается на “поверьте нам” и больше — на границы протокола, владение канистрой и криптографию. ## Как сюда вписываются vetKeys Представьте сейф, у которого нет одного главного ключа. Для каждого файла Rabbithole просит сеть вывести файловый ключ через [vetKeys](https://docs.internetcomputer.org/concepts/vetkeys/): каждый vetKD-узел выдаёт только свою часть, а полный ключ собирается уже в вашем браузере. Один узел не может открыть сейф сам и не видит полный ключ. Standard и High Replication — продуктовые названия двух уровней VetKey в Rabbithole. Числа узлов относятся к сервису ключей, а не к копиям файла. Если нужны детали, читайте [Ключи и vetKeys](/ru/how-it-works/encryption/vetkeys.md). ## Сравнение с конкурентами | Сервис | E2E шифрование | Zero-Knowledge | Открытый код | Децентрализация | Вы владеете инфраструктурой | Деривация ключей | | -------------- | :------------: | :------------: | :----------: | :-------------: | :-------------------------: | ------------------------------------ | | Google Drive | — | — | — | — | — | Ключи компании | | Dropbox | — | — | — | — | — | Ключи компании | | Tresorit | Да | Да | — | — | — | Из пароля | | ProtonDrive | Да | Да | Частично | — | — | Из пароля | | Internxt | Да | Да | Да | — | — | Из пароля | | Filen | Да | Да | Частично | — | — | Из пароля | | Storj | Да | Да | Да | Да | — | На клиенте | | **Rabbithole** | **Да** | **Да** | **Да** | **Да** | **Да** | **Пороговая криптография (vetKeys)** | **Чем Rabbithole отличается:** - **Нет паролей для деривации ключей** — ваш ключ вычисляется из вашей [Internet Identity](https://id.ai) самой сетью - **Персональная канистра** — вы владеете смарт-контрактом, где хранятся ваши данные. После успешной передачи контроля Rabbithole удаляет себя из контроллеров - **Проверяемая реализация** — код [открыт](https://github.com/rabbithole-app/v2), шифрование работает в вашем браузере, а деривация ключей обеспечивается консенсусом IC Открытый текст не загружается в канистру или Blob Storage. Rabbithole всё равно полагается на ваш браузер, консенсус IC и корректный код. Эти допущения перечислены на странице [Модель доверия](/ru/how-it-works/trust-model.md). :::tip\{title="Хотите подробнее?"} - [Основные понятия](/ru/getting-started/concepts.md) — канистры, principal, контроллеры, циклы и vetKeys - [Как работает шифрование](/ru/how-it-works/encryption/index.md) — пользовательская модель приватности - [Ключи и vetKeys](/ru/how-it-works/encryption/vetkeys.md) — Standard, High Replication и деривация ключей - [Суверенитет данных](/ru/how-it-works/sovereignty/index.md) — создание канистры, передача контроля, что если Rabbithole исчезнет - [Модель доверия](/ru/how-it-works/trust-model.md) — модель угроз, чему нужно и не нужно доверять ::: --- url: /ru/getting-started/concepts.md --- # Основные понятия Эти термины пришли из Internet Computer, а не из брендинга Rabbithole. Rabbithole использует их в продуктовой документации, поэтому эта страница показывает, как термины платформы связаны с частями приложения. Канонические определения смотрите в [глоссарии Internet Computer](https://docs.internetcomputer.org/references/glossary/). ## Internet Computer [Internet Computer](https://internetcomputer.org/) — децентрализованная сеть для приложений, которые работают прямо on-chain. В отличие от блокчейнов, которые в основном используются как расчётный слой, Internet Computer может размещать серверную логику, состояние и веб-доступные канистры в одной среде. Rabbithole использует её как слой для всего продукта: фронтенда основного приложения, основной серверной канистры, канистр хранилища, которые создаются для пользователей, и хранения или перемещения пользовательских средств из других сетей через [Chain Fusion](https://docs.internetcomputer.org/concepts/chain-fusion/). ## Канистра [Канистра](https://docs.internetcomputer.org/concepts/canisters/) — это смарт-контрактная единица Internet Computer. Она объединяет код и состояние, работает в сети и доступна через интернет. В архитектуре Rabbithole основная серверная часть — это канистра. Каждое пользовательское хранилище тоже является канистрой. Канистра хранилища содержит записи о файлах, права доступа и, в зависимости от режима хранения, байты файлов. ## Principal [Principal](https://docs.internetcomputer.org/concepts/principals/) — это IC-идентификатор того, кто может вызывать канистры. Он может представлять пользователя, другую канистру или анонимного вызывающего. В документации Rabbithole чаще всего имеется в виду пользовательский principal: идентификатор, через который вы владеете хранилищем, вызываете канистры и получаете права доступа. ## Internet Identity [Internet Identity](https://id.ai) — встроенная система аутентификации Internet Computer. Она позволяет входить через ключи доступа (passkeys) или поддерживаемые OpenID-аккаунты без отдельного пароля Rabbithole. Для одного и того же пользователя Internet Identity выдаёт отдельный principal для каждого веб-адреса приложения. Это помогает приложениям не связывать ваши аккаунты через один глобальный идентификатор. В Rabbithole этот слой идентичности используется браузером, чтобы вызывать канистры, владеть хранилищем и запрашивать доступ к зашифрованным файлам. Технические детали описаны в [гайде Internet Identity](https://docs.internetcomputer.org/guides/authentication/internet-identity/). ## Контроллер Контроллер имеет административные права над канистрой. Контроллер может обновить код канистры, изменить настройки или удалить канистру. Для хранилища Rabbithole это важно во время настройки и обновлений. Rabbithole может временно нуждаться в правах контроллера, пока создаёт или обновляет вашу канистру хранилища. После успешной передачи контроля целевое состояние такое: канистрой управляете вы. ## Циклы [Циклы](https://docs.internetcomputer.org/concepts/cycles/) — это единица оплаты ресурсов в Internet Computer: вычислений, памяти, хранения и сетевого трафика. У каждой канистры есть счёт циклов, и использованные ресурсы списываются с этого счёта. В Rabbithole циклы поддерживают работу вашей канистры хранилища. Стоимость настройки покрывает создание канистры и стартовый баланс циклов. Позже канистре может понадобиться пополнение, чтобы продолжать работать. ## Как это связано Когда вы создаёте хранилище, Rabbithole разворачивает канистру хранилища и пополняет её циклами. Вы входите через Internet Identity, а Rabbithole получает principal для вашей сессии. После передачи контроля этот principal становится идентификатором владельца, который Rabbithole использует для вашей канистры хранилища. Браузер шифрует файлы до загрузки. Подробный поток ключей описан на странице о шифровании. --- url: /ru/getting-started/quickstart.md --- # Быстрый старт ## Начало работы 1. Перейдите на [rabbithole.app](https://rabbithole.app) 2. Нажмите **Войти** и авторизуйтесь через [Internet Identity](https://id.ai) 3. **Создайте хранилище** — оплатите фиксированную стоимость настройки. Rabbithole развернёт вашу персональную канистру на блокчейне примерно за минуту. 4. Работайте со своим хранилищем: Когда хранилище готово, вы можете: - Загружать и скачивать файлы. - Раскладывать файлы по папкам. - Переименовывать, перемещать и удалять элементы. - Давать другим пользователям доступ к файлам или папкам. Если слова вроде канистры, principal или циклов пока незнакомы, прочитайте [Основные понятия](/ru/getting-started/concepts.md) перед более техническими разделами. Rabbithole строится вокруг сквозного шифрования. Файлы защищаются ещё до загрузки. :::tip\{title="Хотите узнать больше?"} Читайте [Как работает шифрование](/ru/how-it-works/encryption/index.md), чтобы понять, как защищены файлы, или [Суверенитет данных](/ru/how-it-works/sovereignty/index.md), чтобы разобраться, что именно вы контролируете. ::: --- url: /ru/how-it-works/sovereignty/index.md --- # Суверенитет данных в Rabbithole В Rabbithole владение хранилищем связано с канистрой, а не с одной записью в базе аккаунтов. Когда вы создаёте хранилище, Rabbithole разворачивает для вас персональную канистру Internet Computer с кодом хранилища, данными и собственным веб-интерфейсом. После завершения передачи Rabbithole удаляет себя из контроллеров. Хранилище остаётся частью Internet Computer, но управление им переходит к вам. :::tip Короткий вывод Rabbithole помогает создать хранилище и остаётся сервисом вокруг него. Само хранилище принадлежит вам: вы можете открывать его напрямую, пополнять циклы и решать, принимать ли будущие обновления. ::: ## Что вы контролируете После первичной передачи ваш Internet Identity principal становится контроллером канистры хранилища. Это даёт вам прямой контроль над инфраструктурой, где хранятся записи о файлах, правила доступа, фронтенд-ассеты и, в режиме On-chain Storage, сами байты файлов. Вы контролируете эти части хранилища: - **Настройки канистры**: ваш principal управляет контроллерами и обновлениями. - **Прямой доступ**: канистра обслуживает собственный фронтенд по адресу `https://.icp0.io`. - **Финансирование циклов**: вы можете поддерживать работу хранилища через автопополнение циклов в Rabbithole Pro или напрямую через инструменты Internet Computer. - **Обновления**: вы решаете, давать ли Rabbithole временный доступ для установки новой версии. - **Удаление**: вы можете удалить канистру и её данные, когда хранилище больше не нужно. ## Что по-прежнему делает Rabbithole Суверенитет не означает, что Rabbithole исчезает из пользовательского опыта. Он означает, что Rabbithole становится сервисным слоем вокруг инфраструктуры, которую контролируете вы. Rabbithole может по-прежнему предоставлять: - основной интерфейс приложения на `rabbithole.app`; - создание и первичную настройку хранилища; - доставку обновлений кода и фронтенд-ассетов, когда у вас активен Pro и вы подтверждаете временный доступ; - автопополнение циклов для активного Pro, когда канистре нужны циклы перед дорогими операциями; - координацию Blob Storage, если вы выбираете более дешёвый режим хранения. ## Как создаётся хранилище Rabbithole использует временный доступ только для создания и инициализации хранилища. Передача контроля происходит до того, как хранилище становится вашей самостоятельной канистрой. ```mermaid flowchart TB subgraph S1["Шаг 1: Оплата"] U1[Вы] -->|фиксированная цена| PAY[Rabbithole] end subgraph S2["Шаг 2: Развёртывание"] direction TB PAY -->|создание канистры| CAN[Новая канистра] CAN -->|контроллеры: Вы + Rabbithole| W[Установка WASM-модуля] W --> FE[Установка фронтенд-ассетов] end subgraph S3["Шаг 3: Передача"] FE --> RV[Отзыв права записи ассетов] RV --> RM[Удаление Rabbithole из контроллеров] RM ==> OWN[Вы единственный контроллер] end subgraph S4["Результат: Ваше хранилище"] OWN --> A1[rabbithole.app] OWN --> A2["https://<canister-id>.icp0.io"] end style S1 fill:#e0f2fe,stroke:#0284c7 style S2 fill:#fef3c7,stroke:#d97706 style S3 fill:#dcfce7,stroke:#16a34a style S4 fill:#f0fdf4,stroke:#16a34a style OWN fill:#22c55e,color:#fff style RM fill:#fb923c,color:#000 style RV fill:#fed7aa,stroke:#d97706 style A1 fill:#a5d8ff,stroke:#0284c7 style A2 fill:#a5d8ff,stroke:#0284c7 ``` Поток создания состоит из трёх фаз: 1. **Вы оплачиваете развёртывание**. Платёж покрывает создание канистры, начальный баланс циклов, операции развёртывания и связанные инфраструктурные расходы. 2. **Rabbithole устанавливает хранилище**. В канистру загружается код хранилища и фронтенд-ассеты, которые она будет обслуживать. 3. **Rabbithole завершает передачу**. Сервис отзывает своё право записи ассетов и удаляет себя из контроллеров канистры. После этой передачи Rabbithole больше не имеет постоянного административного доступа к вашей канистре. Целевое финальное состояние: ваш principal остаётся единственным контроллером. ## Что будет, если Rabbithole недоступен Rabbithole является одним из интерфейсов к вашему хранилищу, а не владельцем канистры. Если `rabbithole.app` недоступен, канистра может обслуживать собственный фронтенд напрямую, пока у неё достаточно циклов. ```mermaid flowchart LR subgraph NORMAL["Штатная работа"] direction LR U1[Вы] -->|rabbithole.app| C1[Ваша канистра] U1 -->|прямой URL| C1 end subgraph GONE["Rabbithole недоступен"] direction LR U2[Вы] -.->|rabbithole.app| X[Недоступен] U2 ==>|"напрямую: canister-id.icp0.io"| C2[Ваша канистра] end style NORMAL fill:#dcfce7,stroke:#16a34a style GONE fill:#fef3c7,stroke:#d97706 style X fill:#fca5a5,stroke:#ef4444 style C1 fill:#22c55e,color:#fff style C2 fill:#22c55e,color:#fff ``` Что останется доступным, зависит от режима хранения: - **On-chain Storage**: байты файла остаются внутри канистры, пока она профинансирована. - **Blob Storage**: канистра хранит доверенную запись о файле и данные проверки, а доступность байтов файла зависит от срока хранения Blob Storage. ## Границы модели Суверенитет данных убирает Rabbithole из постоянных контроллеров, но не отменяет операционные зависимости. Эти ограничения важно понимать заранее. - **Циклы всё равно нужны**. Канистра без финансирования может заморозиться, а позже может быть удалена сетью Internet Computer. - **Blob Storage имеет отдельную модель доступности**. Канистра хранит запись о файле, но байты файла зависят от финансирования и срока удержания (retention) Blob Storage. - **Шифрование остаётся отдельной темой**. Суверенитет отвечает за владение и администрирование. Шифрование отвечает за конфиденциальность файла. - **Потеря identity остаётся риском**. Если вы потеряете доступ к Internet Identity, который контролирует канистру, Rabbithole не сможет восстановить контроль за вас. ## Продолжить чтение Эти страницы углубляют модель суверенитета и связанные части продукта. - [Как проверить владение](/ru/how-it-works/sovereignty/verify-ownership.md) - [Обновления хранилища](/ru/how-it-works/sovereignty/updates.md) - [Аутентификация](/ru/how-it-works/authentication.md) - [Хранилище](/ru/how-it-works/storage/index.md) - [Оплата и циклы](/ru/how-it-works/payment.md) --- url: /ru/how-it-works/sovereignty/verify-ownership.md --- # Как проверить владение Проверка владения отвечает на простой вопрос: кто сейчас может управлять вашей канистрой хранилища? Для большинства пользователей достаточно интерфейса Rabbithole. `icp-cli` нужен, если вы хотите проверить тот же факт напрямую через инструменты Internet Computer. В обоих случаях важно сравнивать контроллеров с тем principal, которым вы входите в Rabbithole через Internet Identity. ## Проверка в Rabbithole Откройте страницу настроек канистры внутри приложения Rabbithole: ```text /dashboard//canister ``` В таблице **Controllers** должны быть только ожидаемые principal-идентификаторы. Строка текущего пользователя выделяется жирным. После завершения передачи Rabbithole не должен оставаться в этом списке. Если вы только что создали хранилище или подтвердили обновление, дождитесь завершения операции: во время настройки или обновления временный доступ контроллера может быть частью нормального процесса. ## Почему обычный principal из CLI может не совпасть Internet Identity защищает приватность тем, что выводит principal для конкретного веб-адреса приложения. Поэтому principal для `rabbithole.app` может отличаться от обычной локальной identity в `icp-cli`. Из-за этого две команды сами по себе могут ввести в заблуждение: ```bash icp identity principal icp canister settings show -n ic ``` Они могут использовать локальную CLI-identity, а не Internet Identity principal, которым вы входите в Rabbithole. Для корректной проверки нужно связать локальную identity с Internet Identity через login host Rabbithole. ## Проверка через icp-cli Сначала проверьте, что ваша версия `icp-cli` поддерживает привязку к Internet Identity: ```bash icp identity link ii --help ``` Если команда недоступна, обновите `icp-cli` до версии с поддержкой `icp identity link ii`. Затем создайте локальную identity, связанную с вашим Internet Identity для Rabbithole. В `icp-cli` 0.2.7 адрес приложения задаётся через `--host`: ```bash icp identity link ii --host https://rabbithole.app rabbithole-app ``` Команда откроет вход через Internet Identity и сохранит делегацию для Rabbithole. После этого можно вывести principal именно этой identity: ```bash icp identity principal --identity rabbithole-app ``` Теперь проверьте настройки канистры от имени этой identity: ```bash icp canister settings show -n ic --identity rabbithole-app ``` Проверьте поле `controllers` в выводе: - ваш principal должен быть в списке контроллеров; - Rabbithole не должен оставаться в списке после завершения передачи. Когда делегация истечёт, обновите вход: ```bash icp identity login rabbithole-app ``` ## Проверка кода Проверка контроллеров показывает, кто управляет канистрой. Если вы хотите проверить ещё и установленный код, сравните хеш модуля с опубликованным релизом. Internet Computer описывает общий процесс в руководстве по [reproducible builds](https://docs.internetcomputer.org/building-apps/best-practices/reproducible-builds). ## Продолжить чтение - [Суверенитет данных](/ru/how-it-works/sovereignty/index.md) - [Обновления хранилища](/ru/how-it-works/sovereignty/updates.md) - [Аутентификация](/ru/how-it-works/authentication.md) --- url: /ru/how-it-works/sovereignty/updates.md --- # Обновления хранилища После передачи контроля Rabbithole не может обновить вашу канистру самостоятельно. Это намеренная часть модели: чтобы установить новую версию, сервису нужно временное окно доступа, которое подтверждаете вы. Такая схема позволяет Rabbithole доставлять исправления и новые возможности, но не оставаться постоянным администратором вашего хранилища. Доставка обновлений — сервисная возможность Rabbithole Pro. При этом Pro не меняет модель контроля: обновление всё равно требует вашего подтверждения и временного доступа к канистре. ## Почему нужен временный доступ контроллера Обновление канистры меняет код, который обслуживает хранилище. На Internet Computer такие операции может выполнять только контроллер канистры. Поэтому Rabbithole не может тихо обновить ваше хранилище после передачи контроля. Когда вы подтверждаете обновление, происходит ограниченный по задаче процесс: 1. Вы добавляете Rabbithole как временного контроллера. 2. Rabbithole устанавливает новый WASM-модуль или фронтенд-ассеты. 3. Rabbithole удаляет себя из контроллеров. 4. Хранилище снова остаётся под вашим контролем. ```mermaid sequenceDiagram participant U as Вы participant R as Rabbithole participant C as Ваша канистра R-->>U: Доступна новая версия U->>C: Добавить Rabbithole как временного контроллера U->>R: Подтвердить обновление R->>C: Установить новый WASM или фронтенд-ассеты R->>C: Удалить себя из контроллеров Note over C: Вы снова единственный контроллер ``` ## Что происходит с данными Обычное обновление меняет код канистры, но не должно стирать данные. Записи о файлах, права доступа и сохранённые данные находятся в Stable Memory, которая переживает обновления канистры. Перед обновлением вы можете создать снапшот из интерфейса Rabbithole. Снапшот фиксирует текущее состояние Stable Memory и WASM-модуля. Если обновление завершится ошибкой или будет работать некорректно, вы сможете восстановить канистру из снапшота. ## Что делает Rabbithole на уровне протокола Во время первичной передачи и обновлений Rabbithole работает с двумя разными видами доступа: - **Права на фронтенд-ассеты**. Rabbithole может установить или обновить файлы веб-интерфейса, который обслуживает ваша канистра. После передачи сервис отзывает своё право записи ассетов. - **Права контроллера канистры**. Rabbithole получает их только на время операции, устанавливает нужную версию и удаляет себя из контроллеров. Первичная передача завершается вызовом `IC.update_settings` с финальным списком контроллеров. После удаления Rabbithole у сервиса нет административного обхода: правила контроллеров применяются менеджмент-канистрой Internet Computer. ## Что проверить после обновления После завершения обновления проверьте таблицу **Controllers** на странице канистры в Rabbithole. В списке должны остаться только ожидаемые principal-идентификаторы. Если вы хотите проверить это напрямую через инструменты Internet Computer, используйте инструкцию на странице [Как проверить владение](/ru/how-it-works/sovereignty/verify-ownership.md). ## Продолжить чтение - [Суверенитет данных](/ru/how-it-works/sovereignty/index.md) - [Как проверить владение](/ru/how-it-works/sovereignty/verify-ownership.md) - [Оплата и циклы](/ru/how-it-works/payment.md) --- url: /ru/how-it-works/authentication.md --- # Аутентификация Аутентификация в Rabbithole начинается с Internet Identity и приводит к principal-идентификатору, который может вызывать канистры. Проверенные атрибуты, например email, находятся на отдельном уровне. Они помогают поддерживать совместный доступ и уведомления, но не становятся вашим паролем или ключом шифрования. ## Вход без паролей Rabbithole использует **[Internet Identity](https://id.ai)** — систему аутентификации Internet Computer. Вы можете войти несколькими способами без пароля. - **Ключи доступа (passkeys)**: Touch ID, Face ID, Windows Hello или аппаратные ключи безопасности - **OpenID-аккаунты**: Google, Apple или Microsoft, если выбранный поток входа их поддерживает - **SSO**: корпоративный вход, если он доступен для вашего аккаунта - **Аппаратные ключи безопасности**, например YubiKey У Rabbithole нет отдельного пароля, который нужно помнить, и нет базы паролей, которую можно взломать. Ваше устройство или провайдер входа доказывает вашу личность Internet Identity, а Rabbithole получает криптографический идентификатор — **principal**. ```mermaid sequenceDiagram participant U as Вы participant II as Internet Identity participant R as Rabbithole U->>II: Вход через passkey, ключ безопасности или OpenID II-->>U: Делегация для этого приложения U->>R: Вызов Rabbithole от вашего principal-идентификатора R-->>U: Ваши хранилища, настройки и файлы ``` ## Отделяйте аутентификацию от атрибутов Вашего **principal-идентификатора** достаточно, чтобы аутентифицировать вас. Rabbithole не нужен email, чтобы понять, какой аккаунт вызывает серверную часть. Некоторые потоки входа также могут передавать **проверенные Identity Attributes** — например email или имя. Эти атрибуты отделены от аутентификации. - Аутентификация отвечает: **какой principal-идентификатор делает вызов?** - Атрибуты отвечают: **какой проверенный email или имя вы решили передать?** Rabbithole использует атрибуты только когда они доступны через поток Internet Identity и привязаны к вошедшему principal-идентификатору. ## Используйте email для совместного доступа Rabbithole создаётся для приватного совместного доступа к хранилищам, в том числе с людьми, которые ещё не зарегистрировались. Проверенный email поддерживает сценарии, которые сложно построить только через principal-идентификаторы. - **Приглашение по email**: владелец хранилища может пригласить email-адрес до того, как человек создал аккаунт Rabbithole. Когда этот человек позже войдёт с совпадающим проверенным email, Rabbithole сможет автоматически связать приглашение с его principal-идентификатором. - **Будущие уведомления**: email можно использовать для важных уведомлений о хранилищах, доступе, оплате или безопасности, когда пользователь не находится в приложении. - **Меньше повторной проверки**: если email уже проверен через Internet Identity или OpenID, Rabbithole не нужно строить отдельный процесс подтверждения того же email. Email не является вашим паролем, приватным ключом или ключом шифрования. Аккаунт и доступ к файлам по-прежнему контролируются вашим Internet Identity principal-идентификатором и разрешениями, сохранёнными в вашей канистре. Читайте [Совместный доступ](/ru/how-it-works/sharing/index.md), чтобы увидеть, как приглашение по проверенному email превращается в права внутри канистры хранилища. ## Сохраняйте приватность по умолчанию Internet Identity устроена так, чтобы приложения не получали глобальный идентификатор пользователя. Пользователь получает отдельный стабильный псевдоним для каждого веб-адреса приложения. Это помогает предотвращать отслеживание между приложениями. Для Rabbithole это означает: - Другие приложения не могут определить ваш аккаунт Rabbithole по своему входу через Internet Identity. - Rabbithole не получает ваш номер Internet Identity anchor или секреты ключа доступа. - Биометрия не покидает устройство; она только разблокирует локальный passkey. - Передаваемые атрибуты ограничены тем, что поддерживает поток входа и что разрешил пользователь. ## Используйте один аккаунт в интерфейсах хранилища Ваша персональная канистра хранилища отдаёт собственный веб-интерфейс. Без дополнительного механизма прямой URL канистры и `rabbithole.app` были бы разными веб-адресами. Rabbithole решает это через **посредническую делегацию**. Вы входите через Rabbithole, после чего Rabbithole выпускает делегацию только для нужной цели: сессии веб-интерфейса хранилища. Этот интерфейс может вызывать следующие канистры: - Вашу канистру хранилища - Серверную часть Rabbithole - Управляющую канистру IC, когда это нужно для операций с канистрой Так пользовательский опыт остаётся простым. Вам не нужно создавать отдельный аккаунт только потому, что вы открыли своё хранилище напрямую. ## Почему у одного пользователя бывают разные principal Internet Identity защищает приватность тем, что не выдаёт один глобальный идентификатор во все приложения. Один и тот же Internet Identity anchor получает разные principal-идентификаторы для разных веб-адресов приложения. Для Rabbithole это важно в двух сценариях: - При входе через `rabbithole.app` Internet Identity выводит principal для основного приложения Rabbithole. - При прямом входе через `<ваше-хранилище>.icp0.io` Internet Identity выводит другой principal, потому что это другой веб-адрес приложения. В обычном сценарии хранилище всё равно видит principal основного приложения: интерфейс хранилища получает делегацию от Rabbithole и использует её для вызовов канистры. Поэтому пользователь не замечает разницы. ```mermaid flowchart TD II[Один Internet Identity anchor] RH[rabbithole.app] StorageOrigin["URL хранилища"] P1[Principal Rabbithole] P2[Principal прямого входа] Delegation[Делегация Rabbithole
для интерфейса хранилища] II --> RH --> P1 II --> StorageOrigin --> P2 P1 --> Delegation ``` Запасной principal прямого входа используется в доступе восстановления. Это позволяет владельцу подтвердить себя через веб-адрес самого хранилища, если ему нужен прямой путь к своей канистре. ## Доверяйте проверенным атрибутам Обычное поле формы — это просто заявление пользователя. Проверенный **Identity Attribute** устроен иначе: он подписан или сертифицирован потоком Internet Identity и отправляется в Rabbithole так, что серверная часть может его проверить. Rabbithole проверяет данные атрибутов перед сохранением. 1. Данные должны быть подписаны доверенной канистрой подписи Internet Identity. 2. Данные должны относиться к тому же principal-идентификатору, который вызывает Rabbithole. 3. Одноразовый `nonce` должен быть выдан Rabbithole и ещё не использоваться. 4. Веб-адрес (`origin`) должен совпадать с ожидаемым адресом Rabbithole. 5. Время подписи должно быть свежим. Только после этих проверок Rabbithole сохраняет атрибуты вроде `email`, `name`, `verifiedEmail` и `authProvider`. *** ## Технические детали Техническая схема состоит из двух частей: делегации доказывают, что сессия может действовать как principal-идентификатор, а Identity Attributes доказывают конкретные сведения профиля, которые пользователь передал через поток входа. :::details\{title="Делегации, principal-идентификаторы и проверенные атрибуты"} ### Principal **Principal** — это криптографический идентификатор, который Rabbithole использует как ID вашего аккаунта. Он выглядит примерно так: ```text o57ld-4as4d-f6pr2-nnmyc-mslbj-67jt3-3huxb-x6jul-f3doo-yxyhi-wqe ``` Principal используется, чтобы: - идентифицировать вашу запись пользователя в Rabbithole, - проверять разрешения на доступ к хранилищам, - получать доступ к ключам зашифрованных файлов через vetKeys, - и управлять вашей персональной канистрой хранилища там, где это применимо. Principal зависит от веб-адреса приложения. Эта зависимость нужна для приватности: разные приложения не могут просто сравнить один глобальный ID и понять, что перед ними один и тот же человек. ### Цепочка делегирования Internet Identity не передаёт Rabbithole приватный ключ passkey. Вместо этого она подписывает краткоживущую делегацию на сессионный ключ. Rabbithole также использует посредническую делегацию, когда веб-интерфейс хранилища должен работать как та же пользовательская сессия. ```mermaid sequenceDiagram autonumber participant S as Интерфейс хранилища participant R as Rabbithole participant II as Internet Identity participant C as Канистра хранилища S->>S: Генерация пары сессионных ключей S->>R: Запрос делегации с публичным сессионным ключом R->>II: Вход через passkey или OpenID II-->>R: Делегация на сессию Rabbithole R->>R: Делегация, ограниченная хранилищем R-->>S: Цепочка делегирования S->>C: Вызов канистры от principal-идентификатора пользователя ``` Ограничение цели задаёт, где можно использовать делегированную сессию. ### Синхронизация Identity Attributes Когда атрибуты доступны, браузер получает у Internet Identity подписанные атрибуты с одноразовым nonce. Затем он выполняет финальный вызов входа от имени identity, в которую добавлены эти атрибуты. Серверная часть проверяет подпись, nonce, origin, время и caller, а затем сохраняет проверенные атрибуты для principal-идентификатора. Получение доступа к storage invite остаётся отдельным шагом и использует только уже верифицированный email. ```mermaid sequenceDiagram autonumber participant B as Браузер participant II as id.ai / Internet Identity participant API as Серверная часть Rabbithole B->>API: _internet_identity_sign_in_start() API-->>B: Одноразовый nonce B->>II: Вход и запрос атрибутов email/name с nonce II-->>B: Делегация и подписанные атрибуты B->>API: _internet_identity_sign_in_finish() API->>API: Проверяет подпись, nonce, origin, время, caller API->>API: Сохраняет проверенные атрибуты для principal-идентификатора B->>API: claimVerifiedEmailAccess() API->>API: Claim storage invites для верифицированного email ``` Серверная часть отклоняет устаревшие, неподписанные, повторно использованные, подписанные не тем источником или пришедшие с неверного веб-адреса данные до сохранения атрибутов. ### Дополнительные материалы Эти ресурсы помогут глубже разобраться в Internet Identity и Identity Attributes. - [Internet Identity](https://id.ai) - [Internet Identity GitHub repository](https://github.com/dfinity/internet-identity) - [Internet Identity specification](https://docs.internetcomputer.org/reference/internet-identity-spec/) - [Identity Attributes design discussion](https://forum.dfinity.org/t/identity-attributes/64212) - [Совместный доступ в Rabbithole](/ru/how-it-works/sharing/index.md) ::: --- url: /ru/how-it-works/storage/index.md --- # Хранение данных ## Режим хранения, лицензия и Pro — разные вещи В сценарии создания и использования хранилища рядом стоят несколько понятий. Они отвечают за разные части продукта: - **Режим хранения** отвечает за то, где лежат байты файла. - **Лицензия хранилища** задаёт базовые лимиты зашифрованного хранения. - **Pro** включает дополнительные возможности для уже созданного хранилища. Режим хранения не заменяет шифрование и права доступа. Содержимое файлов шифруется в браузере до отправки, а в обоих режимах канистра хранилища хранит владение, правила доступа и доверенные записи о файлах. Подробный список возможностей подписки описан на странице [Что даёт подписка Pro](/ru/how-it-works/pro.md). :::tip Короткий вывод Для обычных файлов чаще подходит **Blob Storage**: он дешевле и лучше работает с большими объёмами. **On-chain Storage** выбирайте, когда внешний слой хранения нежелателен, а стоимость и размер файлов не главные ограничения. ::: ## Два режима хранения ### Blob Storage Рекомендуется Blob Storage хранит байты файла во внешнем объектном хранилище, а ваша канистра хранит запись о файле, права доступа и данные проверки. Внешний слой видит только зашифрованные байты. - Около **$0.05 за ГБ в месяц**. - Лучше подходит для больших файлов и более низкой стоимости. - Файл хранится во внешнем object storage. - Ваша персональная канистра хранит правила доступа и данные для проверки файла. ### On-chain Storage Продвинутый режим On-chain Storage хранит файл прямо в вашей персональной канистре. Доверять нужно меньшему числу компонентов, но цена выше, а баланс циклов становится важнее. - Около **$1.04 за ГБ в месяц**. - Лучше подходит для небольших, ценных файлов. - Файл хранится прямо в вашей персональной канистре. - Нет зависимости от внешнего слоя хранения. ## Сравнение | | Blob Storage | On-chain Storage | | --------------------------------- | ---------------------------------------------- | --------------------------------------------------------------- | | **Для кого** | Повседневное использование | Специальные сценарии и максимальный контроль | | **Оценочная стоимость** | Около **$0.05/ГБ в месяц** | Около **$1.04/ГБ в месяц** | | **Где хранится файл** | Во внешнем объектном хранилище | В вашей персональной канистре | | **Что хранит ваша канистра** | Запись о файле, права доступа, данные проверки | Запись о файле, права доступа, байты файла | | **Что может остановить загрузку** | Доступность Blob Storage и фиксация записи | Баланс циклов и безопасный минимум циклов (safe floor) канистры | | **Модель доверия** | IC + локальная проверка + storage-сервис | IC + криптография | :::note О стоимости Это ориентировочные значения для сравнения. Реальная стоимость хранения может меняться со временем. ::: :::note Целостность и доступность — не одно и то же Проверка помогает обнаружить незаметную подмену файла. Она не гарантирует, что файл будет доступен вечно. Доступность зависит от режима хранения, баланса циклов и правил удержания (retention) выбранного storage-сервиса. ::: ## Что одинаково в обоих режимах В обоих режимах пользовательская модель та же. Меняется место хранения байтов, а владение и права доступа остаются прежними. - Ваша персональная канистра хранит владение, правила доступа и доверенные записи файлов. - Зашифрованные файлы шифруются в браузере до отправки. - Канистра проверяет права перед файловыми операциями и выдачей ключа. - Лицензия хранилища и Pro определяют, какие зашифрованные загрузки разрешены. - Проверка целостности остаётся частью пути хранения. ## Что будет, если Rabbithole недоступен? **On-chain Storage:** файл останется в вашей канистре, пока у неё есть [циклы](/ru/how-it-works/payment.md). **Blob Storage:** канистра по-прежнему хранит запись о файле и данные, нужные для проверки файла. Доступность самого файла зависит от финансирования хранения и политики удержания (retention) Blob Storage. :::note Rabbithole — интерфейс, а не владелец данных Постоянная запись о файле находится в вашей канистре. Rabbithole помогает работать с ней и управлять сервисными операциями, но не становится владельцем данных. ::: ## Узнать больше ## Как устроено хранение ### [Как работает Blob Storage](/ru/how-it-works/storage/blob-storage.md) ### [Как работает On-chain Storage](/ru/how-it-works/storage/on-chain-storage.md) ### [Как Rabbithole проверяет ваши файлы](/ru/how-it-works/storage/integrity.md) ### [Оплата и циклы](/ru/how-it-works/payment.md) ### [Что даёт подписка Pro](/ru/how-it-works/pro.md) ## Официальные материалы Internet Computer ### [Canister smart contracts](https://docs.internetcomputer.org/building-apps/essentials/canisters) ### [Query calls](https://docs.internetcomputer.org/building-apps/interact-with-canisters/query-calls) ### [Canister storage and stable memory](https://internetcomputer.org/docs/building-apps/canister-management/storage) --- url: /ru/how-it-works/storage/blob-storage.md --- # Как работает Blob Storage ## Что такое Blob Storage Blob Storage — рекомендуемый режим для большинства зашифрованных файлов. Байты лежат вне вашей канистры, а канистра хранит запись о файле, права доступа и данные, по которым браузер проверяет, что файл не подменили. Слой хранения видит только шифротекст. Blob Storage отвечает за хранение и доставку байтов, а конфиденциальность содержимого обеспечивает шифрование в браузере до загрузки. :::tip Компромисс Вы платите меньше и легче работаете с большими файлами. В обмен доступность самих байтов зависит от жизненного цикла Blob Storage. ::: :::note Важное различие Внешний слой хранения держит **сам файл**. Ваша персональная канистра держит **доверенную запись о файле, права доступа и данные для проверки**. ::: ## Где находится файл ![Архитектура Blob Storage](/diagrams/fossflow-diagram-2.png) Путь Blob Storage выглядит так: - браузер подготавливает и загружает файл; - персональная канистра хранит доверенную запись и состояние доступа; - **Blob Gateway** принимает загрузку и отдаёт файл при скачивании; - **Cashier** и **Cleanup service** поддерживают биллинг, очистку и события удержания (retention). ## Как работает загрузка ### Подготовить части файла в браузере Браузер делит файл на части и шифрует каждую часть локально. Зашифрованные части записываются во временное хранилище браузера, чтобы не держать весь зашифрованный файл в памяти. ### Загрузить части в Blob Gateway Браузер читает зашифрованные части из временного хранилища и отправляет их в Blob Gateway. Gateway сохраняет данные в S3-совместимом объектном хранилище. ### Записать результат в канистру После успешной загрузки Rabbithole записывает результат в канистру. Канистра сохраняет доверенную запись о файле: размер, хеши, метаданные и состояние доступа. ## Как работает скачивание ```mermaid flowchart LR C[Ваша персональная канистра] -->|сертифицированные данные о файле| B[Ваш браузер] G[Blob Gateway] -->|зашифрованный файл| B B -->|сначала проверка| V[Проверка целостности] V --> D[Локальная расшифровка] ``` Перед открытием файла браузер делает две вещи: 1. Получает у канистры ожидаемый цифровой отпечаток файла. 2. Проверяет, что скачанный файл совпадает с этим отпечатком. Только после этого начинается расшифровка, если она была включена для файла. ## Как в схему вписываются оплата и очистка У байтов в Blob Storage свой жизненный цикл. Канистра остаётся доверенной системой записи, но доступность байтов зависит от финансирования Blob Storage и правил удержания (retention). - **Blob Gateway** принимает загрузки и отдаёт файлы при скачивании. - **Cashier** поддерживает финансирование хранения. - **Cleanup service** синхронизирует удаление и события удержания (retention) с вашей канистрой. ## Почему этот режим дешевле Blob Storage дешевле, потому что сам файл не обязан жить внутри памяти канистры. Канистра хранит заметно меньше данных: запись о файле, права доступа и данные проверки. ## На чём строится доверие Здесь доверие распределено между несколькими частями: - Internet Computer хранит состояние вашей канистры. - Канистра сертифицирует доверенные метаданные файла. - Браузер проверяет скачанные байты перед открытием. - Blob Storage отвечает за доступность и удержание (retention) самих байтов. Blob Storage и On-chain Storage используют одно и то же сквозное шифрование, но доступность у них устроена по-разному. ## Читать дальше ## Связанные страницы ### [Как Rabbithole проверяет ваши файлы](/ru/how-it-works/storage/integrity.md) ### [Как работает On-chain Storage](/ru/how-it-works/storage/on-chain-storage.md) ### [Оплата и циклы](/ru/how-it-works/payment.md) ## Официальные материалы ### [Canister smart contracts](https://docs.internetcomputer.org/building-apps/essentials/canisters) ### [Asset certification](https://learn.internetcomputer.org/hc/en-us/articles/34276431179412-Asset-Certification) ### [Certified data](https://docs.internetcomputer.org/tutorials/developer-liftoff/level-3/3.3-certified-data) --- url: /ru/how-it-works/storage/on-chain-storage.md --- # Как работает On-chain Storage ## Что такое On-chain Storage On-chain Storage хранит файл прямо внутри вашей персональной канистры. Внешнего storage-сервиса для байтов нет: канистра хранит сам файл, запись о нём и правила доступа. Этот режим проще по модели доверия, но дороже. Каждый сохранённый байт живёт в памяти канистры и оплачивается циклами, поэтому On-chain Storage лучше подходит для небольших, ценных файлов. :::tip Компромисс Вы убираете внешний слой хранения. В обмен стоимость выше, а баланс циклов становится частью обычной работы с хранилищем. ::: ## Где находится файл ![Архитектура On-chain Storage](/diagrams/fossflow-diagram-4.png) Путь On-chain Storage короче: - браузер подготавливает и загружает файл прямо в канистру; - персональная канистра хранит файл, доверенную запись и состояние доступа; - внешнего gateway-сервиса и внешнего объектного хранилища в пути файла нет. ## Как работает загрузка Перед загрузкой канистра проверяет, что файл можно безопасно принять: у вас есть право записи, заявленный размер подходит для хранилища, а баланса циклов достаточно для операции. ### Подготовить файл в браузере Браузер шифрует файл локально и делит его на части, чтобы загрузка не требовала одного большого запроса. ### Передать части в канистру Канистра принимает части файла по одной и следит, что загрузка остаётся в границах разрешённого размера и доступных циклов. ### Сохранить файл и доверенную запись После передачи всех частей канистра сохраняет файл и фиксирует данные, которые браузер использует для будущей проверки. ## Если циклов не хватает В On-chain Storage баланс циклов быстро становится практическим ограничением: файл хранится внутри канистры, и запись байтов тоже оплачивается циклами. Если во время загрузки безопасного запаса не хватает, возможны два сценария. - **Активный Pro включён**: Rabbithole может запросить автопополнение циклов. Интерфейс показывает **Waiting for cycles...**, а загрузка ждёт пополнения. - **Активного Pro нет**: владелец должен пополнить канистру вручную. После пополнения совместимая повторная попытка может продолжить загрузку. Это не ошибка владения и не потеря файла. Канистра просто не начинает работу, которую не сможет безопасно завершить. ## Как работает скачивание ### Запросить части файла у канистры Браузер запрашивает у канистры данные файла. Внешнего gateway-сервиса в пути файла нет. ### Проверить и открыть локально Браузер проверяет целостность и расшифровывает файл на вашем устройстве. ## Почему это дороже On-chain Storage дороже, потому что каждый сохранённый байт живёт внутри памяти канистры и влияет на её операционный баланс. - Сеть поддерживает хранение байтов во времени. - Stable memory и вычисления оплачиваются циклами канистры. - Большие файлы требуют большего безопасного минимума циклов (safe floor) и могут чаще запускать проверки финансирования. ## Практические ограничения On-chain Storage разумен, когда: - файлы относительно небольшие; - файлов немного; - простота архитектуры важнее, чем экономия; - вы готовы следить за балансом циклов или поддерживать активный Pro. Для больших медиабиблиотек и дешёвого массового хранения этот режим обычно не подходит. ## Почему модель доверия проще При On-chain Storage нет внешнего файлового gateway-сервиса и внешнего объектного хранилища, которые держат файл. Поэтому путь хранения проще: - браузер подготавливает файл; - канистра хранит файл; - браузер проверяет его и открывает. ## Технические детали :::details Сессия загрузки On-chain Storage не записывает большой файл сразу в финальное состояние. Загрузка проходит через сессию: канистра сначала создаёт временную запись, резервирует заявленный размер, принимает части файла и только затем переносит данные в финальную версию файла. ```mermaid sequenceDiagram participant B as Браузер participant C as Канистра participant F as Пополнение циклов B->>C: beginUploadSession C->>C: Создать временную запись C->>C: Зарезервировать заявленный размер alt циклов не хватает C-->>B: Waiting for cycles... F-->>C: Пополнение циклов end alt загрузку можно продолжить loop для каждой части файла B->>C: appendUploadChunk C->>C: Записать часть во временную запись end B->>C: finishUploadSession C->>C: Перенести данные в финальную версию файла C-->>B: Файл сохранён else продолжить нельзя B->>C: abortUploadSession C->>C: Освободить временные ресурсы end ``` Если циклов не хватает, сессия остаётся в ожидании пополнения. Совместимая повторная попытка может продолжить существующую сессию, поэтому загрузка не обязана начинаться с нуля. Если продолжить нельзя, клиент пытается завершить сессию через отмену и освободить временные ресурсы. ::: ## Читать дальше ## Связанные страницы ### [Как работает Blob Storage](/ru/how-it-works/storage/blob-storage.md) ### [Как Rabbithole проверяет ваши файлы](/ru/how-it-works/storage/integrity.md) ### [Оплата и циклы](/ru/how-it-works/payment.md) ## Официальные материалы ### [Canister smart contracts](https://docs.internetcomputer.org/building-apps/essentials/canisters) ### [Canister storage and stable memory](https://internetcomputer.org/docs/building-apps/canister-management/storage) ### [Motoko stable memory](https://internetcomputer.org/docs/motoko/base/ExperimentalStableMemory) --- url: /ru/how-it-works/storage/integrity.md --- # Как Rabbithole проверяет ваши файлы ## Почему это важно Когда файл хранится вне браузера, возникают два разных вопроса: - **Может ли кто-то прочитать файл?** - **Может ли кто-то заменить файл так, чтобы вы этого не заметили?** Шифрование отвечает на первый вопрос. Проверка файла отвечает на второй. :::tip Что это значит на практике Если файл незаметно подменят по пути к вам, Rabbithole не должен открыть его.\ Вместо подменённого файла вы увидите ошибку загрузки или проверки целостности. ::: ## Проверка для Blob Storage ![Проверка Blob Storage](/diagrams/fossflow-diagram-3.png) При Blob Storage браузер не доверяет gateway-сервису вслепую. ### Запросить у канистры ожидаемые данные о файле Браузер получает у канистры ожидаемый хеш файла и связанные метаданные. ### Проверить, что эти данные действительно подлинные Метаданные передаются через механизм сертификации Internet Computer, поэтому браузер может проверить, что они действительно пришли от вашей канистры. ### Сравнить скачанный файл с этим хешем Если файл не совпадает, браузер отвергает его до открытия. ## Проверка для On-chain Storage ```mermaid flowchart LR C[Ваша канистра] -->|зашифрованные части файла| B[Ваш браузер] B --> V[Проверка целостности] V --> D[Локальная расшифровка] ``` При On-chain Storage внешнего gateway-сервиса хранения в пути файла нет, поэтому и путь проверки получается проще. При этом браузер всё равно проверяет полученные данные до расшифровки, просто здесь не нужен отдельный внешний путь доставки файла. ## Что именно сертифицирует Internet Computer Для Blob Storage Rabbithole сертифицирует метаданные, которые говорят браузеру, какой именно файл он должен ожидать. Сюда входят, например: - хеш файла - размер файла - тип содержимого Это позволяет обнаружить подмену ещё до расшифровки. ## Что браузер проверяет локально Браузер заново вычисляет хеш скачанного файла и сравнивает его с сертифицированным значением из канистры. Только если они совпадают, начинается расшифровка. :::note Почему важны обе проверки Сертификация доказывает, что ожидаемые метаданные действительно пришли от вашей канистры.\ Локальная проверка доказывает, что скачанный зашифрованный файл совпадает с этими метаданными. ::: ## Технические детали :::details Сертифицированные метаданные и локальное хеширование ### Путь Blob Storage Для Blob Storage браузер выполняет две связанные проверки: 1. Проверяет сертифицированные метаданные, которые вернула ваша канистра. 2. Локально хеширует скачанный blob и сравнивает его с сертифицированным хешем. Сертифицированные метаданные сейчас включают: - ожидаемый хеш файла - размер файла - тип содержимого Сначала браузер проверяет, что эти метаданные действительно сертифицированы Internet Computer, а затем проверяет, что скачанный blob побайтно совпадает с ожидаемым значением. ### Какой хеш используется Rabbithole использует **SHA-256** для сертифицированного хеша файла и для локального сравнения в браузере. ### Почему сертификации и хеширования недостаточно по отдельности - **Сертификация** доказывает, что ожидаемые метаданные действительно пришли от вашей канистры. - **Локальное хеширование** доказывает, что скачанный blob совпадает с этими метаданными. Обе проверки нужны одновременно. Одна только сертификация не доказывает, что gateway-сервис отдал правильный файл. Одно только локальное хеширование не доказывает, что ожидаемый хеш был надёжным. ### Путь On-chain Storage При On-chain Storage отдельного внешнего слоя доставки нет, поэтому путь проверки короче: - браузер скачивает данные файла из канистры - браузер всё равно проверяет целостность до открытия - расшифровка начинается только после успешной проверки ::: ## Читать дальше ## Связанные страницы ### [Как работает Blob Storage](/ru/how-it-works/storage/blob-storage.md) ### [Как работает On-chain Storage](/ru/how-it-works/storage/on-chain-storage.md) ### [Модель доверия](/ru/how-it-works/trust-model.md) ## Официальные материалы ### [Certified data](https://docs.internetcomputer.org/tutorials/developer-liftoff/level-3/3.3-certified-data) ### [Motoko CertifiedData](https://docs.internetcomputer.org/motoko/core/CertifiedData) ### [Query calls](https://docs.internetcomputer.org/building-apps/interact-with-canisters/query-calls) --- url: /ru/how-it-works/encryption/index.md --- # Шифрование ## Шифрование начинается в браузере Rabbithole шифрует содержимое файла в браузере до загрузки. Дальше по пути хранения идут уже зашифрованные байты: канистра, Blob Storage или On-chain Storage не получают читаемый файл. Это важная граница. Rabbithole может перемещать файл, хранить метаданные, проверять права и целостность, но для этого ему не нужно видеть читаемое содержимое файла. ```mermaid flowchart LR subgraph Browser["Ваш браузер"] F[Ваш файл] --> SP[Разбивка на фрагменты] SP --> E1[Фрагмент 1] SP --> E2[Фрагмент 2] SP --> E3[Фрагмент N] VK[vetKeys\nпороговые узлы IC] -.->|вывод ключа файла| ENC E1 --> ENC[AES-GCM\nшифрование] E2 --> ENC E3 --> ENC end subgraph Storage["Ваше хранилище"] ENC --> CH[Зашифрованные фрагменты] CH --> META[Права доступа\nи данные проверки] end style Browser fill:#f0f9ff,stroke:#0284c7 style Storage fill:#dcfce7,stroke:#16a34a style VK fill:#ddd6fe,stroke:#7c3aed style ENC fill:#6c63ff,color:#fff style CH fill:#22c55e,color:#fff ``` ## Что это значит для вас Rabbithole работает с закрытым файлом, а не с читаемым содержимым. - Команда Rabbithole не может читать содержимое файлов. - Узлы Internet Computer и storage-сервисы хранят зашифрованные фрагменты, а не открытый файл. - Канистра хранилища решает, кто может запросить ключ файла. - Ключ возвращается зашифрованным для той сессии браузера, которая его запросила. - Режим хранения остаётся отдельным выбором: Blob Storage и On-chain Storage отвечают за место хранения байтов, а шифрование отвечает за то, читаемы ли эти байты. Главная идея такая: Rabbithole не просит верить обещанию оператора “мы не будем смотреть”. Он убирает читаемый файл из пути оператора. Допущения всё равно остаются: браузер, загруженный фронтенд и протокол Internet Computer имеют значение. Они перечислены в [модели доверия](/ru/how-it-works/trust-model.md). ## Откуда берётся ключ Rabbithole не просит придумывать пароль для шифрования. Когда зашифрованный файл нужно открыть, браузер просит канистру хранилища выдать ключ файла. Канистра проверяет, есть ли у вашего principal доступ, а затем обращается к сервису [vetKeys](https://docs.internetcomputer.org/concepts/vetkeys/) в Internet Computer. Главное здесь: ключ не лежит готовым в канистре и не передаётся Rabbithole. Internet Computer возвращает зашифрованный ответ, который может открыть только браузер, сделавший этот запрос. Если хотите понять, чем отличаются уровни Standard и High Replication, читайте [Ключи и vetKeys](/ru/how-it-works/encryption/vetkeys.md). ## Совместный доступ не перешифровывает файл Когда вы делитесь файлом, Rabbithole меняет правила доступа. Он не загружает вторую зашифрованную копию для получателя. Если у получателя есть доступ, канистра разрешает его браузеру запросить тот же ключ файла. Если доступ отозван, канистра перестаёт разрешать будущие запросы ключа для отозванной области. Как и в любой системе обмена файлами, отзыв не может стереть копию, которую человек уже скачал. ```mermaid sequenceDiagram participant A as Пользователь A - владелец participant C as Канистра participant VK as vetKeys - узлы IC participant B as Пользователь B - получатель A->>C: Даёт доступ пользователю B Note over C: Канистра обновляет правила доступа B->>C: Запрашивает файл C->>C: Проверяет доступ пользователя B C->>VK: Запрашивает деривацию ключа файла VK-->>B: Возвращает ключ, зашифрованный для B B->>B: Расшифровывает файл в браузере ``` Подробный поток описан в разделе [Шифрование общего доступа](/ru/how-it-works/sharing/encryption-in-shared-access.md). ## Узнать больше ## Разделы о шифровании ### [Ключи и vetKeys](/ru/how-it-works/encryption/vetkeys.md) ### [Как устроено шифрование](/ru/how-it-works/encryption/how-encryption-works.md) ### [Режимы хранения](/ru/how-it-works/storage/index.md) ### [Совместный доступ](/ru/how-it-works/sharing/index.md) ### [Модель доверия](/ru/how-it-works/trust-model.md) ## Официальные материалы Internet Computer ### [vetKeys](https://docs.internetcomputer.org/concepts/vetkeys/) ### [Canister smart contracts](https://docs.internetcomputer.org/concepts/canisters/) --- url: /ru/how-it-works/encryption/vetkeys.md --- # Ключи и vetKeys ## Почему Rabbithole не просит пароль для шифрования Многие зашифрованные хранилища выводят ключи файлов из пароля или recovery phrase. Rabbithole использует другую модель: браузер входит через [Internet Identity](https://id.ai), а канистра хранилища просит Internet Computer вывести файловые ключи через [vetKeys](https://docs.internetcomputer.org/concepts/vetkeys/). Канистра хранилища не получает от вас сырой пароль. Она проверяет, есть ли у пользователя доступ к файлу, а затем запрашивает зашифрованный ответ с ключом для этой сессии браузера. ## Аналогия: сейф и закрытый конверт Представьте сейф без одного главного ключа. Несколько IC-узлов держат только свою долю, нужную для вывода ключа файла. Ваш браузер приносит закрытый конверт. Сеть кладёт в него производный ключ файла, а открыть конверт может только ваш браузер: временный секрет остался у него. Ни один отдельный узел не видит полный ключ. Rabbithole не получает читаемое содержимое файла. Задача канистры хранилища: решить, имеет ли principal право запросить ключ. ## Что происходит при деривации ключа Обычный поток короткий: 1. Браузер просит канистру хранилища выдать ключ зашифрованного файла. 2. Канистра проверяет правила доступа для вашего principal и этого файла. 3. Канистра вызывает IC vetKD API с derivation input файла и временным публичным transport key браузера. 4. Браузер получает зашифрованный vetKey, проверяет его и превращает в ключевой материал для локального шифрования или расшифровки. Один и тот же файл снова выводит тот же ключевой материал. Поэтому Rabbithole не нужно хранить постоянный файловый ключ в канистре. ## Standard и High Replication При создании зашифрованного хранилища Rabbithole просит выбрать VetKey level. Так вы выбираете, какой сервис ключей Internet Computer Rabbithole будет использовать для деривации. | Level | Текущая репликация сервиса ключей | Оценка стоимости деривации | Хороший выбор для | | ----------------------- | --------------------------------- | -------------------------- | ------------------------------------------------------------------------------------------ | | Standard (по умолчанию) | 13 узлов | Около $0.014 | Большинство зашифрованных хранилищ | | High Replication | 34 узла | Около $0.035 | Пользователи, которым нужен более крупный сервис ключей и подходит более дорогая деривация | Числа 13 и 34 описывают текущий IC threshold key service за каждым уровнем Rabbithole. Это не количество копий файла и не обязательно сабнет, на котором работает ваша канистра хранилища. Если конфигурация Internet Computer или Rabbithole изменится, актуальные варианты будут видны на экране создания хранилища. Документация объясняет модель; экран создания показывает конкретный вариант, который вы собираетесь купить. ## Как сюда вписывается OpenCloud [OpenCloud](https://opencloud.org/) позволяет разработчикам создавать Internet Computer cloud engines с выбранными узлами и провайдерами. В его [pricing guide](https://opencloud.org/pricing) сейчас показан пример Hobby engine из 4 nano-узлов. Это выбор хостинга, а не замена VetKey level. У канистры хранилища есть сабнет хостинга. Деривация VetKey использует IC-сабнет, где находится выбранный vetKD master key. Management canister маршрутизирует запрос деривации между этими слоями. Для пользователей Rabbithole сегодня видимый выбор шифрования остаётся Standard или High Replication. OpenCloud важен потому, что будущие развёртывания могут дать контроль над хостингом отдельно от уровня сервиса ключей. ## Стоимость и циклы Каждая зашифрованная загрузка или скачивание, которым нужна новая деривация ключа, расходует циклы. Rabbithole показывает оценку в долларах для читаемости, но канистра платит сети циклами. Это отдельная статья расходов от хранения. Хранение оплачивает доступность байтов. Деривация оплачивает запрос к сети, которая возвращает зашифрованный ответ с файловым ключом. --- url: /ru/how-it-works/encryption/how-encryption-works.md --- # Как устроено шифрование ## Что описывает эта страница Эта страница для читателей, которым нужна более низкоуровневая модель: derivation input файла, transport keys, шифрование фрагментов и граница между контролем доступа и криптографией. Пользовательское объяснение начинается на странице [Шифрование](/ru/how-it-works/encryption/index.md). Выбор уровня сервиса ключей описан в [Ключи и vetKeys](/ru/how-it-works/encryption/vetkeys.md). ## Уникальный ключ для каждого файла У каждого зашифрованного файла есть key ID. В канистре хранилища этот key ID собирается из principal владельца ключа и идентификатора файла. Канистра строит vetKD derivation input из этих значений и использует domain separator `file_storage_dapp`. Результат детерминированный: один и тот же key ID файла снова выводит тот же ключевой материал. Благодаря этому Rabbithole может расшифровать файл позже, не храня сырой файловый ключ в канистре. ```mermaid flowchart TB subgraph VK["vetKeys - пороговая деривация"] MK[Мастер-секрет\nразделён между узлами IC] --> D1 MK --> D2 MK --> D3 end D1["derivation ID: файл A"] --> K1[Ключ для файла A] D2["derivation ID: файл B"] --> K2[Ключ для файла B] D3["derivation ID: файл C"] --> K3[Ключ для файла C] K1 --> E1[Зашифрованный файл A] K2 --> E2[Зашифрованный файл B] K3 --> E3[Зашифрованный файл C] style VK fill:#ddd6fe,stroke:#7c3aed style K1 fill:#6c63ff,color:#fff style K2 fill:#6c63ff,color:#fff style K3 fill:#6c63ff,color:#fff style E1 fill:#dcfce7,stroke:#16a34a style E2 fill:#dcfce7,stroke:#16a34a style E3 fill:#dcfce7,stroke:#16a34a ``` Один master secret даёт разные ключи для разных derivation ID. Поэтому ключ одного файла не открывает остальные файлы. ## Поток запроса ключа Канистра проверяет доступ до обращения к Internet Computer за деривацией ключа. Пользователь без права чтения отклоняется до vetKD-вызова. ```mermaid sequenceDiagram autonumber participant B as Браузер participant S as Канистра хранилища participant P as Проверки прав participant V as IC vetKD API B->>B: Генерация временной transport key pair B->>S: getEncryptedVetkey(keyId, transport public key) S->>P: Проверка подписки и права чтения P-->>S: Разрешено или отклонено S->>V: vetkd_derive_key(input, context, key id, transport public key) V-->>S: Зашифрованный vetKey S-->>B: Зашифрованный vetKey B->>S: getVetkeyVerificationKey() S-->>B: Verification key B->>B: Локальная расшифровка и проверка B->>B: Шифрование или расшифровка фрагментов ``` Transport key pair временная. Публичная часть уходит в канистру. Секретная часть остаётся в браузере, поэтому зашифрованный ответ vetKey полезен только для этого браузерного запроса. ## Фрагменты и шифрование Rabbithole шифрует фрагменты файла в браузере. Реализация использует клиентскую библиотеку Internet Computer vetKeys для производного ключевого материала и аутентифицированного шифрования. | Параметр | Текущее значение | | -------------------------------------------- | ------------------------------------------------------ | | Макс. размер чанка канистры | 2 097 152 байта | | On-chain фрагмент до шифрования по умолчанию | 1 900 000 байт | | Blob Storage chunk | 1 048 576 байт | | AES-GCM overhead | 28 байт: 12-байтный IV + 16-байтный authentication tag | | Blob Storage фрагмент до шифрования | 1 048 548 байт | Большие файлы разбиваются на фрагменты. Каждый зашифрованный фрагмент несёт свои данные аутентификации, поэтому подмена ciphertext обнаруживается при расшифровке. ## Проверка Blob Storage Когда используется Blob Storage, зашифрованные фрагменты загружаются вне канистры. Канистра хранит запись о файле и данные, нужные для проверки blob: content hashes, Merkle tree и IC-certified metadata. Так Rabbithole разделяет две проверки: - шифрование защищает конфиденциальность; - проверка целостности обнаруживает незаметную подмену или повреждение. Подробнее о проверке хранения читайте в разделе [Проверка целостности файлов](/ru/how-it-works/storage/integrity.md). ## Поддержка TEE Trusted Execution Environment может усилить изоляцию среды исполнения, если доступен на нужном IC-сабнете. Но это не основное privacy-допущение Rabbithole. Главная граница конфиденциальности: клиентское шифрование плюс деривация vetKey, разрешённая канистрой. TEE остаётся дополнительным слоем, а не причиной, по которой Rabbithole может не читать содержимое зашифрованных файлов. ## Ограничения модели Шифрование сужает область доверия, но не убирает все допущения. - Браузер должен выполнять ожидаемый фронтенд-код Rabbithole. - Протокол Internet Computer и vetKD-сервис должны работать корректно. - Пользователь, который уже скачал и расшифровал файл, может сохранить копию после отзыва доступа. - Метаданные файла, например имя, размер и структура папок, не получают такие же гарантии конфиденциальности, как содержимое файла. Более широкие допущения перечислены в [модели доверия](/ru/how-it-works/trust-model.md). --- url: /ru/how-it-works/sharing/index.md --- # Совместный доступ Совместный доступ позволяет открыть другому человеку доступ к хранилищу, папке или файлу. Хранилище остаётся вашим, а приглашённый человек получает только те права, которые вы выбрали. Вы можете поделиться с пользователем Rabbithole или с email-адресом. Доступ по email позволяет пригласить человека ещё до того, как он создал аккаунт Rabbithole. Совместный доступ входит в [Pro](/ru/how-it-works/pro.md). Лицензия хранилища сохраняет персональное зашифрованное хранение владельца, но не заменяет активный Pro для приглашений, управления доступом и приглашённых пользователей. ## Как это выглядит в интерфейсе Обычно всё сводится к трём действиям: выбрать объект, выбрать права и указать получателя. Rabbithole покажет доступ получателю там, где он ожидает его увидеть. - Поделиться всем хранилищем, папкой или одним файлом. - Выдать права **View**, **Edit** или **Manage**. - Пригласить человека по email до его регистрации. - Дать человеку возможность запросить доступ, если он открыл хранилище без прав. - Увидеть входящие хранилища в **Shared with me**. Если получатель с правом **Edit** загружает файл, он использует канистру владельца. Владелец контролирует и видимость данных, и расход ресурсов хранилища. :::tip Почему важны приглашения по email Вы можете поделиться доступом с будущим пользователем. Когда этот человек позже войдёт с тем же проверенным email из [Identity Attributes](/ru/how-it-works/authentication.md#доверяйте-проверенным-атрибутам), Rabbithole автоматически свяжет приглашение с его аккаунтом. ::: ## Как Rabbithole защищает совместный доступ Rabbithole не хранит совместный доступ как заметку в центральной базе. Права проверяет само хранилище. В терминах Internet Computer каждое хранилище — это канистра: самостоятельный смарт-контракт с правилами доступа, файловой структурой и собственным фронтендом. Когда человек открывает расшаренный файл, канистра хранилища проверяет его principal до выдачи данных файла или ключа шифрования. Principal — это криптографический ID аккаунта, который Internet Identity выдаёт приложению. ```mermaid sequenceDiagram autonumber participant Owner as Владелец participant App as Приложение Rabbithole participant Storage as Канистра хранилища participant Recipient as Получатель Owner->>App: Делится папкой или файлом App->>Storage: Сохраняет правило доступа Recipient->>Storage: Открывает расшаренный объект Storage->>Storage: Проверяет principal и права Storage-->>Recipient: Возвращает только разрешённые данные ``` :::details Технические детали: канистры, события и список Shared with me Канистра хранилища остаётся источником истины для прав. Серверная часть Rabbithole держит синхронизированный индекс, чтобы пользователи находили хранилища, которыми с ними поделились, в основном приложении. ```mermaid sequenceDiagram autonumber participant O as Владелец participant UI as Интерфейс Rabbithole или хранилища participant S as Канистра хранилища participant API as Серверная часть Rabbithole participant R as Получатель O->>UI: Делится хранилищем, папкой или файлом UI->>S: createAccessBatch() S->>S: Сохраняет активное или ожидающее правило доступа S-->>API: onStorageAccessChanged() API->>API: Обновляет индекс Shared with me R->>API: listSharedWithMeStorageViews() API-->>R: Активные или ожидающие хранилища R->>S: Открывает хранилище от своего principal S->>S: Проверяет права перед защищённой операцией ``` Если индекс на серверной части недоступен, канистра хранилища всё равно принимает решение о правах. Индекс нужен для обнаружения и уведомлений; он не заменяет проверки в канистре. ::: ## Короткий словарь Эти термины встречаются на более глубоких страницах раздела. - **Канистра**: смарт-контракт в Internet Computer. Хранилище Rabbithole — это канистра. - **Principal**: криптографический ID аккаунта, по которому проверяются права. - **Проверенный email**: email из [Identity Attributes](/ru/how-it-works/authentication.md#доверяйте-проверенным-атрибутам), подтверждённый потоком входа, а не обычное поле формы. - **Правило доступа**: запись в канистре, которая определяет, кто и что может делать. - **Активный Pro**: состояние, при котором доступны совместный доступ и управление доступом. - **vetKey**: криптографический ключ, который выводится по запросу после проверки прав в канистре. ## Узнать больше ## Темы совместного доступа ### [Приглашения по email](/ru/how-it-works/sharing/email-invites.md) ### [Модель прав](/ru/how-it-works/sharing/permissions.md) ### [Шифрование общего доступа](/ru/how-it-works/sharing/encryption-in-shared-access.md) ### [Аутентификация и Identity Attributes](/ru/how-it-works/authentication.md#доверяйте-проверенным-атрибутам) ### [Что даёт подписка Pro](/ru/how-it-works/pro.md) --- url: /ru/how-it-works/sharing/email-invites.md --- # Приглашения по email Приглашения по email позволяют поделиться доступом до того, как вы знаете principal получателя. Вы вводите email, выбираете права, а Rabbithole держит приглашение в ожидании, пока нужный человек не войдёт. Email не становится паролем и не становится ключом шифрования. Это проверенный [Identity Attribute](/ru/how-it-works/authentication.md#доверяйте-проверенным-атрибутам), который помогает Rabbithole связать приглашение с правильным principal. ## Когда использовать приглашение по email Используйте приглашение по email, когда вы знаете, кто должен получить доступ, но этот человек ещё не пользовался Rabbithole. - Пригласить коллегу до создания аккаунта. - Поделиться папкой с будущим участником проекта. - Подготовить экстренный доступ, который сработает при длительной неактивности владельца. - Использовать тот же проверенный email для будущих уведомлений. Это отличается от доступа по principal. Principal удобен, когда получатель уже есть в приложении. Email удобен, когда вы знаете только адрес человека. :::note Какие email сейчас считаются проверенными Internet Identity поддерживает вход через ключи доступа (passkeys), OpenID-провайдеров например Google, Microsoft и Apple, а также SSO там, где он доступен. Для Rabbithole проверенный email — это атрибут, который пришёл из поддержанного потока Internet Identity и прошёл проверку на серверной части Rabbithole. Обычный ввод произвольного email с последующей проверкой письмом в Rabbithole пока не реализован. Такой способ может появиться позже как отдельная настройка профиля, но текущий сценарий приглашений полагается на email из поддержанного провайдера входа. ::: ## Что увидит получатель Получателю не нужна специальная ссылка, чтобы принять приглашение. Он входит в Rabbithole через Internet Identity и передаёт совпадающий проверенный email из поддержанного провайдера входа. ```mermaid sequenceDiagram autonumber participant Owner as Владелец participant App as Rabbithole participant Recipient as Получатель Owner->>App: Приглашает person@company.com Recipient->>App: Входит через провайдера с тем же verified email App->>App: Проверяет Identity Attributes App->>App: Связывает приглашение с аккаунтом получателя App-->>Recipient: Показывает расшаренное хранилище ``` Rabbithole может сделать это, потому что проверяет email через поток аутентификации. Он не доверяет обычному полю профиля, которое можно ввести вручную. ## Почему Rabbithole может доверять email Проверенный email отличается от текста, введённого в форму. Rabbithole принимает его только после проверки данных Identity Attributes на серверной части. Серверная часть проверяет эти факты перед использованием email: 1. Данные пришли от доверенного источника Internet Identity. 2. Principal-идентификатор вошедшего пользователя совпадает с principal-идентификатором, которому принадлежат атрибуты. 3. Одноразовый `nonce` был выдан Rabbithole и ещё не использовался. 4. Веб-адрес (`origin`) совпадает с Rabbithole. 5. Время подписи свежее. 6. Email отмечен как проверенный. После этих проверок Rabbithole может использовать email, чтобы подключать ожидающие приглашения, поддерживать будущие уведомления и не повторять проверку email без необходимости. :::details Технические детали: email commitments и ожидающие правила доступа Rabbithole не обязан хранить глобальный открытый идентификатор email для сопоставления доступа. Интерфейс и канистра считают email commitment из: - разделителя домена Rabbithole для доступа к хранилищам, - ID канистры хранилища, - и нормализованного email. Так как ID канистры входит в commitment, один и тот же email не становится общим глобальным идентификатором доступа для всех хранилищ. ```mermaid sequenceDiagram autonumber participant O as Владелец participant UI as Диалог совместного доступа participant S as Канистра хранилища participant API as Серверная часть Rabbithole participant R as Получатель O->>UI: Вводит email и право доступа UI->>UI: Создаёт commitment для этого хранилища UI->>S: createAccessBatch(email) S->>S: Сохраняет ожидающее правило доступа S-->>API: Событие изменения доступа API->>API: Индексирует ожидающее email-приглашение R->>API: _internet_identity_sign_in_finish() API->>API: Сохраняет email и сопоставляет commitment R->>API: claimVerifiedEmailAccess() API->>S: claimPendingAccessByBackendAttestation() S->>S: Создаёт активное правило для principal ``` Канистра хранилища принимает подтверждение только от доверенной серверной части Rabbithole, настроенной для этого хранилища. Сессия прямого интерфейса хранилища тоже может получить доступ по совпадающему email после получения проверенных атрибутов из потока входа. ::: ## Связанные страницы Эти страницы описывают окружающую модель. - [Аутентификация и Identity Attributes](/ru/how-it-works/authentication.md#доверяйте-проверенным-атрибутам) - [Модель прав](/ru/how-it-works/sharing/permissions.md) - [Шифрование общего доступа](/ru/how-it-works/sharing/encryption-in-shared-access.md) --- url: /ru/how-it-works/sharing/permissions.md --- # Модель прав Права отвечают на простой вопрос: что этот человек может делать с хранилищем, папкой или файлом? Rabbithole держит это решение рядом с данными. Канистра хранилища проверяет права перед показом списка файлов, изменением контента, изменением совместного доступа и выдачей ключа шифрования. ## Уровни прав В интерфейсе Rabbithole показывает три уровня прав. | Право | Что может получатель | | ---------- | ---------------------------------------------------------------------------------- | | **View** | Открывать папки и файлы, которыми с ним поделились. | | **Edit** | Смотреть контент и менять его: загружать, переименовывать, перемещать или удалять. | | **Manage** | Менять контент и управлять доступом для выбранной области. | Выбирайте **View** для читателя, **Edit** для участника, который работает с файлами, и **Manage** для человека, который может приглашать или удалять других людей. ## Операции и нужные права Одна и та же модель прав контролирует файловые операции, совместный доступ и запрос ключа для зашифрованного файла. Через `/` указано техническое название права в канистре. | Операция | Требуемое право | | ------------------------------------------------- | ------------------------------ | | Открыть папку или скачать файл | **View** / `Read` | | Запросить ключ зашифрованного файла | **View** / `Read` | | Загрузить, переименовать, переместить или удалить | **Edit** / `ReadWrite` | | Управлять совместным доступом | **Manage** / `ReadWriteManage` | Blob Storage меняет место хранения байтов файла, но не обходит проверку прав в канистре хранилища. :::note Совместный доступ и Pro Совместный доступ и управление доступом требуют активного Pro у владельца хранилища. Лицензия хранилища сохраняет персональное зашифрованное хранение владельца, но не поддерживает совместный доступ после истечения Pro. ::: ## Что такое область доступа Область доступа — это объект, которым вы поделились. Это может быть всё хранилище, одна папка или один файл. | Где выдали право | Что оно покрывает | | ---------------- | ----------------------------- | | **Хранилище** | Всё хранилище. | | **Папка** | Эту папку и файлы внутри неё. | | **Файл** | Только этот файл. | ```mermaid flowchart LR Storage[Хранилище] --> Folder[Папка] --> File[Файл] StorageRule[Право на хранилище
покрывает всю цепочку] FolderRule[Право на папку
покрывает папку и файл] FileRule[Право на файл
покрывает только файл] StorageRule -.-> Storage FolderRule -.-> Folder FileRule -.-> File ``` Если у человека есть доступ к папке, он может открывать файлы внутри этой папки с тем же уровнем прав, если более сильное правило не задано в другом месте. :::details Технические детали: key IDs и итоговые права Внутри канистры папки и файлы резолвятся в стабильные key IDs. Проверки прав используют эти key IDs и поднимаются по родительской цепочке, чтобы найти самое сильное итоговое право. Поэтому правило на папку может работать для файла внутри папки, а правило на корень хранилища может работать для всего хранилища. ::: ## Приглашения и активный доступ Rabbithole различает доступ, который уже активен, и доступ, который ждёт получателя. - **Активный доступ** означает, что канистра хранилища знает principal получателя. - **Ожидающий доступ** означает, что Rabbithole ждёт, пока получатель примет приглашение, чаще всего через проверенный email. Когда получатель принимает email-приглашение, ожидающий доступ становится активным доступом для его principal. :::details Технические детали: записи доступа В коде активная запись доступа хранится как `principal grant`, а ожидающая запись доступа хранится как `pending grant`. Ожидающая email-запись позже может создать активную запись для principal получателя после совпадения проверенного email. Пользователи с правом **Manage** могут видеть историю приглашения, включая то, было ли email-приглашение принято через Rabbithole или через прямой интерфейс хранилища. ::: ## Особые классы доступа В основном интерфейсе чаще всего встречается стандартный доступ. У Rabbithole есть и более редкие классы, которые нужны для восстановления и заранее заданных политик. | Название для пользователя | Технический класс | Для чего нужен | | -------------------------------------------------------------------------- | ----------------- | --------------------------------------------------------------------------------------- | | **Стандартный доступ** | `ordinary` | Приглашение или одобренный запрос доступа. | | **Долговременный доступ** | `durable` | Доступ, который заранее описан политикой и активируется, если владелец долго неактивен. | | **Доступ восстановления** | `ownerEquivalent` | Запасной principal владельца с правами уровня владельца. | Стандартный доступ зависит от Pro владельца. Долговременный доступ и доступ восстановления закрывают суверенные сценарии: они могут сохранять доступ к разрешённым данным даже тогда, когда Pro владельца не активен. :::details Долговременный доступ Долговременный доступ нужен для экстренных сценариев. Владелец заранее описывает, кто получит доступ, к какой области и с какими правами, если владелец не проявляет активность в течение заданного времени. Пока владелец пользуется хранилищем, канистра фиксирует активность и сбрасывает таймер. Если активности нет достаточно долго, политика срабатывает и создаёт стандартные правила доступа для выбранных получателей. ```mermaid sequenceDiagram autonumber participant Owner as Владелец participant Storage as Канистра хранилища participant Recipient as Получатель Owner->>Storage: Создаёт политику экстренного доступа Owner->>Storage: Пользуется хранилищем Storage->>Storage: Сбрасывает таймер активности Note over Storage: Если активности нет заданный период Storage->>Storage: Активирует политику Storage-->>Recipient: Выдаёт заранее заданный доступ ``` ::: :::details Доступ восстановления Доступ восстановления нужен для самого жёсткого сценария: владелец должен сохранить возможность открыть своё хранилище напрямую, даже если основной интерфейс Rabbithole недоступен. В обычном сценарии вы входите через `rabbithole.app`, а интерфейс хранилища получает делегацию от Rabbithole. Поэтому хранилище видит тот же principal, что и основное приложение. Если владелец входит напрямую через адрес своего хранилища, например `<ваше-хранилище>.icp0.io`, Internet Identity считает это другим приложением. Для приватности Internet Identity выводит отдельный principal для каждого веб-адреса приложения. Доступ восстановления сохраняет principal прямого входа как запасной principal владельца. Подробнее это описано на странице [Аутентификация](/ru/how-it-works/authentication.md#почему-у-одного-пользователя-бывают-разные-principal). ::: ## Запросы доступа Если вошедший пользователь открывает хранилище без прав, Rabbithole может показать действие **Request access**. Владелец или пользователь с правом **Manage** может одобрить или отклонить этот запрос. ```mermaid sequenceDiagram autonumber participant User as Пользователь participant Storage as Канистра хранилища participant Manager as Пользователь с Manage User->>Storage: Request access Manager->>Storage: Просматривает ожидающий запрос alt Одобрено Manager->>Storage: Выбирает область и право Storage-->>User: Доступ становится активным else Отклонено Storage-->>User: Запрос закрыт end ``` Когда запрос одобрен, пользователь с правом **Manage** выбирает, чем поделиться и какие права выдать. ## Что может и не может отзыв доступа Отзыв доступа останавливает будущие проверки. Получатель не может продолжать смотреть, редактировать, управлять или получать ключи для отозванной области. Отзыв не может стереть данные, которые получатель уже скачал. Это обычное ограничение совместного доступа к файлам: можно остановить будущий доступ, но нельзя забрать копию, которая уже покинула систему. ## Связанные страницы Эти страницы описывают системы, от которых зависит модель прав. - [Обзор совместного доступа](/ru/how-it-works/sharing/index.md) - [Приглашения по email](/ru/how-it-works/sharing/email-invites.md) - [Шифрование общего доступа](/ru/how-it-works/sharing/encryption-in-shared-access.md) --- url: /ru/how-it-works/sharing/encryption-in-shared-access.md --- # Шифрование общего доступа Когда вы делитесь зашифрованным файлом, Rabbithole не создаёт новую зашифрованную копию для каждого получателя. Вместо этого канистра хранилища проверяет, есть ли у получателя доступ. Если доступ есть, Internet Computer выводит ключ файла для этой сессии. Так совместный доступ остаётся быстрым, а владелец не должен быть онлайн, когда получатель открывает расшаренный файл. ## Что меняется при расшаривании У зашифрованного файла есть две части: - зашифрованные байты файла, - и правило, кто может получить ключ для расшифровки. Когда вы делитесь файлом, Rabbithole меняет правило. Он не загружает файл заново и не пересылает получателю ключ от владельца. ```mermaid flowchart LR File[Зашифрованный файл] Rule[Правило доступа] Recipient[Получатель] Key[Ключ файла для этой сессии] File --> Recipient Rule --> Key Key --> Recipient ``` Канистра хранилища проверяет правило до того, как получатель получает данные ключа для расшифровки файла. ## Как получатель получает ключ Исходный ключ не передаётся канистре. Браузер создаёт временную пару транспортных ключей (`transport keys`) и отправляет канистре только публичную часть. Производный ключ файла возвращается зашифрованным для этой сессии браузера. Расшифровать и использовать его может только браузер, у которого есть соответствующий временный секрет. ```mermaid sequenceDiagram autonumber participant B as Браузер получателя participant S as Канистра хранилища participant FS as Правила доступа participant V as IC vetKD API B->>B: Генерация transport key pair B->>S: getEncryptedVetkey(keyId, transport public key) S->>FS: Проверка Read-доступа для principal FS-->>S: Доступ разрешён или отклонён S->>S: derivation input из key owner и key name S->>V: vetkd_derive_key(input, context, transport public key) V-->>S: Зашифрованный vetKey S-->>B: Зашифрованный vetKey B->>B: Локальная расшифровка и проверка B->>B: Расшифровка фрагментов файла ``` Если у пользователя нет права `Read` для key ID, канистра отклоняет запрос до деривации ключа. ## Как это влияет на права Совместный доступ меняет права, а не содержимое файла. - Зашифрованные байты файла остаются там, где были. - Канистра хранилища записывает, кто может читать или менять файл. - Получатель с правом **View** может запросить ключ для этого файла. - После отзыва доступа получатель больше не может запрашивать новые ключи для отозванной области. Поэтому приглашения по email работают и для зашифрованных файлов. Приглашение может ждать, пока человек войдёт, а затем канистра выдаст principal этого человека право запрашивать нужный ключ. Полная таблица операций и прав находится в разделе [Модель прав](/ru/how-it-works/sharing/permissions.md). :::note Что меняется без активного Pro Лицензия хранилища сохраняет персональное зашифрованное хранение владельца, но приглашённые пользователи могут запрашивать ключи только когда у владельца активен Pro. Долговременный доступ и доступ восстановления относятся к отдельным суверенным сценариям и описаны в модели прав. ::: ## Ограничения отзыва доступа Отзыв доступа запрещает будущие запросы ключей и файловые операции. Он не может удалить копию файла или данные ключа, которые получатель уже скачал до отзыва. Это практическое ограничение любой системы совместного доступа к файлам: отзыв контролирует будущий доступ, а не уже экспортированные данные. ## Связанные страницы Эти страницы помогут увидеть общую модель. - [Как работает шифрование](/ru/how-it-works/encryption/index.md) - [Ключи и vetKeys](/ru/how-it-works/encryption/vetkeys.md) - [Модель прав](/ru/how-it-works/sharing/permissions.md) - [Режимы хранения](/ru/how-it-works/storage/index.md) --- url: /ru/how-it-works/payment.md --- # Оплата и циклы Ваше хранилище работает в отдельной канистре Internet Computer. Канистре нужны [циклы](https://docs.internetcomputer.org/concepts/cycles/), чтобы хранить данные, выполнять операции и оставаться доступной. Циклы можно воспринимать как предоплаченное топливо для канистры. Rabbithole может помогать с пополнением через [Pro](/ru/how-it-works/pro.md), но канистра принадлежит вам, поэтому вы можете пополнять её напрямую через инструменты Internet Computer. ## За что вы платите Оплата в Rabbithole не сводится к одной подписке. Есть разовый запуск хранилища, есть лицензия на базовый объём зашифрованных данных, а есть циклы, которые поддерживают работу канистры. | Что | Когда оплачивается | Что даёт | | ---------------------- | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Создание хранилища** | Один раз | Канистру хранилища, стартовый баланс циклов, установку приложения хранилища и лицензию хранилища. | | **Rabbithole Pro** | За период подписки | Совместный доступ, обновления хранилища, зашифрованные загрузки без ограничений базовой лицензии, автопополнение циклов и 2 TC включённого баланса циклов. | | **Циклы** | По мере расхода | Работу канистры: загрузки, операции с файлами, хранение, выдачу vetKeys и доступность хранилища. | ## Лицензия хранилища и Pro Лицензия хранилища — это базовый слой. Она выдаётся при создании хранилища и остаётся действовать, даже если Pro истёк или был отменён. Вы всё равно можете пользоваться персональным зашифрованным хранением в пределах лицензии: включённого объёма и максимального размера одного файла. Вдобавок к лицензии Pro включает функции, которые работают через Rabbithole. Пока Pro активен, он добавляет: - зашифрованные загрузки без ограничений базовой лицензии; - автопополнение циклов, когда Rabbithole пополняет канистру при необходимости; - обновления кода и фронтенд-ассетов после вашего подтверждения; - совместный доступ и управление доступом. Полный список возможностей подписки описан на странице [Что даёт подписка Pro](/ru/how-it-works/pro.md). ## Как работает автопополнение циклов Автопополнение привязано к операциям, а не к календарной дате. Перед дорогими операциями, например перед большой загрузкой в On-chain Storage, канистра проверяет баланс. Если у вас активен Pro, она может запросить пополнение у серверной части Rabbithole. ```mermaid flowchart TD S["Канистра хранилища
нужны циклы"] --> B["Серверная часть Rabbithole"] B --> I{"Есть включённый
Pro-баланс?"} I -->|Да| P["Использовать до 2 TC
за Pro-период"] I -->|Нет| A{"Включено платное
автопополнение?"} A -->|Да| U["Списать с вашего
баланса"] A -->|Нет| M["Нужно ручное
пополнение"] P --> CMC["Cycles Minting Canister"] U --> CMC CMC --> S ``` Серверная часть использует два источника в таком порядке: 1. **Включённый баланс циклов**: 2 TC для вас в пределах Pro-периода. Этот баланс общий для ваших хранилищ. Подробнее это описано на странице [Что даёт подписка Pro](/ru/how-it-works/pro.md). 2. **Платное автопополнение**: пополнение из вашего платёжного баланса, если включённый лимит уже исчерпан и вы включили автопополнение. Без активного Pro всё проще: загрузка продолжится, если в канистре уже хватает циклов. Если не хватает, вы пополняете канистру вручную. ## Поддерживаемые токены Список токенов может меняться, если платёжные провайдеры добавят или уберут поддержку отдельных сетей. Rabbithole показывает доступные варианты перед подтверждением платежа. | Сеть | Токены | | ----------------- | -------------------------- | | Internet Computer | ICP, ckETH, ckUSDC, ckUSDT | | Base | ETH, USDC, USDT | | Solana | SOL, USDC, USDT | Баланс используется для продления Pro-периода и, если вы включили автопополнение, для платного пополнения после исчерпания включённого лимита. ## На что тратятся циклы Циклы оплачивают ресурсы Internet Computer и связанные операции хранения. | Ресурс | За что списываются циклы | | -------------------- | --------------------------------------------------------------------- | | **Вычисления** | Загрузки, скачивания, операции с файлами и проверка прав доступа | | **Stable Memory** | Метаданные, права доступа, хеши и записи проверки | | **On-chain Storage** | Байты файлов, если вы храните их внутри канистры | | **Blob Storage** | Хранение и передача байтов через Blob Storage, если выбран этот режим | | **vetKeys** | Деривация ключей для открытия зашифрованных файлов | ## Карточка Canister Cycles Карточка **Canister Cycles** в боковой панели хранилища показывает запас циклов: хватит ли его на загрузки, обычные операции и резерв заморозки Internet Computer. Она видна только владельцу и пользователям с доступом восстановления, потому что это операционная и платёжная информация канистры. Карточка делит баланс циклов на практические зоны: - **Freeze** — резерв, который нужен канистре, чтобы не заморозиться. - **Safe floor** — резерв заморозки плюс оценка активных загрузок, деривации ключей, завершения записи и дополнительного запаса. - **Target** — безопасный минимум циклов (safe floor) плюс буфер, который Rabbithole использует для автопополнения циклов. - **Headroom** — остаток выше target, доступный для обычной работы. Нажимайте **Top up**, если баланс подходит к безопасному минимуму циклов (safe floor) или вы готовите большую загрузку в On-chain Storage. При активном Pro Rabbithole может пополнить канистру сам. Без Pro остаётся ручное пополнение. :::details\{title="Как считается карточка"} Канистра хранилища обновляет метрики времени выполнения через Internet Computer Management Canister и возвращает в приложение нормализованные метрики карточки. Frontend не вызывает `canister_status` напрямую для этой карточки. Safe floor — это безопасный минимум циклов. Это оценка, а не фиксированное значение сети: ```text safeFloor = freezingReserve + remainingUploadWriteCost + remainingUploadHashInstructionCycles + activeVetKeyDerivationCost + activeCommitCost + margin ``` Параллельные загрузки увеличивают активные резервы до завершения, отмены или истечения срока сессии загрузки. Поэтому безопасный минимум циклов (safe floor) и target могут расти, пока выполняются несколько больших загрузок. ::: ## Самостоятельное управление Pro не нужен, чтобы хранилище продолжало принадлежать вам. Канистра остаётся вашей, поэтому её можно пополнять напрямую. Доступные варианты: - **ручное пополнение** через [NNS dapp](https://nns.ic0.app), `icp-cli` или ICP-кошелёк; - **автоматическое пополнение** через сторонние сервисы, например [CycleOps](https://cycleops.dev). :::tip\{title="Ваша канистра — ваш выбор"} Rabbithole Pro снимает часть рутины. Сама канистра остаётся стандартным смарт-контрактом Internet Computer, которым можно управлять через IC-инструменты. ::: ## Что происходит, когда циклы заканчиваются Если у канистры заканчиваются циклы, владелец не меняется. Меняется доступность: сеть может ограничить работу канистры. **On-chain Storage.** Канистра переходит в замороженное состояние, когда циклы падают ниже порога заморозки. Данные сохраняются, но канистра может перестать обрабатывать вызовы, пока вы не добавите циклы. Если канистра слишком долго остаётся без финансирования, Internet Computer может удалить её по правилам жизненного цикла канистры. **Blob Storage.** Если Blob Storage не может списать плату за хранение, данные становятся недоступными через gateway-сервис. В текущей конфигурации действует 30-дневный льготный период. После 30 дней с нулевым балансом gateway-сервис удаляет данные безвозвратно. :::note\{title="Следите за балансом заранее"} Активный Pro снижает операционную нагрузку, потому что Rabbithole может пополнять канистру при необходимости. Если вы не используете Pro, настройте мониторинг или регулярно проверяйте баланс, особенно для On-chain Storage. ::: ## Технические детали Этот раздел нужен, если вы хотите понять приблизительные стоимости и внутренний поток пополнения. :::details\{title="Стоимость циклов и потоки пополнения"} ### Стоимость циклов Текущие приблизительные значения: | Ресурс | Стоимость | | -------------------------- | --------------------------- | | Создание канистры | \~0.5 TC | | Начальный баланс хранилища | 1.5 TC | | Stable Memory | \~127 GiB-seconds на цикл | | Вычисления (update call) | \~590K циклов на инструкцию | | Blob Storage (30 дней) | \~38.5B циклов за ГБ | | Blob upload | \~115.4B циклов за ГБ | | Blob download | \~76.9B циклов за ГБ | Эти значения являются операционными оценками для текущей конфигурации продукта. Стоимость Internet Computer, Blob Storage и обменные курсы могут меняться. **TC = триллион циклов.** 1 TC = 1 XDR. Оценка в USD является справочной и меняется вместе с курсом XDR/USD. ### Поток пополнения через CMC ```mermaid sequenceDiagram participant S as Storage canister participant B as Серверная часть Rabbithole participant T as Treasury / balances participant CMC as Cycles Minting Canister S->>B: ensureStorageCyclesForUpload() B->>B: Проверка Pro-статуса владельца B->>T: Включённое или платное пополнение T->>CMC: ICP transfer B->>CMC: notify_top_up(storage canister) CMC-->>S: Циклы добавлены ``` Канистра хранилища не создаёт циклы сама. Она запрашивает пополнение у серверной части Rabbithole, а та покупает циклы через Cycles Minting Canister. Если CMC возвращает неоднозначный статус, операция попадает в очередь восстановления для административной проверки. Это операционный механизм, а не обычное действие пользователя. ### Взаимодействие с Cashier (Blob Storage) ```mermaid sequenceDiagram participant UC as Ваша канистра participant CA as Cashier participant GW as Storage Gateway CA->>UC: _immutableObjectStorageRefillCashier() UC->>CA: Отправка циклов CA->>CA: Зачисление на платёжный аккаунт GW->>CA: Проверка бюджета перед загрузкой Note over CA: Учёт использования
по канистрам ``` Cashier использует pull-модель: он инициирует списание циклов с вашей канистры, когда платёжный аккаунт Blob Storage нуждается в пополнении. Эти циклы идут на хранение и передачу байтов в Blob Storage. Канистра должна иметь достаточно циклов и для собственных вычислений, и для оплаты хранения. ### Мониторинг Проверить баланс циклов канистры можно несколькими способами: - **В Rabbithole**: боковая панель хранилища показывает карточку **Canister Cycles**. - **Через `icp-cli`**: для полного статуса канистры используйте identity, связанную с вашим Internet Identity для `rabbithole.app`. Настройка описана в разделе [Как проверить владение](/ru/how-it-works/sovereignty/verify-ownership.md). ```bash icp canister status -n ic --identity rabbithole-app ``` - **Через NNS**: если канистра добавлена в NNS и управляется совпадающей identity. ::: --- url: /ru/how-it-works/pro.md --- # Что даёт подписка Pro Rabbithole Pro добавляет к уже созданному хранилищу функции, которые работают через Rabbithole: совместный доступ, обновления хранилища, автопополнение циклов и зашифрованные загрузки без ограничений базовой лицензии. Они не меняют модель владения: хранилище остаётся вашей канистрой Internet Computer. :::tip\{title="Коротко"} [Лицензия хранилища](/ru/how-it-works/payment.md#лицензия-хранилища-и-pro) даёт базовое персональное зашифрованное хранение. Pro добавляет функции, которые работают через Rabbithole: совместный доступ, обновления, автопополнение циклов и 2 TC включённого баланса циклов на период подписки. ::: ## Что входит в Pro Эти возможности доступны, пока Pro активен. | Возможность | Что меняется | | ------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Совместный доступ** | Вы можете делиться хранилищами, папками и файлами, управлять правами, обрабатывать запросы доступа и [приглашать по email](/ru/how-it-works/sharing/email-invites.md) людей, которые ещё не пользовались Rabbithole. | | **[Обновления хранилища](/ru/how-it-works/sovereignty/updates.md)** | После вашего подтверждения Rabbithole может установить новую версию кода или веб-интерфейса хранилища. | | **Зашифрованные загрузки без базовых ограничений** | Pro снимает ограничения базовой лицензии на размер зашифрованных загрузок и общий объём зашифрованного хранения. | | **[Автопополнение циклов](/ru/how-it-works/payment.md#как-работает-автопополнение-циклов)** | Если хранилищу нужны циклы перед операцией или при снижении баланса, Rabbithole может пополнить канистру автоматически. | | **2 TC включённого баланса циклов** | В каждый период Pro входит до 2 TC для автопополнения ваших хранилищ. Этот лимит общий для всех ваших хранилищ. | ## Как связаны автопополнение и 2 TC Канистрам Internet Computer нужны [циклы](/ru/getting-started/concepts.md#циклы): они оплачивают вычисления, память, хранение и сетевые операции. Pro включает автопополнение циклов для ваших хранилищ и даёт до **2 TC** на период подписки. 2 TC — это не отдельная канистра и не токены в вашем кошельке. Это лимит, который Rabbithole может потратить на пополнение ваших хранилищ в течение текущего Pro-периода. Если у вас несколько хранилищ, общий лимит расходуется на те канистры, которым нужны циклы. Обычно автопополнение срабатывает перед дорогой операцией, например перед большой загрузкой в [On-chain Storage](/ru/how-it-works/storage/on-chain-storage.md), или когда канистра приближается к безопасному минимуму циклов. 2 TC — это 2 триллиона циклов. На Internet Computer **1 TC = 1 XDR**. Любая оценка в долларах является справочной и меняется вместе с курсом XDR/USD. Если включённый лимит уже исчерпан, Rabbithole может продолжить платное автопополнение из вашего платёжного баланса. Это происходит только если вы включили такую настройку. ## Что Pro не меняет Pro добавляет сервисные функции, но не делает Rabbithole владельцем хранилища. - Хранилище остаётся самостоятельной канистрой Internet Computer. - Вы сохраняете контроль над канистрой. - Для обновления Rabbithole получает только временное окно доступа, которое подтверждаете вы. - Pro не даёт Rabbithole обходной доступ к файлам или ключам шифрования. - Правила доступа и выдача vetKeys по-прежнему проверяются в канистре хранилища. - Вы можете пополнять канистру вручную через IC-инструменты, даже если Pro не активен. ## Когда Pro не активен Без активного Pro вы продолжаете пользоваться хранилищем в рамках базовой лицензии: это персональное зашифрованное хранение в пределах выданных лимитов. До возобновления Pro недоступны возможности подписки: совместный доступ, управление доступом, обновления через Rabbithole, зашифрованные загрузки без ограничений базовой лицензии и автопополнение циклов. Если канистре нужны циклы, вы пополняете её вручную. ## Связанные страницы - [Оплата и циклы](/ru/how-it-works/payment.md) - [Совместный доступ](/ru/how-it-works/sharing/index.md) - [Обновления хранилища](/ru/how-it-works/sovereignty/updates.md) - [Хранение данных](/ru/how-it-works/storage/index.md) --- url: /ru/how-it-works/trust-model.md --- # Модель доверия ## Чему нужно доверять? У любой системы хранения есть модель доверия. Эта страница показывает, что Rabbithole убирает из пути доверия и чему всё ещё нужно доверять. Содержимое файлов шифруется в браузере до отправки. Rabbithole, инфраструктура хранения и операторы узлов не получают читаемый файл. Приватность и доступность — разные свойства. Шифрование защищает содержимое файла. Доступность зависит от режима хранения, баланса циклов и, для Blob Storage, правил удержания (retention) внешнего слоя хранения. Если поддержка TEE доступна на нужном IC-сабнете, она улучшает изоляцию среды исполнения. Rabbithole рассматривает TEE как дополнительный слой защиты, а не как основную гарантию приватности. ### Вам НЕ нужно доверять - **Команде Rabbithole** — мы не видим содержимое файлов в открытом виде - **Операторам узлов ICP** — они обрабатывают зашифрованные блобы - **Сетевой инфраструктуре** — шифрование происходит до отправки в сеть ### Вам НУЖНО доверять - **Коду шифрования** — он [открыт](https://github.com/rabbithole-app/v2), проверьте сами - **Вашему браузеру** — шифрование работает в JavaScript-движке браузера - **Internet Identity** — для аутентификации (тоже открытый код) - **Консенсусу ICP** — что сеть корректно выполняет код канистр ## Модель угроз Сначала разделим свойства. Шифрование защищает содержимое файла, контроль доступа решает, кто может запросить файл и ключ, а проверка целостности помогает обнаружить подмену байтов. В таблице ниже важно не одно слово «защищено», а граница: как устроена защита и что остаётся отдельной ответственностью. | Сценарий | Как устроена защита | Где граница | | ------------------------------------------- | ------------------------------------------------- | --------------------------------------------------------------------------------------- | | Команда Rabbithole получает доступ к файлам | Открытое содержимое не попадает к Rabbithole | Файл шифруется в браузере до загрузки | | Атака «человек посередине» | Браузер проверяет подлинность ответа и канала | Используются сертифицированные ответы IC и HTTPS | | Оператор узла ICP подглядывает | Узлы получают только зашифрованные данные | Данные уходят в IC уже после шифрования в браузере | | Государство запрашивает данные у Rabbithole | У Rabbithole нет открытого содержимого файла | Метаданные и сервисные записи не являются содержимым файла | | Вы потеряли устройство | Доступ можно восстановить через Internet Identity | Потерянное устройство всё равно нужно защищать системными средствами | | Нежелательное обновление вашей канистры | Установка новой версии требует контроллера | Если контроллер у вас, проверяйте код перед обновлением | | У канистры заканчиваются циклы | Приватность содержимого не меняется | Это проблема доступности: нужно ручное пополнение или активный Pro | | Blob Storage перестаёт хранить байты | Канистра хранит доверенную запись о файле | Доступность байтов зависит от финансирования Blob Storage и срока удержания (retention) | ## Rabbithole vs Традиционное облако ```mermaid flowchart TB subgraph Traditional["Традиционное облако (Google, Dropbox)"] direction TB U1[Вы] -->|загрузка| CS[Сервер компании] CS --> F1[Ваши файлы\nчитаемы компанией] MK[Мастер-ключ] --> CS GOV1[Государство] -->|может запросить данные| CS style CS fill:#fca5a5,stroke:#dc2626 style MK fill:#fca5a5,stroke:#dc2626 style GOV1 fill:#fef3c7,stroke:#d97706 end subgraph Rabbithole["Rabbithole"] direction TB U2[Вы] ==>|зашифрованная загрузка| CAN[Ваша канистра] CAN --> F2[Зашифрованные фрагменты\nнечитаемы] GOV2[Государство] -.-x|нечего расшифровать| CAN style CAN fill:#86efac,stroke:#16a34a style F2 fill:#86efac,stroke:#16a34a style GOV2 fill:#fef3c7,stroke:#d97706 end style Traditional fill:#fef2f2,stroke:#dc2626 style Rabbithole fill:#f0fdf4,stroke:#16a34a ``` ## Сравнение с другими решениями | Решение | Децентрализация | Требуемое доверие | Суверенитет данных | | ----------------- | :-------------: | :---------------: | :---------------------------------------------: | | Google Drive | — | Высокое | Нет | | Dropbox | — | Высокое | Нет | | Tresorit | — | Среднее | Частичный (E2E, но компания контролирует инфру) | | IPFS + Encryption | Высокая | Среднее | Частичный (нет встроенного шифрования) | | **Rabbithole** | **Высокая** | **Низкое** | **Полный (вы владеете канистрой)** | :::note\{title="Идеальных систем не существует"} Rabbithole снижает требования к доверию, но ни одна система не устраняет их полностью. Если вы найдёте уязвимость, [сообщите](https://github.com/rabbithole-app/v2/issues). ::: --- url: /ru/faq.md --- # Вопросы и ответы ## Суверенитет данных Здесь собраны вопросы о владении хранилищем: кто управляет канистрой и что останется под вашим контролем вне интерфейса Rabbithole. ### Кто контролирует мою канистру хранилища? В завершённом сценарии — только вы. Во время настройки или подтверждённого обновления Rabbithole временно становится контроллером, чтобы установить или повторить развёртывание, а затем удаляет себя при передаче контроля. Подробнее в разделе [Суверенитет данных](/ru/how-it-works/sovereignty/index.md). ### Могу ли я использовать свой фронтенд? Да. Ваша канистра обслуживает собственный фронтенд, который вы можете заменить. API канистры публичный — вы можете взаимодействовать с ним через [Candid](https://internetcomputer.org/docs/building-apps/interact/candid/candid-concepts). ### Что будет с данными, если я перестану платить? При On-chain Storage данные остаются в вашей канистре, пока у неё есть циклы. При Blob Storage канистра хранит запись о файле и данные проверки, но доступность самого blob зависит от финансирования Blob Storage и срока удержания (retention). Вы можете пополнять циклы напрямую, без участия Rabbithole. Если Pro истёк, хранилище возвращается к лимитам лицензии, выданной при создании хранилища. Владелец сохраняет персональное зашифрованное хранение в рамках лицензии, но автопополнение циклов и совместный доступ требуют активного Pro. ## Общие вопросы Это короткие ответы про базовую модель продукта и повседневные ограничения. ### Что такое Rabbithole? Децентрализованное файловое хранилище на Internet Computer, задуманное вокруг сквозного шифрования и владения персональной канистрой. ### Сколько это стоит? Вы платите фиксированную цену за создание хранилища. Она покрывает создание канистры, начальный баланс циклов, операции развёртывания, лицензию хранилища и инфраструктуру, нужную для передачи контроля. Лицензия задаёт включённый объём зашифрованного хранения и максимальный размер файла для базового сценария. Pro добавляет возможности поверх лицензии: зашифрованные загрузки без базовых ограничений, совместный доступ и автопополнение циклов. Подробнее в разделе [Что даёт подписка Pro](/ru/how-it-works/pro.md). ### Какие форматы файлов поддерживаются? Любые. Rabbithole хранит бинарные данные файла — формат не имеет значения. ### Есть ограничение на размер файла? Для зашифрованных загрузок лимит зависит от лицензии хранилища или активного Pro. Лицензия задаёт включённый объём зашифрованного хранения и максимальный размер одного файла. Активный Pro, помимо прочего, снимает эти ограничения базовой лицензии. Rabbithole не добавляет отдельный технический лимит на размер файла. Загрузка и шифрование работают по фрагментам, поэтому браузеру не нужно держать весь файл в памяти при работе с большими файлами. Практические ограничения всё равно возможны: при On-chain Storage файл записывается в канистру, и большие загрузки могут упереться в ограничения сабнета, где развёрнута пользовательская канистра, а также в баланс циклов. ### Почему загрузка иногда показывает Waiting for cycles? Так выглядит On-chain Storage загрузка, которой не хватает безопасного запаса циклов. Если у владельца активен Pro, Rabbithole может пополнить канистру и продолжить ту же сессию загрузки. Без Pro владельцу нужно пополнить канистру вручную. ## Безопасность Эти ответы кратко описывают модель конфиденциальности и восстановления доступа. ### Может ли команда Rabbithole читать мои файлы? Нет. В коде и интерфейсе Rabbithole нет механизма, который даёт команде отдельный доступ к пользовательским файлам. Браузер шифрует файл до загрузки, поэтому Rabbithole не получает открытые данные. Канистра хранит правила доступа и доверенные записи, а байты файла идут по выбранному режиму хранения уже в зашифрованном виде. ### Что будет, если я потеряю устройство? Вы можете восстановить доступ через механизм восстановления Internet Identity. Ключи выводятся из вашей идентичности, а не хранятся на конкретном устройстве. ### Проходил ли Rabbithole аудит? Код открыт и доступен для проверки сообществом. Формальные аудиты запланированы. ### Какое шифрование использует Rabbithole? AES-GCM с шифрованием каждого фрагмента. Ключи выводятся через пороговую криптографию vetKeys ICP. Подробнее в разделе [Шифрование](/ru/how-it-works/encryption/index.md). ## Техническое Эти ответы касаются разработки, самостоятельного развёртывания и прямой работы с канистрами. ### Где посмотреть базовые термины Internet Computer? Страница [Основные понятия](/ru/getting-started/concepts.md) объясняет Internet Computer, канистры, principal, Internet Identity, контроллеров и циклы в контексте Rabbithole. ### Можно ли развернуть Rabbithole самостоятельно? Да. Код [открыт](https://github.com/rabbithole-app/v2). Вы можете развернуть свои канистры и фронтенд. ### Можно ли написать свой клиент? Да. API канистр публичный. Вы можете создать любой клиент, который общается с канистрами через Candid. --- url: /ru/legal/privacy.md --- # Политика конфиденциальности **Последнее обновление: 31 мая 2026** ## Коротко Файловый путь Rabbithole зашифрован: мы **не можем** получить доступ к содержимому файлов. Файлы шифруются в браузере до отправки в сеть. У нас нет мастер-ключей и бэкдоров для расшифровки содержимого файлов. ## Что мы НЕ собираем - **Содержимое файлов** — мы не видим открытый текст - **Ключи шифрования** — они вычисляются через пороговую криптографию и не существуют в одном месте - **Пароли** — их нет; аутентификация через Internet Identity (ключи доступа, passkeys, или биометрия) - **Email-адреса по умолчанию** — регистрация не требует email. Если вы соглашаетесь передать подтверждённый email-атрибут, Rabbithole использует его для функций вроде доступа по приглашению на email и будущих уведомлений. - **История просмотров и данные отслеживания** — нет аналитики, cookies, сторонних трекеров ## Что мы обрабатываем ### Principal-идентификатор Internet Identity При входе ваш браузер генерирует криптографическую идентичность (principal-идентификатор) через Internet Identity: - Уникальна для Rabbithole (нельзя использовать для отслеживания в других приложениях) - Не связана с личной информацией - Хранится только на блокчейне Internet Computer ### Взаимодействие с канистрой Ваша персональная канистра хранения записывает: - Метаданные файлов (имена, размеры, структура папок) — хранятся в вашей канистре, не зашифрованы - Содержимое файлов — зашифровано до записи в выбранный режим хранения - Установленные вами права доступа Ваша канистра хранит записи о файлах, правила доступа и байты on-chain файлов. Байты Blob Storage файлов находятся вне канистры, а данные проверки хранятся в вашей канистре. После успешной передачи контроля Rabbithole удаляется из контроллеров. ### Платёжная информация При создании канистры хранения оплата покрывает сетевые расходы Internet Computer, начальный баланс циклов, операции развёртывания и связанную инфраструктуру Rabbithole. Мы не храним платёжные данные. ## Расположение данных Данные вашей канистры хранятся в [Internet Computer](https://internetcomputer.org), распределённом между независимыми узлами, управляемыми разными операторами. Операторы узлов не получают читаемое содержимое файлов. ## Хранение данных Данные сохраняются, пока у канистры есть циклы (топливо). Вы можете: - Пополнять циклы напрямую без Rabbithole - Удалить данные в любой момент - Экспортировать данные в любой момент Если Rabbithole прекратит существование, ваша канистра останется доступной по прямому URL, пока у неё есть циклы. On-chain файлы останутся в канистре; доступность Blob Storage файлов зависит от срока хранения Blob Storage. ## Сторонние сервисы - **Internet Identity** — провайдер аутентификации с открытым кодом, управляется DFINITY Foundation - **Internet Computer** — децентрализованная блокчейн-сеть - **Blob Storage инфраструктура** — используется, когда файлы хранятся вне канистры; она хранит шифротекст, а не читаемое содержимое файла Мы не используем Google Analytics, Facebook Pixel или другие сервисы отслеживания. ## Открытый исходный код Код [открыт на GitHub](https://github.com/rabbithole-app/v2). Многие технические утверждения в этой политике можно проверить по исходному коду. Операционные настройки, внешние провайдеры и поведение сети также могут влиять на работу конкретного развёртывания. ## Изменения Мы обновим эту страницу при изменении практик. Поскольку код открыт, все изменения видны в истории коммитов. ## Контакты Вопросы о конфиденциальности? Создайте issue на [GitHub](https://github.com/rabbithole-app/v2/issues) или напишите в [X (Twitter)](https://x.com/rabbithole_ic). --- url: /ru/legal/terms.md --- # Условия использования **Последнее обновление: 18 мая 2026** ## Обзор Rabbithole — децентрализованное зашифрованное файловое хранилище на блокчейне Internet Computer. Используя Rabbithole, вы соглашаетесь с этими условиями. ## Ваша канистра хранения При создании хранилища развёртывается смарт-контракт (канистра) на Internet Computer. После успешного завершения настройки: - **Вы единственный контроллер** — Rabbithole удаляет себя из контроллеров при передаче контроля. Во время настройки, повторной попытки или подтверждённого обновления Rabbithole может временно добавляться для установки, повтора или обновления развёртывания. - **Вы владеете данными** — канистра хранит владение, правила доступа и доверенные записи; on-chain файлы хранятся в канистре, а Blob Storage файлы хранят байты файла вне канистры - **Вы отвечаете** за баланс циклов канистры (операционное топливо) ## Что можно хранить Вы можете хранить любые файлы, легальные в вашей юрисдикции. Мы не можем прочитать содержимое файлов, потому что шифрование происходит в браузере. Вы несёте полную ответственность за то, что храните. ## Что мы предоставляем - **Веб-интерфейс** на rabbithole.app для управления файлами - **Сервис развёртывания канистр** для создания персонального хранилища - **Обновления фронтенда** для вашей канистры (опционально, вы контролируете принятие обновлений) ## Что мы не гарантируем - **Доступность rabbithole.app** — веб-интерфейс может быть временно недоступен. Однако ваша канистра остаётся доступной по прямому URL вне зависимости от статуса rabbithole.app - **Восстановление данных** — если вы потеряете доступ к Internet Identity, мы не сможем восстановить данные. У нас нет мастер-ключей или бэкдоров - **Управление циклами** — если у канистры закончатся циклы, она может быть удалена сетью Internet Computer. Вы отвечаете за поддержание достаточного баланса циклов ## Оплата - Создание хранилища требует одноразовой оплаты. Она покрывает создание канистры, начальный баланс циклов, операции развёртывания и связанные инфраструктурные расходы. - Оплата не возвращается после развёртывания канистры - Будущие пополнения циклов можно делать напрямую через Internet Computer без Rabbithole ## Интеллектуальная собственность - **Ваши файлы** остаются вашими. Мы не претендуем на владение или права на ваши данные - **Программное обеспечение Rabbithole** имеет открытый исходный код под лицензиями, указанными в [GitHub-репозитории](https://github.com/rabbithole-app/v2) ## Ограничение ответственности В максимальной степени, разрешённой применимым правом, Rabbithole предоставляется «как есть» и «по доступности», без каких-либо гарантий. Мы не несём ответственности за: - потерю данных из-за исчерпания циклов канистры, финансирования выбранного режима хранения, удаления или неудачного экспорта; - потерю доступа из-за Internet Identity, кошелька, браузера, устройства или сетевых проблем; - неудачные обновления канистры, повторные попытки или отклонённые обновления; - косвенный, случайный, специальный, последующий, штрафной или иной ущерб, возникший из-за использования сервиса. Ничто в этих условиях не ограничивает ответственность, которую нельзя ограничить по применимому праву. ## Прекращение - Вы можете прекратить использование Rabbithole в любой момент. Ваша канистра продолжит работать независимо - Вы можете удалить канистру и все данные в любой момент - Мы можем прекратить работу интерфейса rabbithole.app, но ваша канистра продолжит работать самостоятельно, пока у неё есть циклы. Доступность файлов зависит от выбранного режима хранения и финансирования хранения. ## Изменения условий Мы можем обновить эти условия. Изменения будут опубликованы на этой странице. Продолжение использования Rabbithole после изменений означает их принятие. ## Применимое право Эти условия применяются там, где это разрешено законом. Они не ограничивают неотчуждаемые права потребителей в вашей юрисдикции. Итоговые правила применимого права и места рассмотрения спора для платной операции также могут зависеть от юридического лица, кошелька, checkout-провайдера и юрисдикции, участвующих в этой операции. ## Контакты Вопросы? Создайте issue на [GitHub](https://github.com/rabbithole-app/v2/issues) или напишите в [X (Twitter)](https://x.com/rabbithole_ic). --- url: /ru/agent-resources.md --- # Ресурсы для агентов Этот сайт реализует [Agent-Friendly Documentation Spec](https://agentdocsspec.com/). Он публикует текстовые точки входа, которые AI-агенты могут загрузить перед ответом на вопросы о Rabbithole. ## Файлы для агента Используйте эти файлы, когда агенту нужно прочитать русскую документацию: - /ru/llms.txt: индекс документации со списком страниц. Используйте его, когда агент может загрузить только нужные страницы. - /ru/llms-full.txt: вся русская документация одним текстовым файлом. Используйте его, когда агенту нужен весь контекст документации и у него хватает контекстного окна. ## Что сказать агенту Передайте агенту такой запрос: ```txt Используй /ru/llms.txt с этого сайта документации как индекс документации Rabbithole. ``` ## Как скопировать одну страницу Ссылки на Markdown-версии отдельных страниц перечислены в `/ru/llms.txt`. Например: /ru/getting-started/introduction.md. При ручном просмотре используйте **Copy Markdown** в заголовке страницы, чтобы скопировать текущую страницу без навигации и оформления сайта. --- url: /ru/index.md --- # Rabbithole Зашифрованное хранилище на Internet Computer > Без паролей. Без мастер-ключей. Ваши файлы защищены математикой, а не обещаниями. [Почему Rabbithole](/ru/getting-started/introduction) | [Как работает шифрование](/ru/how-it-works/encryption) ## Features - 🏛️ **Личное хранилище**: Ваше хранилище — отдельная канистра Internet Computer с собственным веб-интерфейсом. После передачи контроля она принадлежит вам, а Rabbithole остаётся сервисом вокруг неё, а не владельцем данных. - 🔐 **Шифрование до загрузки**: Rabbithole шифрует файл до того, как он покинет ваше устройство. Хранилище работает с зашифрованными данными, а не с открытым файлом. - 🗝️ **Ключи по запросу**: Ключ файла не лежит готовым в хранилище или у Rabbithole. Он выводится через vetKeys в момент доступа и возвращается зашифрованным для вашего браузера. - 🤝 **Зашифрованный совместный доступ**: Вы можете делиться хранилищем, папкой или файлом, сохраняя шифрование. Rabbithole меняет правило доступа, а не создаёт вторую копию файла. - 🔒 **Вход без пароля**: Rabbithole использует Internet Identity для входа через passkeys, биометрию или поддерживаемый социальный вход. У Rabbithole нет отдельной базы паролей. - 📖 **Проверяемая модель доверия**: Rabbithole не просит верить только словам. Код открыт, а документация показывает, как работают шифрование, vetKeys, права доступа и владение хранилищем.