Hacker News Digest

Bluesky скрывает свой логотип в интерфейсе приложения, но оставляет его видимым на скриншотах. При обычном использовании логотип заменяется кнопкой «Follow», однако при делении скриншота он появляется в правом верхнем углу. Это происходит из-за специального компонента GrowthHack.tsx, который использует UITextField с включённым скрытием пароля (isSecureTextEntry). При скриншоте iOS автоматически блочит отображение этого UITextField, позволяя просвечивать логотипу, который на самом деле отрисован в его слое. Такой трюк, известный в приложениях вроде Telegram и Signal, позволяет обойти стандартные механизмы блокировки скриншотов. Логотип остаётся видимым только на скриншотах, а в реальном интерфейсе его заменяет другая кнопка.

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

• Спор: Некоторые считают, что это полезный способ атрибуции контента, так как Bluesky визуально похож на X, и логотип помогает определить источник; другие возражают, что любое изменение снимка экрана — это нарушение принципа, что пользователь должен видеть и сохранять то, что отображается на экране.

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

• Совет: Пользователь @rmwaite делится практическим способом обхода: если удерживать палец при свайпе вниз и обратно в центр управления, скриншот не содержит логотипа — это работает и для Twitter, что указывает на существование обходных путей в iOS.

• Совет: Пользователь @zzo38computer предлагает сделать функцию управления скриншотами настройкой в системе — с возможностью включения/отключения и указанием, какие приложения её используют, чтобы предотвратить злоупотребления и дать пользователю контроль.

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

• Пользователи отмечают, что X и Threads используют аналогичные методы, что подтверждает, что это не уникальная практика Bluesky, а отраслевой тренд, поддерживаемый платформой и направленный на маркетинг через скриншоты.

• Совет: Пользователь @vachina рекомендует использовать веб-версию приложений вместо нативных, чтобы избежать таких манипуляций, так как браузер не поддерживает подобные хаки и сохраняет чистый снимок экрана.

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

• Совет: Пользователь @Jaxkr предполагает, что этот трюк был изобретён Никитой Бьером при работе в X, что указывает на передачу метода между платформами и его системное внедрение в экосистеме соцсетей.

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

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

• Совет: Пользователь @user00005 ссылается на проблему в Graphene OS, призывая поддержать её, чтобы добиться блокировки таких функций на уровне ОС — это указывает на существование альтернативных платформ, стремящихся защитить пользовательский контроль.

• Пользователи отмечают, что подобные практики напоминают вирусный маркетинг iPhone — 'Sent from my iPhone' — и что это не новая тактика, а эволюция старого подхода: использовать каждый снимок как рекламу.

• Спор: Один пользователь выражает опасение, что если такие методы применяются к юридическим доказательствам — например, в суде — то невидимые метки в скриншотах могут использоваться для отслеживания источников, что ставит под угрозу конфиденциальность.

• Совет: Пользователь @thn-gap подтверждает, что использование веб-версии Bluesky и Twitter — это сознательный выбор, чтобы избежать таких манипуляций, и что это подтверждает, что веб-интерфейс остаётся более прозрачным и предсказуемым.

Хакер Тренды — сервис, который за 18 лет собирает более 45 млн постов и комментариев Hacker News и строит по ним гистограммы частотности упоминаний выбранных терминов. Графики обновляются в реальном времени, позволяют добавлять несколько ключевых слов и сравнивать их популярность, а под графиком отображаются сами статьи и обсуждения, поиск по которым можно фильтровать. База построена на Upstash Redis Search, что обеспечивает быстрый поиск и возможность просматривать детали каждого всплеска интереса.

Самые яркие цепочки: OpenAI‑vs‑Anthropic — OpenAI лидировал до 2026, когда Anthropic резко набрал популярность; AMD‑vs‑Nvidia — AMD доминировал 2017‑20, а Nvidia захватила рынок GPU‑ИИ в 2020‑23; Flash‑vs‑HTML5 — Flash горячим был 2010‑11, а HTML5 обогнал его к 2014‑15. Такие «баттлы» показывают, как технологии сменяют друг друга в хайпе Hacker News. Особенно заметно смена в «социальных» проектах: Mastodon вспыхнул в 2022‑м после оттока от Twitter, а к 2024‑му Bluesky стал объектом вдвое частых обсуждений, тогда как в «инструментах» лидерство переключалось от Sublime → Atom → VS Code, от Docker → Kubernetes. Паттерны показывают привязку интереса к технологическим прорывам.

• Публичный доступ к базе Hacker News через ClickHouse и Upstash Redis Search, обновление в реальном времени.
• Ограничения и ошибки: 502/504‑лимиты, некорректное отображение терминов (например, C# считается как C) и отсутствие некоторых языков/компаний.
• Предложения по улучшению: нормализация по общему объёму, переход к дате по клику на графике, поддержка сравнения «Show HN».
• Интерес к аналитике трендов: сравнение технологий, генерация смайликов по тональности, использование AI‑эмбеддингов для более точного поиска.

После почти 10 лет у руля Mastodon, Евгений Рошко уходит с поста CEO и передаёт права на торговую марку и другие активы некоммерческой организации Mastodon. Он отмечает, что Mastodon больше, чем он сам, и хочет убедиться, что проект остаётся верным своим ценностям, избегая ловушки эго основателей. Рошко признаёт, что управление социальным проектом оказалось для него крайне стрессовым, сравнивая себя с техническими миллиардерами, но без их ресурсов и поддержки. Он вспоминает, как его критиковали за недостаточно модный стиль в сравнении с Джеffом Безосом, и отмечает, что даже мелкие замечания со временем подтачивают.

Решение было принято после особенно неприятного взаимодействия с пользователем летом прошлого года, заставившего его пересмотреть отношения с проектом. Рошко считает одной из своих главных заслуг умение говорить "нет", хотя это стоило Mastodon некоторых возможностей для публичности. Он гордится тем, как далеко проект зашёл за десятилетие — от скромного проекта, написанного в его детской спальне, до одного из последних процветающих элементов оригинального, ориентированного на сообщество интернета. Несмотря на уход с поста CEO, Рошко останется в проекте в роли советника, сохраняя веру в миссию Mastodon как лучшего шанса на лучшее будущее в условиях всё более дистопичного капиталистического мира.

• Основатель Мастодона Евгений Рошко уходит с поста CEO из-за стресса и негативного взаимодействия с пользователем летом прошлого года.
• Сообщество высоко оценивает его вклад в FOSS, приватность и децентрализацию, но беспокоится о будущем проекта без его руководства.
• Критика платформы за сложность поиска пользователей и контента по сравнению с Bluesky, а также за наличие токсичного и агрессивного контента.
• Реорганизация проекта: передача активов некоммерческой организации в США, выплата €1 млн компенсации основателю.
• Беспокойство о сохранении децентрализованной природы Мастодона после ухода ключевой фигуры и возможной централизации.

Идея личного хранения данных, предложенная ещё в 2009 году Тимом Бернерсом-Ли, набирает актуальность на фоне растущих проблем с приватностью и контролем над информацией. Его концепция Socially Aware Cloud Storage и более поздний Solid Protocol предполагают, что пользователи должны хранить данные в одном месте под своим контролем, а приложения — запрашивать доступ к ним. Это меняет парадигму владения данными: вместо корпоративных «силосов» информация становится личным активом, которым можно осознанно управлять.

Хотя Solid пока не достиг массового распространения, его принципы воплощаются в таких проектах, как AT Protocol от Bluesky. Ключевая мысль: данные, генерируемые вами в разных сервисах — от умных часов до соцсетей, — должны быть доступны вам в едином формате и пространстве. Это не только вопрос приватности, но и практической пользы: объединённые данные могут раскрывать новые insights, оставаясь под вашим контролем.

• Скептицизм относительно практической реализации и массового внедрения концепции личных хранилищ данных из-за отсутствия рыночных стимулов для компаний, доминирования удобства над приватностью и технических сложностей, таких как управление схемами данных.
• Предложение постепенных, эволюционных улучшений вместо радикальных изменений, с акцентом на решения, которые предлагают немедленные преимущества по сравнению с текущим статус-кво, например, сквозное шифрование и децентрализованные протоколы.
• Упоминание существующих технологий и инициатив (Bluesky, Solid, IPFS, самохостинг), которые пытаются решить проблему владения данными, но сталкиваются с барьерами в виде сложности использования, бизнес-моделей и необходимости сетевого эффекта.
• Признание того, что проблема часто носит не технический, а экономический и поведенческий характер: пользователи ценят удобство, а компании извлекают выгоду из централизованного хранения и монетизации данных.
• Ностальгия по более открытому и децентрализованному интернету прошлого и осознание того, что для изменений可能需要 сочетание законодательного давления, прорывных приложений и смены парадигмы в восприятии данных как обязательства, а не актива.

Протокол 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) и отмечая избыточную сложность.
• Некоторые пользователи видят коренную проблему не в технологиях, а в социальном аспекте — сложности создания и поддержания качественного контента в децентрализованной экосистеме.

BlueSky автоматически блокирует контент для взрослых, используя алгоритмы для пометки аккаунтов и скрытия их постов. Это вызывает споры, поскольку система может ошибочно цензурировать легальный контент, включая искусство, образовательные материалы и аккаунты ЛГБТК+. Пользователи в ЕС теоретически могут использовать GDPR для обхода этих блокировок, запрашивая исправление неточных меток как ошибочных персональных данных.

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

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

Исследователи отмечают массовый исход учёных с платформы X (бывший Twitter) из-за снижения её профессиональной ценности. Опрос более 800 исследователей и научных коммуникаторов показал, что многие теперь считают Bluesky более эффективным для нетворкинга, популяризации науки и отслеживания новостей в своей области.

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

• Высказываются опасения о будущем Bluesky из-за снижения пользовательской активности, большого штата и объема финансирования, с прогнозами о возможном закрытии к 2026 году.
• Утверждается, что многие ученые и академики переходят с X (Twitter) на Bluesky или Mastodon из-за растущей токсичности и дезинформации на первой платформе, хотя некоторые считают, что это преувеличено и связано с политической предвзятостью.
• Bluesky критикуют за то, что она лишь номинально децентрализована, и предлагают в качестве альтернатив действительно открытые протоколы, такие как ActivityPub (Fediverse) или Nostr.
• Пользователи отмечают, что, несмотря на миграцию определенных профессиональных сообществ, X сохраняет более широкую аудиторию и большее количество casual-контента, а также преимущество в поисковой выдаче Google.
• Обсуждаются технические и usability-проблемы децентрализованных платформ (сложность выбора сервера в Mastodon), которые мешают их массовому adoption, в то время как централизованные решения проще для большинства пользователей.

Открытое ПО стало стандартом для общей инфраструктуры, хотя 35 лет назад многие сомневались в его конкурентоспособности. Сегодня мы находимся на аналогичном переломном моменте с социальными приложениями — возникает движение «открытой социальности». AT Protocol от Bluesky предлагает наиболее убедительный подход, где данные контролируются пользователями, а не платформами, подобно тому, как открытый код изменил разработку.

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

• Обсуждение преимуществ AT Protocol для контроля пользователями своих данных через личные репозитории и домены
• Сравнение AT Protocol с ActivityPub, включая вопросы интероперабельности, доступности и централизации (например, через Bluesky)
• Критические замечания о практических ограничениях: стоимость доменов, сложность для обычных пользователей и риски потери данных
• Вопросы о приватности, модерации и безопасности в децентрализованной модели
• Обсуждение сетевых эффектов, будущего социальных медиа и альтернатив (например, личные сайты, RSS, Nostr)

• 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-консистентности.
• Главный вывод: «децентрализация» сама по себе не цель, а баланс между устойчивостью к цензуре, удобством и экономикой узлов.

Ненавижу Disqus.

Годы вела блог без нормальных комментариев — подходящего решения не находилось.

• Disqus: медленный, тяжёлый, трекает, ничего не контролируешь, тормозит страницы.
• Самостоятельный хостинг: по сути свой мини-соцсервис — пользователи, спам, модерация, БД, задержки.
• GitHub Issues: годится для дев-блогов, но костыль и требует аккаунт GitHub.
• Без комментариев: чисто, но теряются беседы и открытия.

Я давно в Bluesky: комьюнити ок, API вменяемый, децентрализация, люди делают блог-посты в протоколе и комментарии через Bluesky. Почему бы не так же?

Почему Bluesky уместен

• Нет своей инфраструктуры: без БД, аутентификации и модерации — это уже в Bluesky.
• Более богатый контент: изображения, ссылки, треды.
• Реальные профили и переносимость — больше ответственности, меньше троллинга.
• Кроссплатформенность: обсуждения видны и в соцсети, и в блоге.
• Я владею постом, комментаторы — своими реплаями.

Процесс: публикую пост, шарю в Bluesky, добавляю AT URI — ответы на тот пост становятся комментариями в блоге.

Компонент

AT Protocol: DID (did:plc:…/did:web:…), CID, AT URI (at://did…/app.bsky.feed.post/postid). Чтобы получить тред, достаточно вызвать getPostThread с нужным URI, без аутентификации.

Архитектура:

1. главный компонент треда;
2. компонент ответа с метаданными и ссылкой на оригинал;
3. компонент встраиваний (изображения, превью ссылок). Простая и небольшая композиция.

Треды: вложенность произвольная; выбрала рекурсивный рендер с отступами и ограничением в 5 уровней — дальше обычно спор на двоих.

Обогащения: изображения через CDN, часто по несколько — адаптивная сетка + модалка; внешние ссылки — карточки; неизвестные типы — аккуратный фолбэк.

Интеграция с Astro: React + client:load, передаю did и postCid из фронтматтера: bsky: did: "my-bluesky-did" postCid: "the-post-id"

Что узнала

• TypeScript помогает: пакеты с типами (@atcute/client) сняли кучу багов и ускорили разработку.
• Прогрессивное улучшение: комментарии — доп. слой; без JS или при падении API пост остаётся читабельным.

• Автор статьи предлагает использовать Bluesky как систему комментариев для блога, что вызвало оживлённое обсуждение.
• Поддерживающие отмечают простоту интеграции и «открытость» AT-протокола, а критики — зависимость от VC-финансирования, риск lock-in и необходимость иметь аккаунт Bluesky.
• Возникают вопросы модерации спама и удаления оскорблений, а также планы на случай бана или банкротства платформы.
• Альтернативы: Mastodon/ActivityPub, Matrix/Cactus.chat, GitHub Issues, Webmention, «письма редактору» по e-mail или вовсе отказ от комментариев.
• Некоторые участники подчёркивают важность «Can I walk out?» — возможности забрать контент и уйти, если сервис исчезнет.