Эта публикация является развитием идей, сформулированных в предыдущей статье - "Идентификация пользователей в Web 3.0". После предыдущей публикации я понял, что в массах нет однозначного определения, что же именно называть Web 3.0 - виртуальную реальность, интернет вещей или децентрализацию на базе блокчейна. С моей точки зрения, Web 3.0 - это архитектура веб-приложений, обусловленная спросом пользователей на конфиденциальность их собственных данных.
Развитие идей Web 2.0 привело к тому, что пользователи сами стали товаром. Вернее, товаром стала информация об их связях и предпочтениях, которую собирают и монетизируют корпорации типа Google и Facebook. В ответ на это у многих пользователей появилось желание не делиться своими персональными данными с корпорациями, а хранить свои данные в недоступном для корпораций месте. Размышлениям о том, к каким последствиям может привести персонализация хранимых данных, и посвящена данная публикация. Сразу предупреждаю - это просто моё растекание мыслью по древу, а не "сборник рецептов" или разъяснения "как всё устроено". Не очаровывайтесь, чтобы не разочароваться :)
Кэширование
Для начала о забавном. Централизация веб-приложений привела к проблемам с производительностью и к необходимости использования всяких разных кэшей - начиная от кэша в браузере и заканчивая Full Page HTML кэш на сервере в том же Redis'е. Сюда же можно записать кластеры баз данных, да и вообще всё, где присутствует слово "реплика" или "репликация". То есть, с точки зрения стороннего наблюдателя в веб-приложении с кэшированием есть как бы два типа данных:
"актуальные": набор данных на сервере (или в мастер-базе);
"персональные": данные, которые видит у себя в браузере конкретный пользователь;
Персональные данные очень сильно коррелируют с актуальными данными, но, как правило, никогда полностью им не соответствуют. И чем больше и активнее приложение, тем более верно это утверждение.
Таким образом, уже сейчас, даже в централизованных приложениях Web 2.0, каждый пользователь видит свою "картину мира" - актуальная информация доходит до каждого пользователя, прорываясь через кэши всех уровней, с некоторым запозданием. Лишь когда новые данные перестают поступать в веб-приложение, пользователи имеют шанс получить одинаковые "картины мира", совпадающие с актуальным состоянием центра.
Адресная книга, чаты, статьи
Но насколько должны совпадать "картины мира" разных пользователей и должны ли? Хорошим примером персональной базы данных является адресная книга в смартфонах. У каждого пользователя свой набор контактов. Один и тот же номер телефона у одного пользователя может быть записан как "Мама", у второго - "Жена", у третьего - "Дочь". Контакты из адресной книги вообще не должны реплицироваться с другими пользователями. Это данные индивидуального пользования.
С чатами несколько другая ситуация - сообщения одного пользователя другому (или другим - в группе или канале) должны быть одинаковыми у обоих пользователей (группы, канала). При этом остальные пользователи, не относящиеся к этому сообщению, могут вообще ничего не знать про существование сообщения. То же самое (ничего не знать про) относится и к держателю чата (серверу, бэкенду), который обеспечивает доставку сообщения от отправителя к получателю (получателям). Технически, задача держателя чата - обеспечить доставку сообщения, а что там внутри - то не его дело.
Если же мы говорим за информационные порталы, типа того же Хабра, то тут есть полностью публичная информация - статьи. Она должна быть доступна любому желающему. Как и все изменения в ней.
Таким образом, информацию, доступную в веб-приложении, можно разделить на три группы:
индивидуального пользования
группового пользования
общего пользования
Информация группового пользования
С информацией индивидуального и общего пользования всё более-менее понятно. Первую вообще нет нужды ни с кем реплицировать, вторая - это наш привычный веб (1.0 или 2.0 - не важно). А вот с информацией группового пользования интереснее. С одной стороны она должна обрабатываться как информация общего пользования (централизовано - это тупо дешевле по ресурсам, особенно в больших по количеству пользователей группах). С другой стороны в малых группах "тупо дешевле" может быть использование прямого соединения пользователей для репликации данных (WebRTC). Особенно с точки зрения конфиденциальности данных.
Для информации группового пользования, особенно в её децентрализованном исполнении, становится важным актуализация информации - какая из копий информации является актуальной. Если для чатов это прозрачно - копия отправителя, то в других случаях нахождение актуальной копии может быть проблематичным. Например, при одновременном редактировании одного и того же Google-документа.
Тем не менее, если все имеющиеся в веб-приложении копии групповой информации идентичны, то любая из них может считаться актуальной. Логично в таком случае, что для каждого конкретного пользователя будет считаться актуальной та копия, которая находится в его браузере.
А судьи кто?
В чём основное преимущества блокчейна как технологии? Скорее всего, большинство ответит - децентрализация. Информацией владеют одновременно все и никто. Любое изменение в данных записывается сразу (или постепенно - по мере возможности) у всех держателей блокчейна. В случае расхождения данных все держатели блокчейна должны прийти к определённому консенсусу (выбрать актуальную версию) и использовать у себя актуальный экземпляр. Этакая диктатура большинства (это, разумеется, если в блокчейне все держатели равны).
Но в такой ситуации, если мы захотим выпустить "всенародный блокчейн" для всех 8 миллиардов жителей планеты, то нам нужно будет обеспечить консенсус (диктатуру большинства) для порядка 4 с небольшим миллиардов. Остальные им подчинятся по-любому - как меньшинство. Вы только представьте себе, что каждое изменение в этом блокчейне порождает как минимум 8 млрд. транзакций между держателями! А если каждый житель планеты получает ежемесячно зарплату на этот "всенародный блокчейн"?! А если еженедельно?! А если ещё тратить средства на покупки и расчёты друг с другом?!
В общем, полная децентрализация при обмене данными - это полная фигня. Долго и дорого. Поэтому в "децентрализованных" сетях не все узлы "одинаково равны", а есть "более ровные" - авторитеты. Не важно, по каким критериям эти авторитеты выбираются - старожил, самый активный, самый проворный, самый крупный и т.п., а важно, что эти авторитеты являются "центрами силы", которым достаточно найти консенсус друг с другом, а остальные уже возьмут актуальную информацию у них.
Обычные пользователи подобной двухуровневой "децентрализованной" сети вполне могут без проблем взаимодействовать друг с другом в режиме peer-to-peer, если их локальные копии данных (кэш) совпадает друг с другом. Они даже могут произвести какие-то действия со своими локальными копиями в интересах друг друга (например, передать "коин" от одного другому). Самое главное, чтобы потом "децентрализованная" сеть приняла эти изменения - например, через какой-либо из "центров силы".
Самое забавное во всём этом то, что примерно так и работает ныне обычная мировая финансовая система. "Центрами силы" в ней являются банки. "Пользователь" может открыть счёт в каком-либо банке и переводить средства другому "пользователю" - в своём банке или между банками. Банки не парятся глобальностью, а окучивают свою "делянку". Если пользователь не доверяет какому-то банку, он может уйти в другой или открыть счета сразу в нескольких банках.
Да и с точки зрения отдельного пользователя его не интересует состояние финансов сразу всех 8 млрд. жителей планеты, пользователя интересуют в первую очередь собственные финансы, а во вторую очередь - возможность отправить средства любому из 8 млрд. человек или получить их от него. И имеющаяся финансовая система это обеспечивает.
Другими словами, любому пользователю не нужна вся информация из приложения. Ему нужна лишь та, которая относится непосредственно к нему. Если на каком-то участке эта информация пересекается с интересами другого пользователя, то пока у другого пользователя точно такая же информация - проблем нет, а если вдруг возникли расхождения, то нужен "авторитет" (решала), которому доверяют обе стороны. Обычная демократия, когда голосование проводится по любому изменению - слишком дорого. Безумно дорого. Институт судей и шерифов, банков, школ, научных центров, парламентов, муниципалитетов - всё это попытки преодоления дороговизны примитивной демократии.
Эффект Стрейси Барбаранд
Эффект Стрейси Барбаранд - это эффект, обратный эффекту Барбары Стрейзанд. Если эффект Барбары Стрейзанд заключается в том, что социально значимая информация "прорастает" в интернете вопреки всем попыткам изъять её, то эффект Стерйси Барбаранд заключается в том, что непопулярная информация рано или поздно "вымывается" из интернета. Многие замечали, наверное, как иногда бывает тяжело найти в интернете некогда популярную информацию. Десять лет назад некий рекламный ролик вываливался в каждом втором посте, а сегодня нужно перелопатить весь Google, чтобы найти одну-две ссылки на него.
Как ни странно, современные методы хранения информации очень сильно уступают по долговечности тем же самым шумерским глиняным табличкам. Интернет предоставляет доступ к огромному массиву данных, которые по большей части не представляют долговременного интереса для конкретного человека. Как и раньше, человек должен сам собирать свою "персональную библиотеку" из тех данных, которые важны конкретно для него (фотографии, дневники, мемасики и т.п.). Думаю, что у многих из нас уже накопилась подобная библиотека, которая переносится со старого ноутбука на новый ноутбук или периодически копируется на внешние накопители (DVD, SSD, flash). С появлением Dropbox и Google Drive для этих целей стали также использовать и облачные хранилища.
В общем, общедоступная информация в интернете не накапливается, а ротируется - актуальная информация вытесняет устаревшую. Нельзя полагаться на то, что если сегодня какая-то статья, фотография или видео есть на множестве сайтов, то завтра её также можно будет без проблем найти в интернете. Каждый человек сам собирает свою "библиотеку данных". Или не собирает.
Персональные хранилища
Когда-то давно я сталкивался в Windows с таким понятием, как Roaming Profile. Это когда твои персональные данные хранятся на сервере и реплицируются на ту рабочую станцию в windows-домене, через которую ты подключился к серверу. Я уверен, что нечто подобное будет применяться и в Web 3.0. У пользователя будет свой собственный профайл - хранилище данных (на диске, флешке или в облаке), который будет использоваться для подключения к Web3.0-приложению. Точка подключения неважна - любой сервер, который предоставляет услуги подключения к приложению, сможет идентифицировать пользователя на основании данных его профайла и выполнить его распоряжения - получить доступ к ограниченной информации ( группового пользования), переслать сообщения другим пользователям или забрать из временного хранилища сообщения, предназначенные ему самому.
Все персональные данные будут передаваться на то устройство (смартфон, ноутбук, планшет, десктоп), через которое происходит подключение к сети серверов веб-приложения, а уже устройство будет перенаправлять данные в профайл пользователя (на диске, флешке или в облаке). Думаю, что файлы - вполне удобный способ хранения данных, по крайней мере на начальном этапе. В дальнейшем подобный профайл должен будет развиться во что-то, больше похожее на базу объектов. Т.к. для пользователя есть прямой резон использовать одни и те же данные (например, фотографии или документы) в разных Web3.0-приложениях (чтобы не плодить сущности без необходимости).
В общем, на мой взгляд, в условиях запроса на конфиденциальность данных со стороны пользователей, возникает потребность в персональных хранилищах данных, подключаемых к различным веб-приложениям от разных производителей (почта, мессенджер, соц. сеть) и разделяемых между этими веб-приложениями. Ну и как следствие, на протоколы взаимодействия с подобными хранилищами.
Я смотрю с точки зрения веб-приложений. Они живут в браузерах, браузеры живут в мобильных. Хранилища браузера это аналог кэша. Мобильный может потеряться. Конечный пункт хранения - облака. У каждого человека должно быть своё облако с данными. Сейчас это на уровне файлов. Думаю, что файлы - вполне удобный способ хранения данных. Веб-приложения должны будут иметь возможность скидывать данные из хранилищ браузера в облако и наоборот - загружать из облака данные в веб-приложения.
Заключение
К чему я это всё? Да так, просто опубликовал свои мысли. Хабр замечательно подходит для этой цели. Как сообщество неравнодушных людей, которые не преминут воспользоваться возможностью улучшить мир, если вдруг в интернете кто-то окажется неправ.
