Cоциальный граф – кому выгодно?

Автор: Денис Ковалкин 

Написано для Hostinfo.Ru, ссылка на публикацию здесь.
Семнадцатого августа 2007 года Брэд Фитцпатрик, знакомый подавляющему большинству пользователей Сети как автор проекта Live Journal, опубликовал на своей веб-странице статью «Размышления о социальном графе» (здесь — ее русский перевод). Суть предлагаемой им идеи заключается в следующем. Наше время — эпоха бума социальных сетей. Десятки и сотни сервисов накапливают в своих базах узлы социальных сетей — аккаунты и связи между узлами — отношения, строя свои собственные социальные паутинки. Паутинки эти растут, почти не взаимодействуя друг с другом, так что «френды» в одной социальной сети часто не подозревают друг о друге в другой. Фитцпатрик предлагает создать глобальную базу пользователей и их связей в Сети, всеобъемлющий граф, вершины которого — аккаунты пользователей в самых разнообразных социальных сервисах, а грани — все многообразие связей между ними (френды, рекомендации, оценки и прочая). Зачем? Брэд называет две причины.

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

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

 

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

В настоящее время проект социального графа развивается, и, похоже, достаточно успешно. Еще в августе 2007 года были созданы рабочие прототипы прикладных программных интерфейсов для работы с данными графа, обработаны данные из пяти крупных социальных сетей, начата разработка браузерных плагинов. В декабре прошлого, 2007, года Фитцпатрик выступил с докладом о социальном графе на Google Code Day в Москве. Вообще, компания Google, чьим сотрудником является Брэд в настоящее время, проявляет значительный интерес к проекту социального графа. Первого февраля 2008 года Google опубликовала прикладной программный интерфейс Social Graph API. Этот механизм использует информацию из проиндексированных Google источников формата XFN (XHTML Friends Network — микроформат для разметки социальных отношений в Сети) и FOAF (Friend Of A Friend — формат представления личных данных на базе RDF) для определения социальных связей между различными людьми и дальнейшей работы с этими данными. С таким тузом в рукаве, как Google, можно не сомневаться — проект социального графа имеет все шансы в самое ближайшее время воплотиться в реальность. Но так ли уж мы нуждаемся в социальном графе, как нам об этом рассказывают?
Взглянем на это с точки зрения простого пользователя социальной сети. Поиск старых знакомых в новых сервисах — вещь, безусловно, полезная, но не каждый же день мы регистрируемся на новом месте? Системные сбои и наши ошибки, в результате которых может пострадать один из наших аккаунтов, — вещь еще более редкая. Быть может, эти проблемы актуальны для Фитцпатрика, чей перечень аккаунтов в различных веб-сервисах перевалил за второй десяток, но обычно человеку хватает двух-трех. Добавим к этому то, что задачи, которые выполняет социальный граф на уровне пользователя, можно вообще-то решить уже имеющимися средствами без привлечения сложных программных комплексов. Найти в LiveJournal всех друзей из LiveInternet? Нет ничего проще, пишем свой «ЖЖ»-логин в LI-блоге. Те, кто захочет общаться с вами в «Живом журнале», выйдут на связь. Существуют утилиты, позволяющие сохранить список «френдов», на случай неприятностей с аккаунтом; правда, они не претендуют на универсальность, но и публикации личного списка связей в общедоступной базе с удобным API тоже не требуют.

 

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

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

 

Таким образом, напрашивается следующий вывод: продвигая идею социального графа, Брэд Фитцпатрик защищает в первую очередь интересы некоей третьей стороны. Самый вероятный кандидат на эту роль, конечно же, Google, выделяемый из списка действующих лиц методом исключения. Впрочем, этот вывод ни на шаг не приближает к ответу на гораздо более любопытный вопрос: как именно Google намерен использовать социальный граф? Достаточно ли ему для реализации перспективных бизнес-схем независимого веб-сервиса, как изначально предлагалось Фитцпатриком, или нас ожидает будущее в виде монопольного Google Social Graph API на основе баз одноименного поисковика? С учетом того, что указанный API уже увидел свет, вероятнее всего, Google и дальше будет развивать последнее направление.

Но все, перечисленное выше, не означает, что социальный граф не нужен интернет-сообществу. Просто в нынешнем виде его идею можно рассматривать лишь как полуфабрикат, заготовку. Однако при условии некоторой модификации эта идея может в корне изменить текущий характер общения в Сети. Ничего сложного, достаточно логически ее продолжить. Сообщество независимых разработчиков реализует социальный граф, позволяющий отобразить многообразие связей между людьми. Прекрасно, почему бы сообществу не создать ему в пару коммуникационную систему, которая могла бы использовать собранную графом информацию по назначению — для обеспечения коммуникации между людьми? Реализация коммуникационной системы в первую очередь потребует обеспечения приватности личных данных. В своей программной статье Фитцпатрик предлагал отложить разработку этой проблемы на потом, сосредоточившись на механизме публикации открытых данных. Вероятно, приватность и личная тайна не представляли особых коммерческих перспектив для заказчиков проекта. Между тем механизм работы с приватными данными позволит использовать социальный граф в целом ряде полезных приложений; помимо коммуникации сразу напрашивается, к примеру, создание единой системы электронных платежей, как внутренних, между узлами графа, так и внешних. Платежная система open source — звучит как оксюморон; но, быть может, открытая разработка и тестирование гораздо лучше обеспечат надежность и безопасность, чем частный разработчик? Впрочем, учитывая описанную ранее ситуацию, все эти идеи имеют достаточно небольшой шанс воплотиться в жизнь.