Федерация

NB: This is an old article (2019). Everything may have changed since publication.


Меня довольно давно интересуют циклы обратной связи — особенно в контексте системной динамики.

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

Вчера я мимоходом упомянул, что технологии Индивеба устойчивее, и сегодня я попробую развернуть эту мысль подробнее

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

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

Это можно увидеть на примере электронной почты. В мире существует множество провайдеров, от гигантов вроде GMail и коммерчески успешных вроде FastMail до университетов и любителей, запускающих почтовые сервера у себя дома. В теории, письмо, отправленное с любого из серверов может прийти на любой другой сервер, и очутиться на другом конце света. Общение между клиентами и серверами и общение между серверами происходит по открытым протоколам SMTP, POP, IMAP — и поэтому реализаций программного обеспечения огромное количество.

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

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

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

Похожую динамику можно наблюдать на примере IPv6, замены IPv4. О том, что у IPv4 есть ограничение количества адресов, в которое мы скоро упрёмся, было понятно довольно давно, но цивилизация всё никак не может перейти на новый стандарт, который лишён этой проблемы (и проблемы с NAT заодно): это же нужно обновить миллионы устройств, которые раскиданы по всему миру, а особой пользы от того, что лично ты переключишься на IPv6, нет.

В истории были чаты, построенные на открытых стандартах: IRC и XMPP (Jabber). И хотя оба существуют де-факто, я не могу рекомендовать их использовать, это попросту неудобно. Их заменили Slack, WhatsApp, Signal, Telegram, Discord: всё это мессенджеры, разрабатываемые корпорациями, с жёстко контролируемыми клиентами и серверами.

Мокси Марлинспайк (Signal) написал в 2016 большой пост про то, как федеративность ухудшает UX: там где, централизованная компания может единолично выкатить новую фичу, в федерации нужно убедить обновиться всех (или хотя бы большинство участников).

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

(Надо признать, ещё существует Matrix.org, который ставит целью не замкнуть коммуникации внутри себя, а объединять разные сети, я смотрю на проект с некоторым интересом, возможно из него что-то получится)

Как же тогда дело обстоит с Индивебом? За счёт того, что он построен поверх Большого Веба, то он будет существовать ещё очень долго. Мы как цивилизация умудрились создать всемирную паутину — и сделать её действительно всемирной. У нас есть инструменты навроде Archive.org, которые сохраняют историю веба; поисковики, способные проиндексировать огромное количество данных; браузеры, которые постоянно обновляются.

Да, в Индивебе будут медленнее появляться новомодные фичи, чем их будут добавлять продакт-менеджеры Твиттера или Фейсбука. Но принцип progressive enhancement работает не только для разработки коммерческих веб-сайтов: есть ядро, то, без чего никуда (в случае индивеба — публикация постов и чтение постов других), а остальное — это приятные бонусы, которые я могу добавить тогда, когда захочу.

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

Впрочем, публиковать HTML всё ещё сложнее, чем это было у Тима Бернерса-Ли на машине Next при создании веба. О том, какие решения придумали в Индивебе, я расскажу завтра.

День 5: комментарии · День 7: микропаб

Published at no particular date