Hacker News Digest

Tangled — это новая платформа для совместной работы с Git, построенная на AT Protocol. Вместо централизованных серверов она предлагает «узлы» — лёгкие headless-серверы, которые можно поднять на Raspberry Pi. Узлы могут быть как однопользовательскими, так и мультитенантными, а весь «интерфейс» консолидируется в единое веб-приложение на tangled.sh. Проект декларирует три принципа: полный контроль над данными, низкий порог входа и не вмешательство в UX. Пока что доступ осуществляется по инвайтам в IRC-канале #tangled на libera.chat.

• Обсуждение вращается вокруг трёх тем: децентрализация, монолитные платформы vs. модульные сервисы и экономика открытого исходного кода.
• Участники обсуждают, как сделать git более децентрализованным, но при этом не теряя удобства и не создавая барьеров для входа.
• Обсуждается, как избежать блокировок и цензуры, и как при этом не терять удобство и не платить за хостинг.
• Также поднимается вопрос о том, как избежать vendor lock-in и как при этом не терять удобство и не платить за хостинг.

Протокол AT использует at:// URI, где авторитетом выступает создатель данных, а не хост. Например, в at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z пользователь ruuuuu.de — это автор, а физический сервер хостинга не указан напрямую. Это позволяет данным сохранять ссылочную целостность даже при смене хоста.

Разрешение at:// URI происходит в три шага: преобразование хэндла в неизменяемый идентификатор (DID), поиск текущего сервера хостинга через DID-документ и запрос JSON с этого сервера. Например, хэндл ruuuuu.de может разрешиться в did:web:iam.ruuuuu.de, а затем в PDS-сервер, где хранится запись. Это обеспечивает децентрализованность и устойчивость ссылок.

• Пользователи выражают недовольство алгоритмической лентой Bluesky, которая перегружена американской политикой и не соответствует их интересам, несмотря на использование кнопки «меньше такого».
• Поднимаются технические вопросы о децентрализации ATProto: критика зависимости от централизованных сервисов (plc.directory), проблемы с безопасностью (DNS poisoning) и контроль над данными и идентификаторами (DID).
• Обсуждаются альтернативные подходы к использованию платформы: переход на неалгоритмическую ленту «Following», использование пользовательских фидов и ручной подбор контента через интересные аккаунты.
• Высказываются сомнения в практической полезности и уникальности протокола, сравнивая его с существующими решениями (DNS, RSS) и отмечая избыточную сложность.
• Некоторые пользователи видят коренную проблему не в технологиях, а в социальном аспекте — сложности создания и поддержания качественного контента в децентрализованной экосистеме.

• Fediverse (Mastodon, Pixelfed и др.): серверы разделены на «крупнейший» и «остальные» в процентах.
• Atmosphere (Bluesky, WhiteWind и др.): аналогичное деление.

Данные обновляются регулярно.
Концентрация измеряется индексом Херфиндаля-Хиршмана (HHI):

• 0 ≈ полная децентрализация,
• 10 000 ≈ монополия.
  В экономике: <100 — высокая конкуренция, <1500 — неконцентрировано, >2500 — высокая концентрация.

Отслеживаются активные пользователи: для Fediverse — на серверах (инстансах), для Atmosphere — на PDS (личных серверах данных).

Код и данные на GitHub. Предложения и PR приветствуются.
Автор: Rob Ricci (@ricci@discuss.systems, @ricci.io).

• Обсуждение крутилось вокруг того, насколько реально «избежать централизации» в разных сетях: Fediverse, ATProto/Bluesky, Nostr, Git, BitTorrent, SMTP, Bitcoin.
• Участники согласились, что полной децентрализации не существует: всегда появляются «точки притяжения» — GitHub, крупные инстансы Mastodon, Coinbase, трекеры.
• Сравнивали HHI-метрику: Mastodon выглядит менее сконцентрированным, но уступает по числу пользователей; Bluesky проще для массового пользователя, но дороже в инфраструктуре.
• Поднимали риски: спам и DDoS в открытых сетях, исчезновение мелких узлов, дефедерация, отсутствие UX-консистентности.
• Главный вывод: «децентрализация» сама по себе не цель, а баланс между устойчивостью к цензуре, удобством и экономикой узлов.

Основы AT Protocol

AT Protocol (ATProto) — это архитектура, на которой построена соцсеть Bluesky. Bluesky — лишь одно из приложений-«сервисов» в экосистеме ATProto, наряду с WhiteWind, Leaflet, Tangled и др. Все они используют общие механизмы, но разные типы данных и правила. Сообщество называет всё это «Atmosphere».

Базовые блоки

• Record — JSON-объект (пост, профиль и т.д.).
• Blob — бинарные файлы (картинки, видео).
• Collection — группа записей одного типа.
• Repository (repo) — полный набор коллекций пользователя, подписанный его ключом.
• DID — глобальный идентификатор вида did:plc:… или did:web:….
• Handle — человекочитаемый @имя.bsky.social, привязан к DID через DNS TXT-запись.

Серверы

• PDS (Personal Data Server) — хранит репозиторий, принимает новые записи, раздаёт их по запросу.
• Relay — собирает все репозитории, строит глобальный индекс и рассылает «car files» подписчикам.
• AppView — фильтрует и форматирует данные для клиентов (например, Bluesky AppView отдаёт ленту постов).
• Labeler — добавляет метки (NSFW, спам и т.д.) к записям.
• Firehose — поток всех новых записей от Relay; любой может подписаться.

Как это работает

1. Пользователь публикует пост через клиент → PDS сохраняет запись в репозиторий.
2. PDS сообщает Relay об изменении.
3. Relay рассылает diff подписчикам (AppViews, сторонние сервисы).
4. AppView отдаёт клиенту готовую ленту, уже отфильтрованную и обогащённую.

Децентрализация

• Любой может запустить свой PDS, Relay, AppView или Labeler.
• Пользователи мигрируют между PDS, сохраняя DID и подписи.
• Сейчас большинство использует PDS и Relay от Bluesky, но сеть открыта для альтернатив.

Далее

В следующих частях — сравнение с Fediverse, мифы и реальное состояние децентрализации.

• Bluesky отказался от ActivityPub ради «переносимости аккаунта» — защита от банов и закрытия серверов.
• Название AT Protocol вызвало волну ностальгии по старым AT-командам модемов (ATH0, ATDT и т.д.).
• Сейчас вокруг ATProto растёт экосистема: Pebble, Skychat, Graysky, Tangled (GitHub-like) и каталог приложений blueskydirectory.com.
• Основной недостаток — отсутствие поддержки приватных данных; над этим работают в рабочей группе, которая соберётся на IETF в ноябре.