Децентрализованные социальные медиа

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

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

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

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

Не обязательно напоминать, но, основным принципом разработки децентрализованного протокола является, соответственно, децентрализация. Однако, на сегодня, тенденция к централизации ещё слишком мощна. Централизованные узлы имеют возможность для свободного роста, и несложно предсказать – где они появятся и каким образом будут развиваться.

Давайте вспомним о основных протоколах TCP/IP и HTTP, которые крайне широко используются в современной сети. Когда они только появились – казалось, что они полностью децентрализованы. Любой мог создать сайт, и любой мог получить к нему доступ. Единственное условие для входа – наличие интернет-соединения и IP-адреса. Что может быть более эгалитарным? Мы видели, что ранний веб процветал, чего и ожидали от подобной среды. Однако, никто не предвидел какую серьёзную роль сыграет сетевой эффект.

И не имеет никакого значения, что кто-либо тоже может создать сайт для конкуренции с Facebook, YouTube, Reddit или Twitter. Никто просто не станет его использовать. И пусть он имеет лучшую защиту конфиденциальности, более крутой функционал и не размещает рекламы – у него всё равно не будет одной важной вещи, которая даёт этим технологическим гигантам непреодолимое преимущество: большое количество других пользователей. Даже когда Google, уже имея массивную долю рынка, пытался конкурировать с Facebook, занимаясь продвижением Google+, в конечном итоге, после семи лет и миллиардов потраченных долларов, он не смог ничего сделать.

После появления TCP / IP и HTTP – децентрализация буквально споткнулась об URL. Тот, кто контролирует URL – контролирует всё, что стоит за ним. Как пример, это такие URL, как Facebook.com, Google.com, Amazon.com и т.д. За ними стоят сильнейшие и богатейшие корпорации планеты. Но, с DSP мы продвинемся дальше.

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

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

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

Кто контролирует контент?

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

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

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

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

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

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

Деньги имеют значение

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

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

Возможно, это самая сложная часть DSP для проектирования, но, при этом, самая важная. Так или иначе, пользователи должны быть в центре этого процесса создания и передачи ценности. Учитывая, что внимание пользователей является источником ценности для этой системы – проблема не должна быть непреодолимой.

Реструктуризация социальных сетей

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

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

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

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

Эта ориентированная на пользователя парадигма требует переосмысления того, как разрабатываются и создаются онлайн-сервисы. Современные платформы могут быть концептуализированы в трёх частях: контент, пользовательский интерфейс и то, что иногда называют «бизнес-логикой». Бизнес-логика – это все инструкции, которые платформа использует для сбора соответствующего контента и отправки его в пользовательский интерфейс для отображения. Именно здесь работают алгоритмы поиска, сортировки и управления контентом. Механизмы рекомендаций, агрегаторы и различные формы искусственного интеллекта – всё это бизнес-логика.

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

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

В рамках DSP, поскольку поставщики интерфейсов не имеют доступа к контенту, они не могут самостоятельно выполнять бизнес-логику. Это должно быть сделано на стороне пользователя тем, что называется «пользовательским клиентом».

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

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

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

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

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

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

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

Что такое социальная сеть?

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

Чем по сути является DSP? Если мы рассмотрим основные платформы социальных сетей, мы увидим Twitter с его акцентом на короткие публичные заявления, Facebook с его акцентом на обмен информацией с друзьями, Reddit с его нишевыми сообществами, Instagram с его фотографиями, YouTube с его видео и т.д.

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

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

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

Размеры, по которым эти платформы (и любая коммуникационная платформа) различаются – они зависят от типа контента, права доступа к контенту и общего контекста.

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

Тип контента

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

Такие вещи, как хранение, доступ, контекст и различные метаданные (это лишь некоторые) – вполне могут обрабатываться посредством DSP, независимо от типа контента. Instagram, YouTube и SoundCloud – это в основном один и тот же веб-сайт, и отличает их только тип контента, на котором они делают акцент.

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

Права доступа к контенту

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

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

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

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

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

Контекст

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

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

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

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

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

Так, например, если кто-о лайкнул ваш контент на сайте в стиле Twitter, а кто-то другой лайкнул его на сайте в стиле Facebook, то все, кто просматривает ваш контент, независимо от того, какой сайт они используют, увидят два лайка.

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

Правда, выше ничего не говорится об ограничении контента. Но, разве тот же Twitter не отличает тот факт, что его пользователи ограничены 280 символами? Это действительно так, но ограничение контента – это не то, что должно обрабатываться в DSP, поэтому это опять же может быть достигнуто с помощью обработки контекста.

Например, в случае сервиса в стиле Twitter контент, созданный с использованием его интерфейса (твиты), может быть помечен как таковой. Интерфейс не позволит пользователю генерировать что-либо длиннее 280 символов, поэтому весь контент, помеченный как твит из этого интерфейса, будет содержать не более 280 символов. Если бы пользователь самостоятельно генерировал твит длиной более 280 символов, сервис Twitter просто не показывал бы его другим пользователям.

Управление профилем

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

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

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

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

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

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

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

Чтобы децентрализовать это, пользовательские клиенты и поставщики интерфейсов могли бы вести список всех пар ключ/имя, с которыми они столкнулись. При регистрации нового пользователя клиент-пользователь может обратиться к сети и проверить, есть ли это имя в чьём-либо списке. Если нет, объявляется новая пара ключ/имя. Если пользователь столкнётся с тем, что выбранное имя уже кем-то используется и есть в чьём-то списке – интерфейс может устранить дубль посредством случайного параметра nonce (1, 2, 3 и т.д.) или какого-либо другого различия.

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

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

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

Управление репутацией

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

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

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

Эта идея называется Web of Trust (WOT), и это прекрасный простой способ минимизировать влияние «плохих участников» в децентрализованной системе. Это онлайн-версия того, что мы давно делаем в реальном мире.

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

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

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

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

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

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

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

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

Всё это раскрывает истинную красоту WoT: нет централизованной точки зрения. Если я отмечаю кого-то как тролля, то он является троллем только для меня. И это не истина в последней инстанции. Некоторые пользователи могут принять мое суждение и сопоставить его с обвиняемым троллем, другие могут проигнорировать его, а третьи могут найти его просто положительным и принять во внимание.

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

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

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

Создание и передача ценности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Открытым остается вопрос, какую платёжную систему использовать для всего этого. Я не думаю, что DSP должен отвечать на этот вопрос, а скорее должен позволить сторонним разработчикам создавать плагины. Чтобы начать работу, первоначальный плагин для какой-либо популярной платёжной системы, поддерживающей микроплатежи, может быть разработан вместе с DSP. Но, ещё лучше было бы развернуть децентрализованный протокол платежей (DPP).

Сервисные услуги

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

Хранение контента и доступ к нему

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

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

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

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

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

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

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

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

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

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

Пользовательский интерфейс

Ещё одна важная часть задачи реализации DSP – это, конечно, то, что испытывают пользователи при взаимодействии с сетью. Это то, о что представляет большинство из нас, когда мы думаем о социальных сетях: каналы контента, списки друзей, почтовые ящики, домашние страницы, логотипы, форумы, окна чатов и т.д. Здесь, как и ожидалось, платформы полностью монополизировали пользовательский интерфейс для тех данных, которыми они управляют. Например, есть только одно место, где можно просмотреть свой профиль на Facebook, и это сайт facebook.com.

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

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

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

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

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

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

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

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

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

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

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

Граничные случаи

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

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

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

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

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

Проблема контента

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

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

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

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

Однако не всё содержание является выражением свободы слова. Некоторый контент вреден, потому что он способствует или непосредственно приводит к причинению вреда невинным людям. Очевидный пример – педофилия.

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

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

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

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

Вывод

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

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

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

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

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

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

Автор: Ross Ulbricht

Источник: bitnovosti.com