P2p

Что там с P2P-соцсетями поиск альтернативных решений или еще одна мишень для регуляторов

29.11.2020 22:13:53 |

Автор: admin

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

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

Unsplash / Tim Mossholder

Как развивается ситуация

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

Двигаться к столь амбициозной цели и не спровоцировать конфликтные ситуации по определению невозможно. Более того, на первых порах не получилось обойти стороной и спорные моменты, проявившие себя задолго до возникновения первых масштабных peer-to-peer проектов. Именно так в контексте оффлайновой войны за копирайт в 1999 году появился Napster. Судебные дела против музыкальных пиратов шли и до его запуска, но появление столь заметного и эффективного по тем временам решения только подстегнуло их интенсивность.

К закрытию сервиса в 2001 году (в его изначальном исполнении) технологическое сообщество представило своеобразный ответ на усилившееся давление еще один способ децентрализованного обмена данными, а именно с помощью BitTorrent. Его энтузиасты успешно пользовались плодами творчества разработчиков проекта более десятилетия к 2013-му аналитики приписывали протоколу 3,35% общемирового трафика. Но как на владельцев, так и на пользователей торрент-трекеров постепенно нашли управу сегодня площадки охотно выдают их персональные данные, поэтому популярность протокола гаснет от года к году.

Unsplash / George Pagan III

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

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

Не все так просто

Сами P2P-проекты предоставляют решения для многих, но далеко не всех из перечисленных выше проблем. Более того, иногда гайдлайны, декларируемые основателями и разработчиками, отличаются от того, как аудитория пользуется их продуктом. Так, протокол Dat Foundation, обходившей стороной политические темы, неоднократно использовали для хранения и обмена данными в качестве своего рода протеста против определенных мер властей. Те, кто шел на такие действия, испытывали на себе возможные риски, которые были известны и самой организации.

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

Unsplash / Alina Grubnyak

Другие peer-to-peer начинания вроде Secure Scuttlebutt и Fediverse демонстрируют свои особенности. Первый не позволяет пользователям удалять собственные записи и фактически хранит в сети лог всех совершенных ими действий. Второй, представляющий собой гораздо более крупный проект, не задействует end-to-end шифрование.

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

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

Что дальше

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

Дополнительное чтение:

Научная статья по теме Peer-to-Peer based Social Networks: A Comprehensive Survey
Одной канарейки мало: у VPN-сервисов все чаще запрашивают персональные данные
Доступный интернет промежуточные итоги, мнения операторов и пользователей
В Китае ввели блокировку ESNI-соединений: обсуждаем ситуацию и варианты обхода
Переведут ли госсофт на open source возможности для развития этого тренда в США

Подробнее..

Категории: Информационная безопасность , Блог компании vas experts , Vas experts , P2p , P2p-сервисы , Торрент-трекеры , Peer to peer

Команда энтузиастов выпустила P2P-браузер Beaker 1.0 после двух лет разработки

05.12.2020 20:19:25 |

Автор: admin

Пару лет назад стало известно, что группа энтузиастов разрабатывает P2P-браузер с поддержкой протокола Hypercore. Этот браузер получил название Beaker 1.0. Цель проекта предоставить возможность пользователям разрабатывать и размещать свои сайты не где-то там, а прямо в браузере. То есть можно создать локальную папку и поделиться URL-адресом, который откроет доступ сторонним пользователям к новому ресурсу.

Узлы сети в этом случае сами пользователи браузера. Beaker базируется на JavaScript c использованием движка Chromium и платформы Electron. Распространияется Beaker под лицензией MIT. Разработчики подготовили сборки для Linux, macOS и Windows.

А что за протокол такой Hypercore?

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

Чтобы создать собственный сайт, нужно просто подготовить код, развернуть окружение Hyperdrive и разместить на него ссылку. Доступ к ресурсу обеспечивается при помощи URL hyper://. Как только ссылка открыта, контент загружается с системы автора и сразу после загрузки файлов новый пользователь может стать новым узлом в системе раздачи.

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

Целостность лога проверяется при помощи структуры Дерево Меркла (Merkle Tree). В этом случае каждая ветка верифицирует все ветки и узлы, которые находятся ниже. Такая верификация стала возможной благодаря хэш-функции BLAKE2b-256.

Как создавать сайты?

В браузере уже есть все необходимое. Это редактор кода и инструменты для синхронизации каталогов с содержимым сайта. А еще есть web-терминал и специализированный API для чтения и загрузки файлов. Терминал представляет собой командную оболочку для навигации по окружению Hyperdrive.

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

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

Подробнее..

Категории: Информационная безопасность , Социальные сети и сообщества , Браузеры , Сетевые технологии , Блог компании selectel , P2p , Beaker

Пиринговые мессенджеры враг государства?

24.05.2021 12:21:25 |

Автор: admin

В случае полного отключения интернета одна из главных проблем общение с товарищами и родственниками. Опыт Гонконга показывает, что для этого хорошо подходят децентрализованные 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 вариант децентрализованной сети

30.06.2020 12:04:28 |

Автор: admin

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

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

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

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

Подробнее..

Категории: Javascript , Node.js , Распределенные системы , Децентрализация , Децентрализованные сети , P2p

Musiphone децентрализованный музыкальный плеер

22.04.2021 16:18:43 |

Автор: admin

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

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

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

Подробнее..

Категории: Javascript , Node.js , Хранилища данных , Распределенные системы , Децентрализация , Децентрализованные сети , P2p , Музыка , Хранилище данных , Плеер , Хранилище файлов

Бесполезное видеонаблюдение или принцип Чабудо китайских производителей

03.12.2020 20:22:40 |

Автор: admin

Легендарная пыль

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

Если посмотреть на большинство крупных брендов, то на деле все они использует OEM поставки от одних и тех же китайских производителей почти с одним и тем же софтом внутри (Dahua и Hikivision).

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

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

Скриншот программы SmartPSS

Скриншот программы CMS

Большие системы

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

Видеоаналитика

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

Многие компании предлагают облачную видеоаналитику. Но этот подход имеет существенный недостаток - высокую стоимость трафика и самих сервисов.

Представленный на рынке софт для видео наблюдения можно разделить на следующие категории:

Небольшие программы, open source и подручные самописные средства.
Сложные дорогие программы, разработанные для корпоративных заказчиков. Они эффективно работают, но требуют больших затрат в обслуживании и специальной инфраструктуры.
Используемые по наследству морально устаревшие hardware-решения, неудобные в использовании и обладающие ограниченными возможностями. Они функционируют на основе старых алгоритмов видео-кодирования.
VSaaS (video surveillance as a service) - Облачные решения для записи и хранения видеозаписей с облачными сервисами. Такие сервисы часто предлагают уже преднастроенные ip камеры, привязанные к собственным облачным сервисам.

Cиний туман похож на ...

VSaaS значительно упрощает подключение устройств, но в этом случае приходится ежемесячно оплачивать услуги для каждой из ip камер. Эти услуги не дешевы и стоимость сильно зависит от желаемого срока хранения видеозаписей на сервере. Если вы хотите использовать, например, 10 камер, то стоимость выльется в существенную сумму - от 1000 до 30000 долларов в год в зависимости от срока хранения архива без учета стоимости оборудования. Т.е. каждый ежемесячный платеж может быть больше, чем стоимость самого оборудования. Стоимость облачных камер, как правило, существенно выше рыночных аналогов, несмотря на одинаковое железо внутри. Узким местом VSaaS является пропускная способность канала передачи данных.

При круглосуточной трансляции видео 1920х1080 (HD) в течение одного месяца каждая ip камера может съесть до 648 Гб интернет-трафика. При большой нагрузке провайдер может понижать скорость вашего соединения. Одна камера с высокой четкостью изображения, использующая продвинутые алгоритмы сжатия, например, H.264, генерирует поток данных со скоростью 2 - 10 Мбит/с. С другой стороны, средняя скорость исходящего канала в мире сейчас составляет только 5 Мбит/с.

Получается разрыв между текущими запросами пользователей VSaaS и возможностями каналов интернет провайдеров. Использование нескольких камер становится проблематичным, особенно для камер высокого разрешения. Суммарный поток данных при использовании 150 видеокамер разрешением 2 Мп (30 fps) для охраны периметра, имеет нагрузку на канал связи более 1 Гб/с. Удаленный просмотр, запись видео становятся ненадежными и невозможными. В итоге, облачное видеонаблюдение может превратиться в туманное с потерей важных данных. Многие пользователи уже успели разочароваться в таких сервисах из-за потери важных кадров.

Нейронные сети или из тумана снова в облако

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

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

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

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

Боль пользователей

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

Децентрализация без политики

В последнее время благодаря новым решениям и технологии P2P (peer to peer) можно установить и настроить удаленное видеонаблюдение самостоятельно и очень легко.

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

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

В итоге, Р2Р отличается более эффективным использованием полосы пропускания канала. В этом случае не требуется дополнительная облачная ретрансляция и обработка видеопотока (кодирование/декодирование) и пользователь не зависит от бутылочного горлышка возможностей облачного провайдера. Сервер в данном случае выступает только в качестве посредника, пробивающего NAT, связывающего вашу IP-камеру и устройство пользователя напрямую. Видеопоток передается напрямую от одного вашего устройства к другому вашему компьютеру или мобильному устройству.

Простота настроек сетевого оборудования - основное преимущество Р2Р технологии перед другими способами передачи сигнала. Возможность работы с серыми и динамическим IP позволяет установить видеонаблюдения в местах, где нет доступа к проводному интернету. Достаточно будет приобрести 3G/4G модем с поддержкой Wi-Fi и настроить программное обеспечение.

Зачем платить облаку, если можно наблюдать бесплатно?

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

Подробнее можно посмотреть на видео.

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

Почему китайские производители камер создают программы с интерфейсом в стиле Чабудо?

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

Облачный сервис для камер Hikivision

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

Чабудо полная противоположность позыву сделать свое дело качественно и с полной отдачей. Дверь не подходит к раме? Чабудо, можно привыкнуть закрывать ее пинком. Алиэкспресс прислал ip камеру, которая глючит? Чабудо же, она хоть и криво, но работает, на что ты жалуешься? Интерфейс неудобный, не рассчитан на крупные шрифты и высокое разрешения монитора? не проблема, китайские пользователи вполне cмогут использовать, поменяв разрешение экрана.

Мнимая свобода выбора

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

Куда мы идём? Что будет дальше?

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

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

Новая бесплатная программа

Web Camera Pro - бесплатная программа, которая написана на Qt, С++ как мультиплатформенное решение. Вы можете использовать любую ip или usb камеру для полноценной системы видеонаблюдения с удаленным доступом из любой точки мира и с минимальными затратами.

Интерфейс Web Camera Pro:

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

Видеоинструкция:

https://www.youtube.com/watch?v=OvSQ1C5Lsd8

https://www.youtube.com/watch?v=CreFNidJqZI

https://www.youtube.com/watch?v=fRJdZATpixg

Скачать бесплатную версию Web Camera Pro можно здесь:

http://free-video-surveillance.com/home-security-camera

Подробнее..

Категории: Работа с видео , Искусственный интеллект , Машинное обучение , Обработка изображений , Облачные сервисы , Видеоконференцсвязь , Ip камера , P2p , Видеонаблюдение , Программное обеспечение , Видеоаналитика , Облачный сервис , Вебкамера , P2p видео , Удалённый просмотр

Git-ssb децентрализованный хостинг git-репозиториев

17.01.2021 02:11:24 |

Автор: admin

SSB (Secure Scuttlebutt) - это децентрализованная социальная сеть и протокол, на основе которого она работает. git-ssb заворачивает обычные git-репозитории в этот протокол. SSB хочет заменить собой Facebook, а git-ssb - GitHub. Под катом - краткое руководство по git-ssb. Актуально для тех, кому дискомфортна сама идея использования централизованных сервисов в качестве посредника. Своеобразная красная таблетка с полагающимися в этом случае неожиданными последствиями.

Secure Scuttlebutt

Протокол SSB описывает правила синхронизации ваших данных между заинтересованными в них узлами сети. Ваши данные - это история ваших действий в сети, связный список json-объектов. Связь задаётся hash-суммой предыдущего объекта (как в блокчейне). Таким образом, однажды опубликованные объекты неизменяемы и неудаляемы. Добавлять можно только в конец списка. Типичный use case предполагает, что каждый объект в списке - это пост или комментарий в блоге. Картинки и другие тяжёлые объекты хранятся вне списка в виде blob-ов и реплицируются отдельно. Объекты в списке могут на них ссылаться.

Большинство пользователей сети ведут блоги в приложениях Patchwork и Manyverse. Приложений для ведения блогов около десятка, они, в основном, совместимы друг с другом и отличаются интерфейсом. Кроме этого есть шахматы, чат, менеджер пакетов (ssb-npm) и git (git-ssb). Некоторые разработчики SSB используют git-ssb как основной сервис для управления версиями исходников. Мы тоже попробуем.

Установите ssb-server и git-ssb

ssb-server нужен для синхронизации с другими узлами в p2p сети. Он должен быть запущен, когда вы делаете push, pull, fetch, создаёте pull-request или форкаете репозиторий.

Пакет git-ssb включает:

программу для управления репозиториями (git-ssb)
git-remote-helper, который понимает адреса, начинающиеся с ssb://
web-интерфейс, отдалённо напоминающий GitHub

Все три компонента взаимодействуют с запущенным на вашей машине ssb-server.

$ sudo apt install git nodejs npm$ npm install ssb-server git-ssb

ssb-server и git-ssb установятся в папку $HOME/node_modules. Чтобы было удобнее их вызывать, добавьте в конец файла ~/.profile стоки:

if [ -d "$HOME/node_modules/.bin/" ] ; then    PATH="$HOME/node_modules/.bin/:$PATH"fi

Чтобы переменная $PATH обновилась в текущей сессии, наберите

$ source ~/.profile

При логине файл ~/.profile должен исполниться автоматически. Некоторые среды рабочего стола (например, Xfce) этого не делают. Если после перезагрузки переменная $PATH не обновилась, то добавьте в .xsessionrc явный вызов ~/.profile:

. ~/.profile

Запустите ssb-server и оставьте его работающим на время экспериментов.

$ ssb-server start

При первом запуске он создаст identity по умолчанию в папке ~/.ssb.

Получите инвайт и примите его

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

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

$ ssb-server invite.accept <ваш-инвайт-код>

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

Подпишитесь на @cel

@cel - это разработчик git-ssb.

$ ssb-server publish --type contact --contact "@f/6sQ6d2CMxRUhLpspgGIulDxDCwYD7DzFzPNr7u5AU=.ed25519" --following

Сейчас в папку ~/.ssb скачается около 1Gb данных - это его история (там и его git-репозитории) и истории тех пользователей, на которых он подписан. Эта подписка нужна, чтобы последующие примеры у всех работали примерно одинаково.

Установка и настройка завершены. Теперь вы многое можете:

Запустить web-интерфейс

$ git-ssb-web

Перейдя по напечатанной в консоли ссылке вы увидите хронологический список коммитов, issue и других действий в видимых репозиториях. Это, разумеется, не всё, а только то, что скачалось после подписки на предыдущем шаге. Нажав на имя пользователя вы увидите его activity log, нажав на репозиторий - интерфейс, похожий на GitHub.

Репозиторий git-ssb в git-ssb

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

Создать репозиторий

$ mkdir my-new-repo$ cd my-new-repo$ git initInitialized empty Git repository in /tmp/my-new-repo/.git/$ git-ssb create ssb my-new-repoCreated repo: ssb://<hash-code>.sha256 (my-new-repo)Added remote: ssb$ git remote -vssb    ssb://<hash-code>.sha256 (fetch)ssb    ssb://<hash-code>.sha256 (push)

К привычному git init добавилась команда git-ssb create ssb my-new-repo, которая запишет в вашу историю факт создания нового репозитория с именем my-new-repo и добавит его URL в качестве remote с именем ssb. Аналогичным образом можно добавить такой remote к любому существующему репозиторию.

Запушить существующий репозиторий

Вы добавили ssb ссылку в качестве дополнительного remote к вашему репозиторию. Теперь можно пушить.

Важно: невозможно удалить что-то из SSB. Не ставьте эксперименты на чувствительных данных.

$ git push ssb master

Если репозиторий большой, то может не получиться. В git-ssb допустимый размер pack-файла зависит от максимального размера blob, а он ограничен 5Mb. Больший размер сеть не примет. Но закоммитить, тем не менее, возможно:

$ git push ssb master -o allow-big

Это не сделает вашу историю невалидной (blob синхронизируются отдельно от истории), но скачать большой pack-файл другие пользователи не смогут, пока не увеличат у себя в настройках максимальный размер blob.

Альтернативный способ вписаться в ограничение на размер pack-файла - это пушить небольшими порциями так, чтобы создаваемые git-ом pack-файлы не превышали 5Mb.

Клонировать репозиторий

Будем ставить эксперименты с git-ssb на репозитории git-ssb. В SSB нет DNS и красивых названий чего бы то ни было. Ссылку на репозиторий ssb://%n92DiQh7ietE+R+X/I403LQoyf2DtR3WQfCkDKlheQU=.sha256 я скопировал из web-интерфейса.

$ git clone ssb://%n92DiQh7ietE+R+X/I403LQoyf2DtR3WQfCkDKlheQU=.sha256 git-ssb$ cd git-ssb$ git remote -vorigin    ssb://%n92DiQh7ietE+R+X/I403LQoyf2DtR3WQfCkDKlheQU=.sha256 (fetch)origin    ssb://%n92DiQh7ietE+R+X/I403LQoyf2DtR3WQfCkDKlheQU=.sha256 (push)

В этом репозитории у нас единственный remote, и он из SSB.

Форкнуть репозиторий

$ git-ssb fork my-forkCreated repo: ssb://<new-hash-code>.sha256 (git-ssb)Added remote: my-fork$ git remote -vmy-fork    ssb://<new-hash-code>.sha256 (fetch)my-fork    ssb://<new-hash-code>.sha256 (push)origin    ssb://%n92DiQh7ietE+R+X/I403LQoyf2DtR3WQfCkDKlheQU=.sha256 (fetch)origin    ssb://%n92DiQh7ietE+R+X/I403LQoyf2DtR3WQfCkDKlheQU=.sha256 (push)

В вашей истории появится запись о создании нового репозитория, а в текущей папке добавится новый remote.

Сделать пулл-реквест

Вы внесли изменения и сделали коммит.

$ git-ssb pull-request

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

Пушить в чужой репозиторий

Это не баг, а фича. Согласно документации (git-ssb-intro), это одна из принятых моделей совместной работы. Вы создаёте в чужом репозитории ветку с именем @ваш-юзернейм/master (git checkout -b @ваш-юзернейм/master), пушите в неё (git push ssb), а после делаете пулл-реквест (git ssb pull-request). Но ничто не помешает вам запушить прямо в master без всяких пулл-реквестов.

Возможность асинхронного внесения изменений в одну ветку может привести к конфликту, если при помощи двух разных identity (про identity - см. ниже) были созданы два конкурирующих коммита. Когда git-ssb встречает такие ситуации, он просит пользователя сделать слияние этих альтернативных версий. Всё это происходит локально на вашем компьютере. Если вы не подписаны на ту другую identity, которая пушит в ваш репозиторий, то вы не увидите никакого конфликта. Другие же пользователи, которые на неё подписаны, увидят. Таким образом, один и тот же репозиторий будет выглядеть по-разному в зависимости от того, чьи обновления вы получаете.

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

С другой стороны, это может привести к распространению вредоносного кода: вы делаете что-то полезное, все об этом знают, клонируют и делают sudo make install не глядя в историю коммитов. У одних пользователей установится ваше приложение, а у других - ваше приложение с добавлением зловреда. Возможно, что даже вы сами не увидите, что после очередного git pull у вас появились чужие коммиты. Тогда зловред придёт к каждому, в том числе и к вам.

Обсуждение этой возможности внутри SSB.

Что ещё почитать?

git-ssb-intro: a guide to hacking together on the distributed web

Другие способы децентрализации git:

GitTorrent (на основе BitTorrent)
HyperGit (на основе Dat)
igis-remote (на основе IPFS)
ipld-remote (на основе IPFS)
GitCenter (на основе ZeroNet)
Mango (Ethereum + IPFS)
Radicle
Gitopia

Первые четыре подробно проанализированы в статье Daniel Aleksandersen "Four P2P distribution tools for Git repositories compared". К ней есть комментарии разработчиков SSB.

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

Картинка в шапке сгенерирована при помощи сервиса myoctocat.com.

Подробнее..

Категории: Социальные сети и сообщества , Git , Распределенные системы , Децентрализованные сети , P2p , Ssb , Secure scuttlebutt

Recovery mode Использование IPv6 в Advanced Direct Connect

17.10.2020 00:19:46 |

Автор: admin

Наблюдать за развитием файлообменной сети интересно, но ещё интереснее участвовать в нём.

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

С ADC хабами иначе. Структура этого протокола предполагает расширяемость. Хочешь новую фичу? Ну что ж предлагай, продвигай, реализуй, внедряй, пользуйся.

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

Так случилось и с IPv6. Старичок NMDC не умеет его в принципе, а вот ADC сам по себе к нему готов. Однако, не всё так просто.

Совсем немного теории

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

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

И да, этот механизм не зависит от версии используемого протокола IP.

Лебедь, рак и щука

Поговорим о клиентском софте.

Поддержка IPv6 в DC++ носит экспериментальный характер. Отдельных настроек для него нет, и тем удивительнее для меня было увидеть разные режимы работы для разных версий IP, причём пассивный как раз для шестой~~, но это неточно~~.

Получить активный режим при ручной настройке не удалось даже при явном использовании в качестве WAN IP домена с AAAA-записью, а вот в автоматическом режиме с использованием UPnP всё заработало как должно.

AirDC++ также имеет поддержку IPv6-соединений, и реализована она вовсе отдельно от IPv4. Более того, этот клиент модифицирует тэги пользователей таким образом, чтобы отображать режимы работы для обоих IP протоколов одновременно. Сами хабы делать этого (пока) не умеют, а жаль.

Сразу должен оговориться: AirDC++ делает так один и для себя. В дальнейшем для удобства я буду использовать сочетания вроде AP или AA как указание на активный или пассивный режимы работы для IPv4 и IPv6 соответственно, а не их отображение в тэге реального клиента на реальном хабе. Это важно.

В нашем эксперименте мы будем использовать FlylinkDC++ в качестве клиента, вовсе не знакомого с IPv6. Следует также отметить, что поддержка NATT для него на момент написания статьи не была реализована нигде.

Начало

Первым делом мы рассмотрим заведомо невозможные соединения между пользователями разных версий протокола IP. Для теста будет использоваться IPv6 ready хаб с ресурсными A- и AAAA-записями для доменного имени, выступающего в качестве его адреса.

Обратите внимание, здесь при (фактической) попытке обращения к пользователю с IP-адресом шестой версии выводится ошибка.

Hub:[Outgoing][IPv4:412] D<b>RCM</b> AACX AACU ADCS/0.10 337151563Hub:[Incoming][IPv4:412] D<b>CTM</b> AACU AACX ADCS/0.10 1988 337151563Hub:[Outgoing][IPv4:412] DSTA AACX AACU 240 <b>IP</b>\s<b>unknown</b>

Что в переводе на человеческий звучит как:

P4: Можно я к тебе прицеплюсь?
A6: Цепляйся!
P4: Жизнь боль 0_0

Краткий словарик, если что, здесь.

А если наоборот, и соединение иницирует A4, то ошибка не выводится, и соединение просто зависает.

Hub:[Outgoing][IPv4:412] D<b>CTM</b> AACX AACU ADCS/0.10 1993 3871342713

Быть, а не казаться

Что важно, так это отображаемый на хабе режим соединения.

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

FlylinkDC++ vs. IPv6

На деле же ситуация проще и сложнее одновременно.

AirDC++ vs. IPv6

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

Сложнее, потому что если на хабе присутствуют пользователи с поддержкой IPv6, но подсоединены они строго через IPv4-адрес, то

то с ними можно соединиться (наобум) вообще не имея IPv4.

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

Туды его в качель

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

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

Ба! Активный клиент отправляет пассивную команду?.. Логично было бы ожидать зависшего соединения, но нет, оно получается на условиях A4.

Почему так? Обращаемся к разработчику и получаем ответ:

CTM isn't good if the other user doesn't support IPv6

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

Active mode = TCPx + IPx

Попытки же соединения между клиентами с общими в части IPv6 наборами поддержки протокола IP выглядят следующим образом. Напомню, добиться PA для DC++ мне не удалось.

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

Что дальше?

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

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

Второй вот это расширение, которое только-только подходит к стадии тестирования.

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

Кто имеет, тому дано будет, а кто не имеет, у того отнимется и то, что он думает иметь. Лк. 8:18

Подробнее..

Категории: C++ , Open source , Децентрализованные сети , P2p , Ipv6 , Direct connect , Dc++ , Nmdc , Advanced direct connect , Airdc++

Перевод Децентрализованный Веб. Результаты опроса 600 разработчиков

26.08.2020 12:14:14 |

Автор: admin

Примечание. Оригинальный репорт опубликован на 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 явно находится на самых ранних стадиях, это не мешает ему соответствовать, и даже идеально вписываться в картину меняющихся предпочтений современных пользователей Веба.

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

Подробнее..

Категории: Open source , Статистика в it , Децентрализация , Криптовалюты , Децентрализованные сети , P2p , Блокчейн , Blockchain , Peer-to-peer , Ipfs

Азбука libp2p от Textile (или за что мы её любим)

05.04.2021 14:09:20 |

Автор: admin

Перевод статьи начального уровня в блоге проекта Textile от 19 ноября 2019 г.

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

Стремительно нарастающая сложность

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

У них ненадежное оборудование и сеть.
У них неопределённые технические параметры, такие, как вычислительная мощность и доступный объём долговременной памяти.
Брандмауэры могут блокировать их либо они могут находиться в сетях с NAT.
Они могут использовать старые версии приложений.

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

Libp2p приходит на помощь!

Libp2p - библиотека, появившаяся в результате работы Protocol Labs над IPFS. Если вы хоть немного следите за нашим блогом, то знаете, что мы их большие поклонники! Когда вы берётесь за написание p2p-приложения производственного уровня с нуля, то понимаете, что создаёте не только приложение, но и его инфраструктуру - и до вас очень быстро доходит, что требуется дополнительно изобрести ещё кучу колёс. Не весело, однако. С другой стороны, libp2p позволяет вам встать на плечи неких не хилых гигантов, дабы уменьшить сложность инфраструктуры - и чтобы вы могли сосредоточиться на бизнес-логике. А вот это уже веселее! Конечно, libp2p - не панацея в борьбе со всеми нашими p2p-чудищами, но она определённо облегчает бремя реализации инфраструктуры взаимодействия.

Основные концепции Libp2p

Сердцевиной libp2p является объект Хост (Host), который представляет наш локальный узел в сети p2p. Общее описание его компонентов:

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

Следующая базовая абстракция в libp2p - это Потоки. Поток (Stream) - это канал прямой связи с другим узлом. Важно понимать разницу между Stream и "грубым", "сырым" ("raw") сетевым протоколом, таким как TCP или UDP - ибо здесь открывается вся мощь libp2p: сами по себе сетевые протоколы - лишь средства отправки байтов по сети. Если вам нужна высокая надежность доставки пакетов, вы можете использовать TCP, в других случаях UDP может оказаться предпочтительнее. Короче, сами сетевые протоколы не заботятся о том, какие данные передают; для них это просто байты.

Stream же - это поточный канал связи между двумя одноранговыми узлами, имеющий определенную семантику. Тут уже не просто байты, но байты, соответствующие протоколу (более высокого уровня), определённому разработчиком. Протокол этот помечается идентификатором, например /sumtwointegers/v1.0.0. А сам Stream - диалог в рамках данного протокола. К примеру, одна сторона отправляет два целых числа, а другая отвечает их суммой. Вот что мы подразумеваем под потоком байтов с семантикой.

Потоки работают поверх сетевых протоколов, таких как TCP или UDP - по сути, идея состоит в том, чтобы отделить p2p-коммуникацию от сетевых протоколов (более низкого уровня). Нам нужно думать лишь о прикладном использовании поточного канала - для отправки значимой информации, а гибкость работы на любом сетевом протоколе, доступном между узлами, уже заложена в нём (в Stream). Это действительно здорово и мощно. И это также означает, что мы можем оптимизировать функционал раздельно на каждом уровне стека. Нужна лучшая реализация сетевого протокола? Отлично, оставьте это libp2p. Более выразительный семантически дизайн протокола p2p? Круто, это тоже!

Более того, отделение семантики p2p от базовых сетевых протоколов позволяет libp2p пойти дальше и мультиплексировать Потоки в одном и том же сетевом протоколе. Мы можем использовать одно и то же TCP-соединение для многих Потоков. Мы можем запустить протокол умножения двух целых чисел в том же соединении, в котором работали наши протоколы суммы двух целых чисел. Но Streams не обязаны справляться с этим самостоятельно. В действительности Libp2p полагается на мультиплексоры ("Muxers") для исполнения сей магии. Задача мультиплексора - разделить данные (последовательности байтов) на соответствующие потоки внутри одного потока сетевого протокола более низкого уровня. Вот краткая диаграмма, которая немного поясняет сказанное.

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

Возвращаясь на шаг назад

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

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

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

Зачем так стремиться к множественному использованию одного соединения? Может статься, что наши p2p-приложения должны будут работать в очень ограниченных сетевых средах, где существуют брандмауэры, NAT и ограничения на количество подключений. Поэтому, после того, как мы установим соединение, мы должны выжать из него максимальную пользу! При переходе на образ мышления p2p, вы можете встретить много неизвестного, поэтому использование libp2p поможет вам сосредоточиться на хорошем дизайне, даже если вы не являетесь экспертом.

Но это ещё не всё!

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

По этой причине, когда два приложения libp2p впервые общаются друг с другом, большая часть их работы заключается в определении того, какой совместимостью они обладают, дабы достичь успеха в коммуникации. Надо выяснить, каким сетевым транспортом оба собеседника пользуются (TCP, UDP, QUIC, Websockets), какие версии протокола мы можем обрабатывать (/myprotocol/v1.0.0, /myprotocol/v1.1.0), какие реализации мультиплексора можем использовать, надо согласовать параметры безопасности, и т. д. И если этого было недостаточно, libp2p имеет ещё целый ряд встроенных протоколов для решения самых разных повседневных задач p2p-приложений, таких как:

Обход NAT: это больное место у p2p-приложений
Обнаружение узлов в сети: действительно, как вы обнаруживаете новые узлы вне централизованной модели?
Pubsub: наличие механизма публикации-подписки для отправки сообщений в нашем приложении без необходимости знать все существующие узлы и без зафлуживания сети
И многое, многое другое!

Небольшой бонус на заметку: Libp2p очень быстро растёт, поэтому вы можете ожидать появления новых мощных инструментов, которые можно будет использовать с небольшой добавкой собственного кода. Помните, что приложения p2p предполагают разнообразие, поэтому libp2p будет иметь в разных языковых реализациях свои особенности. Скажем, некоторые реализации мультиплексора могут быть недоступны в JS, но вполне себе - в Go или Rust.

Подведём итоги

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

Ну, пока что всё. Следите за обновлениями в нашем следующем эпизоде, где мы переведем некоторые из этих концепций в код на практическом примере. Кроме того, если вам интересны такие вещи или вы хотите интегрировать p2p-коммуникацию в свое приложение или проект, свяжитесь с нами, и давайте поэкспериментируем вместе! Вы также можете попробовать одну из облегченных библиотек, если вам нужен простой способ использования однорангового узла libp2p в браузере, iOS, Android и/или на рабочем столе. Наконец, если вам нравятся такого типа обзорные статьи, сообщите нам об этом или запросите дополнительные темы ... а тем временем, удачного кодирования!

Автор оригинального текста: Ignacio Hagopian

Перевод: Алексей Силин (StarVer)

Подробнее..

Категории: Open source , Распределенные системы , Децентрализованные сети , P2p , Ipfs , Libp2p

Перевод Азбука libp2p от Textile, часть 2

25.04.2021 14:23:00 |

Автор: admin

Переводстатьиначального уровня в блоге проектаTextileот 12 декабря 2019 г.

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

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

Приложение

Сразу оговоримся, наша программа нынче будет написана на языкеGo, с использованием библиотекиgo-libp2p. Если вы ещё не знакомы с этим языком, настоятельно рекомендуем ознакомиться. Он действительно хорош для приложений, имеющих дело с параллелизмом и сетевыми взаимодействиями (такими, как например, обработка множества p2p-соединений). Большинство библиотек IPFS/libp2p имеют свои базовые реализации, написанные на Go. Прекрасным введением в Go являетсятур на golang.org.

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

По умолчанию приложение цепляется к свободному TCP-порту.

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

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

На каждом вновь обнаруженном узле (скажем, узле A) наше приложение будет запускать собственный протокол sayMyAddr (мы его реализуем), который будет узнавать для нас предпочтительный адрес для игры в пинг-понг этого узла.

Мы подключаемся к узлу А, используя предпочитаемый им адрес - и запускаем танец Пинг-Понг. Другими словами, мы запустим ещё один наш самопальный протокол, посредством которого отправим сообщение Ping, а узел A ответит нам сообщением Pong. Круть!

Даже для такой простой системы (если мы хотим сделать p2p-приложение) потребуется принять ряд отдельных решений. Для начала, надо будет ответить на следующие вопросы:

Какой транспортный протокол (TCP, QUIC и т.п.) использовать?

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

Как наши собственные протоколы (Streams) будут работать? - то есть, как мы будем поддерживать двунаправленную связь с другими узлами?

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

Ныряем в код!

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

КОД:ВДЕЛИТЬ ВСЁ

git clone git@github.com:textileio/go-libp2p-primer-article.gitcd go-libp2p-primer-articlecode . // Нам нравится VSCode, ну а вы - сами с усами ;)

Далее: начнём сmain.go, где вы можете лицезреть, как создаётся и запускается хост libp2p. Дополнительно здесь мы указываем, какие сетевые транспортные протоколы будет поддерживать наш хост. Заметьте, что если для флага -quic установлено значение true, мы добавляем новую привязку для транспорта QUIC. Добавление в работу транспортных протоколов сводится к простому добавлению параметров в конструктор хоста! Также обратите внимание, что мы регистрируем здесь все обработчики наших собственных протоколов: RegisterSayPreferAddr и RegisterPingPong. Наконец, мы регистрируем встроенную службуmDNS.

Теперь заглянем вdiscovery.go, где у нас находится настройка mDNS. Здесь, по сути, надо определить частоту широковещательной рассылки mDNS и строковый идентификатор, который в нашем случае не требуется и потому пустой. Последний шаг здесь - регистрация обработки уведомленияdiscovery.Notifee, которая будет вызываться всякий раз, когда mDNS запускает обнаружение пиров, предоставляя нам их информацию. Логика у нас тут будеттакая:

Если мы уже знаем об этом узле - ничего не делаем; мы уже играли в пинг-понг. Иначе же
открываем поток нашего протокола SayPreferAddr, чтобы узнать у обнаруженного узла, по какому адресу (addr) он предпочитает играть в пинг-понг. Ну, и наконец
добавляем адрес узла в нашу адресную книгу, закрываем текущее соединение с ним и запускаем наш второй протокол PingPong, который повторно подключится к узлу, используя его предпочитаемый адрес (который мы добавили на предыдущем шаге).

Наконец, вpingpong.goмы можем увидеть упомянутый ранее метод RegisterPingPong, вызываемый из main.go, и еще два метода:

Handler: этот метод будет вызываться, когда сторонний узел зовёт нас играть в PingPong. Вы можете думать о Handler как об обработчике HTTP REST. В этом обработчике мы получаемStream, реализующий io.ReadWriteCloser, из которого мы можем запускать наш протокол для отправки и получения информации, чтобы делать что-то полезное.

playPingPong: Это другая сторона медали; клиент запускает новыйStreamдля внешнего узла для запуска протокола PingPong.

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

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

Чтобы протестировать нашу демо-программу, можно открыть два терминала и просто запустить: go run * .go , go run * .go -quic или их комбинации. Ниже вы можете видеть иллюстрацию с двумя терминалами, работающими с флагом -quic:

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

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

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

Что дальше?

Важным качеством приложения является его пригодность для дальнейшего развития. В p2p-проектах в основе прикладной логики находится сетевое взаимодействие. Если однажды в будущем мы захотим модернизировать наш протокол PingPong добавлением новых функций или возможностей, мы должны учитывать, что некоторые узлы будут по-прежнему работать со старой версией протокола! Это звучит как ночной кошмар, однако отставить бояться, мы с этим справились. И тут надо приметить следующий фрагмент кода из pingpong.go:

КОД:ВДЕЛИТЬ ВСЁ

const (    protoPingPong = "/pingpong/1.0.0")...func RegisterPingPong(h host.Host) {    pp := &pingPong{host: h}    // Здесь мы регистрируем наш _pingpong_ протокол.    // В будущем, если решите достраивать/исправлять ваш протокол,    // вы можете либо делать текущую версию обратно совместимой,    // либо зарегистрировать новый обработчик,     // с указанием новой главной версии протокола.    // Если хотите, можете также использовать логику semver,    // см. здесь: http://bit.ly/2YaJsJr    h.SetStreamHandler(protoPingPong, pp.Handler)}

Комментарии прекрасно всё объясняют.

Другой важный вопрос связан с механизмом обнаружения других узлов, в нашем случае это mDNS. Этот протокол делает свою работу в локальных сетях, но как насчет обнаружения пиров в Интернете? Позднее вы можете добавить в своё приложениеKademlia DHTили использовать один из механизмовpubsub- также, чтобы находить новые узлы.

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

Заключительные слова

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

Важно: имейте также в виду, если вы используете libp2p с включенными Go-модулями, вам нужно явно указывать тег версии в go get, поскольку иначе вы можете получить не то, что ожидали по умолчанию. Больше информации об этом вы можете найти в секцииUsagereadme-файла go-libp2p.

Надеемся, что вам понравился наш игрушечный проект, и надеемся, что он вселит в вас уверенность в том, что писать p2p-приложения не так сложно, как могло бы показаться! На самом-то деле, это может быть довольно кайфово и вдохновляюще! Если вам по нраву сей материал, присоединяйтесь к нам нанашем канале в Slack, чтобы пообщаться на тему p2p-протоколов, или подписывайтесь на нас вTwitter, чтобы узнавать о самых свежих и славных разработкахTextile. Ну, или хотя бы гляньте некоторыедругие наши статьи и демонстрации, чтобы полнее прочувствовать, что возможно в этом захватывающем мире приложений P2P!

Автор оригинального текста:Ignacio Hagopian

Перевод: Алексей Силин (StarVer)

Подробнее..

Категории: Open source , Распределенные системы , Go , Децентрализованные сети , P2p , Ipfs , Libp2p

NewNode децентрализованная CDN от разработчика FireChat

03.07.2020 14:20:11 |

Автор: admin

На днях я наткнулся на упоминание некоего NewNode:

NewNode SDK для мобильной разработки, который делает любое приложение неубиваемым для любой цензуры и DDoS, и драматически снижает нагрузку на сервере. P2P сеть. Может работать в теории без интернета.

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

dCDN

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

Протокол

Далее выясняется, что NewNode это peer-to-peer протокол, на котором уже строится dCDN. Он обещает высокую скорость, что обычно вызывает проблемы у децентрализованных сетей. Формально протокол нигде не описан, но из пдфки можно понять, что работает он использует:

LEDBAT
Bittorrent DHT
Соединения device-to-device из FireChat

Отдельным пунктом указано свойство сетей на NewNode разворачиваться и чиниться автоматически (последнее, скорее всего, подразумевает нестабильность mesh-сети из мобильных устройств). Также, поскольку разработчики надеются внедрить поддержку протокола во все возможные приложения, трафик, генерируемый NewNode'ом не будет демаскировать пользователя. Заявлена защита от DDoS и отдельно выделена фраза:

Take advantage of BitTorrents 250 Million user base

Вообще непонятно, что этим хотели сказать и как обращение к Bittorrent DHT в протоколе приравняли к юзербазе Bittorrent'а.

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

Репозиторий

В нём лежат SDK под Android, iOS и macOS/Linux. За три с половиной года существования проекта в нём отметились 4 контрибьютора, но по сути весь код написан одним разработчиком Greg Hazel. Тут я, конечно, приуныл вся эта амбициозная мишура оказалась по сути пет-проектом одного разработчика. Но кое-что обнадёживает меня.

Отдельные связи стали выстраиваться ещё на сайте, а порывшись в гитхабе, я вспомнил окончательно. CEO Clostra, разрабатывающей проект, и один из контрибьюторов Станислав Шалунов, один из разработчиков FireChat и автор Low Extra Delay Background Transport (LEDBAT), по которому ходит Bittorrent, Apple и наверняка что-то ещё. Теперь он ещё и инвестор, и очень похоже на то, что он планирует всерьёз развивать свой протокол и сделать его общепринятым (или хотя бы общеизвестным, как это произошло с LEDBAT).

Что ещё смущает

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

О нём никто нигде не пишет. Ни на HN, ни в бложиках или твиттерах. Полный информационный вакуум. Я даже не знаю откуда про него узнал тот человек, который написал характеристику из начала поста.
Если идея действительно хороша, её, пользуясь личным брендом и авторитетом Шалунова, можно было бы давно раскрутить и обзвестись поддержкой крупных игроков (или крупного комьюнити). Ничего этого нет.
Clostra очень мутная студия. Прямо очень. У них крайне стрёмного вида сайт, на котором они представляют свой единственный продукт Keymaker (ну и NewNode), всё без примеров, отзывов, скриншотов и прочей туфты, обязательной для лендинга. Там просто воодушевляющий текст в размытых формулировках и иконки с ближайшего стока. Нельзя изучить команду, вакансии или вообще что-то узнать про эту контору. У них есть твиттер, который судя по всему ведёт бот, и заброшенный в момент создания фейсбук. Но при всей этой внешней стрёмности они в нескольких местах подчёркивают факт своего сотрудничества с госслужбами, особенно с Department of Defence. Есть три отзыва про устройство к ним на работу, где два резко негативные (например, Don't waste your time with Clostra. Something stinks about this scam, а один очень положительный. В общем, на первый взгляд от скама такой проект не отличить.

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

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

Эпичные серверы это надёжные VDS на базе KVM с новейшими процессорами AMD EPYC. Как и для других типов серверов, огромный выбор операционных систем для автоматической установки, есть возможность установить любую ОС с собственного ISO, удобная панель управления собственной разработки и посуточная оплата.

Подробнее..

Категории: Разработка мобильных приложений , Сетевые технологии , Блог компании vdsina.ru — хостинг серверов , Децентрализованные сети , P2p , Newnode , Dcdn , Cdn

Смотрим любое кино мгновенно

06.03.2021 02:15:47 |

Автор: admin

Disclaimer: я не призываю незаконно скачивать контент, пиратство - наказуемо и является преступлением

После ареста серверов Moonwalk жить стало в разы труднее. Лично я уже совсем отвык от торрентов. Нужно что-то качать, ждать, чем-то открывать, куда-то кликать, иногда еще и место на диске кончается. Как можно ждать час пока скачается фильм? За час можно жизнь прожить. Пришлось искать решение, которое позволит смотреть кино также просто, как и раньше. Норматив: от идеи посмотреть что-нибудь и до начала непосредственного просмотра - не более минуты.

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

И вот так он работает:

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

Знакомьтесь, Jackett

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

Jackett можно скачать и запускать на компьютере, но это все усложняет. Лучше захостить его на бесплатном облаке от Oracle, и заходить по адресу. Вам понадобится машина в облаке, linux на ней и docker-compose.yml c приблизительно такими характеристиками:

version: '3.5'services:    jackett:        image: linuxserver/jackett        container_name: jackett        environment:            - PUID=1000            - PGID=1000            - TZ=Europe/Moscow        volumes:            - ./Jackett/config:/config            - ./Jackett/Downloads:/downloads        ports:            - 9117:9117        networks:            - proxy        restart: unless-stoppednetworks:    network:        driver: bridge    proxy:        external:            name: proxy

docker-compose up -d и заходим. Далее нам понадобится добавить все наши трекеры, вбив логины и пароли.

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

Здесь нам приходят на помощь Stremio и Soda player.

Сами по себе это просто потоковые смотрелки торрент файлов. Хорошо, но недостаточно. В комбиации с Jackett они превращаются во что-то совсем невероятное. Soda отлично подойдет для мака, а Stremio, кажется, умеет передавать видео на телевизоры и прочие кофемолки. Про Soda есть статья на reddit, дескать он ворует печеньки. Лично мне плевать, но вас я обязан предупредить.

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

Подробнее..

Категории: Управление медиа , Кино , Расширения для браузеров , Децентрализованные сети , P2p , Видео , Пиратство , Микроформаты , Jackett , Stremio , Soda player , Moonwalk , Торрент

	Русский
	English