В конце прошлого года делал архитектурную проработку проекта для одного иностранного заказчика.
Идея так и не пошла к реализации.
Решил опубликовать здесь один из документов этого проекта, чтобы было.
Сразу выскажусь по поводу цензуры в Интернет.
Я отношусь к ней, скорее, негативно, но лучше соблюдать некий баланс между свободой распространения информации и государственными политиками, чем лишиться даже тени этой свободы. Предлагаемый проект, как мне кажется, этот баланс обеспечивает.
Идеология разделения прав в инфраструктуре распределённой децентрализованной системы Git.Введение Настоящий документ является кратким описанием разделения прав в инфраструктуре распределённой децентрализованной системы Git НЕ привязанным к особенностям реализации. Он может быть употреблён как при реализации с использованием блокчейн, так и при реализации без использования блокчейн (torrent-like). И в том и в другом случае реализация может быть сделана с применением современных средств криптографии.
На текущий момент представляется целесообразной реализация с использованием блокчейн для хранения метаданных о сущностях системы, но это не является окончательной позицией и требует проработки.
Общая идеология подхода состоит в следующем:
- не существует централизованного управления правами. К системе может подключиться кто угодно.
- внутри системы разделяются и структурируются интересы тех, кто осуществляет хостинг проектов (физическое хранение), в дальнейшем,
хостеров, управление непосредственно проектами (в дальнейшем
мейнтейнеры проекта),
контрибьюторами проектов (в дальнейшем
контрибьюторы) и управлением допустимостью контента (в дальнейшем –
ведущие групп). Это – разные роли, с разными возможностями.
- необходимость выделения ведущих групп как отдельной роли вытекает из необходимости обеспечить стыковку системы с правилами работы в разных юрисдикциях. Одновременно, группы будут использоваться для продвижения проектов и обеспечения удобства навигации пользователей.
Общая схема работыПроекты принадлежат мейнтейнерам, управляются мейнтейнерами и модераторами, открывающими проекты на чтение и/или запись другим пользователям/контрибьюторам.
Проекты объединяются в иерархические
группы, адресуемые и управляемые по аналогии с группами и их иерархиями в Usenet (network news). Мейнтейнеры подают заявку проекта на вступление в группу, ведущие группы либо разрешают вступление, либо отказывают в нём. В дальнейшем, они могут исключить проект из группы, также ведущий проекта может выйти из группы в одностороннем порядке. Группы могут таким же образом вступать в другую группу или выходить из неё. Группа или проект может входить в несколько групп, но циклическое присутствие в иерархии недопустимо и отсекается на уровне структур данных и ПО.
Хостеры размещают на своих серверах (физических, или арендованных в облаках виртуальных машинах) проекты. Размещение осуществляется либо по прямому указанию проекта (обычно это нужно для разработчиков конкретного проекта), либо автоматически, путём указания приемлемых групп (при указании группы можно разрешить автоматическое размещение проектов, входящих в её подгруппы.
Проекты и мейнтейнерыПроект обладает полной аналогией со стандартным проектом системы Git.
К проекту относится вся совокупность относящихся к нему файлов и каталогов с историей их изменений, пользователей проекта с правами доступа к нему.
Каждый проект ведётся одним
мейнтейнером или несколькими
мейнтейнерами, если первоначальный мейнтейнер делегировал другим мейнтейнерам соответствующие права. Дисциплина взаимодействия мейнтейнеров между собой и разрешения конфликтов между ними – предмет отдельного документа по мере развития проекта.
Дополнительно, мейнтейнер может предоставить другим пользователям права
модератора, совпадающие с правами мейнтейнера за исключением права включать или отзывать права у других мейнтейнеров и/или модераторов.
Таким образом, мейнтейнер – владелец проекта, с полными правами по распоряжению им, модератор – доверенный служащий. Мейнтейнер может сменить модератора, а модератор мейнтейнера не может.
Мейнтейнеры и модераторы имеют возможность открывать проект или отдельные его каталоги (репозитории) /их ветки отдельным пользователям (возможно также реализовать внутрипроектную механику групп пользователей для облегчения управления).
Таким образом, для любого проекта существует единственная(!) точка авторитетности, заданная его мейнтейнерами.
Группы проектов и ведущие группГруппы проектов являются логическим объединением проектов, визуально и структурно аналогичные группам Usenet. Однако, в отличие от Usenet допускается вхождение одного и того же проекта (или группы) в разные иерархии, но без образования циклов.
Примеры групп
python
python.ml
python.ml.facerecogn
euacceptable.python
chinaacceptable.python
porno
porno.gay
и т.д.
Ведущие групп подают заявки на включение своих групп в вышестоящие группы.
Например, владельцы группы python, посвящённой opensource разработке на языке python могли бы подать заявку на включение своей группы в группы euacceptable. и chinaacceptable, соответствующим “приемлемым для законодательства ЕС” и “приемлемым для законодательства Китая” проектам. А владельцы группы porno могли бы подать такую заявку на вхождение в группу euacceptable, а в chinaacceptable их бы наверное не взяли.
У проектов возможности аналогичные, с той лишь разницей, что в проект не могут входить другие проекты и группы.
Владелец проекта или группы в любой момент и в одностороннем порядке может вывести проект или группу из вышестоящей группы.
Для управления входящими в группу проектами и группами у ведущего группы есть следующие механизмы:
- разрешить вступление
- отказать в заявке на вступление
- в одностороннем порядке удалить
Вывод может распространиться как на всю группу целиком, так и на входящие в неё проекты или группы. Например, владельцы группы euacceptable могли бы разрешить вхождение в неё группы .python, но, потом, удалить из неё euacceptable.python ml.facerecogn из-за законодательных ограничений ЕС на распознавание лиц и сбор биометрии.
При этом такое удаление не повлияло бы на присутствие группы facerecogn в иерархии python.ml и chinaacceptable.python.ml.
Названия групп верхнего уровня могут присваиваться либо желающими путём саморегистрации по принципу “кто первый взял” (и защищаться криптографическими методами), либо выдаваться централизовано. Это зависит от дизайна системы и должно решаться Заказчиком.
Серверы и хостерыХостер управляет одним или несколькими логически обьединёнными в кластер серверами хранения проектов. Для внешнего мира кластер серверов логически не различим, имеет общее имя.
Хостер управляет следующими политиками
сервера:
- что хранить (настраивается на уровне групп и проектов)
- кому из пользователей системы разрешить подключаться через свой сервер (тут могут быть и индивидуальные разрешения, и классовые, например, для всех желающих и какие-то более сложные варианты – об этом см. раздел
Прочие возможности.
Дополнительно хостером может устанавливаться та или иная политика peer-обмена с другими серверами, в том числе с использованием стратегий, аналогичных стратегиям torrent или nntp серверов.
Пользователи и контрибьюторыПользователи (на чтение) и контрибьюторы регистрируются в системе глобально.
Для подключения к системе они могут работать через сторонний сервер (режим lite-клиента) или поднять свой собственный локальный сервер.
Доступ к конкретному проекту осуществляется в зависимости от его настроек или свободным образом, или путём посылки запроса и получения подтверждения запроса от одного из модераторов. Это подтверждение может быть отозвано.
Прочие возможностиСервера и проекты могут устанавливать политики доступа пользователей к себе, в том числе требования по полному или частичному раскрытию анонимность пользователей. Например, сервер может пускать на себя только верифицированных пользователей, устанавливая возможные способы верификации (валидация почты, валидация телефона, что угодно ещё).
Сервер может доверять верификации другого сервера, последний в таком случае, имеет статус
верификатора.
В отличие от систем, основанных на биткоин и эфир, для предлагаемой системы не рационально использование принципа “кто потерял ключ – тот потерял доступ и информацию”. Более рациональным предлагается использование концепций PKI, реализующих управление ключами пользователей, включая их публикацию, отзыв/замену и т.д.
Техника и возможности ограничения доступа к информации и цензурыИнформация внутри проекта хранится в зашифрованном виде, при этом шифрование используется таким способом, чтобы обеспечить контроль мейнтейнеров над проектом.
Сервера со своего уровня не имеют доступа к расшифрованному содержанию проектов, а пользователи, имеющие доступ хотя бы на чтение – имеют.
Из этого вытекает, что, распространяя информацию проектов, сервер может и должен учитывать только метаинфомацию о проекте, но не должен анализировать его содержание. Эта задача возлагается на мейнтейнеров проектов и ведущих групп.
При возникновении конфликтной ситуации, требующей от мейнтейнера безвозвратного (без доступа в истории правок) удаления некоего объекта, сам факт удаления объекта с определённым ID инициируется мейнтейнером, а соответствующее обновление проекта распространяется по всем серверам-хостерам.
При этом фактическая недоступность удаляемого контента обеспечивается на двух уровнях:
- корректно работающий сервер должен отрабатывать удаление такого контента и, в дальнейшем, не предоставлять доступ к нему
- мейнтейнер может отозвать индивидуальный ключ, которым зашиврован этот элемент контента. При этом, если он не закэширован у конечного пользователя или где-то ещё, то расшифровка не удалённых, а закэшированных элементов контента новыми клиентами будет невозможна или затруднена
Разумеется, возможны те или иные стратегии, когда мейнтейнер или сервер игнорируют распоряжения об удалении контента или третьи лица создают клон (копию) проекта с информацией, подлежащей удалению. С копиями напрямую бороться невозможно.
С мейнтейнерами, систематически не соблюдающими требования по удалению контента можно бороться административными методами, отключая их от соответствующих групп.
При этом, серверам внутри конкретной юрисдикции (Китай, ЕС или какая-то ещё страна) могут быть выставлены требования по обязательному использованию в качестве корневых групп, ориентированных на поддержку соответствующих юрисдикций.
Таким образом, цензура будет осуществляться “гладким”, относительно бесконфликтным способом, неугодные проекты будут вытесняться из той юрисдикции, где они нежелательно в те, где они приемлемы. Доступ конечных пользователей, при этом, может быть настроен через страновые сервера (или по принципу самостоятельной ответственности – на внешние сервера, без прямого контроля за этой системы).
https://golosptic.livejournal.com/1710760.html
thesz
