Журнал Витуса

Date: 2012-12-27 08:10
Options: backdate
Subject: Этого не может быть, потому что не может быть никогда.
Tags: экзопланеты

charm -q -x file.with.metadata --autoformat=off --backdate=on

Обнаружилось что в ikiwiki возникает какой-то deadlock. Причем, видимо, только с использованием git в качестве бэкэнда, а то бы может давно заметили. Сейчас вот грохнул процесс git push origin (origin и рабочая копия - в одной файловой системе) и в результате смог завершиться десяток процессов и запоститься три комментария.

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

О существующем положении вещей

Практика показала, что OpenID довольно плохое решение для "бегства из ЖЖ". Пока ЖЖ лежит, никто блог и не комментирует, поскольку аутентифицироваться через OpenID не может.

Вообще, OpenID за те годы, которые прошли со времен его изобретения Фицпатрикром испортился. Исходно идея была очень симпатична - человек, приходя комментировать в чужой блог, представляется URL своего блога. Представляться комментатор должен для того, чтобы у него накопилась репутация. Очевидно, что "владелец такого-то блога" это вполне себе репутация.

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

Особенно, тут отличился гугль. У которого URL вообще неудобочитаема. Конечно, с тех пор в OpenID появлись всякие расширения, которые позволяют запросить определенную информацию о том, кто аутентифицировался. Но нужна ли эта информация читающим блог? Ну ладно E-Mail, он нужен самому блогодвижку, чтобы комменты на почту отправлять. Но всё остальное? Самого главного-то что пользователя как-то характеризует - какой-нибудь ссылки на то, что он ещё написал в интернете, нет.

Кстати, если подумать, то требование чтобы в момент регистрации пользователя его OpenID провайдер был online есть содержательный смысл. Ведь куда мы пойдем для того, чтобы что-то узнать о пользователе? На ту URL, которая является его claimed identity. Ничего другого у нас всё равно нет. Если пользователь у нас не первый раз, то можно просто когда он первый раз (при активном своём сервере) аутентифицируется, выдавать ему уже местную куку на месяц-другой, как делает lj.rossia.org.

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

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

О том, чего хотелось бы

Что такое, на мой взгляд, распределенная блогосфера?

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

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

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

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

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

1. Используются надежные криптографические алгоритмы и протоколы.
2. В этих протоколах предусмотрен срок действия сертификатов
3. Предусмотрена процедура отзыва.

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

Но вот придумать процедуру авторизации, которая не требовала бы наличия в интернете (в данный момент) сервера, которому пользователь полностью доверяет, и на котором можно хранить секрет, и не требовала хранения какого-то достаточно объемного (не вмещающегося в человеческую память) секрета при пользователе, довольно сложно. Хэшированный пароль с солью - это секрет. Его нельзя делать публично доступным, как это было в юниксах 1970 года - словарные атаки на современном железе весьма эффективны. В принципе, можно попробовать распространять вместе с RSS-фидом блога что-нибудь симметрично-зашифрованное с помощью PBKDF2 или scrypt. Тогда серверный софт несущий любую копию данного блога сможет аутентифицировать его владельца.

Тут возникает, правда, вопрос, а достаточно ли доверяет пользователь серверу, на который он пришёл комментировать, чтобы вводить там пароль, дающий доступ ко всем копиям его блога? Собственно одна из причин распространения протоколов вроде OpenID и OAuth заключается в том, что свой пароль пихать куда попало не следует.

Одной из причин, которая до сих пор удерживала меня на ЖЖ-подобных движках, было наличие там френдленты - встроенного в журнал RSS-агрегатора с достаточно удобным интерфейсом добавления ну по крайней мере других журналов с того же хостинга.

Решив всё-таки из DW уйти я встал перед необходимостью завести и собственную френдленту.

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

Пока эксперементирую с rawdog.

Эта собака страшная в общем-то делает почти всё, что мне надо, и почти так, как мне надо. Правда, иногда случаются проблемы с кодировками. Типичные для питоновских web-интерфейсов попытки проинтерпретировать как ascii то, что ascii не является, Как бы его по умолчанию заставить считать что всё, что пришло из сети - по умолчанию utf-8.

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

И интерфейс для добавления новых фидов команднострочный. Хотя я может ещё это и пофикшу и приделаю какую-нибудь cgi-шку.

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