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

Кстати, на пике своего расцвета ЖЖ был довольно открытой платформой. Да, чтобы пользоваться всеми функциями (например, читать закрытые блоги «только для своих») нужен был аккаунт именно в ЖЖ, но в принципе и читать понравившиеся журналы можно было через RSS, не заводя себе «ленту избранного», и комментировать можно было через OpenID… Потом, правда, в погоне за монетизацией всю эту свободу поукоротили. А каждая следующая социальная сеть, что-то упрощая (и тем расширяя аудиторию), приносила всё больше ограничений. Стало можно отмечать друг друга на фотографиях, но нельзя участвовать в дискуссии, не имея аккаунта. Стало можно выкладывать фото и видео вообще без технических знаний, но нельзя читать последовательно то, что сам выбрал, без посторонних включений и всякого «мы решили, что тебе вот это тоже понравится». Стало можно накладывать симпатичные фильтры на фото прямо в приложении, но нельзя в принципе смотреть публикации, не зарегистрировавшись. А самое главное — оказалось, что владельцы платформ в погоне за прибылью то и дело что-нибудь портят: меняют привычное поведение интерфейсов, перенастраивают алгоритмы, делают неудобный дизайн, вешают больше рекламы в самых неподходящих местах…

Это ещё с narod.ru началось: в какой-то момент стало неудобно загружать файлы, всё стало тормозить, а на страницах стали появляться некрасивые рекламные баннеры. Кто-то из-за этого подался на другие платформы, а кто-то решил, что проще немного заплатить и завести собственный сайт, где полностью распоряжаться дизайном, рекламой и всем остальным. Из ЖЖ, когда он начал портиться, тоже многие уходили «в свободное плавание», перенося блог на собственный сайт, где не забанят по надуманному поводу и не повесят баннер с рекламой бургеров в блоге вегетарианца. Даже выражение устойчивое появилось: «уйти на стендэлон» — в смысле, на «отдельно стоящий» блог, вне массовой платформы.

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

Собственно, индивеб — это способ сделать из отдельных индивидуальных сайтов социальную сеть, точнее, использовать саму Сеть в качестве социальной. Или, правильнее сказать, это набор «социальных» инструментов1, которые можно использовать на своём сайте, если хочется. Плюс, конечно, сообщество людей, которые этими инструментами пользуются. Люди все разные, и сайты разные; в том и прелесть собственного сайта, что можно сделать его таким, как тебе нравится. И «социальные» функции каждому нужны свои, и на сайте у себя можно использовать только те инструменты, которые лично тебе нужны и полезны. Я, например, на своём сайте использую, фактически, всего три с половиной.

Во-первых, IndieAuth — способ авторизоваться с помощью своего сайта (в системах, которые это поддерживают). Пока это далеко не везде работает, в отличие от «войти с учётной записью Google» или «войти с помощью Facebook», например, но кое-где — да, я уже могу входить как «владелец evgenykuznetsov.org». Ну и OpenID, конечно, работает тоже.

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

Самое главное, конечно — вебменшены. Это — едва ли не основной инструмент индивеба, способ сообщить другим сайтам, что на моём что-то о них написано (и наоборот). Именно так в индивебе устроены комментарии: я пишу коммент у себя на сайте, и мой сайт вебменшеном сообщает об этом комментарии тому, кому я отвечал; этот кто-то может у себя мой комментарий показывать или не показывать, но сам комментарий всё равно у меня на сайте, и никто, кроме меня, его не сотрёт и не отредактирует. Кстати, существуют сервисы, чтобы отправлять вебменшены и не имея собственного сайта: если, например, хочется прокомментировать вот этот вот мой пост, а сайта, который умеет в вебменшены, под рукой нет — пожалуйста, comment parade в помощь.

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

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

В индивебе, кстати, принято сокрушаться, что обратная сторона вот этой свободы пользоваться только нужными лично тебе инструментами — высокий порог вхождения — ограничивает приток в индивеб широких народных масс. Это отчасти правда. Индивеб можно «прикрутить» почти к чему угодно: есть плагины для WordPress, есть вариант натянуть индивеб на Blogger, можно обходиться генератором статики, как я, но вот универсальной платформы для начинающих пока как-то не сложилось. Был Known, но теперь с ним сложнее; сейчас на эту нишу вроде бы претендует Micro.blog, но к нему тоже есть вопросы, так что простого рецепта типа «хочешь попробовать в индивеб — регистрируйся вот на той платформе, а дальше уж сам поймёшь, как и куда двигаться» на сегодняшний день не существует. Тем, у кого сайта пока нет, надо сначала определиться, как сайт будет выглядеть и как он будет устроен, а это — непростой выбор. Очень уж много разных вариантов, от простого аккаунта с прикрепленным доменом на том же Micro.blog до постройки по кирпичику с нуля, что само по себе — интереснейшее занятие, не хуже выращивания орхидей или самогоноварения…

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

Чем, собственно, и ценен.

1. Метафора  Мюррея Адкока, пост которого подтолкнул меня к написанию этих вот букв. ↩︎

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

Катализатором стал пост о внедрении вебменшенов в Hugo-сайт: в самом деле, пусть сервер ходит время от времени на webmention.io и сохраняет новые вебменшены в JSON, а мы уж тут как-нибудь. Идея хранить их в отдельном файле в /data/ была немедленно забракована: на то и Page Bundles, чтобы хранить для каждого поста его содержание (в index.md) и полученные к нему вебменшены (в webmentions.json) в одной директории. Те вебменшены, что прилетели в адрес сайта в целом (например, person mentions), можно хранить в webmentions.json прямо в директории /content/, и пока не отображать…

Автор упомянутого поста написал сохранение на JS и запускает с Netlify, но у нас тут никаких нетлифаев не водится, так что «сохранялка» нужна отдельная — благо, она уже была написана, надо только добавить опцию для сохранения в соответствующие директории. Сказано — сделано, заодно и ещё полдюжины опций разных дописал, пока ковырялся (не знаю, нужны ли они кому-то, но в процессе отладки «само возникло» — пусть будет)1. Плюс — код, который отвечает за сохранение в поддиректории, наверняка пригодится потом, когда буду писать webmention-endpoint.

Первый затык: на части страниц (а в секции «Реакции» — почти на всех) только текст, и для такой страницы создавать Bundle было, конечно, лень. В Hugo содержимое страницы с адресом https://evgenykuznetsov.org/posts/2021/old-comments/ может быть либо в /content/posts/2021/old-comments.md, либо в /content/posts/2021/old-comments/index.md (во втором случае в эту же директорию можно сложить картинки и прочее, что на этой странице потребуется — это и называется «Page Bundle»). Если я собираюсь хранить вебменшены в Bundle, первый вариант мне совсем не годится, а таких страниц у меня накопилось изрядное количество. Надо сохранить их все по второму варианту, каждую в своей поддиректории. Не вручную, конечно, а то всё лето и уйдёт — особенно с учётом языковых вариантов. Впрочем, у нас тут Linux: бери bash и действуй, как говорится:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

#!/bin/bash
set -e

wd=$(pwd)

if [[ "$1" != "" ]]; then
        wd="$1"
fi

for x in "$wd"/*.md; do
        case "$x" in 
                *.ru.md)    suffix="ru.md";;
                *.en.md)    suffix="en.md";;
                *.md)       suffix="md";;
                *)          continue;;
        esac
        name="${x%%.*}"
        if [ ! -d "$name" ]; then
                mkdir "$name"
        fi
        mv "$x" "$name/index.$suffix"
done

…и да здравствует Stack Overflow!

Дальше — проще. Убрал из шаблонов webmention.js, написал обработку JSON’а из бандла (во многом — тот же webmention.js, переведённый с JavaScript на язык шаблонов Hugo и доработанный «под себя»), «причесал» CSS (теперь знаю о CSS/SaSS сильно больше, чем в июне), написал новый шаблон для RSS-лент комментариев. Заодно разметил динамическую подгрузку аватаров и имён; при этом вылезли баги в indieweb-glue (некоторые вещи не кешировались, хотя стоило, особенно 404-е ответы, в которых к тому же не прописывался CORS-заголовок) — починил тоже. Всё работает. Правда, теперь вебменшены отображаются не сразу после получения, а после следующей пересборки сайта, зато теперь я, при желании, могу легко организовать пре-модерацию, например.

Ой, так я ж теперь могу и старые вебменшены рисовать, те, которые ещё на Known получал, я ведь при переезде с Known на Hugo их сохранил, причём именно в JSON, в том же формате, в котором они отдаются webmention.io! Интересно, а что с аватарами за напасть? Ах, вон оно что: Known, принимая вебменшены, сохранял аватары у себя, и ссылки стоят на evgenykuznetsov.org/service/web/imageproxy/, которого больше и не существует вовсе. Надо эти ссылки поубирать. Не вручную, понятное дело: у нас ведь есть jq и особая магия find — хвала Дискордии за Stack Overflow!

find ./ -type f -name "webmentions.json" \
    -printf \
        "jq -c 'del \
            (..|.photo?| \
            select(contains \
            (\"evgenykuznetsov.org/service/web/imageproxy\")?) \
            )' %p | \
        sponge %p\n" \
    | \
sh

А в каком формате у меня сохранены комменты из G+, ЖЖ и @дневников?.. Надо же, тот же самый JSON, вдохновлённый тем же webmention.io! Отобразим-ка и их тоже… Ага! У «лайков» в Google+ не было даты, и шаблон RSS-ленты об них «спотыкается»: Hugo охотно пытается распарсить дату из nil, но получает значение типа error.Error, которое дальше не обработать. Вписываем ещё одну проверку, и вот они, у меня на сайте — комменты, которым больше 15 лет! До чего же увлекательно перечитывать, особенно из тех времён, когда блог был куда более личным… Кого-то уже и по никам не помню, кого-то и в живых нет, с кем-то переписываемся-общаемся до сих пор, а кому-то тут же захотелось написать: «А помнишь?!.» Что ни говори, блогу, который ведёшь уже почти полжизни, да с комментами, никакой личный дневник и в подмётки не годится.

Следующим шагом буду webmention-endpoint писать.

1. Кстати: если кто-то пойдёт этим путём и будет сохранять вебменшены в JSON, настоятельно рекомендую сохранять их в варианте pretty-printed (как, например, делает по умолчанию jq). Да, несколько сотен лишних байт на страницу, зато потом гораздо нагляднее в git diff. ↩︎

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

Одна из тех причин, по которым я до сих пор за всплывающие карточки не брался — мобильные устройства. На тач-скрине всплывающие карточки лишены смысла, а мне не хотелось делать на сайте что-то, чем нельзя будет пользоваться на телефоне или планшете. Не то, чтобы я был поклонником концепции «mobile first», скорее наоборот, но я всячески пытаюсь, работая над своим сайтом, не забывать и про мобильные устройства. Правда, интерфейсом gitweb на мобильном тоже не шибко удобно пользоваться, ну так и смысла пользоваться им на мобильном, откровенно говоря, немного, так что пусть уж будет. Википедия, опять таки, всплывающих карточек на мобильном не показывает; можно брать пример, пожалуй.

Со всеми этими мыслями я на этой неделе засучил рукава и открыл VSCodium. Очень помогло, что  capjamesg как раз недавно сделал всю сложную часть (знаю, знаю, надо взяться-таки за JavaScript), так что мне осталась интересная. Понятно, что я не использую такой же бэкенд, как у Джеймса, и с этим пришлось как раз разбираться самому.

Откуда, собственно, брать информацию для всплывающей карточки? Логичнее всего — с самой страницы, на которую ссылка. По причинам, о которых я уже писал, собирать эту информацию и хранить у себя, как это делает Джеймс — не моё, так что очевидным решением стал снова indieweb-glue. Понятно, пришлось сначала научить его возвращать информацию о страницах (а не только о людях). Брать же информацию на страницах было решено, для начала, из Open Graph protocol, благо он широко распространён, и на многих страницах в Сети соответствующие мета-тэги есть.

В indieweb-glue я добавил обработку этих мета-тэгов (заодно пришлось немного отрефакторить код), а скрипт Джеймса немного переделал, чтобы он забирал информацию из indieweb-glue. Заодно научил скрипт работать с заранее определённым классом, а не просто с <article>, — так удобнее контролировать, где всплывающие карточки нужны, а где лучше без них. Добавил щепотку CSS, и всё заработало вполне удовлетворительно. Признаюсь, сам удивился.

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

То, что получилось, пока далеко от идеала. Надо допилить CSS, а то карточки не всегда опрятно выглядят, особенно если картинка вертикальная. indieweb-glue надо научить брать информацию не только из Open Graph protocol; например, у страниц Википедии нет og:description, зато первый абзац самого текста — явно именно то, что должно быть в карточке. В планах и доработка скрипта: было бы здорово научить его распознавать особые случаи, и, например, для person mentions заполнять карточку данными из H-Card.

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

Пока писал этот пост, заметил, что для первой ссылки (та, что на статью  Мэгги Эпплтон) в карточке появляется нарядная картинка-обложка, сгенерированная, очевидно, автоматически. Я, разумеется, немедленно захотел себе что-то подобное для страниц, на которых нет «основной» картинки.

Вообще говоря, протокол Open Graph говорит, что свойство og:image — обязательное, то есть должно быть у каждой страницы. Конечно, искать для каждого поста (не говоря уж о твитоподобных заметках) подходящую (или хотя бы примерно годную) картинку слишком хлопотно. У этой проблемы есть три возможных решения: можно завести общую картинку для всего сайта, и ставить её «обложкой» на страницы, где своей картинки нет; можно генерировать картинки-обложки автоматически; наконец, можно просто плюнуть и на (значительной) части страниц не иметь картинки вовсе. Собственно, последний вариант нарушает протокол, но весьма распространён, и на моём сайте тоже до последнего времени использовался именно он.

Я поспрашивал (в чате русскоязычного индивеба, само собой). Судя по всему, большинство (включая Мэгги) пользуется «безголовым» браузером Playwright, разработанным для тестирования, чтобы автоматически открыть страницу и сделать её «скриншот» (который и становится картинкой-обложкой). Подход, надо признать, изобретательный, но к тому, как всё устроено у меня, не очень применимый. При дальнейшем погружении в тему нашлись специально для Hugo разработанная утилита, а также изрядное количество инструкций по созданию таких изображений средствами JavaScript или Python. Инструкции, наконец, подтолкнули меня подумать головой, и в итоге я написал шаблон, который создаёт картинку автоматически для каждой странице, на которой «обложки» не хватает, прямо средствами самого Hugo.

Работает, хотя и в этом случае, конечно, доделок предстоит ещё много. Возможности обработки изображений в Hugo не безграничны, да к тому же меня очень сложно назвать «визуалом», и такие вещи всегда даются мне тяжело. Пока у меня совсем простенький скрипт, в котором задействованы только иконка сайта, информация об авторе и заголовок страницы, и нет никакого механизма, учитывающего длину заголовка, поэтому текст то и дело выезжает за пределы картинки или, наоборот, выглядит мелковато. Радует, что многие из имеющихся недостатков можно будет, при желании, со временем устранить, а скрипт доработать, чтобы использовал и другие данные о странице, для которой генерируется картинка. В любом случае, то, что получилось, лучше, чем ничего. По крайней мере, теперь на каждой странице есть свойство og:image — уже немало.

1. Я иногда сносками злоупотребляю. ↩︎