Перейти к основному содержанию

Публичный RPC без разрешения

Первоначальное публичное предложение RPC существовало как выпуск GitHub, написанный в старой терминологии плеббита. Эта страница переписывает эту идею на языке Bitsocial и представляет ее как предложение на уровне продукта, а не как стену подробностей реализации.

Цель, сформулированная простым языком​

Bitsocial Forge может запускать публичную службу RPC, которая позволяет многим пользователям удаленно управлять своими собственными сообществами Bitsocial, не превращая оператора в хранителя этих сообществ.

Сервис должен сделать мобильных и легких клиентов практичными, сохраняя при этом три ограничения:

  1. По умолчанию пользователи остаются изолированными друг от друга.
  2. Разрешения остаются явными и детальными.
  3. Совместимость с текущим запросом RPC и формой ответа можно сохранить во время развертывания.

Какую проблему решает​

Сегодня простейшая модель RPC обычно работает по принципу «все или ничего»: один ключ аутентификации, один домен полномочий, полный доступ. Это работает для одного оператора, но не для общедоступной многопользовательской службы.

Публичный RPC без разрешений нуждается в более сильной модели:

  • один сервис может обслуживать множество пользователей
  • каждый пользователь получает свои сообщества и лимиты
  • политики, определяемые оператором, могут предотвратить злоупотребления
  • пользователь все равно может уйти или самостоятельно разместиться позже

Базовая модель​

Пользователи​

Каждый пользователь получает учетные данные для аутентификации и пакет разрешений.

Сообщества​

Сообщества, созданные с помощью службы, назначаются записи владельца. Право собственности отслеживается явно, поэтому методы управления могут быть доступны конкретному пользователю.

Разрешения​

Разрешения основаны на возможностях. Вместо одного логического значения «можно использовать RPC» сервер может управлять:

  • сколько сообществ может создать пользователь
  • какие методы управления доступны
  • какие операции публикации разрешены
  • какие ограничения по ставкам применяются
  • какие административные поверхности видны

Администраторская поверхность​

Сам общедоступный RPC должен оставаться сосредоточенным на поведении RPC, ориентированном на пользователя. Административные задачи, такие как создание пользователей, передача прав собственности и проверка аудита, относятся к отдельному API оператора и информационной панели.

Позиция совместимости​

В пользовательской документации следует использовать такие термины Bitsocial, как сообщество и профиль.

На уровне проводов первое развертывание все еще может сохранить текущую форму транспорта и полезной нагрузки JSON-RPC, если это полезно для совместимости. Другими словами: документация больше не должна выглядеть так, как старая документация плеббита, даже если в переходный период некоторые устаревшие имена методов или формы запросов остаются за кадром.

Предлагаемый пакет разрешений​

type PermissionBundle = {
  maxCommunities: number; // 0 = unlimited
  methods: {
    createCommunity: boolean;
    startCommunity: boolean;
    stopCommunity: boolean;
    editCommunity: boolean;
    deleteCommunity: boolean;
    publishComment: boolean;
    publishVote: boolean;
    publishCommentEdit: boolean;
    publishCommentModeration: boolean;
    publishCommunityEdit: boolean;
    getComment: boolean;
    getCommentPage: boolean;
    getCommunityPage: boolean;
    fetchContent: boolean;
    resolveAuthorAddress: boolean;
    commentUpdateSubscribe: boolean;
    communityUpdateSubscribe: boolean;
    communityListSubscribe: boolean;
    settingsSubscribe: boolean;
  };
  rateLimits: {
    requestsPerMinute: number;
    publishesPerHour: number;
  };
  storage: {
    maxTotalSize: number;
  };
  scope: {
    canPublishExternal: boolean;
    canReadExternal: boolean;
  };
  admin: {
    canTransferOwnership: boolean;
    canManageUsers: boolean;
    canViewAuditLogs: boolean;
    canViewAllCommunities: boolean;
  };
};

Точные названия методов носят иллюстративный характер. Важной частью является форма политики: отдельные возможности контролируются независимо, а не объединяются в один токен суперпользователя.

Порядок подключения​

client connects with auth credential
-> server validates the credential
-> server loads the user's permission bundle
-> server returns a permissions notification
-> client proceeds with the subset of actions it is allowed to use

Осведомленность о разрешениях должна оставаться необязательной. Клиент, игнорирующий уведомление, по-прежнему может вести себя корректно, обрабатывая стандартные ошибки авторизации на сервере.

Обеспечение соблюдения прав собственности​

Когда служба создает сообщество, она должна автоматически назначить право собственности вызывающему пользователю. Оттуда:

  • Действия по запуску, остановке, редактированию и удалению сообщества доступны только владельцу.
  • список и ответы на подписку по умолчанию относятся к собственным сообществам вызывающего абонента
  • более широкая видимость — это явное разрешение администратора, а не значение по умолчанию.

Один крайний случай имеет большое значение: если пользователь подписывается на сообщество, которое ему не принадлежит, сервер должен предоставлять только общедоступное состояние, которое должен видеть любой внешний наблюдатель. Конфигурация, доступная только владельцу, или внутренние данные времени выполнения никогда не должны просачиваться через API подписки.

Рекомендуемая поверхность оператора​

API администратора может оставаться скучным и явным:

  • список пользователей
  • проверить одного пользователя
  • создавать или обновлять пользователей
  • удалять пользователей
  • передать общественную собственность
  • проверять журналы аудита

Аутентификация для этого API оператора должна быть полностью отделена от аутентификации RPC конечного пользователя.

Этапы внедрения​

Этап 1​

  • создать структуру публичного проекта RPC
  • добавить записи пользователей и отслеживание прав собственности
  • разветвить или расширить текущий сервер RPC

Этап 2​

  • реализовать пакеты разрешений
  • применять их на уровне метода RPC
  • возвращать метаданные разрешений при подключении

Этап 3​

  • добавить API оператора
  • добавить журнал аудита
  • добавить аутентификацию администратора

Этап 4​

  • отправить панель администратора
  • протестировать средства контроля злоупотреблений
  • ужесточить ограничения скорости и квоты на хранение

Открытые вопросы​

Спам с учетными данными для аутентификации​

Если создание аутентификации обходится дешево, государственным службам может потребоваться уровень запроса перед выдачей учетных данных. Один из возможных путей — повторно использовать саму модель вызова сообщества, чтобы выдача учетных данных наследовала ту же философию борьбы со злоупотреблениями, что и остальная часть сети.

Устаревшее именование​

Некоторые ранние реализации могут по-прежнему предоставлять устаревшие имена методов внутри для совместимости. Это следует рассматривать как деталь миграции, а не как постоянный общедоступный словарь документации Bitsocial.

Краткое содержание​

На самом деле это предложение направлено на одно: сделать публичную инфраструктуру RPC полезной, не превращая ее в хранилище. Хороший публичный Bitsocial RPC должен ощущаться как дополнительная помощь для управления сообществами, а не как новая центральная платформа, которая возвращает право собственности через черный ход.