daeq: quo vadis?

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

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

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

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

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

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

(upd. 19.12.2007) Я написал небольшой хелп, поясняющий, что нужно делать.

Текущая маска (и выбранный юзерпик) показываются вверху страницы. Именно от лица этой маски вы и будете писать сообщения.

Если пост набирает -5 баллов, он скрывается из ленты (но не удаляется). Если комментарий набирает -5 баллов - он удаляется.

Для обсуждения всего этого сделал форум. Так что если вам не совсем безразлично - прокомментируйте получившееся :)

Также можно подписаться на новости (если они будут) по адресу feeds.feedburner.com/maskas.

Пробуйте, должно быть интересно.

Недавно я писал о том, что блог-сервис Google Blogger начал тестирование комментариев с логином с помощью OpenID.

Тестирование заняло две недели, и вот теперь эта фича доступна на всех блогах.

Чтобы включить возможность владельцам OpenID-аккаунтов комментировать на вашем блоге достаточно в настройке “Кто может комментировать” выбрать “Зарегистрированные пользователи”, что теперь включает в себя и пользователей, залогинившихся под OpenID.

Ещё не успел затихнуть первоначальный шум о платформе для социальных сетей от Google по имени OpenSocial, как одна из крупнейших социальных сетей FaceBook открыла свою платформу для использования на сторонних сайтах.

После появления OpenSocial велись разговоры о присоединении FaceBook к платформе от Google, но, как видно, здесь пошли другим путём.

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

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

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

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

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

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

OAuth - стандарт для аутентификации и получения доступа одними сервисами к данным других. Эта идея не нова. Похожие системы существуют у многих крупных и не очень сервисов. Google AuthSub, AOL OpenAuth, BBAuth Yahoo, Facebook Auth. Но пока никто не создавал стандарт, который позволит существенно повысить взаимодействие между сервисами в сети.

4 декабря 2007 года была принята спецификация OAuth 1.0.

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

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

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

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

Стандарт не определяет сам процесс получения данных. Он определяет только процедуру авторизации. Остальное остаётся на усмотрение сервиса, предоставляющего данные. Также на его усмотрение он может потребовать различных механизмов проверки подлинности (подписи). Существуют рекомендованные механизмы (HMAC-SHA1, RSA-SHA1), но можно использовать и другие.

Список сервисов, поддерживающих OAuth, пока невелик. Обновлённую версию можно найти в вики.

Набор библиотек для OAuth внушительнее, чем список использующих его сервисов. Доступны библиотеки на PHP, Ruby, Python, Java, C# и Perl. Ссылки на них можно найти здесь: http://oauth.net/code/

У OAuth, как и OpenID, на мой взгляд, большое будущее. Стандартизация механизма обмена данными между сервисами требовалась уже давно.

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

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

В первой версии OpenID существует расширение Simple Registration Extension (спецификация). Во второй версии, которая наконец появилась официально 5 декабря, предусмотрен значительно расширенный функционал передачи пользовательских данных, называемый OpenID Attribute Exchange (спецификация). Attribute Exchange (AX) уже поддерживают многие OpenID-провайдеры (OP). Очередь за сайтами и сервисами.

Рассмотрим оба способа подробнее:

OpenID Simple Registration Extension

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

Для того, чтобы получить эти данные, сайт или сервис (по официальной терминологии - Relying Party, RP) должен отправить некоторые дополнительные параметры к запросу при перенаправлении пользователя на сайт OpenID-провайдера. RP может указать, что некоторые параметры являются обязательными (например, nickname), а некоторые - опциональными (например, почтовый индекс). При этом проверка введённых данных и их наличия полностью лежит на RP. В спецификации указано, что сайт должен обращаться с данными, полученными от OpenID-провайдера так же, как если бы пользователь ввёл их в ручную и отправил форму.

С помощью Simple Registration Extension можно получить следующие данные о пользователе (если он их ввёл и разрешил отправлять):

• nickname
• email
• fullname - полное имя
• dob - date of birth - дата рождения
• gender - пол
• postcode - почтовый индекс
• country
• language
• timezone

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

OpenID Attribute Exchange

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

Attribute Exchange отличается в лучшую сторону следующим:

• Можно запрашивать произвольные параметры с указанием желаемых типов данных.
• Возможность сохранять и обновлять параметры на OpenID-сервере (с запросом пользователя, конечно).
• Обмен данными не только при логине, а в любое удобное время.

Если провайдер OpenID не знает каких-то данных пользователя, запрашиваемых сайтом, он может попросить ввести их (с указанием типа данных). Также провайдер может позволить пользователю настраивать политики относительно передаваемых данных (на некоторые сайты передавать всё, на другие - только ник и т.п.). Как частный случай, провайдер OpenID может генерировать одноразовый e-mail для некоторых регистраций.

Кроме OpenID существуют и другие способы получать информацию о пользователе по его URI. Это и representative hCard и связанный со страницей FOAF-файл. У них есть свои преимущества (hCard могут читать и люди, FOAF может хранить большое количество другой полезной информации), и недостатки (требуется дополнительные запросы к страницам и библиотеки для парсинга).

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