# ADR-016: Контакты и приглашения — по нику

Закрывает открытый вопрос о механике добавления контакта.

## Контекст

Ник — единственный идентификатор пользователя (ADR-005). Ссылки-приглашения, QR-коды, поиск и каталог пользователей — отдельные сущности со своим жизненным циклом. При открытой регистрации (ADR-015) нужен ещё и механизм согласия: иначе любой, кто знает ник, может писать кому угодно.

## Решение

**Контакт.** Пользователь вводит точный ник. Сервер отдаёт публичный ключ и создаёт запрос контакта. Адресат видит запрос и принимает или отклоняет. Сообщения 1:1 ходят только между взаимными контактами. Поиска по части ника и каталога нет.

**Ключи.** Публичный ключ контакта сохраняется на устройстве при первом получении и больше с сервера не перечитывается. Если сервер когда-либо вернёт для этого ника другой ключ — клиент показывает предупреждение и не шифрует на новый ключ без явного подтверждения. Отпечаток ключа виден в карточке контакта; сверка вне канала — по желанию пользователя, автоматики нет.

**Комната.** Участник приглашает в комнату только своих контактов — добавлением в состав, без отдельного согласия: согласие уже дано на уровне контакта. Не хочешь — выходишь. Создатель комнаты может исключать участников. Любое изменение состава — rekey (ADR-007).

**Блокировка.** Отклонить запрос можно с блокировкой ника: сервер не доставляет от заблокированного ни сообщений, ни новых запросов.

## Следствия

- Серверу достаточно таблиц контактов (пара ников, статус) и блокировок. Новых сущностей — инвайтов, ссылок, токенов — нет.
- Ник надо знать заранее и передать вне Bare. Это ограничение осознанное: Bare — инструмент для людей, которые уже знакомы.
- Закрепление ключа защищает от подмены ключа сервером после первого контакта. Первый контакт — доверие на слово (TOFU): активно-злонамеренный оператор в модели угроз и так за пределами защиты.
- Спам ограничен структурно: чужому нельзя написать, пока он не принял запрос; сами запросы — под лимитами (ADR-017).