Это — текстовая расшифровка небольшого доклада с Форума молодых учёных, про Web 4.0: проблематика, решения и даже прототип, с которым можно невозбранно поиграться.

❓ Аутентификация

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

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

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

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

Что нам поможет от этого всего обезопаситься?

✅ Цифровая подпись

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

❓ Приватность

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

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

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

Что нам поможет от этого обезопаситься?

✅ End-to-End шифрование

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

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

❓ Надёжность

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

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

Что нам поможет от этого обезопаситься?

✅ Децентрализация

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

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

❓ Отзывчивость

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

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

Что нам может с этим помочь?

✅ Local-First

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

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

❓ Конвергенция

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

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

Что может помочь нам достигнуть того же эффекта с нашими данными?

✅ CvRDT

Конвергентные реплицируемые структуры хранят данные не в виде слепков, а мелокогранулярно. У каждой такой гранулы помимо самих данных есть ещё и мета-данные: кто когда куда их вставил и доказательство, что этому всему можно верить.

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

Актуальность

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

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

Как бы нам так извернуться, чтобы данные в принципе не устаревали?

✅ Дельта-синхронизация

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

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

WEB ?.?

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

❌ Web 1.0 — HTTP

❌ Web 2.0 — AJAX

⭕ Web 3.0 — Block Chain

✅ Web 4.0 — Local First

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

WEB 4.0

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

CRUS-DB

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

? Работает даже в браузере

? Любой может поднять сервер

? Слияние разных типов данных

Попробовать прямо сейчас, без CMC

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

page.hyoo.ru#=4soaj4_2jvenc

То ли ещё будет

Спасибо за внимание. Подробности по базе данных и по другим моим проектам вы найдёте по следующим ссылкам.

http://crus.hyoo.ru/

http://jin.hyoo.ru/

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

mol_news

h_y_o_o

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

Актуальный оригинал на $hyoo_page.