Привет, меня зовут Михаил Подивилов. Я специализируюсь на сетевых технологиях и преподаю в Сетевой академии Cisco.

Matrix замечательный, но недооценённый децентрализованный протокол обмена сообщениями с прилагающимся к нему клиентом Element, который я считаю достойной и жизнеспособной альтернативой Telegram.

Рассказываю, почему я использую Matrix вместо Telegram, как присоединиться к сети Matrix и настроить свой сервер.

Почему я использую Matrix вместо Telegram

На Хабре уже писали про Matrix, но я считаю, что этому протоколу нужна большая огласка: чем больше людей о нём узнает и начнёт его использовать тем лучше как для протокола, так и для айти-тусовки.

Matrix это открытый и децентрализованный протокол мгновенного обмена сообщениями, разрабатываемый энтузиастами из Matrix.org Foundation.

Спецификации протокола, равно как и клиент-серверная часть (Synapse как сервер и Element как клиент) находятся в открытом доступе в отличие от Telegram, который в настоящее время в открытом доступе держит только свой клиент, что вызывает немало вопросов по поводу безопасности использования протокола MTProto.

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

Клиент Element обладает всеми современными функциями, которые присущи другим популярным мессенджерам (за исключением голосовых сообщений).

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

• Децентрализация возможность поднять свой сервер для подключения к сети Matrix
• Приватность сквозное шифрование
• Групповые аудио- и видеозвонки для пользователей с разных серверов
• Отличное API для ботов
• Полнофункциональный веб-клиент
• Консольные клиенты

Почему не Jabber?

Потому что протокол XMPP переполнен многочисленными XEP-ами, которые так и не были никогда не реализованы во многих его клиентах. Например, до сих пор не существует ни одного Jabber-клиента c нормальной синхронизацией истории с сервером.

Почему не Signal?

Потому что Signal не поддерживает децентрализацию.

Почему не Telegram?

Потому что исходные коды протокола MTProto, который используется в Telegram, никогда не были опубликованы.

Конечно, Telegram больше любят за его UI/UX но Element на данный момент почти ничем не уступает Telegram: там есть и мосты, и комнаты, и боты, и даже стикеры а вот людей относительно мало. К сожалению, проекту в действительности не хватает хорошего пиара.

Как подключиться к Matrix через чужой сервер

Это очень просто просто используйте веб-клиент Element или его десктопную версию. Регистрация не займёт у вас больше минуты.

Как подключиться к Matrix через свой сервер

Для этого необходимо настроить свой HomeServer на Synapse официальном сервере Matrix. Ниже я привёл инструкции, как это можно сделать.

Процесс настройки сервера Synapse мало чем отличается на разных дистрибутивах Linux основное отличие заключается в том, какую команду необходимо отдать операционной системе, чтобы та поняла, какой пакетный менеджер нужно использовать для установки.

Я буду объяснять на примере дистрибутива Ubuntu Server 20.04.

Шаг 1. Установка сервера Synapse

Подготавливаем нашу рабочую среду к установке сервера Synapse:

sudo apt install -y lsb-release wget apt-transport-httpssudo wget -qO /usr/share/keyrings/matrix-org-archive-keyring.gpg https://packages.matrix.org/debian/matrix-org-archive-keyring.gpgecho "deb [signed-by=/usr/share/keyrings/matrix-org-archive-keyring.gpg] https://packages.matrix.org/debian/ $(lsb_release -cs) main" |    sudo tee /etc/apt/sources.list.d/matrix-org.list

Загружаем непосредственно сам Synapse:

sudo apt updatesudo apt install matrix-synapse-py3

В процессе установки пакета будет запрошено название доменного имени, на котором будет располагаться ваш сервер Synapse. Как правило, это домен вида matrix.example.com, где A-запись поддомена matrix указывает непосредственно на ваш сервер с запущенным Synapse.



После установщик спросит вас, хотите ли вы отправлять анонимную статистику разработчикам.



На этом установка сервера Synapse завершена. Теперь необходимо включить Synapse при загрузке операционной системы:

systemctl start matrix-synapsesystemctl enable matrix-synapse

Мы также можем убедиться, как идут дела у сервера и работает ли он в принципе:

systemctl status matrix-synapsess -plnt

Шаг 2. Настройка сервера Synapse

Используйте текстовый редактор (например, nano или vim) и откройте файл /etc/matrix-synapse/homeserver.yaml для редактирования.

Найдите строку listeners: и приведите секцию в следующий вид:

listeners:  - port: 8008    tls: false    type: http    x_forwarded: true    bind_addresses: ['127.0.0.1']    resources:      - names: [client, federation]        compress: false

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

enable_registration: false

Сгенерируйте случайную строку и поместите её в раздел registration_shared_secret:

registration_shared_secret: ""

После сохранения файла с настройками не забудьте перезапустить Synapse:

systemctl restart matrix-synapse

Шаг 3. Настройка Let's Encrypt

Сертификат необходим в том случае, если ваш сервер не находится за Cloudflare или другим подобным сервисом.

Для начала необходимо установить certbot программу для выпуска сертификатов:

sudo apt install certbot -y

И выпустить сертификат для вашего доменного имени:

certbot certonly --rsa-key-size 2048 --standalone --agree-tos --no-eff-email --email example@example.com -d matrix.example.com

Готово. Ваш сертификат теперь находится по адресу /etc/letsencrypt/live/matrix.example.com/.

Шаг 4. Настройка Nginx в качестве Reverse Proxy

В этой конфигурации мы будем использовать 80 порт для незащищённого соединения, 443 для защищённого и 8448 для подключения к федерации Matrix.

server {    listen 80;    server_name example.com;    return 301 https://$host$request_uri;}server {    listen 443 ssl;    server_name example.com;    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;    location /_matrix {        proxy_pass http://localhost:8008;        proxy_set_header X-Forwarded-For $remote_addr;        # Nginx by default only allows file uploads up to 1M in size        # Increase client_max_body_size to match max_upload_size defined in homeserver.yaml        client_max_body_size 10M;    }}server {    listen 8448 ssl;    server_name example.com;    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;    location / {        proxy_pass http://localhost:8008;        proxy_set_header X-Forwarded-For $remote_addr;    }}

Не забудьте перезагрузить Nginx после внесения изменений в конфигурацию:

systemctl restart nginx

Шаг 5. Регистрация нового пользователя

Теперь зарегистрируйте нового пользователя, под которым вы будете заходить на сервер:

sudo register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http://localhost:8008New user localpart [root]: usernamePassword: Confirm password: Make admin [no]: yesSending registration request...Success!

Готово.

Мои поздравления, теперь вы полноценный участник сети Matrix с собственным сервером.

Давайте поговорим

Вместе с моим коллегой по цеху мы организовали чат для пользователей Хабра, чтобы вы могли проверить протокол Matrix в действии.

Подключайтесь!

Существует ли всё ещё такая вещь, как настоящая анонимность?

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



Но как именно мы можем оградиться от архитектуры угнетения, если она насаждается вокруг нас, нами и для нас же самих?


В оригинальном Манифесте Шифропанка от 1993 года Эрик Хьюз писал, что Открытому обществу в электронном веке необходима конфиденциальность. здесь он затрагивает концепции, которые помогут нам сформулировать ответ на вопрос Что делает VPN?, или, скорее, Что должен делать VPN?.

Люди веками защищали частную жизнь при помощи шёпота, темноты, конвертов, закрытых дверей, тайных рукопожатий и курьеров. Технологии прошлого не позволяли обеспечить строгую конфиденциальность, но теперь это позволяют электронные технологии. Эрик Хьюз.

Прошли десятилетия, но эти электронные технологии не принесли спасение, на которое надеялся Хьюз. Технологии будущего, похоже, забрали большую часть нашей конфиденциальности, вместо того чтобы укрепить её. Интернет становится всё менее свободным, с увеличением вмешательства в онлайн-выборы и усилением государственного надзора, который распространяется на социальные сети.

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

Непрерывная и постоянная лента нашей жизни навсегда вписана в историю Интернета. Ваша жизнь теперь в буквальном смысле открытая книга.

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

Подпольная торговля нашими личными данными превратилась в коммерцию и, как и все ценные товары, теперь превращено в оружие. В докладе Свобода сети за 2019 год отмечается, что 89% интернет-пользователей (почти 3 млрд чел.) из 40 исследованных стран подвергаются действию программ мониторинга социальных сетей.

Это и Facebook, установивший рекламные правила, которые позволяют политикам распространять ложь, и Amazon, укрепляющий связи с полицейскими участками и использующий свои умные дверные звонки Ring, а также связанные с ними продукты социальных сетей, для наблюдения за населёнными пунктами.

Восток встречается с Западом

Система социального кредита" в Китае это реально существующий эксперимент, показывающий, как наши персональные данные могут быть обращены против нас. Каждому гражданину присваивается индивидуальный номер, события непрерывно записываются в базу, которая далее влияет на все аспекты жизни, давая оценку поведению гражданина и его благонадёжности. Будучи пойманным на переходе в неположенном месте, не оплатив госпошлину, включив слишком громко музыку в поезде вы можете лишиться определённых прав, например, бронирования авиабилета или билета на поезд.

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

Однако на Западе повсеместный мониторинг онлайн-поведения (во имя национальной безопасности) означает, что государственные органы и интернет-провайдеры могут легально отслеживать деятельность пользователей в интернете. Пока эволюционируют технологии, всё ещё не существует никаких правил, в которых речь заходит о распознавании лиц, а полиция уже запускает экспериментальные программы для слежки в режиме реального времени, прежде чем закон успеет догнать этику всего этого.

По мере того как мир становится цифровым, оказывается всё важнее, чтобы наши данные, конфиденциальность и свободы оставались под нашим контролем.

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

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

---

Анонимность

Я не знаю, почему люди так стремятся публично раскрывать подробности своей частной жизни; они забывают, что таинственность это сверхсила.
Бэнкси.

Текст на стене: Если повторять ложь достаточно часто, она станет правдой политикой

Принципиальная разница между конфиденциальностью и анонимностью

Между конфиденциальностью и анонимностью следует проводить важное различие.

Конфиденциальность скрывает ваше поведение и действия, но при этом вас всё ещё можно идентифицировать. Примером могут служить ваши приватные банковские операции, где вы отправляете и получаете деньги, тем не менее ваши финансовые транзакции видны только вам. То же самое относится к вашей электронной почте, вашим аккаунтам в социальных сетях, вашим текстовым сообщениям вы остаётесь идентифицируемыми, но можете выбирать, какие данные оставлять, а какие нет.



Анонимность это почти такая же концепция, только наоборот. Быть анонимным это значит, что ваша личность скрыта, но можно увидеть ваши действия. Кто-то может понять, что вы делаете, но не зная, кто это делает. Блокчейны зачастую являются псевдоанонимными, то есть вы можете просматривать каждую транзакцию, которая производится, но не должны иметь возможность идентифицировать личность отправителя или получателя.

Анонимность, как правило, очерняется, поскольку анонимное поведение часто ассоциируется с нелегальной деятельностью. В какой-то момент сформировался даркнет онлайн-обитель чёрных рынков, таких как Silk Road (Шёлковый Путь), создатель которой отбывает пожизненное заключение.

---

Silk Road должен был дать людям свободу делать собственный выбор, гнаться за собственным счастьем, каким бы они его себе лично ни представляли. Это оказалось наивной и дорогостоящей идеей, о которой я глубоко сожалею. Росс Ульбрихт в письме к своему судье.

---

Но так исторически сложилось, что анонимные деятели внесли большой вклад в жизнь общества художники, писатели, журналисты, политические и правозащитные активисты. Даже супергерои анонимны, чтобы защитить себя от негодяев и назойливых бывших подруг. Визуальные послания Бэнкси громче и проникновеннее, так как он не позволяет своей личности повлиять на повествование.

---

Человек меньше всего является собой,
когда говорит от своего лица.
Дайте ему маску, и он скажет вам правду.
Оскар Уайльд.

Анонимность и обеспечивает ту самую свободу слова и самовыражения. Это значит, что вы можете высказывать своё мнение, не опасаясь возмездия. Это значит, что вы можете разоблачать коррупцию, раскрывать её в самых тайных уголках. Это означает наличие свободы прессы, при которой газеты могут проводить свои расследования и публиковать статьи, не опасаясь преследований.

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

---

Идея может стать самой влиятельной вещью в мире

Для многих людей из регионов, наиболее подверженных цензуре, быть анонимным значит быть свободным. Cтатья 19 Всеобщей декларации прав человека гласит о праве на свободу выражения убеждений, а также свободу искать, получать и распространять информацию и идеи любыми средствами и независимо от государственных границ.

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



Несмотря на всеобщую поддержку прав человека в онлайн-среде, по всей видимости, принципы это не панацея. Во всём мире более четверти (27%) интернет-пользователей живут в таких местах, где их могут арестовать за публикации, репосты или даже лайки, оставленные в соцсетях. Аресты, связанные с политическими, социальными или религиозными высказываниями в соцсетях, были произведены в 47 странах. При настоящей анонимности слова могут использоваться для освобождения людей, а не против них. Вы не можете посадить идею в тюрьму.

Исследование, проведённое объединением Article-19, показывает, что анонимность является жизненно важным компонентом защиты свободы слова, а также права на конфиденциальность. Она позволяет людям выражать своё мнение, не опасаясь репрессий, и особенно важна в тех странах, где свобода выражения мнений подвергается жёсткой цензуре.

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

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

---

Эпоха слежки

Но цензура и слежка это не просто реалии диктатуры. Правительства повсюду регулярно пытаются предотвратить использование инструментов шифрования и анонимности в любой форме. Это нацелено якобы на то, чтобы препятствовать незаконной деятельности, такой как терроризм и незаконный оборот наркотиков. За последнее десятилетие Управлением по борьбе с наркотиками США конфисковано более 4 миллиардов долларов у граждан на основании одного только подозрения в преступной деятельности. Тем не менее, более 81% этих арестов никогда не приводили к предъявлению официальных обвинений.

Во многих случаях правительство США может законно запрашивать без ордера цифровые данные, которыми владеют компании. Законопроект EARN IT в настоящее время обсуждается на конгрессе, и если он будет принят, он может приковать компании наручниками к сложному для изменения набору процедур. Одним из пунктов в том чек-листе может оказаться устранение сквозного шифрования в мессенджерах, лишающее мир безопасного средства связи.

Несколько лет назад президент Дональд Трамп принял закон, позволяющий интернет-провайдерам собирать и делиться личными данными своих клиентов без их согласия, например, вашей веб-историей и тем, какие приложения вы используете. hightech.fm/2018/01/31/mass-digital-surveillance
Британский Разведывательный Устав предоставляет правительству право легально контролировать использование интернета своими гражданами. Общий посыл заключается в том, что если вы законопослушный гражданин, то вам не о чем беспокоиться.

Утверждать, что вам наплевать на право конфиденциальности, потому что вам нечего скрывать это всё равно что утверждать, что вам наплевать на свободу слова, потому что вам нечего сказать. Эдвард Сноуден.

---

Вопрос только в том, почему правительство хочет заполучить ваши персональные данные, когда у вас есть право на конфиденциальность?

Используйте свою цифровую свободу, чтобы дать отпор

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

Но как нам сделать интернет безопасным, а конфиденциальность настройкой по умолчанию? Законы, которые регулируют нашу частную жизнь и помогают нам свободно высказывать своё мнение, приносят пользу в основном корпорациям, государствам и их органам. Мы не можем полагаться на изменение законов или ждать, когда интернет-провайдеры начнут служить нашим интересам. Децентрализованная VPN (dVPN) это один из способов вернуть себе контроль.

Более четверти пользователей интернета в мире уже используют VPN. Основные мотивы для его использования: получить доступ к соцсетям и новостным службам (34%), сохранить анонимность при выходе в интернет (31%), скрыть от властей информацию о посещении сайтов (18%) и получить доступ к сети Tor (17%). Однако в странах, где граждане больше всего нуждаются в VPN Венесуэле, Китае, России, Турции, Иране, ОАЭ его, разумеется, стремятся запретить и заблокировать.

Для спасения жертв от цензуры и слежки был разработан dVPN. Обычный VPN соединяет вас с дата-центрами, которые управляемы компаниями, что делает их уязвимыми к обнаружению правительствами и интернет-провайдерами. Эти сервисы также часто медлительны, имеют различные ограничения, и что самое неприятное, могут централизованно хранить журналы онлайн-активности всех своих пользователей. Исследование 62 коммерческих провайдеров показало, что у многих из них (возможно, и не преднамеренно) происходит утечка пользовательского трафика различными путями.

В случае с dVPN сервис обслуживается такими же, как вы, интернет-пользователями. Вы выбираете из глобального меню домашних IP-адресов, поэтому этот сервис практически не подвержен отслеживанию и блокировке властями. dVPN это технологическое лекарство против антиконфиденциальности и антианонимности. Если вы живёте в стране, которая пользуется свободой интернета, в данной P2P-сети вы можете сдавать в аренду свой IP-адрес другим пользователям, а взамен зарабатывать криптовалюту. Благодаря распределённой инфраструктуре ваши данные нигде централизованно не сохраняются, а весь трафик, проходящий через эти персональные узлы, усиленно шифруется.

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

Собственная сеть Mysterium первая в мире dVPN. В ней используются многоуровневые протоколы защиты, чтобы любой желающий мог анонимно выходить в интернет. При установленном подключении реальный IP-адрес и идентификационные данные скрываются от владельцев веб-сайтов, а ваш провайдер не может узнать, какие сайты вы посещаете, таким образом любой пользователь может избежать бесцеремонной слежки за ним. Здесь можно попробовать dVPN для Android.

Также можно присоединиться к сети узлов, чтобы помочь сохранить анонимность самовыражения в интернете, защитив личные данные журналистов, активистов, жертв цензуры и слежки по всему миру.

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

Вперёд.

В случае полного отключения интернета одна из главных проблем общение с товарищами и родственниками. Опыт Гонконга показывает, что для этого хорошо подходят децентрализованные P2P-мессенджеры, которые работают без интернета, используя mesh-сеть по протоколам Wi-Fi Direct, Bluetooth, Apple Multipeer Connectivity Framework, ANT+, LoRa и др.

Для эффективной коммуникации приложение нужно скачать максимальному количеству человек до начала блокады интернета. Иначе придётся искать файлы после блокады. Человек с нужными файлами станет настоящим авторитетом в офисе или в классе (как это было в Беларуси в августе 2020 года за файлами Psiphon люди реально приезжали из других микрорайонов города).

Вообще, вся история сетей wireless mesh намекает на то, что эта технология крайне не нравится правоохранительным органам.

Mesh-сети

Приложения типа FireChat создают mesh-сеть, используя Bluetooth и прямые подключения через Wi-Fi. Они обеспечивают обмен сообщениями и фотографиями в офлайне между устройствами, находящимися друг от друга на расстоянии примерно до 60 метров.

Все пользователи образуют единую сеть, которая расширяется с ростом количества устройств. На пути к получателю (получателям) сообщения передаются от одного устройства к другому.

Другими словами, вам достаточно приблизиться на 60 метров к ближайшему пользователю и вы можете отправить сообщение кому угодно. Каждый юзер нода в сети. Без интернета.

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

Если какой-нибудь узел mesh-сети вдруг выйдет в интернет, то сообщения пакетом от всех пользователей уйдут получателям по всему миру.

Особенно удобно, если каналы или комнаты в мессенджере создаются автоматически и объединяют людей, которые находятся рядом с друг другом (многоквартирный дом, стадион, концертный зал).

Для передачи текстовых сообщений можно приспособить практически любую mesh-сеть, даже сеть из геометок Apple AirTag, которые вообще-то предназначены не для общения людей, а для поиска утерянных вещей. В мае 2021 года хакерам удалось расшифровать трафик AirTag и передать по сети Apple Find My произвольный текст под видом оригинальных зашифрованных сообщений с GPS-координатами. Скорость передачи составила 3байта в секунду. Задержка в сети от 1 до 60 минут.



Подобные mesh-сети есть также у Samsung (Smart Things) и Amazon (Sidewalk) на протоколе LoRa. В принципе, можно использовать эту инфраструктуру для пирингового обмена сообщениями, а также для съёма данных с устройств вне зоны доступа в интернет.

Трагедия FireСhat

FireChat проприетарное приложение от американской компании Open Garden. Эта фирма прекратила дальнейшую разработку, не открыв исходники.

Последняя версия приложения: 9.0.14 (копия на 4pda) вышла полтора года назад (примечание: доступ к сайту 4pda затруднён с территории РФ).


FireChat

Первая версия FireChat появилась в марте 2014 года под iOS, в апреле под Android. Среди сооснователей Open Garden и разработчиков программы Станислав Шалунов и Грег Хазел из компании BitTorrent, где они делали торрент-клиент uTorrent (200 млн пользователей). Там и познакомились.

Вероятно, предприниматели рассчитывали, что FireСhat станет настолько же успешным, как файлоообменные P2P-приложения. Если представить себе эту картину, то весь мир может объединиться в mesh-сеть, а интернет становится практически не нужен! Даже хостинг сайтов теоретически можно размазать в распределённой сети. Такая фантазия.

Очень быстро FireСhat приобрёл популярность в Ираке после того, как местное правительство ввело ограничения на использование интернета, а затем то же самое произошло в Гонконге, во время массовых протестов 2014 года.


Главной проблемой FireСhat во время массовых протестов в Гонконге стала безопасность. Сама архитектура открытой mesh-сети предполагает, что все пользователи приложения светятся как радиомаячки на расстоянии 60 метров, а то и больше. Так что полиции отловить их было очень просто. Наличие программы на телефоне однозначно доказывало вину. Можно предположить, что сотни или тысячи пользователей были арестованы благодаря FireСhat. К тому же, в приложении не использовалось шифрование, так что никакие сообщения не были действительно приватными.

Возможно, критика от специалистов по ИБ повлияла на решение американской компании Open Garden прекратить разработку и не публиковать исходники. Ну или ребята увидели, что всемирная популярность торрентов им не светит, а развитие программы пошло совсем не по тому пути.

Когда появился FireСhat, это была единственная программа такого рода, которая позволяла пользователям создавать mеsh-сети в офлайновом режиме (без интернета) и обмениваться сообщениями¹.

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


Фото из статьи FireChat мессенджер, на котором работают протесты в Гонконге, The Guardian

Тем более обидно, если FireСhat создавали специально для Гонконга, как разработку аналогичного приложения Commotion Wireless в 2011 году профинансировал госдепартамент США в преддверии Арабской весны. Хотели как лучше, а получилось как всегда

После FireСhat фирма Open Garden торговала электронными сим-картами (eSIM), продвигала свою криптовалюту, но в последние годы про неё ничего не слышно.

Вообще, приложение FireСhat было не очень качественным. Во-первых, закрытый код. Во-вторых, для регистрации обязательно (!) был нужен доступ в интернет, хотя потом оно работало в офлайне. Короче, странная программа. Может и хорошо, что разработчики её похоронили.

Рация Zello

Близкой по логике функционирования является интернет-рация Zello, которая заблокирована в Российской Федерации в апреле 2017 года.

Радио работает по принципу уоки-токи или push-to-talk. Основное преимущество возможность слушать голосовые сообщения по громкой связи в реал-тайме, вообще не притрагиваясь к смартфону и в то же время быть на связи с большим количеством пользователей.

Хотя здесь передаётся не текст/картинки, а звук, но принцип работы такой же через mesh-сеть, без интернета. Близкие друг к другу пользователи соединяются друг с другом напрямую и передают сообщения дальше, по цепочке. Что важно, здесь используется сквозное шифрование (E2E).

В России приложение получило особую популярность среди дальнобойщиков и других автомобилистов, поскольку очень удобно (и приятно) беседовать с попутчиками, которые едут по той же трассе. Они подскажут о радаре в кустах, о ДТП на дороге и т.д. Репрессии со стороны государства начались после массовых протестов дальнобойщиков в связи с введением обязательной платы миллиардеру Игорю Ротенбергу за проезд тяжёлых грузовиков по дорогам России (система Платон). Координация протестов осуществлялась через Zello, поэтому программу решили заблокировать.

Это был первый прецедент, когда власти попытались сломать мессенджер, работающий по VPN. Понадобился целый год, чтобы заблокировать свыше 4тыс. IP-адресов из облака AWS, что не принесло успеха. Тогда РКН пошёл на шантаж компании Amazon, угрожая заблокировать 26 подсетей AWS, в сумме 13,5млн адресов.

Компания Amazon оказалась не готова к войне и отказалась предоставлять услуги Zello. Лишившийся облачной инфраструктуры сервис было легко заблокировать.

После успеха с блокировкой облачной VPN-инфраструктуры Zello, в 2018 году власти решили, что смогут успешно заблокировать такую же облачную инфраструктуру мессенджера Telegram. Но здесь нашла коса на камень: Павел Дуров инвестировал миллионы долларов в покупку всё новых и новых инстансов AWS, его брат Николай с коллегами запрограммировал систему обхода блокировок через прокси, а компании Amazon и Google выдержали блокировку своих подсетей в РФ. В итоге властям пришлось заблокировать 18 миллионов IP-адресов AWS и Google Cloud, что нарушило работу крупных ритейл-компаний, банков из топ-20, частных клиник и тысяч бизнесов в России. После двух лет выматывающей борьбы государство сдалось: руководителя Роскомнадзора уволили, Telegram разблокировали, а IP-адреса облачных сервисов удалили из чёрного списка.

Криптомессенджер Briar

Четыре года назад, в июле 2017 года, вышла первая публичная бета-версия мессенджера Briar, который работает через Tor или в офлайне, через пиринг. Его разработка продолжалась аж три года. Но продукт вышел на редкость качественный.

Это уже честный опенсорс. Приложение можно собрать из исходников (пошаговая инструкция для Android Studio). Оно доступно в каталогах приложений (например, Google Play) и отлично поддерживается: последняя версия 1.2.20 от 2апреля 2021года. Реализована стойкая криптография, сквозное шифрование.


По умолчанию мессенджер работает через интернет по протоколу Tor (луковичная маршрутизация). В этом случае программа создаёт на устройстве пользователя скрытый сервис Tor и соединяется со скрытыми сервисами Tor других людей из списка контактов. В случае отсутствия интернета она переходит на peer-to-peer коммуникации через Wi-Fi Direct, локальную сеть или Bluetooth.

Разумеется, при регистрации в криптомессенджере не требуется указывать номер телефона.

Поддерживает передачу сообщений (но не файлов), приватные группы, блоги/статусы и импорт RSS. Есть несколько полезных функций, таких как блокировка приложения (по PIN-коду).

Система относительно защищена от посторонних: добавление новых контактов производится по QR-коду с другого телефона (подразумевается физическое присутствие лица) или через обмен контактами, или по уникальной ссылке. Таким образом, в контакты не должен попасть человек, с которым никто не знаком.



Briar Project некоммерческий проект, который сейчас ведут шесть добровольцев. Код на 97,7% написан на Java (+немного Kotlin, Python и Ruby) и поставляется под GPLv3. Вскоре после первого релиза код прошёл независимый аудит безопасности от компании Cure53. Она известна своим аудитом проектов SecureDrop, Cryptocat и Dovecot. Так что Briar действительно надёжный вариант для пиринговых коммуникаций.

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

Но исходный код открыт, так что теоретически кто угодно может попробовать сделать стороннюю реализацию Briar под iOS, например.

• Руководство пользователя Briar (на русском языке)

Matrix, Riot, Element

Официальный клиент Element (бывший Riot) для относительно децентрализованной сети Matrix не поддерживает пиринговые коммуникации в офлайн-режиме и формирование mesh-сети.

В последнее время этот клиент получил некоторую известность. Сейчас количество пользователей Matrix/Element сравнимо с Briar или больше. У него есть сквозное шифрование, мосты в IRC, Slack, Telegram, Jitsi Meet и др. Но именно пиринга в офлайне нет.

См. также:

Secure Scuttlebutt p2p социальная сеть, работающая и в офлайне (есть клиент Manyverse для Android и iOS)

P. S. Кроме FireСhat, протестующие в Гонконге использовали малоизвестное мексиканское приложение Bridgefy, которое тоже умеет формировать mesh-сеть и передавать сообщения в офлайне. В октябре 2020 года приложение перешло на криптографический протокол Signal.

¹ На самом деле ещё раньше были другие приложения, такие как Serval Mesh от проекта Serval Project или древний Commotion Wireless от Open Technology Initiative (с финансированием госдепа), но все эти разработки давно прекращены [вернуться]

---

На правах рекламы

Мощные виртуальные серверы на базе процессоров AMD EPYC для любых целей, в том числе для установки VPN.

Присоединяйтесь к нашему чату в Telegram.

Зачем вообще нужна децентрализация? Многие люди не совсем понимают смысла, ведь и так вроде все хорошо работает. Причин на самом деле несколько, но обычно сторонники подхода затрагивают только сложные технические моменты, и обывателю становится сложно углядеть суть. Для меня, например, все очень просто.

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

По сути, это альтернатива текущему, доминирующему варианту, когда тебе нужно искать инвесторов, которые оплатят весь банкет. Только в этом случае, зачастую, придется закрывать проект от внешнего мира и полностью зависеть от этих людей, мириться с любыми решениями, потому что это "хорошо для бизнеса" и.т.д. В какой-то момент, ты можешь даже оказаться лишним элементом, и с тобой попрощаются.

Если какая-то идея может быть эффективно реализована децентрализованным способом, лучше так и делать. Когда критическая масса дойдет до этого, то появятся много стандартизированных и удобных механизмов для реализации более высокоуровневых решений. А пока, давайте рассмотрим один простенький алгоритм для создания децентрализованной сети spreadable.

Вариант номер один: одноуровневый

Узлы могут выполнять две роли: master и slave (M и S). Роли распределяются рандомно и могут быть изменены в любой момент. То есть ни один узел не имеет реального преимущества над другим. Роль M нужна для ведения списков S, чтобы соединить всех в одну сеть, и в дальнейшем получать и отправлять информацию. Количество M всегда стремится к квадратному корню от размера сети: если в сети 9 узлов, то M будет 3 штуки. Каждый M ведет свой список S. Количество S в одном таком списке тоже всегда стремится к квадратному корню. В итоге, при 9 узлах у нас будет 3 M и у каждого в списке по 3 S. Информация о том, какие узлы выполняют роль M передается и хранится у всех узлов в режиме синхронизации.

Обход сети происходит следующим образом:

• Клиент хочет совершить какое-то действие
• Для него подбирается координатор рандомный узел, который запустит весь процесс.
• Координатор, как и любой узел имеет список всех M, поэтому он делает нужный клиенту запрос на все эти узлы параллельно.
• Каждый M при этом делает нужный запрос всем S в своем списке, тоже параллельно.
• В итоге, вся нужная информация собирается, фильтруется, превращается в какой-то результат и возвращается клиенту.

Давайте посчитаем сколько времени на все это уходит. Рассмотрим идеальный вариант. Допустим среднее время одного запроса 50ms. Тогда у нас получается общее время 3 * 50 = 150 ms вне зависимости от размера сети.

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

Плюсы данного алгоритма:

• Относительная легкость в реализации
• Очень быстрый обход сети при большом количестве узлов
• Высокая устойчивость к подключению/отключению узлов и смене ролей
• Приемлемое количество работы для предотвращения атак Сивиллы
• Максимальная близость к одноранговости, несмотря на гибридность

Минусы:

• Возможность эффективного совершения параллельных запросов ограничена ОС и ресурсами сервера.
• Чем больше список у каждого мастера, тем дольше обработка данных.

Эти минусы ограничивают максимальный размер сети. По моим прикидкам 10000-100000 узлов это предел эффективной работы. Такое количество узлов достаточно для решения большинства задач, поэтому я пока остановился на этом алгоритме.

Вариант номер два: многоуровневый

Этот алгоритм почти тот же, только уровней вложенности списков становится бесконечное количество. Размер списка узлов выбирается опционально, а не квадратный корень. Возьмем число 2 для дальнейших примеров. Роль мастеров становится иерархической. Появляются мастера первого уровня, второго и.т.д. (M1, M2 ...). M3 формируют списки M2, M2 -> M1, M1 -> S.

В такой схеме изначально у нас один уровень. Как только узлов станет больше 4, появится новый уровень и первый M2, когда узлов станет больше 6, появится третий уровень и M3, после 12 узла мы получаем уровень четыре и так далее.

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

Плюсы данного алгоритма:

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

Минусы:

• Сложность реализации
• Большое количество работы для предотвращения атак Сивиллы

Безопасность

Децентрализованные сети в той или иной степени уязвимы перед различными атаками Сивиллы. Это когда узел или несколько узлов принадлежат злоумышленнику, который изменяет код таким образом, чтобы как-то скомпрометировать всю сеть. Чем более открыта сеть, тем больше узких мест для воздействия. Навскидку, некоторые наиболее очевидные способы навредить:

• Выдавать клиенту некорректные данные со своего узла.
• Проспамить базу данных, чтобы увеличивать время на обработку данных.
• Сделать все роуты узла висячими, вызывая постоянные таймауты и замедляя время совершения запросов.
• Если в сети есть какая-то система голосования, то можно попробовать набрать критическую массу узлов и влиять на решения.
• Найти узкие места в системе ведения списков и изменить код, вызывая нарушения и задержки в соединении узлов друг с другом.

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

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

Голосование

Было бы полезно, в некоторых случаях, разрешать клиенту совершать какие-то действия только при определенных условиях. Например, пройти капчу сначала, или подтвердить ip адрес, либо что угодно другое. Как в децентрализованной сети можно реализовать подобное? Один из вариантов это голосование. Прежде чем пользователь сможет что-то сделать, определенная часть узлов должна подтвердить, что клиент имеет на это право. Управление этим происходит с помощью специального сервиса approval. Из коробки уже есть классы для проверки капчи и ip адреса. Для кастомных проверок мы должны отнаследоваться от базового класса и изменить некоторые методы.

Создавая класс, мы можем передавать некоторые базовые опции:

• approversCount количество узлов из всех имеющихся, которые сформируют совет голосующих. По умолчанию, это квадратный корень от размера сети, но можно указать процент от размера или просто какое-то число.
• decisionLevel достаточное количество голосов для положительного исхода. По умолчанию, 66.6%. Можно указать просто число.
• period промежуток времени на которое будет сформирован совет голосующих. По умолчанию, 5 минут.

Опция decisionLevel необходима, так как узлы в любой момент могут подключаться и отключаться. И если в процессе принятия решения один из голосующих узлов выйдет из сети, то клиент получит отказ. Поэтому мы допускаем тут некоторое отклонение.

Давайте рассмотрим как выбираются узлы для голосования. Для каждого узла вычисляется хеш, исходя из его уникальных данных и временного периода. Допустим, approversCount=3, decisionLevel=2, period=10m для какого-то действия. Все полученные хеши сортируются, и первые 3 узла в массиве имеют право голосовать в течение десятиминутного периода. Как только наступит следующая десятиминутка, хэши узлов поменяются, и голосующими станет уже какой-то другой массив узлов.

Далее, клиент, перед совершением целевого действия, сначала должен отправить голосующим некоторые данные о себе, через координатора. Они эти данные сохраняют и выдают ему свои требования (капча, например). Пользователь выполняет эти требования и во время нужного запроса дополнительно отправляет доказательства, которые будут проверятся голосующими узлами на истинность. Если хотя бы 2 узла из 3 подтвердят ответ, то клиент получает результат, который ему был нужен.

Исходя из настроек в примере, для того, чтобы "взломать алгоритм" нужно иметь контроль над 2 узлами, рассчитать когда именно эти узлы станут одновременно голосующими (при небольшом улучшении алгоритма, можно убрать возможность расчета заранее) из всех имеющихся, переписать кучу кода и тогда, в течение какого-то десятиминутного периода раз в N времени можно делать запросы без проверок.

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

Каптча тут реализована вышеописанным путем.

Синхронизация

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

Библиотека

Все написано на nodejs. Рассмотрим пример использования:

Сервер:

const  Node  =  require('spreadable').Node;(async () => {try {const node =  new  Node({port: 4000,hostname: 'localhost',initialNetworkAddress: 'localhost:4000'});await node.init();}catch(err) {console.error(err.stack);process.exit(1);}})();

Клиент:

const  Client  =  require('spreadable').Client;(async () => {try {const client =  new  Client({address: 'localhost:4000'});await client.init();}catch(err) {console.error(err.stack);process.exit(1);}})();

Для поднятия узла работаем с классом Node. Для подключения и работы с сетью используем Client.

Некоторые особенности:

• Сеть работает через http протокол. Можно также настроить https.
• Чтобы запустить узел нужно как минимум указать порт (port) и точку входа (initialNetworkAddress). Точка входа это любой другой узел, который уже зарегистрирован в сети. Также можно вручную передать имя хоста (hostname).
• Идентификатором узла является адрес. Он формируется как хост: порт. Хост может быть доменным именем или IP-адресом. Для ipv6 это [ip]: порт.
• Сеть может быть как открытой, так и закрытой. Для ее закрытия можно использовать базовую аутентификацию или перезаписать методы фильтрации запросов.
• Клиент библиотеки изоморфен, можно работать из браузера.
• Можно работать с узлом из командной строки.

Более подробно информация выше описана в readme.

Чего пока нет

Сейчас, чтобы использовать механизм и дописать что-то свое, нужно разобраться детально как устроено все изнутри, наследовать все необходимые классы, расширять маршруты и.т.д. С одной стороны это позволяет реализовать что угодно, но с другой стороны требует много времени, чтобы вникнуть. Поэтому в дальнейшем я думаю добавить возможность работы с сетью в стиле событий (EventEmitter). Это ограничит некоторые возможности, но упростит работу, в целом.

На данный момент, можно посмотреть как все наследовать на примере уже имеющихся расширений: metastocle, storacle, museria. Если будет смысл, то напишу как-нибудь статью как расширять и использовать библиотеку для своего проекта.

Мои контакты:

• @ortex
• mywebstreet@gmail.com

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

Свой рассказ я бы хотел поделить на две части:

1. Плеер изнутри (musiphone, museria-player)

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

const Node = require('musiphone').Node;(async () => {try {const node = new Node({port: 4000,hostname: 'localhost',musicStorageAddress: 'storage.museria.com:80'});await node.init();}catch(err) {console.error(err.stack);process.exit(1);}})();

const Client = require('musiphone').Client;(async () => {try {const client = new Client({address: 'localhost:4000'});await client.init();const title = 'Playlist title';const songs = ['Onycs - Eden','Onycs - Shine','Onycs - Timeless'];// Add the playlistconst response = await client.addPlaylist(title, songs);// Get the playlistconst playlist = await client.getPlaylist(response.hash);}catch(err) {console.error(err.stack);process.exit(1);}})();

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

Надо держать в голове, что система не гарантирует перманентности хранения данных, поэтому для большей надежности вы можете сохранять все также и в файлы. Об этом поподробнее будет во второй части.

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

2. Плеер извне (сайт, android приложение)

Снаружи плеер это сайт и приложение для андроид (честно скажу, мало на каких версиях и устройствах тестировал). Несмотря на не очень большую ныне популярность и очевидные проблемы, выбор пал на cordova, поскольку она удовлетворяет основным требованиям к проекту и сильно упрощает и ускоряет разработку.

Интерфейс везде примерно одинаковый, поэтому разберем все на примере сайта.

Создание и сохранение плейлиста в сеть.

Вначале вы попадаете на интерфейс с бобром и неактивной кнопкой "NEW PLAYLIST". Это означает, что сейчас идет создание нового плейлиста. Чтобы добавить песню, нужно найти ее в музыкальном хранилище, используя поле ввода слева. Если нужной песни там нет, то вы можете сами добавить ее, перейдя по ссылке "MUSIC STORAGE" сверху, тем самым вы поможете и себе и другим людям, которые в дальнейшем будут ее искать.

Для примеров будут использоваться рандомные песни, разрешенные для свободного распространения и прослушивания. Давайте поищем "Onycs Eden"

В хранилище нашлось пару вариантов, можно их прослушать и добавить нужный, нажатием на плюсик. Добавим несколько песен.

Теперь у нас три песни в плейлисте. По ним можно производить поиск, сортировать, перетаскивая и.т.д. Коричневое предупреждение означает, что были сделаны какие-либо изменения и если не сохранить их в сеть, то они исчезнут после очистки localStorage.

Попробуем сначала сохранить все в сеть. Для этого нажимаем "SAVE TO WEB".

Ввели название и сохраняем.

Теперь видно, что появился таб с названием плейлиста, где мы можем его удалить или сохранить все содержимые песни в кэш браузера/телефона. То же самое, кстати, как видно, можно сделать и с каждой отдельной песней, используя иконки справа. С плеером можно работать без интернета, если у вас есть закешированные треки.

Также мы видим, что исчезло коричневое предупреждение и появилось синее табло, в котором у нас ссылка на плейлист. Вы можете дать эту ссылку любому человеку, перейдя по ней, он увидит тоже самое. Создадим еще один плейлист. Для этого нажимаем "NEW PLAYLIST". Повторяем те же шаги и получаем:

Видим уже два плейлиста, а также сам плеер, который появился после нажатия на блок с песней.

Сохранение плейлистов в файл
Для большей надежности вы можете сохранять плейлисты в файлы. Для этого нажимаем "SAVE TO FILE". Файл будет сохранен в общепринятом формате m3u и может быть загружен и прослушан в любом другом плеере.

Загрузка плейлистов
Чтобы загрузить плейлист, нажимаем "LOAD PlAYLIST".

В модальном окне у нас есть два варианта. Мы либо загружаем по ссылке, либо из файла. В первом случае существует два типа ссылок:

• Статическая ссылка. Это обычная ссылка с хэшем на плейлист в хранилище: http://player.museria.com:80/musiphone/3deeb6052c5a46c05d6bec2cab5bade9 Напрашивается вопрос, зачем ее грузить через форму, если можно просто по ней перейти. Дело в том, что во-первых это нужно для мобильной версии, а во вторых узлы относительно которых создается ссылка рандомные. Это может быть неудобно когда вы уже настроили свое окружение на каком-то хосте, ведь вся временная информация хранится в localStorage. Поэтому переходы по таким ссылкам удобны, чтобы ознакомится с плейлистами, но чтобы формировать свое пространство нужно работать с интерфейсом какого-то одного узла, например, дефолтного: player.museria.com

  
  

• Динамическая ссылка. Такая ссылка не связана с хранилищем, она должна содержать путь к любому валидному m3u файлу/ответу сервера в интернете. Содержимое будет автоматически трансформировано в плейлист приложения. Каждые 10 секунд будет происходить новый фоновый запрос по этой ссылке, на случай, если вдруг данные изменились и нужно обновить список. Динамическая ссылка проебразуется в следующий вид, для того, чтобы ею можно было также делиться: http://player.museria.com:80/musiphone/external:someUrlHash

  
  

В случае же с файлом, мы используем тот же самый m3u формат.Все m3u файлы должны быть корректными, но могут не содержать путей к файлам. Достаточно названий песен для загрузки.

Конфиги
Все, что вы настраиваете в плеере хранится в localStorage. Чтобы сохранить эту информацию в файл(json), используйте кнопку "SAVE CONFIG", для загрузки "LOAD CONFIG". Вы можете настраивать различные группы плейлистов, уровень громкости плеера и прочее, создавая разные конфиги. Вот, например, вам конфиг из примеров в этой статье.

Вы можете помочь проекту, запустив хотя бы один узел для музыкального хранилища у себя на сервере пространством 50-1000гб, от 2гб оперативки, 2 ядра. Чем больше узлов, тем больше песен будет доступно.

Либо узел для сети плеера: от 300 мб свободного пространства, 1гб оперативки, 1 ядро. Больше узлов дольше живут ссылки.

Группа в телеграм на английском, либо сразу пишите мне в личку ortex

Сегодня вы узнаете, что такое Fediverse, как он выглядит в России и в мире, и как стать частью "будущего интернета" уже сейчас. Поехали!

Привет, Хабр! Впервые я узнал о Fediverse этой зимой, когда прочитал статью Алексея Поликовского В Новой газете. Предмет рассказа меня зацепил и я решил опробовать его на себе. Тогда я зарегистрировался в Mastodon и пользуюсь им уже 8 месяцев. Поделюсь своими впечатлениями от "интернета будущего" в этой статье.

Что такое Fediverse
Fediverse собирательное название для сети децентрализованных сервисов, связанных воедино протоколом ActivityPub. Если по простому, это совокупность сервисов, работающих по принципу федерации, таких, как Mastodon, Pleroma и Peertube.

Что такое федерация
Федерацией называют принцип устройства сервисов, при котором сервис работает на множестве отдельных автономных серверов, образующих единую сеть. Это можно сравнить с электронной почтой: письма могут писать друг-другу пользователи разных сайтов, независимо от того, на каком из них они зарегистрированы, будь то Gmail, Yandex или Tutanota. Преимущество такого подхода в том, что в этой сети нет главных, нет центра. Такая децентрализованная сеть не поддается цензуре и контролю, является крайне устойчивой к блокировкам, атакам и прочему внешнему воздействию. Сервера при этом рассредоточены по всей планете и управляются разными людьми. Рассмотрим пример такого сервиса.

Mastodon самая популярная федеративная соцсеть. На момент написания статьи ее аудитория оценивается приблизительно в 4 млн. пользователей. По сути, Mastodon является практически полной копией Твиттера: здесь так же можно писать короткие посты, репостить их, отвечать, создавая тред. Соцсеть разработана сообществом во главе с Юджином Рочко (Eugen Rochko) из Германии. Вместе они разрабатывают Tootsuite бекэнд соцсети, необходимый для создания сервера Mastodon, так называемого Инстанса (instance). Tootsuite имеет открытый исходный код и распространяется под лицензией AGPL-3.0. Mastodon был создан как свободная децентрализованная альтернатива Твиттеру, не предполагающая наличия слежки, рекламы, умной ленты и цензуры.

Mastodon устроен по принципу Федерации, а значит любой желающий может арендовать сервер, установить на него нужное ПО и создать таким образом свой инстанс соцсети. Правила поведения на каждом сервере устанавливает его администратор: на каких-то инстансах нет никаких правил, на некоторых запрещен NSFW контент и оскорбления, на других такое поведение даже поощряется. Свои сервера есть у гиков, фанатов аниме, музыкантов, ученых и т.д. На практике это означает, что каждый сможет найти себе сообщество по интересам или основать свое собственное. При этом все инстансы объединены в одну сеть, и контент с каждого из них можно просматривать с любого другого.

Небольшой размер комьюнити отдельных инстансов (в среднем по 100-1000 пользователей) позволяет сохранять уютную атмосферу, эффективно модерировать контент и поддерживать работу сервера. Администратор не является абстрактной сущностью, отвечающей неделями на почту. Вместо этого администратор такой же пользователь инстанса, которого всегда можно отметить в своем посте и рассказать ему о том, что вас беспокоит относительно жизни на сервере.

Mastodon лишь часть Fediverse. Fediverse образован многими сервисами: Pleroma (площадка для ведения блогов), Peertube (федеративный аналог YouTube), Pixelfed (федеративный аналог Instagram) и другими. Все сервисы "общаются" с помощью единого протокола ActivityPub.

ActivityPub пожалуй, главная фишка Fediverse. Это "универсальный клей" сети. Оперируя привычными категориями, это все равно, что если бы вы имели возможность видеть твиты своих друзей в ленте Инстаграма, читать посты на Facebook не выходя из YouTube, или писать собеседнику в Whatsapp из Telegram. Регистрировать много аккаунтов также необязательно. Со своей учетной записью, например, Mastodon, можно пользоваться и другими сайтами в Fediverse.

Разве это не утопия?
Fediverse и вправду звучит как утопия. Дивный новый интернет, лишенный множества изъянов привычных соцсетей: мягкой и жесткой цензуры, проблем с приватностью, рекламы, умных лент и неотзывчивой поддержки. Но, как пел Егор Летов, свято место не бывает без греха.

Я провел в Fediverse 8 месяцев и готов поделиться своими впечатлениями. О преимуществах уже сказано выше, теперь о недостатках "Интернета будущего".

Сломанная федерация
Несмотря на всю гениальность протокола ActivityPub, которым я правда искренне восхищаюсь, люди остаются людьми. Иногда по недосмотру или незнанию сервера оказываются настроенными неправильно, из-за чего коммуникация между ними может быть нарушена. Например, может случиться так, что содержимое профиля, находящегося на другом инстансе, может не отображаться на вашем. Впрочем, зачастую, достаточно написать админам обоих серверов о проблеме и ее удастся оперативно решить.

Неприятные личности
Mastodon действительно свободная соцсеть. Иногда это приводит туда не самых приятных персонажей. В русскоязычном сегменте существует целый инстанс провластных политических троллей, который я здесь не буду называть. В сети также можно найти множество радикалов. Мне даже попадался на глаза целый инстанс с анкетами "девушек пониженной социальной ответственности". Впрочем, с этим можно бороться. Вы можете блокировать у себя отдельных пользователей или целые инстансы. По договоренности с администратором вашего инстанса и другими пользователями вы можете экскоммуницировать нежелательный инстанс разорвать с ним связь на уровне вашего сервера. Известен даже случай коллективной экскоммуникации инстанса, на котором поселилось сообщество неонацистов. Вы также можете жаловаться на пользователей администраторам их инстансов. В таком случае, если администратор решит, что этот пользователь нарушил правила его сервера, он примет в отношении него меры.

Я не считаю это "стукачеством". Коллективная модерация помогает поддерживать здоровье сообщества, а "изгоев" вынуждает перемещаться туда, где им будут рады, отделяя мух от котлет. У человека всегда есть возможность перейти на другой инстанс, где правила ему по душе, либо основать свой. Для сравнения, если вас "забанили" в Твиттере, то значит, вы исключены из Твиттера насовсем.

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

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

Контента в сети тоже остро не хватает. Главная беда тут в том, что две эти проблемы связаны и образуют порочный круг.

Авторы не хотят заходить на площадку, потому что здесь слишком мало пользователей, а пользователей больше не становится, потому что нет контента. Круг замкнулся. Отпугивает авторов еще и тот факт, что в Fediverse не принято размещать рекламу.

На месте авторов я бы задумался о приходе в Fediverse: в условиях информационного вакуума есть все шансы быстро завоевать популярность.

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

Хочу в Fediverse, как туда попасть?
Знакомство с Fediverse я бы посоветовал начать с Mastodon. Mastodon самый популярный федеративный сервис, поэтому вы скорее сможете найти там контент по вкусу или интересных собеседников. Интересным для многих будет полностью открытый и отлично описанный API соцсети.

Сперва, нужно выбрать инстанс для регистрации. варианты можете поискать тут. Инстансы там далеко не все, например там не представлено русскоязычных. От себя могу посоветовать phreedom.tk и mastodon.ml это русскоязычные инстансы общей направленности, населены, в основном, целевой аудиторией Хабра. Старайтесь регистрироваться на маленьких инстансах: "кучкование" на крупных серверах способствует централизации федерации и нарушает один из основных принципов её существования децентрализованность.

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

Все, вы полноправный участник Fediverse! Добро пожаловать!

Клиенты Mastodon для разных платформ можно найти тут, лично я для Android использую Tusky.

Выводы
Как это ни печально, сегодняшний интернет остро нуждается в свободе. Государство настырно лезет в сеть, спец. службы хотят бекдоров, а IT корпорации, владеющие привычными сервисами, обрели слишком много власти и стали творить, что им хочется: торговать данными, влиять на политику, допускать утечки и банить без объяснения причин. В ответ на эту ситуацию, родился запрос на новую свободу в интернете, приватность и децентрализацию, переход инициативы в руки сообщества. Появление альтернативы было лишь вопросом времени.

Fediverse призван удовлетворить эти запросы и, похоже, неплохо справляется с этим. Это подтверждает как растущий интерес к "новому свободному интернету", так и рост популярности таких сервисов, как Mastodon.

Сегодня Fediverse все еще очень молод, но он имеет огромный потенциал для роста, и я не сомневаюсь, что интернет будущего будет федеративным. По сути, интернет в прошлом был децентрализованным: множество мелких сайтов и форумов со своими правилами и сообществами по интересам составляли лицо сети в нулевых и девяностых. Однако, этот подход не обеспечивал связи между всеми этими площадками и их сообществами. Тогда человечество свернуло на путь централизации и объединения вокруг огромных площадок. Сегодня же люди начинают осознавать свою ошибку и возвращаются на путь децентрализации, но, уже наученные опытом, создают гибрид этих двух моделей, объединение децентрализованной сети: федерацию. И это правильный путь.

Я бы посоветовал всем уже сегодня попробовать стать частью нового интернета, особенно авторам, коих там остро не хватает.

Спасибо за чтение! Делитесь своим мнением в комментариях. Увидимся в Fediverse!

Основатели Namebase раскритиковали соц.сети и централизованные системы управления доменными именами. Посмотрим, в чем суть их собственной инициативы, и почему она нравится не всем.


/ Unsplash / Charles Deluvio

Что случилось

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

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

За что критикуют они

На сайте компании есть отсылки к проблеме избыточной централизации на стороне технологических монополистов, национальных и международных организаций от ICANN до социальных сетей.

Основатели Namebase ставят под сомнение то, как под управлением таких структур (и даже государств) реализуются права на свободу слова и собственности на цифровые активы вроде профилей, пользовательских и доменных имен. В своих выступлениях они часто вспоминают случаи кражи, блокировок и удаления таких активов без должных разбирательств или объяснения причин.

Какие выдвигают предложения

По мнению энтузиастов этой темы, чтобы отойти от всевозможных сложностей в сторону универсального, устойчивого и децентрализованного пространства имен, потребуется:

1. Удостовериться в децентрализации новой системы.
2. Оставить только ключевые функциональные возможности.
3. Обеспечить низкую ресурсоемкость и trustless-доступность.
4. Сохранить совместимость с общей инфраструктурой сети.
5. Предусмотреть возможность обновления на уровне протокола.

Первое и второе требование возможно реализовать с помощью выделенного PoW-блокчейна (в компании его назвали Handshake).Таким образом разработчики планируют исключить риски дестабилизации системы из-за действий стейкхолдеров или каких-либо внешних факторов.

По их мнению, проектирование на основе уже существующих блокчейнов не позволит добиться такого эффекта в долгосрочной перспективе, что является определяющим фактором для бесперебойной работы и обновления (пятый пункт требований) IT-стандартов такого уровня.

В ответ на третье требование разработчики предлагают хранить данные пространства имен в так называемых Urkel Tree, спроектированных специально для решения этой задачи. Они выступают альтернативой particia-деревьям в Ethereumе, но с узлами на 32 (leaf/sibling nodes) и 76 байт (internal nodes), а PoW-вес здесь не превышает килобайта даже при наличии десятков миллионов листьев.

Так команда пытается оптимизировать время и ресурсы, необходимые для разрешения имен. Помимо этого она открыла и легкий клиент на C он занимается исключительно DNS-задачами.


/ Unsplash / Thomas Jensen

Если говорить о совместимости (четвертый пункт), по словам основателей, проект направлен на расширение возможностей действующих IT-стандартов, а не на их вытеснение. Разработчики уверены, что у пользователей сети должно быть больше возможностей, чтобы сохранить контроль и удостовериться в том, что то или иное имя принадлежит именно им, и продолжают развитие своего продукта (основная информация по нему GitHub-репозиторий, документация, API).

За что критикуют их

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

В какой-то момент дискуссия ушла в сторону один из резидентов площадки даже высказал мысль об аналогичном оживлении RSS-экосистемы, которая могла бы стать децентрализованным ответом для монополизированного рынка соц.сетей. Но здесь как и в ситуации с Handshake все уперлось в вопрос монетизации и степень элегантности его разрешения. Как известно, подобные DNS-проекты уже пытались запустить, но этот процесс проходил не так гладко, как хотелось бы их основателям.

Сейчас у Handshake и Namebase есть сразу несколько альтернатив от Unstoppable Domains (документация) до Ethereum Name Service (ENS). Смогут ли они составить конкуренцию существующим подходам к управлению доменными именами и стать массовыми, покажет время.

P.S. Дополнительное чтение в нашем хабраблоге работа провайдеров и развитие систем связи.

Y messenger разрабатывается чтобы быть одновременно и защищенным на уровне Tox, BitMessage, и удобным на уровне Telegram и WhatsApp. В этой статье я опишу как выглядит архитектура и какие решения были использованы чтобы достичь поставленных целей.

Какие преимущества современных мессенджеров мы собрали в нашем продукте:

• Общение
  
  • Отправка текста, фото, файлов, голосовых сообщений;
  • Отправка сообщений, защищенных сквозным шифрованием (включая фото и файлы);
  • Реализация диалогов, многопользовательских чатов и каналов;
  • Получение push-уведомлений о новых сообщениях;
  • Высокая скорость отправки сообщений;
  • Возможность отображения онлайна пользователей и индикации набора текста;
  • Иерархия ролей пользователей в групповых чатах и каналах;
• Регистрация и авторизация пользователей:
  
  • Возможность анонимной регистрации без номера телефона / эл.почты;
  • Возможность регистрации по номеру телефона / почте;
  • Возможность скрыть персональные данные или ограничить видимость определенным группам;
  • Возможность просматривать список сессий пользователя;
  • Отсутствие жесткой привязки пользователя к серверу и возможность переноса данных пользователя между серверами;
• Работа с пользователями:
  
  • Поиск пользователей по доступным данным (имя, почта, телефон);
  • Поиск пользователей по идентификатору;
  • Хранение списка контактов и групп контактов;
• Администрирование:
  
  • Возможность разворачивания собственного сервера;
  • Автообновление серверного приложения;
  • Автоматическое создание резервных копий;
  • Настройка под местные требования (законов и внутренних политик владельцев);
  • Возможность настройки доступности шифрования для пользователей сервера;
  • Возможность просмотра незашифрованных диалогов администратором сервера;
  • Хранение статических файлов в облаке.

Сетевая архитектура

Взаимодействие всех участников сети мы строим на базе протокола WebSocket. Файлы передаются по протоколу HTTP. Описание протокола доступно в нашем репозитории на GitHub.

Цели и задачи

• Создать децентрализированный мессенджер.
• Обеспечить равенство участников децентрализрованной сети.
• Обеспечить отказоустойчивость сбоям отдельных серверов.
• Оптимизировать нагрузку на мобильные устройства пользователей.
• Обеспечить защиту пользовательских данных.
• Обеспечить возможность общения между пользователями разных серверов.
• Минимизировать зависимость пользователей от других элементов сети
• Обеспечить возможность реализации функций современных централизованных мессенджеров.

Решение

Мы рассматривали различные варианты и пришли к выводу, что сетевая архитектура, способная наилучшим образом удовлетворить всем требованиям "федерализированная децентрализация".

Федерализированная децентрализация подразумевает создание общих точек обмена данными (хабов). Хабы являются доверенными представителями пользователей, и пользователи позволяют хабам обрабатывать часть информации о себе в обмен на снижения нагрузки на своё устройство.

Как видно из картинки выше, пользователь подключаются к своему хабу. Все хабы равнозначны и образуют одноранговую сеть.

Аналогичную сетевую архитектуру образуют почтовые сервера (E-mail).

Хабы

Задачи хабов:

1. Авторизация, регистрация и верификация пользователей.
2. Хранение данных о пользователе (профиль, сообщения, контакты, настройки).
3. Обеспечение передачи данных между пользователями.
4. Предоставление информации о пользователе в соответствии с его настройками конфиденциальности.
5. Маршрутизация запросов от других хабов и пользователей.
6. Хранение файлов (у себя или в S3-совместимом хранилище).
7. Поддержание распределенного хранилища Blockchain.
8. Резервное копирование данных.
9. Проксирование запросов между пользователей других хабов при сбое хаба, к которому они принадлежат.
10. Администрирование своих пользователей.

Хаб может быть запущен кем угодно, подобно серверу электронной почты. Команда разработчиков Y messenger не имеет доступа к хабам пользователей и не может читать / записывать / изменять / удалять данные в этих хабах.

Прочие элементы сети

Помимо хабов и пользователей, в сети Y messenger существуют общие микросервисы (shared microservice), к которым обращаются хабы:

• Push shared microservice микросервис push-уведомлений. Обеспечивает отправку уведомлений на устройства пользователей по распоряжению хаба пользователя. Защищает пользователей от отправки спама через Push-уведомления.
• Balancer shared microservice микросервис балансировки сети. Обеспечивает целостность сети и является одним из источников информации о действующих хабах. Обеспечивает верификацию хабов и защиту от подделки запросов хаба при взаимодействии хаб <-> хаб и хаб <-> пользователь.

При необходимости, любой хаб может использовать собственные реализации микросервисов, однако при этом возможна потеря части функционала официальных клиентов. Решить эти проблемы может выпуск альтернативных клиентов.

Архитектура хранилища данных

Цели и задачи

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

Решение

Для достижения всех поставленных целей нам приходится использовать комбинацию разных хранилищ. На клиенте локальная СУБД. На хабах классическая РСУБД, распределенный блокчейн и кэш для быстрой отдачи горячих данных.

Для хранения блокчейна и данных мы используем PostgreSQL, а для кэша Redis. Эти продукты оптимальны с точки зрения безопасности, скорости работы и удобства администрирования, кроме того они являются свободным ПО.

Где что хранится

• Данные пользователей. Хранятся на устройствах и на привязанном хабе. Хаб шифрует данные на своем ключе и отправляет в блокчейн. Другие хабы не получают доступа к информации о пользователе, они видят только привязку ID пользователя <-> ID хаба для маршрутизации.
• Незащищенные личные сообщения. Хранятся на устройстве пользователя и в СУБД на хабах собеседников. В блокчейн не отправляются, т.к. блокчейн не приспособлен для обработки быстрых вставок, а ожидание синхронизации между хабами сделает доставку сообщений неприемлемо долгой. При общении между пользователями разных хабов сообщения хранятся на обоих хабах.
• Приватные ключи пользователя. Хранятся только на устройствах клиентов. Могут передаваться между устройствами пользователя через хаб в зашифрованном виде (на ключах пользователя), поэтому передача через хаб безопасна.
• Ключи оконечного шифрования. Хранятся на устройствах собеседников. Могут храниться в зашифрованном виде на хабе, но для расшифровки нужен приватный ключ пользователя.
• Оконечно зашифрованные сообщения. Хранятся на устройствах пользователей. Опционально могут храниться в зашифрованном виде на хабе.
• Информация о групповых чатах и каналах. Хранится на хабах всех участников. Отправляется в блокчейн хабом администратора в зашифрованном виде.
• Сообщения групповых чатов и каналов. Хранятся на хабах всех участников. При подключении нового участника чата / канала, его хаб загружает последние сообщения и подгружает более старые по запросу пользователя. Поиск сообщений в групповом чате выполняет поиск только по локальной копии истории сообщений на хабе запросившего пользователя.
• Список участников чата/канала. Хранится на хабах всех участников чатов. Отправляется в блокчейн хабом администратора в зашифрованном виде.
• Контакты пользователя и группы контактов. Хранятся на устройстве. При необходимости могут храниться на хабе и синхронизироваться.

Шифрование

Компоненты шифрования реализованы на базе OpenSSL. В своей работе Y messenger использует следующие алгоритмы шифрования и подписи AES-CBC, RSA-OAEP, RSA-PSS. Эти алгоритмы реализованы в большом количестве криптопровайдеров, а следовательно, у желающих и/или не доверяющих есть больше шансов самостоятельно разобраться в функционировании системы или выпустить свой альтернативный клиент.

Ключи

Y messenger, как и многие другие решения, использует комбинацию симметричного и асимметричного шифрования. У каждого пользователя и хаба есть следующий набор ключей:

• ключи подписи (публичные и приватные);
• ключи шифрования (публичные и приватные);
• ключи симметричного шифрования.

Количество пар ключей подписи и ключей шифрования, а также симметричных ключей ограничено только емкостью Int64.

В настоящее время Y messenger использует для асиметричной криптографии ключи, полученные из модуля длинной 8192 бита. Большинство продуктов в данный момент используют ключи на базе модуля 4096 бит, хотя известны случаи применения ключей на базе модуля 16384 бита и более. Мы решили, что 8192 бита будет достаточно. Дальнейшее увеличение длины критическое увеличение времени работы алгоритмов, что негативно сказывается на пользовательском опыте.

Хранение ключей

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

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

Мы используем парольную фразу длиной от 40 символов, на основе которой генерируется Master-Key, используемый для шифрования ключей. Приложение может хранить парольную фразу прямо на устройстве для удобства использования, но для достижения наивысшего уровня защиты рекомендуется вводить эту фразу при каждом входе в приложение.

Механизм не исключает возможность кражи ключей и парольной фразы, но делает этот процесс еще более сложным.

Сквозное шифрование

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

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

Как происходит обмен симметричными ключами:

1. Alice хочет отправить Bob'у зашифрованное сообщение.
2. Alice получает со своего хаба публичный ключ асимметричного шифрования Bob'а.
3. Alice генерирует симметричный ключ.
4. Alice шифрует симметричный ключ на публичном ключе Bob'а и подписывает своим приватным ключом подписи.
5. Alice отправляет Bob'у сообщение, в которое вкладывает зашифрованный симметричный ключ.
6. Следом Alice уже может отправлять оконечно зашифрованные сообщения, шифруя их на сгенерированном симметричном ключе.
7. Bob получает сообщение с вложенным зашифрованным симметричным ключом.
8. Bob проверяет подпись с помощью публичного ключа подписи Alice.
9. Bob расшифровывает вложение на своем приватном ключе.
10. Bob получает симметричный ключ и может с его помощью расшифровывать сообщения, полученные от Alice.

Таким образом достигается конфиденциальность передаваемой информации, а также ее целостность, авторство и неотказуемость от авторства. По подписи можно легко установить отправителя сообщения, а модификации приведут к ошибке при верификации сообщений.

Обмен ключами между устройствами

Современный мессенджер должен быть cross-device, чтобы пользователь мог начать переписку на одном устройстве и продолжить ее на другом. При использовании хабов, сделать cross-device нешифрованную переписку не составляет никакого труда. Реализовать cross-device зашифрованную переписку становится сложнее из-за того, что контент зашифрован, а ключи шифрования находятся на другом устройстве. Существует несколько способов решения (список не конечный, но достаточный):

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

Первые два варианта предлагают очень низкий уровень защиты. Мы такое не используем.

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

Третий вариант оптимален, но требует внимания со стороны безопасности. Мы не можем доверять хабу свои симметричные ключи, поэтому их нужно защищать. В общих чертах, процесс обмена между устройствами A и B выглядит так:

1. Пользователь начал переписку на устройстве A.
2. Пользователь решил перейти на устройство B (с ПК на телефон).
3. Устройство B авторизировано и имеет свой набор ключей асимметричного шифрования и подписи, которые уже отправлены на хаб.
4. Устройство B отправляет на хаб сообщение с командой передать ключи, передает один из своих публичных ключей асимметричного шифрования, идентификатор ключа подписи, подписывая всю команду своим приватным ключом подписи.
5. Хаб определяет все подключенные устройства пользователя и отправляет им команду подготовить ключи для передачи на устройство B и передает им данные из предыдущего этапа.
6. Устройство A получает команду от хаба и проверяет что запрос был создан с устройства пользователя путем проверки подписи (запрашивает с хаба публичный ключ по переданному идентификатору).
7. Устройство A генерирует одноразовый симметричный ключ, шифрует его на полученном публичном асимметричном ключе.
8. Устройство A шифрует набор ключей на созданном симметричном ключе и подписывает данные (зашифрованный симметричный ключ, зашифрованный набор ключей устройства, идентификатор ключа подписи) своим приватным ключом подписи и отправляет на хаб.
9. Хаб отправляет эту информацию на устройство B.
10. Устройство B проверяет подпись и расшифровывает одноразовый симметричный ключ на своем приватном ключе шифрования.
11. Устройство B расшифровывает набор ключей с помощью симметричного.

В результате, у устройства B появились ключи шифрования устройства A. При передаче через хаб данные были защищены от чтения и модификации.

Остается вероятность что при "взломе" аккаунта и успешной авторизации, злоумышленник может быстро получить доступ к зашифрованной переписке. Решается либо ручным подтверждением пересылки ключей устройством А, либо временным недоверием устройству B (устройство А не доверяет устройству B пока пользователь не авторизует сессию на устройстве А).

Исходный код

Мы опубликовали исходный код наших разработок:

• серверное приложение: https://github.com/Ymessenger/ymessenger
• клиент для Android: https://github.com/Ymessenger/android-app
• протокол сетевого обмена: https://github.com/Ymessenger/protocol

Примечание. Оригинальный репорт опубликован на Medium на английском языке. Он содержит также цитаты респондентов и ссылки на участников. Доступна укороченная версия в виде твит-шторма.

О чем исследование

Термин DWeb (Decentralized Web, Двеб) или Web 3.0 чаще всего является собирательным для ряда новых технологий, которые перевернут веб в ближайшие несколько лет. Мы поговорили с 631 респондентом, которые в данный момент работают с распределенными технологиями и строят децентрализованный веб.

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

Веб изначально задумывался Тимом Бернерсом-Ли как открытая децентрализованная сеть для взаимодействия. Со временем технологические гиганты пятерки FAANG начали создавать удобные для пользователей интерфейсы и вырвались вперед, набрав критическую массу.

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

Сейчас все больше и больше проектов создают независимую инфраструктуру и стараются избавиться от посредников в виде FAANG.

В начале 2000-х годов крупные инди проекты Napster, Tor и BitTorrent ознаменовали возвращение к децентрализации. Позже их затмили их централизованные конкуренты.
Интерес к децентрализации затих, и возродился с появлением научной работы о новой децентрализованной валюте Bitcoin, за авторством Сатоши Накамото.

С этого момента новые DWeb протоколы, такие как, например, IPFS, прокладывают путь к фундаментальным изменениям в вебе. А уцелевшие проекты начала 2000-х годов, такие как Tor, I2P и даже Mixnets, выходят на новый виток развития. Теперь целое поколение проектов и разработчиков стремится к первоначальному видению децентрализованного веба, задуманного Тимом Бернерсом-Ли в 1990 году в CERN.

В сообществе нашлись заметные разногласия относительно того, что такое новый веб. Наше исследование раскрывает общие принципы, разделяемые разработчиками в этой сфере.
Исследование начинается с изучения наиболее существенных проблем с текущим вебом и заканчивается тем, как DWeb может преодолеть стоящие перед ним трудности.

Основные выводы

• Большинству проектов менее двух лет, что говорит о том, что DWeb все еще формируется и остается неокрепшей технологией.
• Три четверти респондентов полагают, что DWeb толкает вперед в основном идеология и энтузиазм, и он пока еще не понят обычными пользователями.
• Конфиденциальность данных, и контроль над ними, а также устойчивость технологий к сбоям наиболее ожидаемые особенности DWeb.
• Самые большие сложности при разработке под DWeb вызывают peer-to-peer технологии и незрелость новых технологий.
• Больше всего беспокойств у разработчиков вызывает DNS, протоколы уровня приложений SMTP, XMPP и пр., а также HTTP.
• Бизнес-модели в экосистеме DWeb пока что отсутствуют; у более половины проектов нет никакой модели монетизации.
• IPFS и Ethereum являются лидерами среди основных технологий, которые респонденты используют для создания DWeb приложений.
• Интерес к DWeb среди разработчиков высок, но путь к его внедрению тернист: инфраструктура молода, и нуждается в улучшении, а пользователей нужно обучать преимуществам использования DWeb по сравнению с централизованными аналогами.
• Тем не менее, возможности децентрализации веба ощутимы, и если текущая вирусная пандемия COVID-19 будет иметь хоть какой-то положительный эффект, то это может быть массовая осознанность при переходе к децентрализованным услугам.

Содержание

Отличия Web 3.0 и DWeb
Участники исследования
Текущий Веб
3.1 Проблемы текущего веба
3.2 Веб протоколы
DWeb
4.1 Понятие децентрализации
4.2 Ценности и миссия
4.3 Технические проблемы
4.4 Применение DWeb в будущем
Внедрение Двеба
5.1 Основные ограничения
5.2 Препятствия массовому использованию
5.3 Роль блокчейна
Проекты DWeb
6.1 Типы проектов
6.2 Мотивация
6.3 Статус проектов и команды
6.4 Технические характеристики
6.5 Бизнес-характеристики
Заключение и выводы

Отличия Web 3.0 и DWeb

В ходе исследования DWeb технологий мы ориентировались на несколько отличий в восприятии распределенных веб-технологий по сравнению с Web 3.0. В частности на то, как разработчики и сторонники сообщества определяют перспективы двух довольно расплывчатых терминов.

Ответы на опрос показывают, что общие цели и видение DWeb и Web 3.0 существенно пересекаются.

Web 3.0, в основном продвигаемый блокчейновым сообществом, делает упор на коммерческие разработки финансы, электронную коммерцию, AI и большие данные для компаний. Сторонники DWeb (например, IPFS и Internet Archive) напротив, в большей степени ориентированы на идеологию децентрализации: суверенитет данных, безопасность, конфиденциальность и устойчивость к цензуре. Проекты DWeb охватывают более широкий спектр технологических инноваций, нежели Web 3.0.

В целом, два восприятия следующей итерации сети не противоречат и могут фактически дополнять друг друга.

С точки зрения навигации по исследованию лучше всего ориентироваться на взгляды сторонников DWeb и то, как эти разработки (например, P2P, децентрализованное хранение, конфиденциальность данных) будут формировать инфраструктуру будущей сети.

Участники исследования

Исследование состояло из опроса, который был заполнен 631 респондентом, из которых 231 активно работают над проектами, связанными с DWeb.

1. Ваш бэкграунд?

Опрос составлял 38 вопросов. Процентное распределение в ответах основано на неограниченном выборе ответов респондентами в большинстве случаев общий процент ответов составит более 100 процентов.

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

Текущий Веб

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

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

Самые уязвимые места текущего веба

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

2. Назовите основные проблемы в текущем Вебе

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

• Из общего числа респондентов наибольшую озабоченность вызывали массовые утечки персональных данных, как например было с Marriott и Equifax по мнению 68,5% респондентов.
• Цензура и ограничение доступа, введенные как техническими гигантами, так и правительствами, заняли второе и третье место, согласно 66% и 65% респондентов.
• Реклама, использующая личные данные 61%
• Данные пользователей из приложений 53%

Интересно отметить, что диапазон мнений свидетельствует о сильной неприязни к текущей веб-парадигме, особенно когда дело доходит до того, как веб монетизирован в настоящее время.
Вопрос о том, насколько неблагоприятны долгосрочные последствия монетизации рекламой (например, централизованный контроль данных и вторжение в личную жизнь), не имеет значения респонденты недовольны результатом.

Кроме того, респонденты выразили антипатию к закрытым системам. В особенности неудобство приносят закрытия продуктов или отсутствие контроля со стороны пользователей над их данными. Пользователи мало влияют на то, какой контент они видят в лентах, данные или навигацию по закрытым системам. Необходимо найти более доступные и удобные для пользователя стандарты.

3. Что должно быть исправлено в текущем вебе в первую очередь?

Ответы несколько повторяли комментарии о самых уязвимых местах.

• Суверенитет данных был явным лидером. Причем 75,5% респондентов указали, что возвращение пользователю контроля над данными является первостепенным.
• Конфиденциальность данных 59%
• Технологическая устойчивость к разрушительным событиям или авариям (например, в случае Cloudflare) 56%
• Безопасность, в частности повсеместное использование криптографических подписей в приложениях 51%
• Анонимность сети 42%

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

Веб протоколы

4. Что нужно добавить или изменить в существующих протоколах?

Ответы на этот вопрос сильно различались во мнениях.

• Встроенный слой персональных данных 44%
• Встроенная идентификация пользователя 42%
• Функционирование в офлайн режиме по умолчанию 42%
• Встроенный peer-to-peer слой 37%
• Некоторые ответы, такие как независимая от платформ идентификация и аутентификация пользователя 37%, могут быть объединены под более широким слоем персональных данных.

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

5. Какие из существующих интернет-протоколов нуждаются в редизайне?

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

• Протоколы слоя адресации ресурсов (DNS) 52%
• Протоколы коммуникации (SMTP, XMPP, IRC) 38%
• HTTP 29%

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

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

DWeb

Понятие децентрализации

6. Что значит Д в понятии Двеб?

Буква D в DWeb обозначает decentralized, то есть некую распределенную или децентрализованную систему. Не существует четкого определения такой системы, но, на практике это может быть динамическое движение от централизованной модели текущей сети к децентрализованной. Однако, такое движение нелинейно, и сталкивается с определенными трудностями.

Данный раздел исследования раскрывает задачи и перспективы реализации концепции DWeb.

Как отмечают респонденты, движение в сторону DWeb является идеологически ориентированным.

• Большинство понимает DWeb как архитектурно децентрализованную сеть, где нет единой точки отказа или накопления данных 82%,
• 64% участников видят Двеб как политически не контролируемую сеть,
• 39% отмечают, что логика сети должна быть децентрализована,
• 37% респондентов указали, что сеть должна быть распределенной или децентрализованной по принципу не доверяй, проверяй, где всё поддается проверке.

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

Ценности и миссия DWeb

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

7. Какие наиболее значительные изменения может привнести, по вашему мнению, DWeb?

• Возвращение контроля над личными данными 75%
• Неспособность подделать или подвергнуть цензуре контент 55%
• Отсутствие трекинга/отслеживания пользователей или надзора 50%

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

8. Что крутого в DWeb технологиях по сравнению с традиционным Вебом?

Ответы на этот вопрос в значительной степени опирались на ценности и миссию, в очередной раз отражая идеологически мотивированный характер DWeb.

• Безопасность 43%
• Сообщество и поддержка 31%
• Совместимость 31%
• Масштабируемость 30%

Разработка оффлайн/локальных приложений, более короткая задержка и высокая отказоустойчивость в комментариях были названы основными техническими преимуществами DWeb.

Технические проблемы

9. Какие технологии могут поспособствовать массовому использованию DWeb?

Ответы на опрос в этом разделе выявили мнения участников о технологиях, которые помогут прийти к новому вебу.

• Протоколы p2p коммуникации 55%
• Адресно-ориентированное хранилище 54,5%
• P2P обмен файлами 51%
• Децентрализованный DNS 47%
• Сети, ориентированные на конфиденциальность 46%

10. Пробовали ли вы делать приложения с технологиями DWeb? Какими именно?

• IPFS 36%
• Ethereum 25%
• Dat 14%
• Libp2p 12%

IPFS и Ethereum, в частности, являются одними из самых быстрорастущих open source проектов из всех приложений и протоколов DWeb.

Разработчики также упомянули ряд других проектов, включая WebTorrent, Freenet, Textile, Holochain, 3Box, Embark, Radicle, Matrix, Urbit, Tor, BitTorrent, Statebus / Braid, Peerlinks, BitMessage, Yjs, WebRTC, Hyperledger Fabric и многие другие.

11. Что наиболее всего разочаровывает вас в DWeb технологиях?

Подобно нашему прошлогоднему исследованию DApp и блокчейн разработчиков, многие из перечисленных разочарований были связаны с нехваткой документации. То же самое мы видим и в отношении технологий DWeb.

• В частности, главное разочарование это недостаток документации, учебных пособий, видео и других образовательных ресурсов для разработчиков 44%
• Также существует проблема с пониманием того, где и как применять Dweb технологии на практике 42%
• Сложность интеграции технологий друг с другом 40%
• Проблемы масштабирования распределенных технологий 21%

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

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

12. Назовите наиболее сложные технические моменты в разработке с использованием P2P

Ответы на вопрос о трудностях DWeb сфокусировались на конкретных проблемах реализации p2p проектов. Мы снова наблюдаем уже названные ранее сложности.

• Проблемы масштабирования 34%
• Стабильность соединения пиров в сети 31%
• Производительность 25%

* * *
Следующая часть будет полезна разработчикам, интересующимся конкретными трудностями в экосистеме DWeb. Некоторые проблемы Двеба включают в себя техническую сложность, например, многоуровневая архитектура P2P.

В DWeb явно прослеживаются трудности с мотивацией пользователей. Другого рода нерешенные вопросы связаны с проблемами регистрации пользователей, сетевыми задержками (latency), задачей обнаружения пиров, затратами на тестирование сети и вопросами синхронизации данных.

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

Использование DWeb технологий в будущем

13. С какой вероятностью вы используете DWeb технологии в своем следующем проекте?

Респонденты, уже работающие над проектами DWeb, выразили большее желание задействовать технологии DWeb в своем следующем проекте. И, наоборот, разработчики, которые просто интересовались технологией DWeb, указали на более низкое предпочтение использования технологий DWeb для своего следующего проекта.

Возможно, заинтересованные разработчики просто ждут, пока технология немного окрепнет, прежде чем начать ее использовать. С другой стороны, разработчики, уже работающие с Двебом, не хотят потерять потраченное время, усилия и вклад в общую идеологию, и будут продолжать работать с DWeb в обозримом будущем.

Внедрение DWeb

14. Назовите наиболее трудные препятствия на пути к DWeb

Несмотря на технические проблемы, стоящие перед дальнейшим ростом DWeb, они не являются главной помехой проблема в пользователях.

• Пользователи недостаточно осведомлены о том, что такое DWeb, как и о его преимуществах 70%
• Неготовность новой технологии 49%
• Сопротивление FAANG 42%
• Отсутствие бизнес-моделей для DWeb проектов 38%
• Отсутствие интеграции децентрализованных технологий с веб-браузерами 37%

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

15. Что именно препятствует массовому использованию вашего DWeb приложения/протокола?

• Неготовность проекта 59%
• Трудности с обучением/объяснением новым пользователям, как работает DWeb 35,5%
• Сравнительно небольшое количество пользователей DWeb 24%

Осведомленность пользователей о децентрализованных технологиях необходима, чтобы отвлечь их от централизованной, традиционной парадигмы, которая сегодня доминирует в сети. Наряду с преимуществами UX/UI централизованных систем, идеология DWeb несет гораздо больше положительных моментов для пользователей. Пока что понимание и особенно использование слишком сложно для обычного пользователя без технического бэкграунда. Запуск многих p2p приложений отличается от запуска обычных приложений.

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

Роль блокчейна

Блокчейн технология была на пике популярности во время массового запуска ICO в конце 2017 года. С тех пор разработчики и компании взаимодействуют с различными блокчейн сервисами с переменным успехом.

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

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

16. Что вы думаете о роли блокчейна?

• Блокчейн не решение всех проблем 58%
• Блокчейн удобен для цифровой валюты и платежей 54%
• Блокчейн идеален для децентрализованных ID 36%
• Полезность блокчейна для широкого круга задач DWeb 33%
• Блокчейн можно использовать в цифровой сертификации 31%
• Технология блокчейн это пустая трата времени 14%

Проекты DWeb

Типы проектов

Респонденты, работающие над различными DWeb проектами, географически разбросаны по всему миру, и работают как в неизвестных, так и в более популярных в этой сфере проектах. Некоторые из наиболее известных проектов включают IPFS, Dat и OrbitDB, менее крупные например, Lokinet, Radicle, Textile, и другие.

17. Типы DWeb проектов

Типы проектов DWeb значительно различались. Мы обобщили их в группы в зависимости от целей. Вот наиболее популярные направления, которым респонденты отдают свои идеологические предпочтения:

• Области хранения и обмена данными 27
• Социальные сети 17
• Финансы 16

Интересно, что цензура в социальных сетях и ограниченные возможности обмена данными без использования инфраструктуры FAANG как раз упоминались в наиболее острых проблемах с текущим вебом.

Кроме того, финансовая революция, проявляющаяся в наиболее практическом юзкейсе DeFi на Ethereum это слияние технологии блокчейна и P2P протоколов DWeb.

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

18. Что вы разрабатываете протокол или приложение?

Из всех участников исследования 231 человек указал, что работает над проектом.

• Развивают приложения для конечных пользователей 49%
• Работают над инфраструктурой или протоколами для разработчиков 44%

Мотивация

19. Почему вы сделали выбор в пользу P2P, а не централизованной архитектуры для своего проекта?

Разработчики ранее уже отмечали идеологическое предпочтение использования DWeb и технологий P2P. В вопросе почему они выбирают peer-to-peer технологии,

• Большинство опирается на фундаментальные идеологические ценности 72%
• Выбрали DWeb по техническим причинам 58%

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

Статус проектов и команды

20. На какой стадии ваш проект?

• Все еще находятся на стадии разработки 51%
• Запущены 29%
• На стадии идеи / концепции 15%
• Находятся на других стадиях разработки 5%

21. Сколько вы работаете над своим проектом?

Условно говоря, большинство проектов DWeb являются новыми по сравнению с их централизованными веб-аналогами.

• Работают только 1 2 года 31,5%
• Существуют более 3 лет 21%
• Работают менее 1 года 17%

22. Сколько человек работает в вашем проекте?

Размеры команд варьируются в небольших диапазонах.

• От двух до пяти человек 35%
• Работают в одиночку 34%
• Более 10 разработчиков в команде (обычно это хорошо известные проекты, такие как IPFS) 21%
• Команда от 6 до 10 разработчиков 10%

Технические характеристики

Что касается лицензирования open source DWeb проектов, разработчики выбирают лицензии релевантные и для традиционных технологий.

23. Какую лицензию вы выбрали для своего проекта?

• MIT 42%
• AGPL 3.0 21%
• Apache 2.0 16,5%
• Решение о лицензировании пока не принято 18,5%
• Не лицензируют свой код 10%

24. Основной стек вашего проекта?

Стек проектов представляет собой сочетание наиболее часто используемых технологий front-end, back-end и DWeb.
Фронтенд в основном представлен:

• React 20
• Typescript 13
• Angular 8
• Electron 6

Для бэкенда респонденты в основном используют:

• GO 25
• Node.js 33
• Rust 24
• Python 18

В целом, выбор отражает массовые тенденции в области разработки open source, например, в отчете Github State of the Octoverse.

В технологиях DWeb лидируют:

• IPFS 32
• Ethereum 30
• libp2p 14
• DAT 10

Бизнес-модели и инвестиции

25. Какая бизнес-модель у вашего проекта?

Бизнес-модели в DWeb были названы одной из наиболее серьезных проблем, стоящих перед разработчиками. Трудно извлечь ценность из открытых протоколов, которые не придерживаются централизованных схем монетизации данных.

• Нет модели получения доходов со своего проекта 30%
• Подумаю об этом позже 22,5%
• Модель Freemium 15%
• Платный DWeb продукт 15%

Некоторые из концептуальных идей монетизации остаются пока полусырыми для применения в DWeb. Например, SaaS и лицензирование были упомянуты несколько раз в комментариях. Стэйкинг и governance в блокчейнах также упоминались в нескольких проектах. Хотя в них определенно есть потенциал, они все еще находятся на самых ранних стадиях и не готовы к широкому распространению.

Финансирование

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

26. Как были получены первые инвестиции для вашего проекта?

• Проект DWeb финансируется его основателем 53%
• Получили инвестиции от венчурных фондов или бизнес-ангелов 19%
• Получили гранты 15%
• Количество токен сейлов и ICO существенно сокращается с 2017 года, и составляет малую долю от всех проектов 10%

Участники исследования не стеснялись выражать свое разочарование в сложностях получения инвестиций для DWeb.

Аудитория проектов

27. Ежемесячная аудитория вашего проекта

Проблема привлечения и обучения пользователей влияет на количество пользователей проектов DWeb. Количество сильно разнится в меньшую сторону по сравнению с централизованными приложениями.

• Еще не запустили продукт 35%
• Менее 100 пользователей в месяц 21%
• Не имеют возможности оценить свою аудиторию 10,5%
• Не знают количество пользователей 10%
• От 100 до 1K пользователей 9%

Заключение и выводы

• Понятие DWeb среди его сторонников в основном обусловлено как семантикой, так и более широкими целями децентрализации: суверенитетом данных, конфиденциальностью, борьбой с цензурой и сопутствующими ими изменениями. По-видимому, всё это является основным лейтмотивом и точкой роста Двеба.
• Многие проекты и заинтересованные респонденты поддерживают идеологические ценности DWeb. Ценности варьируются от подавления государственного надзора за пользователями до прекращения злоупотребления пользовательскими данными технологическими гигантами.
• Разработчики в восторге от DWeb, но широкое признание технологий и приложений DWeb в лучшем случае пока что не на должном уровне. Информации достаточно мало, а проблемы суверенитета и конфиденциальности данных все еще не доведены достаточным образом до общественности. Разработчики сталкиваются со множеством препятствий, начиная от недостатка документации и инструментов до несовместимости технологии DWeb с существующей инфраструктурой.
• Большинство обычных пользователей склонны согласиться с предпосылками DWeb. Однако технические ограничения мешают разработчикам. Неудобные для пользователей приложения, например, из-за производительности или сложности, препятствуют более широкому внедрению технологии DWeb.
• Правительства и крупные технологические компании демонстрируют ощутимое сопротивление появлению децентрализованных технологий, будь то финансы, конфиденциальность данных или устойчивость к цензуре. Крупные технологические фирмы не смогут легко отказаться от контроля над необъятными массивами пользовательских данных, которыми они владеют. Тем не менее, технология DWeb может вытеснить их. Фундамент положен, и за ним должно прийти сильное массовое движение. Теперь речь идет о создании инфраструктуры технологии, предоставлении большего количества образовательных материалов для разработчиков и обычных веб-пользователей.
• Монетизация и финансирование являются критическими проблемами для технологий DWeb на данный момент. Доступ к финансированию, несомненно, будет повышен после окончания пандемии. Всё же проектам DWeb необходимо найти новые способы расширения своих финансовых возможностей, помимо вариантов венчурных или инвестиций от бизнес-ангелов. Технологические гиганты в виде FAANG держат хватку и демонстрируют склонность к подавлению конкуренции. Без адекватных моделей монетизации проекты DWeb будут бесконечно бороться за актуальность и привлекательность для массового пользователя.

Видение DWeb состоит в том, чтобы разрушить многие централизованные модели, например, модель данных клиент-сервер и бизнес-модель, основанную на рекламе, и воссоздать децентрализованные с нуля, что очень амбициозно.

Технология DWeb вызывает глубокий интерес и стремительно растет. У выдающихся проектов, таких как Ethereum и IPFS, уже есть огромное количество сторонников. Тем не менее количество пользователей и признание небольших проектов уменьшается в связи с монополизацией рынка традиционными технологическими гигантами. Для того чтобы эти проекты получили дальнейшее развитие, необходима инфраструктура. К примеру, инструменты для разработчиков, и поддерживаемая документация, а также рычаги для привлечения обычного веб-пользователя к приложениям DWeb.

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

• Растущая осознанность о необходимости более высокого уровня конфиденциальности после разоблачения правительственного надзора, серьезных нарушений и массовых утечек данных потребителей. Пользователи хотят контролировать свои данные. Цифровая конфиденциальность теперь пользуется большим спросом. DWeb сможет показать пользователям практические решения.
• Неопределенная экономическая и денежно-кредитная политика во время пандемии может подтолкнуть многих к изучению крипто технологий, и тем самым познакомить их с частью DWeb.
• Глобальный всплеск развития open-source проектов, инструментов и лицензий накапливает сферу влияния на главные индустрии, тем самым снижая барьеры доступа и раскрывая децентрализованный потенциал Интернета.
• Основные веб-браузеры, интегрирующие протоколы DWeb (например, Opera) и новые появляющиеся браузеры (Brave), могут сделать переход к децентрализованным технологиям простым и почти незаметным для обычных пользователей.

Интернет, несмотря на свое скромное, децентрализованное происхождение, десятилетиями переходил к централизации.

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

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

Список участников исследования можно посмотреть тут. Так же доступны анонимизированные сырые данные. Спасибо всем за участие!

Специально к старту курса Машинное обучение в этом материале знакомим читателей Хабра с Fetch.ai децентрализованной платформой для оптимизации существующих технологий с помощью искусственного интеллекта, машинного обучения и интеллектуального обмена данными. Платформу можно использовать, чтобы создать агента, например, программу, которая с учётом реальных обстоятельств рекомендует, когда сесть на поезд. Ещё один пример агент, контролирующий потребление электроэнергии. Подробности о самой Fetch.ai, датах тестирования сети агентов, список партнёров стартапа (который включает Кембриджский Университет) и ссылки на ресурсы, включая репозиторий GitHub, под катом.

---

Миссия Fetch.ai создать инфраструктуру, необходимую для автономных программных агентов, чтобы раскрыть ценность, казалось бы, бесполезных данных и организовать выполнение сложных задач в интересах частных лиц, предприятий и организаций.

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

Прогресс в области партнёрства где мы находимся сегодня?

Наша долгосрочная цель разработать и реализовать полезные варианты применения нашей технологии. Чтобы достичь этой цели цели, нам необходимо было сотрудничать с разделяющими наши взгляды организациями. Буквально на прошлой неделе мы объявили о партнёрстве с Datarella, в сотрудничестве с которой планируем построить децентрализованную сеть машинного обучения с открытым доступом для интеллектуальной инфраструктуры. В частности, цель этого партнёрства сосредоточена на расширяющейся сейчас интеллектуальной парковке, интеллектуальной мобильности и инфраструктуре умного города, построенной с использованием искусственного интеллекта, блокчейна и интернета вещей. Ключевые преимущества этого сотрудничества включают снижение выбросов CO2, заторов на дорогах и борьбу с изменением климата. Но наше партнерство с Datarella не единственное, о чём мы объявили в прошлом, направлено на изменение взгляда на технологии в повседневной жизни. Посмотрите полный список всех наших партнёрских отношений, которые мы уже подтвердили:

Cambridge University, T-Labs, Batu Metallurgy, Warwick Business School, Wi-Q technologies, Hegic, Conflux Network, Waves, Ankr, Grey Swan Digital, Mobility Open Blockchain Initiative (MOBI), Sovrin Steward, Smart Dubai with Outlier Ventures, Trusted IoT Alliance, Blockchain 4 Europe.

Зачем это разработчику?

Вопрос на миллион, правда? Зачем вам присоединяться к этому в качестве разработчика? Сегодня мы в значительной степени незаметны не потому, что хотим оставаться незаметными, а потому, что хотим поддерживать дискуссию.

Мы не обещаем миру утопию, но хотим сделать мир лучше, заложив основы цифровой экономики. Взаимосвязанную демократизированную экономику, в которой вы контролируете свои данные и получаете от них прямую выгоду. Мы начали программу Incentivized Testnet, в которой сегодня создаём и тестируем настоящих автономных агентов, направленных на решение множества проблем.

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

Но мы хотим пойти дальше. Наша цель запустить сеть Mainnet v2.0 в начале следующего года, и, чтобы не отклоняться от намеченных целей, мы разделили график разработки, разбив его на разные фазы. Сейчас мы находимся на первой фазе программы Incentivized Testnet, в которой запущен и работает Agent World 2. Если вы еще не присоединились к программе Incentivized Testnet, вы можете сделать это здесь.

В любом случае, где мы были? Мы тестируем Agent World 2 Testnet, в которой создаем агентов, помогающих решать проблемы серьёзнее, чем заказ пиццы. После начала партнёрских отношений с Datarella мы хотим использовать наших агентов для решения текущих проблем в области мобильности и изменения климата.

Имейте в виду, что агенты должны соответствовать правилам FIPA (Фонда интеллектуальных физических агентов) для ведения переговоров и заключения сделок, и мы создадим агентов-покупателей для отслеживания доставляемой информации. После завершения Agent World 2 у вас будет реальный агент, продающий реальные данные, ищущий и обнаруживающий их с помощью Simple Open Economic Framework (SOEF) в цифровом мире Fetch.ai. Если вам интересно, что означает SOEF:

OEF это протокол поиска, обнаружения и транзакций для сети Fetch. Представьте три уровня:

Агенты это программное обеспечение, боты, приложения, созданные пользователями, которые находят друг друга через OEF. OEF, в свою очередь, является коммуникационным протоколом для ботов, использующим учётный журнал в качестве средства для расчётов и завершения транзакций.

Я залогинился. Что дальше?

20 ноября мы запустили создание большой сети взаимодействующих агентов или, как мы любим ее называть, Agent World 3. Заключительный этап первой фазы программы Incentivized Testnet Agent World 3 (AW-3) планируется начать в эту пятницу, он продлится до 4 декабря. Если вы хотите стать частью команды разработчиков Fetch.ai и помочь нам создать нечто важное в экосистеме блокчейна с передовыми решениями в области искусственного интеллекта и интернета вещей, отправьте нам электронное письмо по адресу developer@fetch.ai и присоединяйтесь к нам в Discord. Не забудьте посмотреть наш репозиторий для разработчиков на docs.fetch.ai.

• Продвинутый курс Machine Learning Pro + Deep Learning
• Курс Математика и Machine Learning для Data Science
• Курс по Machine Learning
• Обучение профессии Data Science
• Обучение профессии Data Analyst
• Курс Python для веб-разработки

Рекомендуемые статьи

• Сколько зарабатывает дата-сайентист: обзор зарплат и вакансий в 2020
• Сколько зарабатывает аналитик данных: обзор зарплат и вакансий в 2020
• Как стать Data Scientist без онлайн-курсов
• 450 бесплатных курсов от Лиги Плюща
• Как изучать Machine Learning 5 дней в неделю 9 месяцев подряд
• Machine Learning и Computer Vision в добывающей промышленности

Предлагаемая информационная среда является своего рода децентрализованной социальной сетью. Но в отличии от многих существующих решений данная среда имеет ряд полезных свойств помимо децентрализации и создана на базе достаточно простых и стандартных технических решений (email, json, текстовые файлы и немного блокчейна). Что позволяет любому желающему с базовыми знаниями программирования создавать свои сервисы для данной среды.

Универсальный идентификатор

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

В данном случает в качестве идентификатора пользователя выступает email, который уже фактически стал общепринятым идентификатором для авторизации на сайтах и других сервисах (jaber, openId).

Фактически идентификатор пользователя в данной онлайн среде это пара login+domain, которая для удобства записывается в привычном для большинства виде. При этом для большей децентрализации каждому пользователю желательно иметь свой домен. Что близко принципам индивеба, где в качестве пользовательского идентификатора используется домен. В нашем случае к своему домену пользователь добавляет никнейм что позволяет создавать несколько аккаунтов на одном домене (для друзей, например) и делает систему адресации более гибкой.

Такой формат идентификатора пользователя не привязан к какой-либо сети. Если пользователь размещает свои данные в TOR сети то можно использовать домены в зоне .onion, если это сеть с DNS системой на блокчейне то домены в зоне типа .bit. В итоге, формат адресации пользователей и их данных не зависит от сети, через которую они передаются (везде используется связка login+domain). Для желающих использовать в качестве идентификатора bitcoin/ethereum адрес можно доработать систему под использование псевдо email адресов вида xaca1b7c8126806f672f9dbee4951527bb0f2c4e4@ethereum.blockchain

Адресация объектов

Данная онлайн среда фактически является набором объектов, которые описаны в структурированном машиночитаемом виде, ссылаются на другие объекты и привязаны к определённому пользователю (emailу) или проекту/организации (домену).

В качестве идентификаторов объектов используются urn в пространстве имён urn:opendata. Например, профайл пользователя имеет адрес вида:

urn:opendata:profile:user@domain.com

Комментарий пользователя имеет адрес вида:

urn:opendata:comment:user@domain.com:08adbed93413782682fd25da77bd93c99dfd0548

где 08adbed93413782682fd25da77bd93c99dfd0548 случайный sha-1 хэш, выступающий в роли id объекта, а user@domain.com владелец данного объекта.

Принцип публикации пользовательских данных

Имея под управлением свой домен пользователь может достаточно просто публиковать свои данные и контент. И в отличии от индибеба, для этого не требуется создавать сайт с html страницами, в которых встроены семантические данные.

Например, базовая информация о пользователе размещается в файле datarobots.txt, который находится по адресу вида

http://55334.ru/konstantin@55334.ru/datarobots.txt

И имеет содержание такого формата:

Object: userServices-Enabled: 55334.ru,newethnos.ruEthnos: newethnosDelegate-Tokens: http://55334.ru/konstantin@55334.ru/delegete.txt

То есть фактически это набор строк с данными вида ключ->значение, спарсить которые простая задача для любого человека с базовыми знаниями программирования. А редактировать данные при желании можно через обычный блокнот.

Более сложные данные (профайл, комментарий, пост и т. д.), имеющие свой urn отдаются в виде JSON объекта по стандартному API (http://personeltest.ru/away/opendatahub.org/api_1.0?lang=ru), которое может находиться как на домене пользователя, так и на стороннем сайте, которому пользователь делегировал хранение, публикацию и редактирование своих данных (в строке Services-Enabled файла datarobots.txt). О подобных сторонних сервиса написано ниже.

Простая онтология и JSON

Онтология коммуникационной среды является относительно простой, по сравнению с онтологиями отраслевых баз знаний. Так как в коммуникационной среде существует относительно небольшой набор стандартных объектов (пост, комментарий, лайк, профайл, отзыв) с относительно небольшим набором свойств.

Поэтому для описания объектов в такой среде достаточно использовать JSON вместо более сложного по структуре и парсингу XML (важно не забывать про необходимость низкого порога входа и масштабируемость).

Для получения объекта с известным нам urn необходимо обратиться к домену пользователя, либо сторонним сервисам, которым пользователь делегировал управление его данными.

В данной онлайн среде каждый домен, на котором существует онлайн-сервис, также имеет свой datarobots.txt размещённый по адресу вида example.com/datarobots.txt с подобным содержанием:

Object: serviceApi: http://newethnos.ru/apiApi-Version: http://opendatahub.org/api_1.0

Из которого мы может узнать, что получить данные об объекте можно по адресу вида:

http://newethnos.ru/api?urn=urn:opendata:profile:konstantin@55334.ru

JSON объект имеет такую структуру:

{    "urn": "urn:opendata:profile:expample@55334.ru",    "status": 1,    "message": "Ok",    "timestamp": 1596429631,    "service": "example.com",    "data": {        "name": "John",        "surname": "Gald",        "gender": "male",        "city": "Moscow",        "img": "http://domain.com/image.jpg",        "birthtime": 332467200,        "community_friends": {            "example1@domain.com": "1",            "example2@domain.com": "0.5",            "example3@domain.com": "0.7"        },        "interests_tags": "cars,cats,cinema",        "mental_cards": {            "no_alcohol@main": 8,            "data_accumulation@main": 8,            "open_data@main": 8        }    }}

Сервисная архитектура

Сторонние сервисы необходимы для упрощения процесса публикации и поиска данных конечными пользователями.

Выше был упомянут один из видов сервисов, которые помогают пользователю публиковать его данные в сети. Возможно существование множества подобных сервисов, каждый из которых предоставляет пользователю удобный интерфейс для редактирования одного из видов данных (форум, блог, вопрос-ответ и т. д.). Если же пользователь не доверяет сторонним сервисам, то он может установить на свой домен скрипт сервиса по работе с данными или разработать его самостоятельно.

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

Одним из видов таких сервисов являются хабы данных ( opendatahub.org/ru пример ), выполняющие роль своего рода веб архива, который собирает все публичные машиночитаемые данные пользователей и предоставляет к ним доступ по API.

Наличие сервисов в такой открытой децентрализованной онлайн среде существенно снижает порог входа для пользователей, так как отсутствует необходимость в установке и настройке собственного узла. В тоже время у пользователя остаётся контроль над своими данными (в любой момент можно сменить сервис которому делегирована публикация данных или создать свой узел).

Если же пользователю вообще не интересно владение своими данными и он не имеет своего домена или знакомого с доменом то по умолчанию его данными управляет opendatahub.org.

За чей счёт всё это?

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

Для покрытия расходов на разработку и маркетинг в данной онлайн среде используются donate + tokens.

Все пожертвования, которые пользователи вносят внутренним проектам/сервисам являются общедоступными, машиночитаемыми и привязаны к email. Что позволяет учитывать их, например, при вычислении внутрисетевого социального рейтинга и публиковать на страницах пользователей. Когда пожертвования перестают быть анонимными, то фактически пользователи не жертвуют, а скидываются на поддержку общей информационной среды. Также как люди скидываются на ремонт мест общего пользования с соответствующим отношением к тем людям, которые отказались скинуться.

Помимо пожертвований, для привлечения средств используются токены эмитированные в ограниченном количестве (400.000), которые начисляются всем кто вносит пожертвования в основной фонд (ethnogenesis).

Дополнительные функции токенов

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

Токены являются хорошим спам-фильтром из-за своей ограниченности. Чем больше в системе пользователей тем сложнее получить токен и тем более затратно создавать ботов.

Люди, их данные и социальные связи важнее технологий

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

Создаваемая социальная общность, участники которой имеют свои универсальные идентификаторы (email и свой домен) и структурированные данные (с URN адресами, онтологией и JSON объектами) при появлении лучшего технического решения может перенести все эти данные в другую онлайн среду, сохранив при этом сформированные связи (рейтинги, оценки) и контент.

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