Hacker News Digest

Tenacity — это удобный кроссплатформенный многофункциональный аудиоредактор и рекордер с открытым исходным кодом, разработанный добровольцами для Windows, Linux и других ОС. Программа поддерживает запись с аудиоустройств, работу с широким спектром форматов (расширяемых через FFmpeg), включая высококачественный 32-битный float audio. Среди ключевых возможностей — поддержка плагинов VST, LV2 и AU, скриптинг на Nyquist, Python и Perl, а также продвинутые инструменты редактирования с произвольной дискретизацией и мультидорожечной временной шкалой.

Особое внимание уделено доступности: редактирование с клавиатуры, поддержка скринридеров и голосовое сопровождение. Для получения помощи сообщество активно использует Matrix-канал #tenacity2:matrix.org, а также присутствует в Mastodon и Lemmy. Развернутые версии доступны на странице релизов на Codeberg, где находится основной репозиторий проекта, хотя существует зеркало на GitHub для удобства и CI.

• Tenacity — форк Audacity, созданный из-за добавления телеметрии и новой политики конфиденциальности в основной проект.
• Причины разделения подробно описаны на официальном сайте Tenacity: https://tenacityaudio.org/docs/_content/Introduction_and_Mot...
• Ранее обсуждение на Hacker News: https://news.ycombinator.com/item?id=34835200
• Исправлена сломанная legacy-ссылка: https://tenacityaudio.org/legacy/legacy.html
• Источник исправления — Codeberg и обсуждение на IRC.

Запуск собственного XMPP-сервера на базе ejabberd позволяет избежать слежки за перепиской и утечек данных, которые характерны для коммерческих мессенджеров. Это особенно актуально на фоне планов ЕС по автоматическому мониторингу всех чатов и сообщений. XMPP поддерживает шифрование OMEMO, обмен файлами, групповые чаты и аудио-/видеозвонки, оставаясь ресурсоэффективным решением.

Для развёртывания сервера требуется настроить DNS-записи для оснвных и вспомогательных поддоменов, установить ejabberd через официальный репозиторий или GitHub, открыть необходимые порты (5222, 5269, 5280 и другие) и настроить конфигурацию в YAML. Ключевые настройки включают отказ от модулей, нарушающих приватность (mod_last, mod_bosh), использование SQLite вместо Mnesia и генерацию свежих DH-параметров. Все шаги автоматизированы с помощью Ansible-ролей в открытом репозитории.

• Участники обсуждают проблемы с клиентами XMPP, особенно на iOS: отсутствие реакций, ненадежные уведомления, неудовлетворительный пользовательский интерфейс и недостаток современных функций (гифки, звонки).
• Многие отмечают простоту настройки и надежность серверов XMPP (Prosody, ejabberd), но подчеркивают, что основная сложность для широкого внедрения — это сетевой эффект и нежелание неподготовленных пользователей мириться с отсутствием привычного удобства.
• В качестве альтернатив упоминаются Matrix (критикуется за сложность и нестабильность), Delta.Chat (на основе email) и Signal (отмечаются проблемы с приватностью из-за номера телефона и возможный уход из ЕС).
• Поднимается вопрос цензуры и тотального мониторинга в ЕС, что может подтолкнуть пользователей к самохостингу и децентрализованным решениям.
• Обсуждаются технические аспекты развертывания: проблемы с блокировкой портов на публичных сетях, необходимость reverse proxy, использование Docker для упрощения установки и управления.

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

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

• Обсуждаются преимущества почтовых рассылок: независимость от компаний, федеративность, архивируемость и доступность.
• Отмечаются проблемы рассылок: сложность модерации, уязвимость email-адресов, плохой UI/UX и отсутствие истории для новичков.
• Упоминаются альтернативы: NNTP (Usenet), ActivityPub, Matrix, IRC, RSS и форумы (Discourse), но у них есть свои ограничения.
• Подчёркивается ирония обсуждения рассылок на централизованном проприетарном форуме (Hacker News).
• Приводятся примеры успешного использования рассылок для HOA, профессиональных сообществ и длительных дискуссий.

Мы поменяли блоги на чёрные ящики и теперь расплачиваемся.

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

Как вернуть человечность:

• Читайте RSS-ленты и блоги на BearBlog, Neocities, Write.as.
• Используйте Invidious, Nitter, Libreddit вместо официальных клиентов.
• Создавайте html-страницы, пишите в gemini-сети, сидите в Mastodon и Matrix.
• Делайте закладки вручную, заводите «клубы по интересам» вне алгоритмов.

Перестаньте быть «средним пользователем» — станьте куратором собственного интернета.

• Алгоритмы убили «старый» текстовый интернет: блоги и форумы вытеснены видео и лентами с лайками.
• Кто хочет убрать алгоритм — возвращается к RSS, e-mail-рассылкам, узким форумам и чатам.
• Проблема не в количестве подписчиков, а в открытом поиске: мейнстрим-площадки прячут хронологию и усиливают «рекомендации».
• Религиозные и хоббийные группы показывают, что работает «старомодный» принцип: репутация и сарафан, а не лайки.
• Платные подписки, Gemini, Kagi/Small-Web и домашние RSS-серверы становятся «белыми островами» вне рекламного болота.

Что такое Chat Control
ЕС хочет заставить мессенджеры и почту сканировать все переписки на «подозрительный» контент автоматически и до отправки. Это касается даже зашифрованных чатов.

Почему это плохо

• Тотальный массовый контроль, а не выборочный.
• Конец приватной переписки и доверию к европейским сервисам.
• Ложные срабатывания: интимные фото, медкарты, ЛГБТ-подростки — всё попадёт в базу.
• Хакеры и злоупотребления: централизованные сканы — приманка для атак и утечек.
• Детей не спасёт: реальные преступники уйдут в даркнет и зарубежные платформы.

Как отразится

• В ЕС: придётся соглашаться или уезжать.
• За пределами: европейские письма и звонки станут «прослушиваемыми» по умолчанию; тренд быстро расползётся в другие страны.

Что делать

1. ЕС-граждане:
   • Написать депутатам Европарламента (пошаблонно тут → saveprivacy.eu).
   • Подписать европетицию Stop Scanning Me.
2. Всем:
   • Перейти на открытые, проверенные мессенджеры с端到端-шифрованием (Signal, Matrix, XMPP+OMEMO).
   • Отказаться от «безопасных» облаков Big Tech, использовать шифрование клиента (Cryptomator, age).
   • Рассказать друзьям, поделиться мемами и роликами (#StopChatControl).

Ссылки

• Кратко и по-русски: edri.org, epicenter.works
• Видео: Patrick Breyer, The Hated One
• Петиции и инфа: stopchatcontrol.eu, saveprivacy.eu

• Chat Control — это предложенный ЕС регламент, обязывающий все сервисы сканировать переписку и файлы, включая зашифрованные, на предмет «запрещённого контента».
• Участники обсуждения считают молчание СМИ и общества тревожным; статья, вызвавшая тред, критикуется за невнятное изложение сути.
• Технически инициатива невыполнима без разрушения end-to-end шифрования и встроенных бэкдоров; злоумышленники просто перейдут на самописные каналы.
• Многие видят в проекте «размыкание» охвата: сначала борьба с CSAM, далее — копирайт, политический диссонанс, коммерческий шпионаж и тренировка ИИ.
• Германия пока против, но новое правительство ещё не высказалось; считается, что позиция Берлина (и/или Парижа) решит исход голосования.
• Пользователи призывают переходить на самостоятельные, несовместимые протоколы и отказываться от «удобных» централизованных мессенджеров.

ForgeFed — протокол федерации для хостингов кода и инструментов разработки. Он позволяет разным сайтам обмениваться репозиториями, задачами, PR и т.д., не заставляя пользователей регистрироваться везде.

Расширяет ActivityPub: серверы обмениваются JSON-объектами, а репозитории и трекеры получают «входящие» для удалённого взаимодействия.

Статус
Следить за прогрессом можно в Fediverse и чатах Matrix/Libera.Chat #forgefed.

Реализации

• Vervis — эталон.
• Forgejo — внедряет федерацию.
• Pagure: неподдерживаемый плагин.

Проект отдан в CC0; копируйте и делитесь!

• Участники обсуждают, стоит ли связываться с ActivityPub/ForgeFed для федерации форджей или проще улучшить email-интеграцию.
• Forgejo уже начал внедрение, но до практической полезности ещё «годы работы»; GitLab тоже ведёт эпик по ActivityPub.
• Мечта — самостоятельно хостить репозитории, не теряя связи с сообществом, но пока приходится мириться с GitHub ради «сетевого эффекта».
• Сомнения в надёжности ActivityPub: пропадают медиа и часть ответов, хотя это скорее проблемы серверов, а не протокола.
• Прогресс полностью зависит от числа добровольцев: спецификация и реализации развиваются только тогда, когда люди берутся за код.

Ненавижу 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?» — возможности забрать контент и уйти, если сервис исчезнет.

Я работал удалённо ещё до моды. В первой большой компании нас было двое в Варшаве, остальные — в Осло. Менеджер сказал: «Команда тебя приняла». Парадокс? Нет: был IRC-канал, где мы не только кодили, но и болтали о «Стартреке» и котиках. Компания создала онлайн-«кухню», и люди здоровались, спрашивали «как дела?» — как в офисе.

Пандемия. Я в консалтинге, всё как всегда: рабочие и оффтоп-каналы в Matrix. Нам поручили клиента, который «внезапно» стал удалённым. Менеджер велел включать камеры «ради командного духа». Мы купили вебки и ржали в чате. У клиента не было оффтопа; люди знали друг друга только по рабочим ролям. Ревью превращались в разборки, потому что никто не играл вместе вечерами и не пил пиво по пятницам.

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

Недавно пришёл в «remote-first» компанию без офиса. На собеседовании хвалил оффтоп, и мне ответили: «У нас куча каналов и рандомных кофе-ботов». А по факту — тишина. В #music сбросили ссылку на клип и разошлись. Коллега пояснил: «Релиз на носу, все боятся выглядеть бездельниками». Так уже несколько месяцев.

Сколько ни создавай каналов, без культуры «можно поболтать» они мертвы. В старых командах боссы постили мемы чаще всех — потому что их работа и есть быть в курсе настроений. Если начальство молчит, остальные тоже замолкают.

• Участники обсуждают, как «человеческий элемент» в работе (оффтоп-общение, дружба) повышает удовлетворённость, но может выродиться в клановость и изоляцию.
• Переход на удалёнку усилил страх слежки: в офисе кофе-пауза была приватной, в Slack всё может читаться HR/IT.
• Корпоративная культура часто подавляет неформальность: стартапам позволено шутить, крупным компаниям важно минимизировать конфликт.
• Некоторые считают, что коллеги не обязаны быть друзьями (особенно в Германии), другие подчёркивают пользу доверия и симпатии.
• Технические решения (DM, каналы без истории) могут частично заменить «водопроводные разговоры», но не решают проблему культуры.