Аннотация

Google Reader выключили 1 июля 2013 года, а его API — тот самый, которого официально никогда не существовало, — в 2026 году остаётся единственным способом подключить к самохостящемуся агрегатору Reeder, NetNewsWire или Newsboat. Ниже разбирается, что именно обязывает реализовать этот контракт: две схемы аутентификации, три формата идентификаторов, курсорная пагинация вместо ссылок и протокол репликации состояния, замаскированный под REST. Дальше — где FreshRSS, Miniflux, BazQux, The Old Reader и freshgo расходятся между собой, почему клиенты оказались строже серверов и что это стоит тому, кто сегодня пишет собственный сервер (данные на 2026-10-21).

Введение

Первого июля 2013 года Google выключил Reader, а через две недели безвозвратно удалил подписки пользователей. Прошло тринадцать лет; за это время закрылись Google+, Digg Reader и десятки более мелких сервисов, а RSS объявляли мёртвым примерно раз в год. И всё же в октябре 2026-го свежий релиз самохостящегося агрегатора freshgo описывает свою главную функцию так: сервер «отвечает тем же Google Reader API, поэтому мобильные и десктопные клиенты продолжают работать с теми токенами и идентификаторами статей, которые у них уже есть»1. Не «новый, современный API», а именно тот, что умер вместе с продуктом.

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

Границы разбора: только API синхронизации читалки (подписки, потоки статей, состояние «прочитано/звёздочка», метки). Разбор фидов, парсинг RSS/Atom, веб-интерфейсы и федерация остаются за рамками — про них есть отдельные обзоры. Примеры адресов даны на example.org.

Как появился протокол, которого не было

Официальная версия закрытия коротка и не содержит технических деталей: «Мы запустили Google Reader в 2005 году, чтобы людям было проще следить за любимыми сайтами. Хотя у продукта есть преданные поклонники, со временем использование снизилось. Поэтому 1 июля 2013 года мы закрываем Google Reader»2. Через день после отключения команда попрощалась с пользователями и предупредила, что данные подписок будут «безвозвратно удалены» и после 15 июля 2013 года восстановить их не сможет никто3.

«На самом деле никакой документации Google Reader API не существует».

— Брент Симмонс, автор NetNewsWire, 14 марта 2013 года4

Симмонс не преувеличивал: он лишь выложил PDF, который Ник Брэдбери написал в 2009 году, когда переводил FeedDemon и NetNewsWire с синхронизации NewsGator на Google Reader4. Первые публичные описания протокола появились ещё раньше и делались обратной разработкой. Автор wiki проекта pyrfeed прямо предупреждал: «Этот документ совершенно неофициальный… Google Reader API не был официально опубликован»5. Единственный корпус документации, которому можно доверять больше остальных, собрал инженер Google Reader Михай Парпарита: с 2010 по 2012 год он вёл вики, где «документировал и уточнял поведение неофициального API Google Reader», а репозиторий так и называется — «неофициальная документация неофициального Google Reader API»6.

Контраст с форматами разительный. RSS 2.0 — опубликованная спецификация с редакционными правками и версией 2.0.11 от 30 марта 2009 года7; Atom — стандарт IETF RFC 4287 от декабря 2005-го8. То есть синтаксис ленты был стандартизирован, а синхронизация состояния читателя — нет. Именно этот пробел и занял протокол закрытого сервиса.

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

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

Вход и токены

Аутентификация устроена как в Google эпохи 2005 года: POST /accounts/ClientLogin с параметрами Email, Passwd, service=reader и accountType=GOOGLE возвращает текст из строк SID, LSID и Auth, после чего клиент прикладывает к каждому запросу заголовок Authorization: GoogleLogin auth=<значение>9. Для изменяющих запросов нужен второй токен: GET /reader/api/0/token отдаёт action token, который передаётся параметром T; он живёт 30 минут, а при ошибке сервер обязан вернуть 401 с заголовком X-Reader-Google-Bad-Token: true10. OAuth в документации Парпариты назван предпочтительным, но ClientLogin остался основным путём для десктопных клиентов9.

Именно здесь начинается первое расхождение. В FreshRSS токен вычисляется как SHA-1 от соли установки, имени пользователя и хеша отдельного API-пароля и фактически бессрочен, а отдельного шага получения action token для правок в документации нет — изменяющий запрос в примере уходит с тем же заголовком Authorization1112. Практик, писавший в 2025 году собственную реализацию на Elixir, формулирует это прямо: «в FreshRSS они генерируют SHA-1-хеш от системной соли, имени пользователя и соответствующего хеша пароля, делая токен фактически постоянным, без истечения срока»12. Miniflux пошёл другим путём: токен — это HMAC-SHA256 от пустого сообщения с ключом из имени пользователя и bcrypt-хеша пароля, GET-запросы принимают его только в заголовке, а POST-запросы — только в поле T13. Один и тот же клиент обязан уметь оба поведения.

Идентификаторы: две системы координат

Второй слой — идентификаторы, и это самая болезненная часть контракта. Поток (stream) в Google Reader адресуется строкой: feed/<URL фида> для ленты, user/<id>/state/com.google/read, starred, reading-list для состояний, user/-/label/<имя> для пользовательских меток, причём дефис означает «текущий аутентифицированный пользователь»14. В FreshRSS и Miniflux тот же слой выглядит иначе: в примерах FreshRSS фигурирует feed/52, то есть числовой идентификатор11, Miniflux в ответах тоже отдаёт feed/<число>, но при подписке требует feed/<абсолютный URL>, а при редактировании и отписке — снова число13.

Идентификатор статьи в оригинале — 64-битное число, которое представляется двумя способами: длинная форма tag:google.com,2005:reader/item/ плюс 16 шестнадцатеричных цифр с ведущими нулями и короткая — знаковое десятичное число, причём отрицательное для старших битов. Документация честно предупреждает: «Все методы, принимающие идентификаторы статей, понимают обе формы, но разные ответы содержат разные формы (по историческим причинам)», и советует хранить идентификаторы как строковые блобы, не пытаясь конвертировать15. Реализации расширили это пространство кто во что горазд: The Old Reader использует BSON ObjectId вида 00157a17b192950b65be3791 и в идентификаторах статей, и в идентификаторах фидов16; Miniflux принимает четыре формы — длинную, короткую с префиксом, 16 шестнадцатеричных цифр без префикса и десятичное число, — но в stream/items/ids отдаёт десятичные, а в stream/items/contents длинные13; FreshRSS и freshgo работают с числовыми идентификаторами, где «строка цифр, не начинающаяся с нуля, — десятичное число»17.

Отсюда простое правило, которое независимо формулируют оба практика: парсер идентификаторов должен принимать всё, а генератор — выдавать ровно ту форму, которую ждёт конкретный эндпоинт1217.

Чтение: потоки, страницы, время

Чтение устроено вокруг двух эндпоинтов. GET /reader/api/0/stream/contents/<stream> отдаёт статьи: n ограничивает размер страницы (по умолчанию 20, максимум 1000), c — курсор продолжения, ot и nt — границы по времени в секундах эпохи, r задаёт порядок, xt исключает помеченные статьи, а output переключает JSON и XML, причём по умолчанию это XML1819. GET /reader/api/0/stream/items/ids отдаёт только идентификаторы: до 10 000 за запрос, можно несколько потоков сразу и merge, а в ответе — itemRefs с полями id и timestampUsec20. Документация прямо мотивирует такой дизайн: получать идентификаторы «значительно дешевле», и фильтровать надо на уровне идентификаторов, а содержимое забирать только для выжимки20.

Здесь же спрятана главная неопределённость. Курсор c в оригинале — непрозрачный токен вида CJLRnpeNpakC18; в Miniflux это «числовое смещение в SQL, закодированное как JSON-строка, а не непрозрачный токен»13; в freshgo — идентификатор последней статьи полной страницы, и запрос с c начинает с неё, исключая её саму17. Все три варианта совместимы с клиентом, который просто возвращает серверу то, что получил, и все три ломаются, если клиент попытается интерпретировать курсор сам.

Запись: состояние вместо ресурсов

Изменения сделаны не через ресурсы, а через операции над тегами. POST /reader/api/0/edit-tag получает повторяющиеся i (идентификаторы статей), a (добавить тег) и r (снять тег): отметка «прочитано» — это добавление user/-/state/com.google/read, звёздочка — starred, метка — user/-/label/<имя>1711. Подписки меняются через subscription/edit с действием ac=subscribe|unsubscribe|edit, где s — поток фида, t — новое имя, a и r — папка, в которую фид кладут или из которой убирают1621. Массовая отметка «прочитано» — отдельный mark-all-as-read с параметром ts1713.

Такая модель означает, что сервер обязан хранить не «статью с флагом», а множество тегов на статью и уметь отвечать на вопрос «что изменилось», не имея для этого отдельного эндпоинта. Это и есть корень всех проблем синхронизации.

Синхронизация: протокол репликации, а не REST

Самое полезное, что было написано про этот API, написал конкурент. Документация BazQux начинается словами: «Это копия Google Reader API. Единственное, что нужно, чтобы поддержать BazQux Reader, — поменять в коде адреса эндпоинтов с google.com на bazqux.com»21. Дальше идёт раздел «The Right Way to Sync», где автор перечисляет, как синхронизироваться нельзя: скачивать каждый фид отдельно (у пользователя может быть 3000 фидов, большинство не обновлялось), ограничивать выборку через n по фиду (один фид даст 250 новых статей, другой — пять за год), и — самое важное — синхронизироваться по ot21.

«Пожалуйста, НЕ „синхронизируйтесь“, скачивая каждый поток фида отдельно».

— документация BazQux Reader, раздел The Right Way to Sync21

Причина, по которой ot не работает, — не производительность, а семантика. Пользователь может отметить прочитанной статью пятилетней давности, снять звёздочку с прошлогодней, поменять фильтр, из-за которого статья исчезла из выдачи; сервер может удалять старые статьи, чтобы не разрасталась база21. Правильный алгоритм, по мнению автора BazQux, — получить списки идентификаторов всех непрочитанных, всех избранных и всех помеченных метками, удалить у себя то, чего больше нет, дозагрузить содержимое недостающего и отправить обратно изменения состояния через edit-tag21.

То же самое, только в виде баг-репорта, видно у FreshRSS: разработчик Android-клиента спрашивает, как узнать, что статья, которую он уже синхронизировал, была отмечена прочитанной в веб-интерфейсе, — и получает ответ, что эндпоинта «что изменилось с момента X» в протоколе нет22. Обсуждение в трекере Capy Reader показывает, как эту дыру латают: клиент берёт stream/items/ids с параметром ot, ограничивая глубину тремя месяцами, а FreshRSS отдельным изменением переопределяет ot так, чтобы он означал «статьи, которые новые или изменились с этого момента»23. Формально это расширение контракта, фактически — ещё одна версия протокола, которую должны угадать остальные.

freshgo доводит ту же логику до спецификации: it/xt комбинируются побитово, ot оставляет статьи, добавленные или изменённые фидом начиная с этой секунды, nt — добавленные и в последний раз изменённые не позже неё, а вместе они расширяют выборку17. Это уже не «как в Google», а зафиксированное поведение конкретной реализации, без которого клиенты FreshRSS работать не будут.

Где реализации расходятся

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

Модель токена. Google: action token на 30 минут и обязательный X-Reader-Google-Bad-Token при отказе10. BazQux: свой токен живёт 14 дней, а причина отказа логина передаётся в заголовке X-BQ-LoginErrorReason со значениями вроде YearSubscriptionExpired21. FreshRSS: бессрочный SHA-1 от соли, пользователя и хеша API-пароля12. freshgo повторяет эту схему, чтобы выданные ранее токены оставались валидными, но принимает и пустой T (так его присылает FeedMe), и T=x (так делает Reeder)17. Miniflux: HMAC-SHA256 и разные способы передачи токена для GET и POST13. Все четверо называют это «Google Reader API».

Идентификатор фида. Google отдаёт и принимает feed/<URL>14. Miniflux в ответах отдаёт feed/<число>, но при подписке ждёт feed/<URL>13. freshgo принимает и число, и адрес, но напоминает, что «feed/<...> — не единый стабильный формат идентификатора на всех эндпоинтах»17.

Ошибки. У Google — 401 и заголовок10. У Miniflux аутентификация под /reader/api/0/* отвечает простым текстом 401 Unauthorized, а не JSON, ClientLogin — JSON, а неизвестный эндпоинт возвращает [] с кодом 200, а не 40413. У freshgo, который повторяет поведение FreshRSS, неизвестный эндпоинт — 400 Bad Request!, а tag/list, subscription/list и unread-count без output=json — 50117. Клиент, написанный под один сервер, на другом получит либо ошибку там, где ждал пустой список, либо пустой список там, где ждал ошибку.

Полнота. Miniflux честно пишет о себе: «Miniflux реализует совместимое подмножество, предназначенное для существующих клиентов Google Reader. Это не полная реализация исторического Google Reader API, и ряд поведений намеренно уже или специфичен для реализации»13. Практическое следствие описано в документации RSS Guard: «Miniflux требует интеллектуальной синхронизации, потому что его совместимый API не предоставляет более старую операцию полного потока», а The Old Reader вообще не синхронизирует метки статей24.

Эталон. freshgo выбрал эталоном FreshRSS 1.30.1 и записал 292 эталонных запроса, ответы на которые воспроизводятся в тестах побайтово, — включая странности вроде того, что клиенту newsplus на пустой список идентификаторов нужно отвечать одним идентификатором 017. Там же перечислены намеренные отступления: например, перебор пароля через ClientLogin замедляется и отвечает за время одного сравнения хешей, потому что FreshRSS «отвечает мгновенно на неизвестное имя и не ставит паузу, что выдаёт, какие имена существуют»17.

Почему он всё ещё держит экосистему

Первое объяснение — сетевой эффект в чистом виде: ценность подключения к протоколу растёт с числом клиентов, а клиенты уже написаны. В таблице совместимых приложений FreshRSS девятнадцать строк с пометкой GReader — от Capy Reader и Readrops до Newsboat, Reeder Classic и NetNewsWire25. Классическая работа Каца и Шапиро о сетевых внешних эффектах описывает ровно эту ситуацию: совместимость с установленной базой повышает ценность продукта для пользователя сильнее, чем любое улучшение самого продукта26.

Второе — асимметрия затрат. Новый сервер обязан повторить поведение существующего, а не наоборот, потому что клиенты менять дороже. Автор собственной реализации 2025 года описывает это без иллюзий: API «никогда не документировался официально, а существующие реализации полагаются на спецификации, полученные обратной разработкой», причём «многие такие описания предлагают реализации, совместимые с „оригинальной“ спецификацией, но, к сожалению, не работающие со многими клиентами»12. Иными словами, контракт — это не документ, а поведение популярнейшей реализации.

Третье — эффект окостенения, хорошо изученный в сетевых протоколах: как только развёрнутая база промежуточных узлов или клиентов начинает зависеть от конкретных behaviours, любое изменение спецификации перестаёт доходить до конца, и протокол фиксируется в том виде, в каком его застали27. Здесь роль «middlebox» играют мобильные клиенты, которые нельзя обновить синхронно с сервером.

Четвёртое — инверсия принципа устойчивости. IAB в документе о поддержке протоколов напоминает каноническую формулировку: «Будь строг в том, что отправляешь, и терпим к тому, что принимаешь»28 — и показывает, что при отсутствии активного сопровождения терпимость серверов превращается в накопление неоднозначностей, которые потом никто не может убрать, не сломав клиентов. Google Reader API — учебниковая иллюстрация: серверы терпят пустой T, лишние идентификаторы и неизвестные эндпоинты, а клиенты, наоборот, стали строгими и требуют конкретных отклонений.

Пятое — у протокола нет стандартизированной замены. RSS 2.0 и RFC 4287 стандартизируют формат ленты78, WebSub — доставку уведомлений об обновлении через хабы29, но ни один из них не описывает состояние читателя: что прочитано, что отмечено, какие метки и в каком порядке. Именно этот слой остался незанятым, и его занял API мёртвого продукта. Альтернатива, Fever API, появилась в 2013 году и не вытеснила Google Reader API: в README FreshRSS она описана как «ограниченные возможности, менее эффективная, менее безопасная», а её аутентификация — это md5(login:password), отдаваемый в теле каждого запроса2530.

Что это значит на практике

Если вы пишете сервер. Синхронизацию надо строить вокруг идентификаторов, а не вокруг времени: отдавайте полный список непрочитанных и избранных, держите курсор стабильным между версиями, не изобретайте семантику ot молча. Эталонный набор запросов к существующей реализации — самый дешёвый способ поймать несовместимость до пользователей; freshgo сделал это 292 запросами, снятыми с FreshRSS 1.30.1, и сравнивает ответы как данные, оставляя вне сравнения updated, iconUrl, порядок категорий статьи и — для добавленных в ходе прогона фидов — идентификаторы и время статей17.

Если вы пишете клиент. Не пытайтесь предвычислять токены (в Miniflux они зависят от bcrypt-хеша, известного только серверу)13, храните идентификаторы как непрозрачные строки15, ожидайте и feed/<URL>, и feed/<число>13, следуйте за continuation и не считайте, что неизвестный эндпоинт вернёт ошибку13.

Про безопасность. Обе популярные реализации отделяют API-пароль от пароля веб-интерфейса1113, и это не формальность: токен в FreshRSS фактически бессрочен12, а BazQux держит свой 14 дней21. Если сервер принимает ClientLogin, он принимает и перебор пароля — freshgo поэтому считает неудачные попытки вместе с веб-логином и отвечает за время сравнения хешей17.

Про миграцию. Главный практический аргумент в пользу протокола — не удобство, а то, что перенос сервера не требует перенастройки клиентов. freshgo импортирует установку FreshRSS, сохраняет соль и хеши API-паролей, поэтому выданные ранее токены остаются валидными, а идентификаторы статей — теми же117.

Почему сейчас. За последний месяц вышли FreshRSS 1.30.2 (19 октября 2026)31 и Miniflux 2.3.4 (20 октября 2026)32, а freshgo выпустил 24 релиза за тринадцать дней — с v0.1.0-rc.1 седьмого октября до v0.3.11 двадцатого33. Вопрос «какой API реализовывать» перестал быть теоретическим для всех трёх проектов одновременно.

Противоречия и открытые вопросы

Что считать соответствием. Спецификации нет, эталон не назначен. FreshRSS объявляет Google Reader API «лучшим» из двух своих API25, Miniflux — «совместимым подмножеством»13, freshgo выбрал эталоном FreshRSS17, а автор независимой реализации советует ориентироваться на поведение клиентов, а не на архивные документы12. Формально все правы, практически эталон — та реализация, под которую настроено больше клиентов, и это состояние не зафиксировано нигде, кроме кода.

Семантика ot. Для Google это «статьи не старше момента», для FreshRSS после изменения — «новые или изменившиеся», для Miniflux — «опубликованные после», а BazQux прямо просит не использовать параметр вообще18231321. Клиент, написанный под один сервер, на другом получит другую выдачу, и обнаружит это не сразу.

Пробелы в данных. Публичных цифр о распределении клиентов и серверов нет: ни FreshRSS, ни Miniflux не публикуют число активных установок, а оценки доли рынка RSS-читалок опираются на данные магазинов приложений. Поэтому утверждение «протокол держится, потому что клиентов больше, чем серверов» здесь опирается на число совместимых приложений (девятнадцать в таблице FreshRSS25) и на прямые заявления разработчиков о том, что клиенты не переписывают1217, а не на измеренную базу пользователей.

Возможная замена. Технически место Google Reader API мог бы занять стандартизированный протокол синхронизации состояния, но ActivityPub и WebSub решают другие задачи — федерацию и доставку обновлений29, — а не «что я прочитал на телефоне». Пока такого стандарта нет, любая новая попытка будет конкурировать не с Google, а с девятнадцатью уже написанными клиентами.

Заключение

Google Reader API пережил свой сервис на тринадцать лет не благодаря качеству дизайна, а благодаря тому, что оказался единственным описанным контрактом для слоя, который никто не стандартизировал, — синхронизации состояния читателя. Его реальная спецификация — не вики 2010 года и не архивные PDF, а поведение FreshRSS, Miniflux и десятка клиентов: с бессрочными токенами, четырьмя формами идентификаторов, курсорами, которые то непрозрачны, то числовые, и с молчаливыми расширениями вроде переопределённого ot.

Для того, кто сегодня пишет сервер, это означает скучный, но точный вывод: совместимость здесь измеряется не соответствием документу, а совпадением с наблюдаемым поведением — и проверяется только прогоном реальных клиентских запросов. Пока этого не сделано, «поддержка Google Reader API» остаётся обещанием, а не свойством.

Quality Metrics

MetricValue
Источников33
Уникальных URL33
Официальные/первичные и стандарты27 (82%)
Академические2 (Katz & Shapiro 1985, Honda et al. 2011) + документ IAB
Покрытие параграфов цитатами82% (37 из 45)
Полных прочитанных страниц20, из них 7 — короткие wiki-страницы
Раундов углубления2
Объём3 399 слов
Дата данных2026-10-21

  1. Evsyukov D. “freshgo — FreshRSS-compatible feed aggregator server in Go.” GitHub. https://github.com/juev/freshgo ↩︎ ↩︎

  2. Google. “A second spring of cleaning.” The Keyword, 13 марта 2013. https://blog.google/company-news/inside-google/company-announcements/a-second-spring-of-cleaning/ ↩︎

  3. Google Reader Team. “A final farewell.” Official Google Reader Blog, 2 июля 2013. https://googlereader.blogspot.com/2013/07/a-final-farewell.html ↩︎

  4. Simmons B. “Google Reader API Documentation.” inessential.com, 14 марта 2013. https://inessential.com/2013/03/14/google_reader_api_documentation.html ↩︎ ↩︎

  5. pyrfeed. “GoogleReaderAPI.” Wiki проекта pyrfeed (архив Google Code). https://code.google.com/archive/p/pyrfeed/wikis/GoogleReaderAPI.wiki ↩︎

  6. Parparita M. “Unofficial documentation for the unofficial Google Reader API.” GitHub, 2010–2015. https://github.com/mihaip/google-reader-api ↩︎

  7. RSS Advisory Board. “RSS 2.0 Specification (2.0.11).” 30 марта 2009. https://www.rssboard.org/rss-specification ↩︎ ↩︎

  8. Nottingham M., Sayre R. “RFC 4287: The Atom Syndication Format.” IETF, декабрь 2005. https://www.rfc-editor.org/rfc/rfc4287 ↩︎ ↩︎

  9. Parparita M. “Authentication.” Google Reader API wiki. https://github.com/mihaip/google-reader-api/blob/master/wiki/Authentication.wiki ↩︎ ↩︎

  10. Parparita M. “ActionToken.” Google Reader API wiki. https://github.com/mihaip/google-reader-api/blob/master/wiki/ActionToken.wiki ↩︎ ↩︎ ↩︎

  11. FreshRSS. “Google Reader compatible API implementation.” Документация для разработчиков. https://freshrss.github.io/FreshRSS/en/developers/06_GoogleReader_API.html ↩︎ ↩︎ ↩︎ ↩︎

  12. davd.io. “Re-Implementing the Google Reader API in 2025.” 5 февраля 2025. https://www.davd.io/posts/2025-02-05-reimplementing-google-reader-api-in-2025/ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  13. Miniflux. “internal/googlereader/README.md — Miniflux Google Reader API.” GitHub. https://github.com/miniflux/v2/blob/main/internal/googlereader/README.md ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  14. Parparita M. “StreamId.” Google Reader API wiki. https://github.com/mihaip/google-reader-api/blob/master/wiki/StreamId.wiki ↩︎ ↩︎

  15. Parparita M. “ItemId.” Google Reader API wiki. https://github.com/mihaip/google-reader-api/blob/master/wiki/ItemId.wiki ↩︎ ↩︎

  16. The Old Reader. “The Old Reader API.” GitHub. https://github.com/theoldreader/api ↩︎ ↩︎

  17. freshgo. “docs/specs/greader-api.md — Google Reader API.” GitHub. https://github.com/juev/freshgo/blob/main/docs/specs/greader-api.md ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  18. Parparita M. “ApiStreamContents.” Google Reader API wiki. https://github.com/mihaip/google-reader-api/blob/master/wiki/ApiStreamContents.wiki ↩︎ ↩︎ ↩︎

  19. Parparita M. “ApiCommonInputs.” Google Reader API wiki. https://github.com/mihaip/google-reader-api/blob/master/wiki/ApiCommonInputs.wiki ↩︎

  20. Parparita M. “ApiStreamItemsIds.” Google Reader API wiki. https://github.com/mihaip/google-reader-api/blob/master/wiki/ApiStreamItemsIds.wiki ↩︎ ↩︎

  21. BazQux. “BazQux Reader API Documentation.” GitHub. https://github.com/bazqux/bazqux-api ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  22. FreshRSS. “Greader API: get modified items (issue #2566).” GitHub, 2019. https://github.com/FreshRSS/FreshRSS/issues/2566 ↩︎

  23. Capy Reader. “Synchronisation tips (discussion #533).” GitHub, 2024–2025. https://github.com/jocmp/capyreader/discussions/533 ↩︎ ↩︎

  24. RSS Guard. “Google Reader API.” Документация. https://rssguard.readthedocs.io/en/latest/services/google-reader-api.html ↩︎

  25. FreshRSS. “FreshRSS README — APIs & native apps.” GitHub. https://github.com/FreshRSS/FreshRSS ↩︎ ↩︎ ↩︎ ↩︎

  26. Katz M., Shapiro C. “Network Externalities, Competition, and Compatibility.” American Economic Review 75(3), 1985, с. 424–440. https://openalex.org/W1598833883 ↩︎

  27. Honda M., Nishida Y., Raiciu C. et al. “Is it still possible to extend TCP?” IMC 2011. https://openalex.org/W1981800388 ↩︎

  28. Thomson M., Schinazi D. “Maintaining Robust Protocols.” IAB, draft-iab-protocol-maintenance-12, февраль 2023. https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance ↩︎

  29. Genestoux J., Parecki A. “WebSub.” W3C Recommendation, 2 июня 2026. https://www.w3.org/TR/websub/ ↩︎ ↩︎

  30. FreshRSS. “Fever API implementation.” Документация для разработчиков. https://freshrss.github.io/FreshRSS/en/developers/06_Fever_API.html ↩︎

  31. FreshRSS. “FreshRSS 1.30.2.” GitHub Releases, 19 октября 2026. https://github.com/FreshRSS/FreshRSS/releases/tag/1.30.2 ↩︎

  32. Miniflux. “Miniflux 2.3.4.” GitHub Releases, 20 октября 2026. https://github.com/miniflux/v2/releases/tag/2.3.4 ↩︎

  33. freshgo. “Releases.” GitHub, октябрь 2026. https://github.com/juev/freshgo/releases ↩︎