X-Net | | |
| Анонимная одноранговая пиринговая социальная сеть на базе сети Тор |
Устройство сети
Сеть состоит из одноранговых клиентов, связывающихся друг с другом через тор.
Клиенты соединяются другом с другом используя собственный протокол, основанный на json.
(Вместо технических объяснений - прилагается полный компилируемый исходный код проекта на java)
Пользовательским интерфейсом клиента является страница хтмл,
доступ к которой осуществляется либо через торбраузер по приватому тор-адресу,
если клиент развёрнут на удалённом хосте, либо через обычный браузер,
по адресу 127.0.0.1:21917, если клиент развёрнут на локальной машине.
Мобильный клиент будет со временем разработан, но пока со смартфона можно
заходить через мобильный Тор-браузер.
Все клиенты в сети связаны между собой. Каждый клиент обязательно
имеет 5 связей с соседями-клиентами.
По этим связям распространяются события клиентов и их поисковые запросы.
Адресация
При первом старте клиента, он генерирует для себя 20 тор-адресов.
5 адресов используются для связи с соседями-клиентами (каждый сосед знает другого по уникальному адресу),
3 используются для создания директ-соединений с контактами, по которым передается звук и видео.
3 адреса используются как слоты для скачивания, в работе файлообменного сервиса (см. ниже).
Три адреса "Приватный", "Приватный2" и "Приватный3"
- используется для личного доступа владельца к странице.
По этим адресам открывается защищённая пинкодом
страница пользовательского интерфейса владельца клиента.
Ещё один адрес "Персональный" - используется как адрес пользователя (владельца клиента),
связанный с ником, в сервисах поддерживаемых сетью, таких как мессенджер или форум.
Это адрес можно раздавать свои знакомым, чтобы они нашли вас в сети,
и смогли установить контакт.
Ещё один адрес "Публичный" - используется как публичный адрес клиента,
по которому находится страница с этим текстом и ссылкой на скачивание
дистрибутива клиента (см. TorWeb ниже).
Ещё один адрес "Финансовый" - используется как финансовый акаунт клиента.
Через этот адрес проходят все финансовые взаимодействия.
Ещё один адрес "API" - используется как адрес для api-запросов к клиенту.
И ещё один - "Сетевой" используется как адрес узла, для аутентификации
и установки связей с соседями.
Для поддержки работы git, для него создается еще один отдельный торадрес
на внутреннем порту 9418.
В системе отсутствует возможность прямо связать "Публичный", "Сетевой",
"Персональный", "Финансовый" и "Приватный" адреса.
(кроме адресов банков, у которых финансовый адрес связан с персональным)
"Приватный" адрес не предназначен для распространения, и желательно
должен содержаться в секрете.
Узнав его, можно попытаться подобрать пинкод и получить полный доступ
ко всем сервисам от имени владельца клиента.
Дополнительно, приватные адреса защищены рандомным внешним портом от 10000 до 65535.
Если выбранный рандомно порт конфликтует с существующим,
просто замените значение в torrc на то, которое не конфликтует.
Аутентификация клиента в сети и подключение
При старте, клиент должен включиться в сеть, т.е. установить
полнодуплексные сокетные соединения с 4 соседями.
В дистрибутиве содержится список адресов базовых технических узлов сети (backbone nodes).
При первом старте, клиент выбирает случайным образом из этого списка
один узел, и получает с него список сетевых адресов 111 случайных узлов сети
(56 байт на адрес, csv).
При дальнейших стартах, клиент больше не обращается к backbone nodes,
поскольку полученный список узлов уже хранится в его базе.
Дополнительный список узлов он может получить, обратившись с неавторизуемым запросом list
к любому узлу из своего списка.
Имея список узлов сети, клиент выбирает из него случайным образом узлы
и последовательно пытается подключиться к ним, пока не наберёт необходимое количество
соседей.
Каждый сосед подключается следующим образом:
При запросе подключения, первый клиент отправляет второму запрос со своим сетевым
торадресом и своим публичным ключом. В ответ, второй отправляет на полученый адрес свою случайную строку
и просит подписать её приватным ключом. Если подпись, проверенная полученым ранее публичным
ключом, валидна, то клиент 1 считается аутентифицированым и заносится в базу клиента 2.
После этого, второй клиент становится его соседом.
Если у второго клиента на момент запроса было 4 соседа, и при установке
нового соединения их стало 5, он опрашивает всех своих соседей по всем 5 адресам,
и спрашивает - у кого тоже есть 5 подключений.
Из тех у кого найдется 5, он выбирает самого тормозного, заключает с ним договор
о взаимном сокращении коннекта, и этот коннект освобождается (и у него и у партнера).
Так что в сети может быть максимум 1 клиент с 5 коннектами,
на 5 узлов с 4 коннектами, которые имеют 1 свободный канал
для подключения новых узлов.
До установки 4 коннектов, узел пытается найти соседей, периодически
опрашивая известные узлы, на предмет поиска новых соседей.
При установке соединения через сетевой адрес,
клиенты обмениваются адресами своих выделенных коннекторов, и в дальнейшем
сетевые события полученные о одного из соседей - бродкастятся по всем остальным соседям,
таким образом распространяясь по сети. (Детали реализации можно посмотреть в исходниках).
Для связи с каждым соседом, клиент выделяет один из адресов (neighbor_0 - neighbor_4),
на котором открывается серверный сокет, слушающий этот адрес на постоянный приём.
Для передачи данных этому соседу, используется канал, открытый с первого клиента,
на такой же серверный сокет второго.
Таким образом, между клиентами устанавливается полнодуплексное сокетное соединение,
где каждый из каналов "приём-передача", работает на своем торадресе,
и по каждому каналу идут данные только в одном направлении.
При поступлении события в сеть, времени на установку соединений не тратится,
поскольку все клиенты связаны прямыми, постоянно открытыми сокетными соединениям.
Поэтому события по сети распространяются очень быстро.
Роли
Все отношения между персонами регулируются ролями.
Информация о назначении и отзыве ролей передается грантором(тем кто выдает роль) сетевыми запросами
к соответствущему сервису каждого клиента. Роль передается вместе со своей цепочкой до рута.
При получении информации о новой роли в сети, каждый клиент проверяет эту цепочку от своего рута
(который у всех один) по подписям и ключам. Если вся цепочка валидна - роль заносится в базу.
Роли могут выдаваться как бессрочно, так и на определенный грантором срок, по истечении которого,
они автоматически становятся недействительными.
Роли также могут быть с парметрами или без (об этом чуть ниже).
Корневая роль ROOT - её владелец может грантить роль NET_SUPERVISOR.
Роль ROOT - синглтон, т.е. может быть назначена только одной персоне.
Эта роль не назначается, а хардкодится в код клиента разработчиком.
NET_SUPERVISOR и прочие - грантятся обычным порядком, и могут быть отозваны.
Все роли могут быть отозваны тем, кто имеет роль, которая может её грантить.
Не допускается наследование ролей - т.е. например, ROOT не может грантить
роль NET_ADMIN, а может только NET_SUPERVISOR.
Если ему нужно дать кому-то роль NET_ADMIN, то сначала он должен сам себе выдать роль NET_SUPERVISOR.
NET_ADMIN может грантить роли FORUM_CATEGORIES_MANAGER, BANKS_MANAGER, APP_CATEGORIES_MANAGER
Это всё были роли без параметров, и они бессрочны.
Далее, FORUM_CATEGORIES_MANAGER может грантить роль FORUM_CATEGORY_MANAGER.
Это уже роль с параметром, и параметр этот - путь в глобальном каталоге категорий форумов.
Роль FORUM_CATEGORY_MANAGER может грантить роли PUBLIC_FORUM_OWNER и COMMERCIAL_FORUM_OWNER,
в той категории, путь которой указан в качестве параметра роли FORUM_CATEGORY_MANAGER.
Роль PUBLIC_FORUM_OWNER уже имеет три параметра - адрес владельца форума, ид форума на машине владельца,
и опять же, путь в глобальном каталоге категорий форумов.
После того, как такая роль будет назначена, и известие об этом дойдет до вашего клиента сети,
В поле categoryPath данного форума запишется это путь, и при открытии соответствующего раздела
каталога форумов, вы и все пользователи сети, каждый на своем клиенте, будут видеть это форум.
(На самом деле, технически, все немного сложенее, но для специалистов всегда есть исходники.
Вся иерархия ролей - в энуме xnet.security.role.RoleTemplate.)
Каждая персона может давать роли FORUM_ADMIN и TOPIC_MODERATOR для своих форумов и топиков.
Роль FORUM_ADMIN также может грантить роль TOPIC_MODERATOR, помимо самого владельца форума.
В качестве параметров указываются данные форума или топика, соответственно.
Чтобы получить роль PUBLIC_FORUM_OWNER для определённой категории каталога (т.е. фактически, добавить
форум в глобальный каталог), нужно отправить запрос персоне с ролью FORUM_CATEGORY_MANAGER
с панели редактирования своего форума из категории personal.
Об остальных ролях читайте и спрашивайте на форуме "global/x-net/Как работает сеть",
в топике "Роли".
Ключи
До старта самого первого клиента,
разработчик генерирует корневой ключ (RSA 4096) для подписи апдейтов.
Публичный ключ этой пары включается во все дистрибутивы
и является корневым удостоверяющим ключом для данной сети.
Этим ключом подписывается роль ROOT, которая является корневой
для всех остальных ролей (см. пакет xnet.security.role).
Этот публичный ключ, персональный адрес, с которым связана роль ROOT,
и подпись этой роли корневым ключом - включены в код клиента.
При первом старте, каждый клиент создаёт Person с этим адресом и ключом,
а также Role с именем ROOT, назначенной этой Person.
(Для обозначения пользователя, мы используем два слова:
Person - это пользователь для других пользователей,
глобальная сущность, а User - это пользователь
для программы узла клиента, т.е. локальная сущность.)
При первом старте, клиент генерирует и записывает в базу три ключевые пары:
1. для узла сети, с которым связан сетевой адрес клиента (RSA 2048).
2. для собственной Person, с которым связан персональный адрес клиента (RSA 4096).
3. для финансовых операций, с которым связан финансовый адрес клиента (RSA 4096).
В дальнейшем, этими ключами подписываются прямые и сетевые запросы
к соответствующим сервисам других клиентов.
Обновления
Все обновления накатываются, по умолчанию, автоматически.
Номер версиии клиента включается во все запросы между клиентами.
Как только номер версии не совпадает - узел с большей по номеру версией
отвечает ошибкой, в описании которой содержится указание сменить версию,
информация об обновлении, подписанная корневым ключом,
и адрес с которого можно скачать дистрибутив (один из своих слотов slot_0 - slot_4).
При этом, всегда скачиваются рабочие файлы, и с того узла, который дал слот.
После скачивания, клиент проверяет скачанные файлы на валидность подписи, по
публичному ключу персоны с ролью ROOT (этот ключ хардкодится в дистрибутив каждой версии.)
Если дистрибутив валидно подписан рутом, то считается что всё ок, старый клиент
запускает новую версию и самовыключается по System.exit(0).
В настройках на панели Workshop/Server можно отключить включенную по умолчанию опцию
"autoRun After Update", и новая версия стартовать не будет. Старая версия клиента при
этом всё равно отключится, поскольку сеть не может работать с узлом неактуальной версии.
Поэтому, если вы так сделаете, вам придется запускать своего клиента вручную,
как в первый раз, после каждого обновления (не забудьте сменить номер версии в своём батнике!).
И самое главное, в этом случае, чтобы быть уверенными в том, что код вашего клиента
не модифицирован с момента его остановки, вам придётся скачать дистрибутив новой версии,
и запустить испоняемый файл клиента из него. Либо сверять хэш-суммы обновлённых
файлов с сайта xnet.info или xnetinfo2ug7eno7.onion.
В случае автозапуска, эту проверку делает предыдущая версия,
и вам не нужно будет каждый раз заходить на сервер, чтобы перезагрузить клиента.
Клиент спроектирован так, чтобы его можно было поставить один раз,
и забыть про сервер вообще. Все файлы и база данных зашифрованы.
Настроив бэкапы, можно не беспокоиться о его дальнейшей судьбе.
Даже если вы потеряете доступ к серверу, где размещен клиент,
вы всегда сможете полностью восстановить его из бэкапов.
Бэкапы
Каждый узел сети может быть бекапным клиентом и бэкапным сервером.
Панель Workshop/Backup разделена на две панели:
"Client backup tasks" и "Server backup permissions"
Чтобы создать задачу (task) бекапа, нужно указать адрес персоны,
кому принадлежит сервер, на который вы хотите бекапиться.
Если у вас нет никого знакомых в сети, можно поднять еще одного
своего клиента на другом сервере, и использовать его как бэкапный.
Указав адрес, максимальный объем бэкапа и интервал, нужно нажать
на generate и сгенерировать идентификатор задачи (task key).
После этого можно отправить запрос владельцу бекапного сервера.
Он получит этот запрос и увидит его на панели "Server backup permissions".
После этого он сможет или одбрить его или удалить.
Если запрос одобрен, в списке задач у этой задачи появится кнопка "активировать",
и при её нажатии бэкапы начнут выполняться.
Можно создавать сколько угодно задач бэкапа на разные сервера.
Нагрузку для сети они не создают, поскольку всё взаимодействие между бэкап-клиентом
и бэкап-сервером происходит напрямую.
При создании задачи бэкапа будет предложено сохранить пароль и ключи от бэкапа
в отдельный файл. Этим не стоит пренебрегать, поскольку без данных из этого файла
восстановить бэкап будет невозможно.
Что бэкапится:
Бэкапится файл базы данных (приватные ключи к тор-адресам хранятся в базе),
файлы ключей, и все файлы из категорий private и protected.
Чтобы восстановить клиента из бэкапа, нужно скачать дистрибутив нового клиента
актуальной версии, и запустить его с параметрами адрес_бэкап__сервера,
идентификатор_задач, пароль_от_бэкапа.
Эта команда, с правильными параметрами, как раз и записана в том файле,
который нужно сохранить.
Новый клиент скачает бэкап, рашифрует его, создаст тор-адреса и записи в торрц,
и стартанёт уже в рабочем состоянии.
Старый клиент и старые торадреса, конечно, должны быть выключены.
Сервисы сети и приложения
Сервис - это распределённое приложение, работающее на клиентах сети.
Сервисы бывают встроеные и подключаемые.
Встроеные сервисы: хранение и поиск файлов, мессенджер, блог, форум,
платёжный сервис, торговый сервис, биржа, бэкап.
Код этих сервисов встроен в основной дистрибутив клиентского приложения.
Подключаемые сервисы называются приложениями (Apps) :
Git, облачное файлохранилище, бухгалтерия, органайзер, файлообмен,
хантинг, знакомства, тесты, игры и т.д.
Код этих сервисов реализован в виде отдельных исполняемых jar файлов,
запускаемых основным клиентом. Они взаимодействуют с клиентским кодом только
через API, согласно установленным разрешениям, и не имеют прямого доступа к его базе.
Обновляются как обычные файлы приложения, подписанные разработчиком и двумя ревизорами кода.
Глобальные сетевые сущности
ГСС - это объекты сохраняемые в базе данных (Entity), создаваемые на одном клиенте,
распространяемые по сети, и сохраняемые на других клиентах.
Каждая глобальная сетевая сущность(гсс) имеет идентификатор состоящий из трёх частей.
Первая часть - короткое имя класса сущности (Forum, Topic, Message, ExchangeOffer, и т.д.)
Вторая часть - хэш персонального ключа владельца клиента (owner), на котором была создана сущность.
Третья часть - уникальный ид сущности в базе клиента на машине владельца.
Таким образом, например, идентификатор моего форума с ид 1 будет выглядеть так: Forum_cuom2u3ik7uygko2_1
(На самом деле, первая часть идентификатора (класс сущности) опускается,
и восстанавливается где это нужно из контекста. т.е. это будет просто: cuom2u3ik7uygko2_1)
В зависимых сущностях, таких как топик, сообщение и комментарий, такой идентификатор
будет плохо информативен - т.е. для поиска по нему придётся произвести большое количество вычислений.
Поэтому, для таких сущностей используются синтетические идентификаторы, построенныые по аналогичному принципу.
Это будет показано на примере, в разделе Форумы, ниже.
Форумы
Как видно на панели Форумы, каждый форум может существовать в какой-то из категорий:
Глобальной(global), Персональной (personal) или Кастомной (custom выборочной).
В глобальной категории находятся форумы, которые видны всем клиентам сети.
В персональной - форумы которые создал владелец клиента.
В кастомной - персональные форумы контактов(см. про мессенджер ниже.), которые владелец добавил себе.
Изначально, все форумы создаются в персональной категории.
Пресональные форумы и сообщения в них - видны только их участникам, т.е. тем кто на них подписан.
Любой из ваших контактов может посмотреть список ваших форумов, и подписаться на любой из них.
Процесс подписки на персональный форум, состоит в том, что подписчик получает список всех персон,
подписанных на этот форум, и адрес подписчика включается в список подписанных на данный форум.
Информация о этом событии рассылается всем ранее подписанным.
Далее, когда кто-нибудь из подписанных публикует сообщение, его клиент рассылает это сообщение
по списку рассылки данного форума, и оно записывается в базы каждого из подписчиков.
Если подписчик "проспал" рассылку, то при пробуждении, его клиент проверит все такие форумы,
и соберёт пропущеные сообщения и коменты.
Если владелец форума посчитает, что его форум может представлять интерес для глобального сообщества,
и захочет добавить свой форум в раздел глобал, то он выбирает в глобале соответствующую
его форуму категорию, и отправляет запрос менеджеру данной категории
(кто есть менеджер, т.е. кому отправлять запрос, программа клиента определяет по наличию соответствующей
роли FORUM_CATEGORIES_MANAGER в его базе )
После того как менеджер получит запрос, он может его одобрить (или нет).
Процесс одобрения состоит в том, что владельцу данного форума менеджером категории грантится роль
PUBLIC_FORUM_OWNER, с двумя параметрами: глобальный ид сущности этого форума
и путь в глобальном каталоге форумов.
Событие о назначении роли рассылается по сети, и новая роль записывается в базу на каждом клиенте.
По наличию этой роли, остальные клиенты узнают, что форум стал глобальным, и в какую категорию его поместить.
В глобальном форуме сообщения рассылаются по другому принципу, чем в персональном.
Когда кто-то на своем клиенте отправляет сообщение или комент в глобальный форум,
это сообщение рассылается по всей сети как глобальное событие (точнее, сначала не само сообщение,
а его глобальный индекс), так что каждый клиент сети узнаёт об этом.
По этому индексу видно (см. ниже как именно), в каком топике опубликовано сообщение.
Если владелец клиента подписан на этот топик (оранжевая буква U перед названием топика
означает, что пользователь на топик не подписан. Чтобы подписаться, нужно нажать
на эту букву и выбрать фид), то его клиент отправляет сетевой запрос на поиск этого сообщения
по его глобальному индексу, скачивает его через одного из своих соседей и сохраняет у себя.
Если пользователь на топик НЕ подписан, то программа клиента уведомление о новом сообщении игнорирует.
Чтобы просмотреть старые сообщения в подписаном топике, нужно нажать команду refresh вверху.
Поскольку в сети существует как минимум один узел на котором точно есть это сообщение - узел автора,
то оно обязательно будет найдено, даже если у топика всего один подписчик.
При рассылке запроса поиска сообщения, если его нет у соседа - сосед опрашивает своих соседей,
и т.д., пока не найдется, либо пока все сетевые запросы не упрутся друг в друга.
Если сообщение не найдено - значит машина клиента внезапно отключилась после отправки события
о новом сообщении, и до того, как успела отдать текст сообщения хотя бы одному другому клиенту.
В этом случае, клиент подписчика будет периодически (примерно раз в 15 минут) опрашивать сеть
на предмет поиска таких сообщений (без тела - с одним индексом).
Сообщения форума могут редактироваться автором.
При правке поддерживается версионирование сообщений, т.е. разница между правками
сохраняется в поле "дельта" объекта сообщения. (в разработке)
Все сообщения и коменты форума подписываются приватным ключом автора, и проверяются
принимающим клиентом по публичному ключу автора.
В базе каждого клиента хранятся адреса и публичные ключи всех персон, информация о которых
проходила через клиента (сообщения форума, распространяемые запросы сервисов, и т.д.).
Эти персоны, если они не в контактах пользователя, заносятся в невидимую группу "транзит" (см. Контакты.)
Публичный ключ персоны всегда доступен по её персональному сетевому адресу, без авторизации.
Если клиент видит какой-то адрес без ключа, он идёт по этому адресу, берёт оттуда публичный ключ,
и записывает его себе в базу.
Модерация
Топик может быть модерируемым, что определяется в его настройках.
Модератором может быть любой, кому владелец форума выдал роль модератора.
Если модератор не назначен - модератором считается сам владелец.
В модерируемом топике, все сообщения и коменты в сначала приходят к модератору,
и после того как он их одобрит, отправляются с его машины, от имени автора, как обычные
сообщения(по способу в зависимости от типа форума - глобальный или персональный).
В интерфейсе модератора, сообщения ожидающие модерации выделены жёлтым цветом фона заголовка.
До одобрения и отправки сообщения в паблик, модератор может в комментарии к этому сообщению
попросить автора исправить ошибки, автор может ему ответить, и т.д.
Эта предварительная переписка будет видна только автору и модератору.
Разрешение спорных вопросов (RFC)
В случае. если модератор и автор не сойдутся во мнениях по поводу возможности
публикации данного сообщения, автор может обратиться последовательно, к
владельцу форума (если это не одна персона с модератором), менеджеру глобального
каталога форума, менеджеру глобальных каталогов форума, администратору сети, и супервайзору сети.
Обращения в "вышестоящую инстанцию" - платные.
Модератор форума вносит залог(если форум локальный - то владельцу форума, а если глобальный,
то менеджеру каталога) в размере 100 рублей (суммы будут уточнены, и здесь для примера
приводятся условные).
Для обращения к владельцу форума по поводу конфликта с модератором, автор перечисляет владельцу
свои 100 рублей. Обе суммы, и модератора и автора блокируются на счёте владельца форума.
В своём интерфейсе владелец форума читает конфликтную переписку, и принимает решение.
Либо в пользу модератора, либо в пользу автора, или добавляет свои комментарии
к конфликтной переписке.
После принятия решения общая сумма залогов (200р.) перечисляется на счёт выигравшей
в споре стороны, за вычетом 10% арбитру - т.е владельцу форума, в этом случае.
Для локальных форумов верховным судьей является владелец форума,
а для глобальных - супервайзор сети.
Рут - робот, и поэтому в разрешении конфликтов человеков участия не принимает.
В случае конфликта в глобальном форуме, ставка для каждого следующего этапа обращений
увеличивается в 2 раза. т.е. За обращение к менеджеру каталога нужно "поставить на кон"
уже 200р. Соответственно увеличивается и размер выигрыша до 400р.
(При обращении к менеджеру каталогов это будет уже 400р, админу сети 800р, супервайзору - 1600)
Эскалирование конфликта может производиться только без пропусков уровней.
Т.е. на решение модератора можно пожаловаться только владельцу форума,
на решение владельца - менеджеру каталога, на решение менеджера каталога
- менеджеру каталогов, на него - админу сети, на админа - спервайзору.
В глобальных форумах, должности модератора выборные.
Частый вопрос - можно ли заблокировать комментарии к сообщению в глобальном форуме.
В принципе - это было бы можно реализовать технически.
Нужно было бы указать в метаданных сообщения, что комментарии к нему запрещены,
и программно обязать всех клиентов следовать этому правилу.
Т.е. ограничить возможности пользователя клиента (что-то вроде умного авто,
которое не разрешает проезжать на красный свет).
Однако, такой подход создал бы перекос в сторону интересов автора сообщения,
против интересов читателей данного сообщения.
Желание автора не видеть комментарии - удовлетворялось бы за счет отнятия у читателей
возможности это сообщение прокомментировать, что вряд ли бы им понравилось.
А поскольку читателей по определению больше, в данном случае, рационально было бы
учитывать интересы большинства.
Так как исходный код открыт - никто не сможет запретить сделать твик,
и это ограничение обойти.
Поэтому, чтобы не провоцировать пользователей на твики и форки, при проектировании системы
мы старались следовать принципу наименьших ограничений, который можно сформулировать так:
"Ограничения должны быть минимальными, и применяться только там, где их отсутствие
может привести к технической невозможности выполнения заявленой функциональности."
Как пример того, что бывает если не следовать данному принципу, можно рассматривать
появление этой сети, как результата запретительной деятельности "регуляторов" в открытом интернете.
Экспорт форумов в тор и открытый интернет
В заголовке форума, после его названия, виден знак #.
Нажав на него, в алерте появится внешняя тор-ссылка на данный форум.
Знак # виден, когда форум выбран(цвет названия зелёный), и его доступ равен all.
В экспортированом форуме отсутствует возможность отправлять сообщения и комментарии,
но видны все сообщения и комментарии, картинки в них, и доступны для прослушивания и просмотра
аудиозаписи и видео.
Топики в экспортированом форуме упорядочены по номеру.
Изменить порядковый номер топика можно на панели редактирования топика.
Для доступа с локальной машины - нужно заменить тор-адрес на 127.0.0.1:21918.
Для организации доступа через обычный интернет-адрес, можно арендовать
самый простой впс, установить на нём яву и тор, и запустить Toxy (ссылка внизу страницы xnet.info),
указав внешний порт и целевой адрес - тор-адрес из ссылки.
ИП этого впс и внешний порт Toxy будут публичным интернет-адресом
экспортированого форума, по которому он будет доступен через обычный браузер.
Контакты и Мессенджер
В клиента сети встроен мессенджер, позволяющий обмениваться сообщениями и файлами.
Ваш адрес для этого мессенджера в сети xnet - это ваш персональный тор-адрес,
без окончания ".onion". Он виден на панели "I am".
Любой другой пользователь сети может послать вам по этому адресу предложение установить контакт.
Вы увидите это предложение как новый контакт в группе "incoming"
После того как вы приняли предложение, контакт перемещается в группу "mutal",
и у вас и у контакта появляется возможность запросить список персональных форумов контакта,
и публичные данные (из поля "public data" на панели "I am").
Вы также можете отклонить передложение контакта (в этом случае он сможет послать вам его повторно),
или забанить этот контакт, и никогда больше не получать от него приглашений.
Забаненные контакты видны в группе "banned".
Разбанивание происходит путём удаления контакта их этой группы.
В случае, если приглашение посылаете вы - новый контакт появится у вас в группе "outgoing".
В приглашении можно отправить до 256 символов текста.
Пока приглашение не принято - написать контакту невозможно.
Кроме видимых групп контактов - существуют две скрытые,
которые не отображаются: группа "transit" и группа "system".
В группу транзит - записываются авторы сообщений и комментариев
в глобальных форумах.
В группе систем - всегда два контакта - это сам пользователь,
и рут (персона, чьей подписью валидируются все роли).
Это два пользователя, которым нельзя отправить сообщения или предложение контакта.
Все контакты организованы в стандартные группы (incoming, outgoing, mutal, trusted, banned, transit, system).
Какждый контакт может находиться(и находится) только в одной группе.
Создание новых групп - невозможно, но можно перевести контакт из группы в группу.
При принятии предложения контакта, он переводится из групп incoming или outgoing,
в группу mutal - автоматически.
Также, при забанивании транзитного контакта (например с форума),
он автоматически переводится в группу banned.
Для гибкого группового управления контактами - используются списки.
Количество списков не ограничено.
Каждый контакт может быть занесён в любое количество списков.
Списки, также как и группы, используются для задания прав доступа к форумам и топикам.
Вы можете, например, разрешить доступ к определённому топику только контактам из такого-то
списка(или группы). Или запретить комментировать сообщения в топике персонального форума
одному списку но разрешить другому. Или разрешить всем, кроме тех кто в списке, и т.д.
Группа "trusted" не имеет своего технического смысла, а используется
для разделения контактов по степени доверия пользователя.
Финансы | (кошельки, переводы, коды, банки, эмиссия, ввод-вывод, обмен) |
Внутренние деньги сети икснет называются, соответственно, икс-мани (x-money).
Искмани существуют во всех валютах. Их код образуется из буквы икс(X) и
международного кода валюты. Например - xRUB, xUSD, xBTC, xDASH
Поддерживаются все валюты. Можно выпускать и погашать коды,
выставлять счета и делать переводы между счетами.
В переводах и кодах возможно указание зашифрованного комментария.
Переводы, а также выпуск и погашение кодов, производятся без комисси (0%).
Время прохождения перевода - примерно 15 секунд.
Кошельки
Управление счетами(кошельками) находится на панели Services/Finance X-Money
Кошелёк иксмани для определённой валюты предствляет собой пару приватный-публичный
ключ длиной 4096 бит, которая генерится на клиенте пользователя.
Клиент подписывает все транзакции этого кошелька его приватным ключом.
Затем приватный ключ этой пары шифруется хэшем SHA1 от случайной 12-словной фразы(bip39).
Этот хэш SHA1 является паролем восстановления.
Затем создаётся объект "кошелёк", адресом которого является цифровой самовалидирующийся хэш от публичного ключа.
Адрес, публичный ключ, зашифрованный приватный ключ, хэш MD5 от ключевой фразы, включены в поля этого объекта.
Затем этот объект отсылается в первый попавшийся банк, который становится его регистратором.
Регистратор проверяет валидность подписей владельца нового кошелька по публичному ключу,
подписывает эту запись своей подписью, ставит в поле "регистратор" свой адрес,
и рассылает запись нового кошелька по всем банкам.
После чего отдаёт клиенту свою подпись.
После этого клиент считает кошелёк зарегистрированным, и может проводить с ним операции.
Фон поля кошелька становится из желтого белым.
Если доступ к клиенту потерян, то при сохранении 12-словной фразы восстановления,
можно скачать нового клиента с любого узла или поднять из имеющегося дистрибутива,
и ввести в нём ДО создания хотя бы одного кошелька, фразу восстановления.
Хэш MD5 этой фразы будет отослан в запросе на восстановление в первый случайный банк,
и если кошелёк был валиден, то он обязательно будет в его записях,
и будет найден по хэшу MD5 фразы восстановления.
Записи о всех кошельках хранятся в базах всех банков сети.
Поэтому, если кошелёк вдруг не найдётся в первом случайном банке
(может быть, этот банк только активировался, и еще не успел синхронизироваться с сетью),
то клиент отправляет запрос в следующий по случайному списку банк.
И если кошелёк не найден, значит или его не было, или фраза восстановления
введена неправильно (хотя там строгий валидатор).
Запись найденного кошелька возвращается клиенту отправившему запрос,
и он, хэшем SHA1 (уже не MD5, который публичен и известен всем, а SHA1,
который никогда с клиента не уходит), расшифровывает приватный ключ от
этого кошелька, и записывает его данные в базу нового клиента.
После этого кошелек становится виден в списке на панели Services/Finance X-Money,
и им можно полностью управлять.
Переводы и коды
Переводы осуществляются двумя транзакциями - транзакция списания и транзакция зачисления.
Транзакция списания списывает деньги с кошелька, и хранится во всех банках до
зачисления.
При появлении в сети клиента целевого кошелька, он инициирует транзакцию зачисления.
После проведения транзакции зачисления, запись транзакции списания уничтожается.
При запросе транзакция списания, вместо целевого кошелька может быть указан код.
В этом случае, транзакцию зачисления инициирует владелец кода, и указывает при этом свой кошелек как целевой.
Код генерируется на клиенте оправителя и включает в себя информацию о валюте и сумме.
Код самовалидируемый. Последние 4 цифры кода - начало хэша от предыдушей части.
Операционный банк(каждый раз случайно выбирается клиентом для проведения транзакции)
находит транзакцию списания для данного кода (по хэшу кода указанному инициатором),
и отправляет её инициатору.
Инициатор указывает код, и отправляет запрос банку. Банк проверяет код, и если он совпадает с хэшем,
указанным в транзакции списания отправителем, производит транзакцию зачисления как при обычном переводе.
Баланс кошелька не хранится в каком-то поле, а является вычисляемой величиной.
Это разница между суммами поступления и списания с данного кошелька.
Эти суммы всегда только увеличиваются.
Разделение баланса на сумму списания и сумму поступления, позволяет рассинхронизировать
процессы зачисления и списания. Т.е нам не нужно блокировать кошелёк для зачисления,
когда мы производим транзакцию списания, и наоборот.
Транзакция зачисления всегда инициируется получателем, поэтому он и определяет
порядок зачисления транзакций, если их есть несколько.
В кошельке указан номер последней транзакции списани и номер последней транзакции зачисления.
Поэтому, к исполнению может быть принята только транзакция с большим номером.
Технически, всё происходит немного сложнее, чем тут кратко описано.
Для полного понимания, смотрите исходный код классов в пакете xnet.srv.finance.
Банки
За осуществление переводов отвечает сеть клиентов, владельцы которых
имеют роль BANK_OWNER. Для простоты, такой клиент называется банком.
Такие клиенты обязаны размещаться на мощных серверах с безлимитным каналом,
и быть доступны не менее 99,9 времени.
Поскольку вся информация во всех банках одинаковая, т.е.
каждый банк хранит данные всех кошельков, такая сеть является одним
логическим "неубиваемым" банком.
Пока в сети существует хотя бы один банк, в ней смогут идти переводы.
Чем больше банков в сети, тем надежнее она работает.
Однако, с увеличением количества банков, при существующей архитектуре связей банков
"каждый с каждым", возрастает и время проведения транзакции.
Поэтому количество банков ограничено 10.
Каждый банк анонимен и находится в неизвестной геолокации, поэтому
фактора репликации 10, по любым разумным меркам, достаточно,
чтобы гарантировать практически 100% надежность системы.
Эмиссия, ввод-вывод и обмен
Откуда изначально в системе образуются иксмани?
Новые иксмани образуются при переводе на привязанный к кошельку счёт Монеро (XMR)
Остальное
Какие и для чего бывают кошельки,
как проводятся транзакции, как предотвращается двойное списание или зачисление,
как синхронизируются данных в банках, как выпускаются и гасятся коды,
как устроено шифрование комментариев к транзакции, и другие технические подробности
могут быть получены на форуме разработчков сети (см. ниже Разработка)
или самостоятелно, при чтении исходного кода клиента.
Всеми функциями финансового сервиса можно управлять через апи клиента (см. ниже АПИ).
Торговля
Сервис в разработке.
Позволит создавать магазины и витрины, с партнёрской программой.
Витрина может быть представлена как отдельный вебсайт магазина,
как в торе, так и в открытом интернете.
В витрине будет "изкоробки" включен прием оплаты икскодамии и криптовалютам даш и биткоин.
Для покупателей все товары будут доступны на панели Торговля/Товары.
Управление магазином будет происходить с панели Торговля/Магазин.
Более подробное описание работы торгового сервиса будет опубликовано на форуме сети
после запуска сервиса.
TorWeb
TorWeb - это встроенный вебсервер, понимающий только GET запросы.
Он слушает http запросы на публичном адресе клиента (см. Адресация),
и отдаёт по ним содержимое директории tor_web клиента (аналог eprst-сайта в i2p).
Например, если имя файла на машине клиента /opt/xnet_work/tor_web/images/moikotik.jpg,
а публичный адрес iywaxrdk7t6xk6p7.onion, то картинка котика будет отдаваться
по адресу http://iywaxrdk7t6xk6p7.onion/images/moikotik.jpg .
С панели управления(Services/TorWeb disableTorWebListener) можно отключить прослушивание
порта 21918 клиентом, и поднять на нём свой вебсервер с ..., ну в общем с чем хотите.
Пока, файлы в директорию tor_web нужно загружать вручную, но планируется сделать
загрузку, удаление, перемещение и переименовывание файлов - на панели Services/TorWeb.
Если вы читаете этот текст с сайта xnet.info, то вы видите файл about.html,
который, на самом деле, находится на машине клиента разработчика, и отдаётся через TorWeb.
Доступ к клиенту, с сервера xnet.info, происходит через Toxy.
Та же страница доступна напрямую из тора, по адресу http://xnetinfo2ug7eno7.onion/about.html
Через внешний тор-адрес TorWeb также отдаются специальные запросы других сервисов.
Эти запросы определяются по зарезервированым префиксам:
"shared/", "forum/", "git/", "shop/", "app/".
Файлы
Клиент сети имеет собственное хранилище файлов.
Как видно на панели "Services/File Storage", в хранилище имеются три категории:
private protected shared
В каждой категории содержится одинаковая структура директорий,
для каждого из поддерживаемых типов контента: audio image other text video
В каждой из этих директорий есть еше директория cache, куда записываются транзитные
файлы, и файлы отправленные в аттачах сообщений.
Кроме категории private. В ней нет директории cache, поскольку приватные файлю с машины
пользователя никогда не уходят и не приходят.
В директориях типов контента можно создавать свои директории любого уровня вложенности
и как угодно их перемещать внутри типа, удалять и переименовывать.
Нельзя только изменять название и перемещать директорию cache.
Шифрование
Приватная директория используется для хранения личных секретных файлов,
доступ к которым есть только у пользователя.
Все файлы в ней шифруются основным секретным ключом пользователя.
Это тот же самый ключ, который используется для шифрования базы данных.
Он зашифровани пинкодом, и расшифровывается при его введении.
Протектед директория используется для хранения файлов, которыми можно делиться со своими контактами.
Файлы в ней также хранятся в зашифрованном виде, и расшифровываются в памяти программы, в момент передачи.
Принимающий такой файл клиент, шифрует его своим ключом, и сохраняет в кэш протектед директории.
Сответственно, сторонний наблюдатель случайно зашедший на сервер с клиентом, увидит в поддиректориях
private и protected, только списки зашифрованных файлов с зашифрованными именами.
В поддиректориях директории shared - файлы не шифруются, и доступны всем, по публикуемой ссылке.
В эту директорию нужно помещать файлы, которые потом могут быть назначены как ваш аватар.
А также те файлы, которые вы хотите опубликовать в сообщениях глобального форума.
Поиск файла в сети
Универсальным идентификатором файла в сети xnet - является его 40 символьный хэш SHA1.
Но, на каждом клиенте у файла с одним и тем же хэшем могут быть разные имена.
Поэтому, поиск можно вести по дву параметрам на выбор - либо по хэшу файла, либо по его названию.
В случае поиска по названию будут выданы столько вариантов, сколько будет несовпадающих хэшей.
В результате запроса будет также указан тип контента файла.
Поисковый запрос отправляется по всей сети, и анализируется каждым клиентом.
Пришедшие ответы (без дублирвания) показывается в результатах поиска.
Нажав на ссылку результата - можно или загрузить себе найденный файл, или просмотреть или прослушать.
Глобальный поиск осуществляется только в поддиректориях категории shared.
Api
Все сервисы клиента можно вызвать через програмный интерфейс приложения, т.е. API.
Любой метод может быть вызыван через api, если он аннотирован @ApiCallable.
Подробное описание работы с api, с интерактивными примерами,
находится на панели Workshop/API
Технические детали реализации обработки вызова апи, можно посмотреть в классе ApiListener
и остальных классах пакета xnet.api.server.
Для вызова методов апи из кода на java-совместимых языках, есть библиотека xnet-api.jar.
Вместе с исходниками xnet-api.src.zip, она упакована в архив xnet-api.zip
Как ей пользоваться и где взять, написано на панели Workshop/API/Java.
Ключи API
Управление ключами апи находится на панели Workshop/API
Там можно создать ключ, назначить ему разрешения (permissions), и отозвать их.
А также удалить ключ.
Разрешения необходимые для ключа, указаны в сигнатуре вызываемого метода,
при помощи параметра KeyPermission аннотации @ApiCallable
Например, аннотация метода погашения икс-кода UserReplenishService.redeemCode(String, String),
вызывается с аннотацией @ApiCallable(KeyPermission.REDEEM_CODE)
Т.е у ключа апи, чтобы вызывать этот метод, должно быть разрешение KeyPermission.REDEEM_CODE.
Разрешение также может иметь параметр, указывающий, к какому именно параметру
вызываемого метода должно применяться данное разрешение.
Например, вызов метода UserWithdrawService.withdrawMoney(String, String, String, Long, String)
аннотируется как @ApiCallable(KeyPermission.WITHDRAW_MONEY) , но если мы посмотрим в код
самого разрешения в класе KeyPermission, то увидим что в его конструкторе есть параметр
KeyPermissionParamName.sourceAddress ( WITHDRAW_MONEY(KeyPermissionParamName.sourceAddress, ALL_WITHDRAW) ).
Соответственно, параметр sourceAddress должен присутствовать(и точно с таким именем - sourceAddress),
в методе withdrawMoney (это нужно знать, только если вы решите написать новый сервис для клиента).
По значению этого параметра, при вызове данного метода, проверяется, выдано ли разрешение
этому ключу, именно для этого адреса кошелька.
Сам адрес(sourceAddress), для которого разрешен вызов данным ключом,
указывается при создании ключа, в соответствующем поле значения параметра разрешения.
При проектировании конструкции разрешений, была заложена возможность наследования разрешений.
т.е. если у ключа есть разрешение родителя, то у него есть и все разрешения-потомки.
Например, если у ключа есть разрешение ALL_FINANCE, то этот ключ может управлять
движением по всем внутренним и внешним счетам.
Полная структура иерархии разрешений ключей видна в классе xnet.api.server.KeyPermission.
На панелях вкладки Workshop/API доступно полное описание методов апи.
X-Auth
Система аутентификации пользователя клиента сети на любом стороннем сайте,
через апи его клиента.
Используется владельцами сайтов для аутентификации своих клиентов через икс-нет.
Чтобы её использовать, посетитель сайта должен иметь своего клиента сети икс-нет.
Владелец сайта должен добавить в свой интерфейс два поля с адресом апи клинета
- одно в профиль пользователя, и одно на страницу логина.
На сайте посетитель(владелец клиента) вводит, в соответствующее поле в своём профиле,
тор-адрес апи своего клиента (виден в клиенте на панели Workshop.../I am).
Далее, для входа на этот сайт, владелец клиента вводит на панели логина сайта
свой адрес апи, и нажимает кнопку "войти через икс-нет".
Сайт по адресу апи, сохранённому в профиле ранее, находит акаунт пользователя,
и отдаёт ему пинкод из 4 цифр, который отображает на панели логина сайта.
Далее, с этим пинкодом сайт отправляет лонг-полл запрос на адрес апи клиента.
На старнице управления клиентом (она должна быть открыта), возникает модальное окно
с вопросом: "Запрошен вход на сайт такой-то, с пинкодом таким-то".
Если пинкод в модальном окне клиента совпадает с пинкодом на странице логина сайта,
вы жмёте кнопку ок. Если нет - то, соответственно, отмену.
Если вы нажали ок, сайт получает на свой длинный запрос ответ ок,
и впускает вас.
Скоро будут рабочие примеры.
Код и разработка
Код бэкэнда клиента сети, который мы предлагаем как базу для дальнейшего развитя сообществом,
написан на java и реализован в отдельном maven-проекте.
Код фронтэнда - на AngularJS (сборка на jsp), также реализован в отдельном проекте.
Ссылка на исходные коды клиента в виде архивов проектов Eclipse, находится на этой странице.
В ближайших планах - встраивание git в клиента сети, как приложения.
Оплата труда разработчиков
Все коммерческие сервисы работающие в сети, платят небольшую комиссию.
Сумма этой комисси образует фонд развития сети.
Из фонда развития 40% идёт на оплату труда разработчиков, пропорционально количеству
написанного кода в байтах (без комментариев) и коэффициента ценности кода от 1 до 5
(candidate, junior, middle, senior, guru).
Код автора разработки, написанный до начала совместной разработки, учитывается весь с коэффициентом middle.
Если в проект включается код приложения, либо код отдельного сервиса,
то он весь в сумме также оценивается как middle.
Остальные коэффициенты применимы только к правкам в проекты.
Для оценки труда дизайнеров будет выработан коэффициент "graphicsToCode".
Пример: если нас на проекте, например, двое - вы и я, и я написал 1мб кода с коэффициентом middle(3),
а вы 100 кб, с коэффициентом сеньор (4), то мой относительный код будет 1*3 - 3мб, а ваш - 100*4 - 400 кб.
итого в сумме будет 3400 кб. Соответственно, если 40% от фонда развития за месяц
будут составлять, например, точно 3400 рублей, то вы получите 400 рублей, а я - 3000.
Сколько бы мало кода ни написал разработчик, этот код всегда будет составлять какой-то процент
от кода проекта, и поэтому начисления и выплаты по нему будут идти всё время существования проекта.
Выплаты производятся раз в месяц.
Решение о включении кода в проект и его коэффициенте принимает автор разработки.
Все вопросы возникшие после прочтения этого раздела, можно задать
в глобальном форуме разработчиков в сети Икснет: global/x-net/Development.
Администрирование сети
Другие 40% из фонда развития идут на оплату труда администраторов сети.
К администраторам относятся технические администраторы базовых узлов сети,
менеджеры категорий каталогов форума и приложений, модераторы глобального форума,
ревизоры кода приложений, арбитры и аудиторы.
Они получают фиксированную ежемесячную оплату, и премии в соответстви с их техническим рейтингом.
Общественные проекты
Ещё 20% из фонда развития сети образуют фонд оплаты общественных проектов.
Из этого фонда производятся оплаты проектов, за которые проголосовало
как сообщество налогоплательщиков, так и сообщество не-налогоплательиков.
Такой подход позволит избежать перекоса интересов как сторону владельцев сервисов,
так и в сторону их пользователй, и даст гарантию, что будут финансироваться
только те проекты, которые принесут пользу всем.
На момент написания, система выплат технически не реализована, и ждёт своих разработчиков.
Поддержать проект материально
Вы можете перечислить в фонд развития сети любую сумму.
Адреса в криптовалютах:
BTC 3BpGyQcC55iXGYsVUKddtUKSqe4TahACBT
LTC MUx7dwzBPMkHzdfftMoXLJFjyiYLBc1tWX
DASH XqBuD2PN1rmUFJZUSYU59o8qtiFZcpQcjj
BEAM 1632f8be98b549d3d63c31f42ed2e4c9a2ebe25216fb3968cd0664e004aa4a47180
Для целевого финансирования проектов сети - свяжитесь с администратором.
Если вы установите клиента, то вы сможете финансировать выбранные вами
проекты сети, переводами со своего внутреннего счёта
(который можно пополнить теми же криптовалютами).
Все вопросы, возникшие после прочтения этого раздела, можно задать
в глобальном форуме, в топике: global/x-net/Other/about.