Плавный переход к распределенному интернету?

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

Для начала два «предупреждения»:
1. Предлагаемая идея — это не «еще одна соц. сеть по типу Биткойна», поэтому прошу не делать поспешных выводов.
2. Хотя я никогда не слышал о подобных проектах, но это не значит что их нет. Если вы знаете о чем-то подобном, или знаете почему все гарантированно не будет работать — прошу напишите, я удалю статью и мы сбережом время других читателей.

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

Можно ли совместить преимущества традиционных соц. сетей с распределенными? Я считаю что можно.

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

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

Таким образом, те люди которым не нравятся блокировки, вместо того чтобы искать другие площадки (которых становится все меньше), могут в два клика установить наше расширение и увидеть «мир без диктата и запретов…». Но это только первый шаг. Если вам интересны еще 3 — добро пожаловать под кат.

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

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

Как в этом случае будет работать наше расширение? Чтобы послать сообщение конкретному пользователю — нужно как-то связать его аккаунт внутри распределенной сети, с его аккаунтом в обычной соц. сети.
Можно предложить такой вариант. Пользователь регистрируется в нашем расширении, указывает свой логин/пароль для соц. сети (напр. «вконтакте»), после чего, для подтверждения факта владения этим аккаунтом, расширение от его имени публикует на его странице в соц. сети случайный ключ, и по распределенной сети отправляет запрос на проверку. Другие клиенты автоматически проверяют наличие кода на странице, после чего регистрация подтверждается и код удаляется со страницы. Вся операция может занимать доли секунды.
Таким образом в распределенной базе пользователей сохраняется информация о том что такому-то аккаунту в распределенной сети соответствует такой-то аккаунт в соц. сети. При отправке сообщений на этот аккаунт — они отправляются напрямую владельцу по распределенной сети.

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

Шаг 3.
Итак, теперь мы можем прозрачно хранить музыку и фильмы внутри распределенной сети, а также обмениваться информацией внутри нее и между ней и соц. сетью. Но можно пойти дальше. Почти весь контент соц. сети можно постепенно перенести в распределенную сеть. Причем каждый пользователь будет хранить свой контент, плюс часть общего.
Это позволит со временем реализовать три цели.
1. Добавить сайту автономности. к примеру посмотреть свои альбомы с фотографиями или послушать музыку — пользователь сможет даже без интернет доступа. ведь они хранятся локально.
2. Обеспечить частичную защиту от блокировок. Ведь к этому моменту у нас по сути есть клиент, есть контент и есть возможности обмена данными. Даже если сайт «родительской» соц. сети заблокируют — она останется внутри распределенной сети и может сохранить большую часть функционала. Да, какие-то вещи реализовать не удастся, например приложения и игры. Но основной контент — останется.
3. Обеспечить частичную анонимность. Если пользователь выставит в настройках «получать только контент из распределенной сети» — то соц. сеть не получит информации о том какой контент и когда пользователь получил.

Шаг 4.
На предыдущем шаге мы добились интеграции принципов распределенной сети в обычную соц. сеть. Можно сказать добились цели, но можно пойти еще дальше.
Почему мы работаем только с одной соц. сетью? Почему бы нашему приложению не работать с другими?

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

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

Все это приводит нас к вопросу, где же хранить все эти данные? А как-же «облака» — которые позволяют «разгрузить» устройства, сделать жизнь проще и легче?
А почему нет? Кто сказал что данные пользователя должна хранить та же компания, что предоставляет ему сервис? Почему, например не хранить данные vk.com — на google-drive? А данные gmail.com — на серверах yandex-диск? Единожды настроив такую трансляцию с шифровкой данных «на лету» — мы получим беспрецедентный контроль над своими данными. Именно то чего нас всех так хотят лишить. Интернет может стать гораздо свободнее и децентрализованнее чем когда-либо. При этом не потеряв удобства и простоты.