То, что мы наблюдаем сегодня — это шквальный рост числа новых сервисов. Каждый день появляется что-то новое. Что можно сказать о пользователях, на которых рассчитаны все эти сервисы? Они растерянны, сбиты с толку этим бесконечным потоком предложений. Они мне представляются как несчастные граждане, не ведающие о своих правах, завязшие в водовороте бурлящего рынка. А есть ли какие-либо права у пользователей этого «дикого» социального веба? Участники группы Open Social Web убеждены, что каждый пользователь имеет право владения персональными данными, право контроля над тем, с кем эти данные могут быть разделены и право предоставлять постоянный доступ к этим данным для определенных внешних сайтов. Но чем это может помочь нашим раздосадованным пользователям? Видите ли, для того чтобы в полной мере опробовать какой-либо новый сервис, требуется регистрироваться в нем, заполнять все свои персональные данные, формировать свой круг друзей, проявлять активность и накапливать авторитет. Вот она — проблема. Вам потребуется много времени и сил для того, чтобы узнать, нужен ли вам действительно этот сервис. Времени и сил уже потраченных на каком-то другом сервисе. Но если разработчики нового сервиса солидарны с идеями Open Social Web, то достаточно будет лишь делегировать новому сервису доступ к вашим персональным данным, к вашей активности. Вы войдете на новый сервис преисполненными собственной значимостью, со всем накопленным авторитетом, с вашими друзьями по социальным сетям и прочее. Более того, новый сервис импортирует структуру ваших предпочтений и покажет вам на переднем плане то, что вы хотели бы увидеть и в том виде в котором вам это понравиться. Звучит как фантастика. Но теоретически это достижимо. Как?
Международная группа достаточно известных в социальном вебе экспертов именуемая как Data Portability рекомендует использовать определенные существующие технологии как раз для достижения описанной выше миссии. Так что же это за технологии и как их использовать в собственных проектах?
Начнем с идентификации пользователя. Самый простой стандарт в этом отношении MicroID. Он использует пару email + url для идентификации пользователя. Вот его формула:
Для подтверждения того, что пользователь реально владеет указанной им страницей, достаточно лишь указать в ее секции HEAD следующее:
Несмотря на всю видимую простоту стандарта его уже поддержали такие проекты как Digg, Plaxa, ClaimID, Last.fm, Ma.gnolia, Wikitravel, и Yedda.
Лично мне показалось интересным, что MicroID может быть использован не только для подтверждения подлинности пользователя при обратной связи, но и, скажем, для подтверждения его репутации на стороннем сервисе:
Второй стандарт по идентификации пользователя, полагаю, вам знаком – это OpenID. Я уже ранее рассматривал этот стандарт на Хабрахабре в отношении идентификации пользователя на собственном проекте (OpenID consumer). Однако коль уж мы заговорили о правах пользователей, то было бы справедливо предоставить пользователям вашего сервиса эдакий «виртуальный паспорт», который они смогли бы предъявлять на сторонних проектах. Для этого потребуется раздавать пользователям адрес личных страниц на сервисе в поддоменах типа http://sheiko.pozzzy.ru. Для тех, кому не случалось делать подобное, порекомендую использовать в конфигурации Apache (если вы используете этот сервер) в секции VirtualHost параметр ServerAlias на манер ServerAlias *.pozzzy.ru. После этого останется лишь разбирать содержание переменной $_SERVER[«HTTP_HOST»] в стартовом скрипте PHP. Для того чтобы сделать свой сервис OpenID provider вам понадобиться соответствующее программное обеспечение. В общем случае можно использовать библиотеку от OpenID Enabled (имеются PHP, Python, Ruby версии). Однако меня покорил своей простотой крохотный фреймворк PHPMyID.
Имеется так же крохотный стандарт Pavatar, позволяющий связать изображение 80x80px. (аватару) с пользователем. Допускаются форматы PNG, JPG и GIF. Достаточно лишь добавить на странице пользователя код:
Кстати говоря, pavatar и MicroID могут предоставляться с прочей информацией из профиля пользователя провайдером OpenID.
Информация о пользователе так же может быть задана посредством микроформата hCard.
Ок. Мы разобрались с тем как можно идентифицировать пользователя и предоставить ему возможность делегировать право чтения данных его профиля. Но как можно получить информацию о его друзьях в различных социальных сетях? Как минимум это позволило бы нам показать пользователю, кто из его друзей представлен на нашем сервисе.
Небезызвестный Брэд Фицпатрик (Brad Fitzpatrick), основатель LiveJournal, автор стандарта OpenID последнее время активно продвигает концепцию Social Graph и гугловский API к ней. Идея в том, что Google индексирует информацию о связях пользователей в социальных сетях если они, эти связи, представлены в заданных форматах (XFN и FOAF). API позволяет получать эту информацию в удобном виде. Кстати, если вам вдруг не достаточно Google, воспользуйтесь Plaxo Open Social Graph.Т.е. когда пользователь вошел на наш сервис, мы можем опросить Social Graph по поводу его друзей в других сервисах. Далее останется лишь сравнить их идентификаторы по базе пользователей нашего сервиса и сообщить пользователю о его друзьях на проекте. Поскольку получить данные от Social Graph достаточно просто (предлагается ответ по вашему запросу в форме text, JSON, XML), имеет смысл остановиться над тем, как оформить данные для их дальнейшей индексации в граф.
Прежде всего, следует изменить код ссылок на страницах пользователей в рамках сервиса в соответствии с микроформатом XFN.
Можно использовать <a rel=«me» ..>..</a> для дополнительных ссылок, связанных с владельцем открытой страницы и <a rel=«friend» ..>..</a> для ссылок на страницы его друзей. Если в вашем сервере доступны подробности отношения пользователя с его друзьями это можно отразить, скажем, как <a rel=«friend met» ..>..</a>.
Что касается стандарта FOAF (The Friend of a Friend), то позволяет описать пользователя и его связи в более структурированной форме, в RDF. Вам следует указать в коде страницы пользователя ссылку на его RDF-документ:
Сам RDF-документ должен формироваться автоматически на основании данных о пользователе и его связях в рамках проекта.
Говоря о правах пользователя, я также упоминал возможность обмена информацией о предпочтениях пользователя между сервисами. Одной из наиболее любимой в еще одном коллективе почтенных джентльменов Media 2.0 Workgroup является технология APML. Существует множество различных методов учета предпочтений пользователя на основании его активности. Для этого служат и настольные приложения (Particls) и такие онлайн сервисы как Bloglines, Cluztr, Dandelife и конечно Google. Указанные сервисы за исключением Google используют язык разметки APML для описания профилей предпочтений пользователей. Что собственно и открывает возможность обмена этими профилями между сервисами с позволения пользователя.
В заключении хотелось бы также отметить и технологию OAuth. Она позволяет делегирование прав на постоянный или временный доступ к персональным данным пользователя для сторонних сервисов и их API.
Как видите это в наших руках — сделать социальный веб открытым, дать пользователям законные права касательно их личных данных. Умные люди уже продумали, как это может быть достижимо и задача разработчиков сервисов лишь воплотить эти идеи.
Международная группа достаточно известных в социальном вебе экспертов именуемая как Data Portability рекомендует использовать определенные существующие технологии как раз для достижения описанной выше миссии. Так что же это за технологии и как их использовать в собственных проектах?
Идентификация пользователя и данные его профиля
Начнем с идентификации пользователя. Самый простой стандарт в этом отношении MicroID. Он использует пару email + url для идентификации пользователя. Вот его формула:
microID = sha1(
sha1( "mailto:sheiko@mysite.com" )
+
sha1( "http://cmsdevelopment.com/" )
)
Для подтверждения того, что пользователь реально владеет указанной им страницей, достаточно лишь указать в ее секции HEAD следующее:
<meta name="microid" content="mailto+http:sha1:код_microID"/>
Несмотря на всю видимую простоту стандарта его уже поддержали такие проекты как Digg, Plaxa, ClaimID, Last.fm, Ma.gnolia, Wikitravel, и Yedda.
Лично мне показалось интересным, что MicroID может быть использован не только для подтверждения подлинности пользователя при обратной связи, но и, скажем, для подтверждения его репутации на стороннем сервисе:
<span class="score microid-mailto+http:sha1:fe98b5adf288318c0763e1d5b0855b3d2266338c">5</span>Второй стандарт по идентификации пользователя, полагаю, вам знаком – это OpenID. Я уже ранее рассматривал этот стандарт на Хабрахабре в отношении идентификации пользователя на собственном проекте (OpenID consumer). Однако коль уж мы заговорили о правах пользователей, то было бы справедливо предоставить пользователям вашего сервиса эдакий «виртуальный паспорт», который они смогли бы предъявлять на сторонних проектах. Для этого потребуется раздавать пользователям адрес личных страниц на сервисе в поддоменах типа http://sheiko.pozzzy.ru. Для тех, кому не случалось делать подобное, порекомендую использовать в конфигурации Apache (если вы используете этот сервер) в секции VirtualHost параметр ServerAlias на манер ServerAlias *.pozzzy.ru. После этого останется лишь разбирать содержание переменной $_SERVER[«HTTP_HOST»] в стартовом скрипте PHP. Для того чтобы сделать свой сервис OpenID provider вам понадобиться соответствующее программное обеспечение. В общем случае можно использовать библиотеку от OpenID Enabled (имеются PHP, Python, Ruby версии). Однако меня покорил своей простотой крохотный фреймворк PHPMyID.
Имеется так же крохотный стандарт Pavatar, позволяющий связать изображение 80x80px. (аватару) с пользователем. Допускаются форматы PNG, JPG и GIF. Достаточно лишь добавить на странице пользователя код:
<link rel="pavatar" href="http://example.com/path/my-pavatar.png" />Кстати говоря, pavatar и MicroID могут предоставляться с прочей информацией из профиля пользователя провайдером OpenID.
Информация о пользователе так же может быть задана посредством микроформата hCard.
Информация о социальных связях пользователя
Ок. Мы разобрались с тем как можно идентифицировать пользователя и предоставить ему возможность делегировать право чтения данных его профиля. Но как можно получить информацию о его друзьях в различных социальных сетях? Как минимум это позволило бы нам показать пользователю, кто из его друзей представлен на нашем сервисе.
Небезызвестный Брэд Фицпатрик (Brad Fitzpatrick), основатель LiveJournal, автор стандарта OpenID последнее время активно продвигает концепцию Social Graph и гугловский API к ней. Идея в том, что Google индексирует информацию о связях пользователей в социальных сетях если они, эти связи, представлены в заданных форматах (XFN и FOAF). API позволяет получать эту информацию в удобном виде. Кстати, если вам вдруг не достаточно Google, воспользуйтесь Plaxo Open Social Graph.Т.е. когда пользователь вошел на наш сервис, мы можем опросить Social Graph по поводу его друзей в других сервисах. Далее останется лишь сравнить их идентификаторы по базе пользователей нашего сервиса и сообщить пользователю о его друзьях на проекте. Поскольку получить данные от Social Graph достаточно просто (предлагается ответ по вашему запросу в форме text, JSON, XML), имеет смысл остановиться над тем, как оформить данные для их дальнейшей индексации в граф.
Прежде всего, следует изменить код ссылок на страницах пользователей в рамках сервиса в соответствии с микроформатом XFN.
Можно использовать <a rel=«me» ..>..</a> для дополнительных ссылок, связанных с владельцем открытой страницы и <a rel=«friend» ..>..</a> для ссылок на страницы его друзей. Если в вашем сервере доступны подробности отношения пользователя с его друзьями это можно отразить, скажем, как <a rel=«friend met» ..>..</a>.
Что касается стандарта FOAF (The Friend of a Friend), то позволяет описать пользователя и его связи в более структурированной форме, в RDF. Вам следует указать в коде страницы пользователя ссылку на его RDF-документ:
<link rel="meta" type="application/rdf+xml" title="FOAF" href="http://sheiko.pozzzy.ru/foaf/"/>
Сам RDF-документ должен формироваться автоматически на основании данных о пользователе и его связях в рамках проекта.
Информация о предпочтениях пользователя
Говоря о правах пользователя, я также упоминал возможность обмена информацией о предпочтениях пользователя между сервисами. Одной из наиболее любимой в еще одном коллективе почтенных джентльменов Media 2.0 Workgroup является технология APML. Существует множество различных методов учета предпочтений пользователя на основании его активности. Для этого служат и настольные приложения (Particls) и такие онлайн сервисы как Bloglines, Cluztr, Dandelife и конечно Google. Указанные сервисы за исключением Google используют язык разметки APML для описания профилей предпочтений пользователей. Что собственно и открывает возможность обмена этими профилями между сервисами с позволения пользователя.
В заключении хотелось бы также отметить и технологию OAuth. Она позволяет делегирование прав на постоянный или временный доступ к персональным данным пользователя для сторонних сервисов и их API.
Как видите это в наших руках — сделать социальный веб открытым, дать пользователям законные права касательно их личных данных. Умные люди уже продумали, как это может быть достижимо и задача разработчиков сервисов лишь воплотить эти идеи.
