Comments 139
Дизайн сайта, конечно, ужасен, как будто тёмная тема, которая не до конца корректно применилась. Тёмное на тёмном, плохо читающийся текст и прочие прелести.
RSS не масштабируется
RSS это просто XML‐файл на диске, он не может масштабироваться по определению.
сервис должен выдерживать нагрузку около 1000 запросов в секунду!
популярный сервис с 1 млн. подписчиков
Ваш вебсервер не может держать 1000 соединений — смените вебсервер.
Если на вас вебсервер зайдёт весь этот миллион подписчиков чтобы посмотреть страницу index.html, вы тоже обвините язык разметки гипертекста, что он не масштабируется?
RSS подразумевает поллинг. Не существует пуш реализаций
Ваш вебсервер не может держать 1000 соединений — смените вебсервер.
Ни яблоко, ни гугл менять веб сервер не стали. Факт остаётся - поддержку RSS просто прекращают
Ее прекратили не поэтому. 1000 рпс за простеньким текстовым контентом это смешно.
Никогда не разбирался - а как работают пуш-уведомления в браузере? Я честно говоря думал, что браузер за ними также периодически куда-то обращается. Или сервер прямо может послать сообщение на браузер за натом в произвольный момент времени?
Есть различные протоколы websocket, sse и тп
И это, внезапно, те самые 1 000 000 соединений с веб-сервером. Они, кстати, куда затратнее раздачи статики
а в чем проблема 1 млн соединений? пусть себе висят. это потянет даже один инстанс. лимит у ядра линукса - 1,048,576 файловых дескрипторов
Эм. Ну это тяжелее раздачи статики вообще-то.
Потому как этот млн соединений надо не только держать, но и отправлять по ним что-то. Вот только когда клиент запрашивает инфо - она ему нужна. А когда вы отправляете свою новость на весь миллион соединений - 90% нафиг оно не нужно и это, опа, лишняя нагрузка.
Уведомления (веб-сокеты сюда же) - это не для рассылки "всем", это для отправки сообщений конкретным клиентам в реалтайме. И это вообще не замена RSS, это просто разные вещи.
Так здесь рассылается лишь то, что нужно конкретному клиенту. Поэтому если сообщение матчится с миллионом клиентов, значит оно интересно им всем
Я вам про нагрузку, вы мне про полезность. Ну вы уж определитесь.
Миллион запросов на статику можно раздать достаточно дешево, а то и вообще не за свой счет (CDN от Cloudflare бесплатен).
Миллион пушей - ну попробуйте, че уж. Не мнимый, а реальный миллион одновременных соединений. Вот вам реальный опыт: https://habr.com/ru/companies/vk/articles/331784/
Обратите внимание на подсчет памяти, например.
Вот только когда клиент запрашивает инфо - она ему нужна.
Если клиент запрашивает RSS-ленту, то он ещё сам не знает есть ли там нужная ему информация.
Насколько я знаю, RSS - это всего лишь формат файла, а не протокол, потому там нет даже механизма отбрасывания старых "новостей". Клиенту остаётся лишь периодически запрашивать одно и то же в поисках изменений.
Да, протокол там HTTP в котором есть такая замечательная вещь как ETag
Etag не поможет, уже здесь обсуждали. Не позволяет кэшировать на стороне CDN
И что с того? Откуда CDN узнает, изменилась лента или нет у самого сервиса?
Как правило, сервисы ничего не знают о CDN. И в общем, не должны.
По ссылке я наблюдаю какой то очень уж странный костыль, о котором надо знать заранее, автоматизировать и ещё, похоже, заплатить
Если сервис использует CDN, то он конечно же о нем знает. Если нет, то я не понимаю кто, как и зачем в вашей картине мира использует CDN и как CDN по-вашему узнает об изменениях просто в вебе?
Кэш в принципе должен быть прозрачен как для клиента, так и для сервиса. Сброс кэша по вашей ссылке - скорее ручная операция при аварии. Тем более там лимит на частоту операций. Этот способ никак не может использоваться для нормального режима работы
Вот захожу я на сайт просто, без подписок по всяким протоколам, и там я тоже напарываюсь на необновленный кэш что ли? Да, обычно это сброс не по урлу, а по тегу, но он будет
Да, соглашусь, идиотской передачи файла на каждый запрос можно без труда избежать. Но заголовки никуда не денутся.
Не существует пуш реализаций
WebSub не присылает RSS файл, это принципиально другое.
У меня есть план добавить поддержку подобного, но мне более перспективной кажется поддержка ActivityPub
Он присылает уведомление что надо сходить за файлом и создавался специально как расширение для лент Atom
ActivityPub же не гарантирует доставку, это протокол сходный с Email по принципу работы - если не доставлиось, то потерялось. WebSub же наоборот, гарантирует что вы получите пропущенное либо при следующем уведомлении, либо при поллинге.
Activitypub доставляет постом на вебхук подписчика. Это исключает транспортные потери, по крайней мере
Как? Поломалась сеть между 2 узлами и всё
То есть WebSub publisher должен надёжно хранить состояние каждого подписчика? Это уже совсем другое дело) теперь понятно, почему так мало публичных websub источников
Нет, я выше объяснял почему ему это не надо. Есть конечно тоже риск что за время даунтайма напишут больше чем $rss_length постов, но на практике я с таким не сталкивался, а вот с потерей постов и распаданием тредов на ActivityPub серверах - постоянно
И все же activitypub популярнее будет, чем websub
https://trends.google.com/trends/explore?date=today 5-y&q=Wesub,Activitypub&hl=en
Может, конечно, хайп на ровном месте
Если исправить опечатку, то примерно на уровне до октября 2022, когда Маск купил Твиттер и завирусился Мастодонт как альтернатива
Но ActivityPub безусловно более популярен, потому что это протокол соцсетей (и он очень плох именно в этом своем сегменте)
А WebSub действительно довольно редок, из крупных площадок его использует на вскидку только Medium, но это потому что крупные площадки либо не поддерживают RSS, это факт, либо не обновляли его поддержку десятилетиями, когда WS еще не существовал. Большая часть контента который генерит RSS это статические блоги, они как раз поллингом неплохо обходятся
В современном мире важно быстро получать новости
Да кто все эти люди, откуда у вас столько времени, когда вы успеваете читать всё?
Расскажите, сколько у вас каналов обновлений и какой объём новостей вы потребляете, мне правда интересно. :)
Простой пример: поиск работы. Вы бы не хотели ограничивать свой поиск одним лишь условным superjob. Для этого вам понадобится множество источников. Причём вы можете даже не все их знать. Это означает фильтрацию в потоке сообщений неограниченной ширины.
Да кто все эти люди, откуда у вас столько времени, когда вы успеваете читать всё?
По работе - 194 каналов. Не так часто все они обновляется и часто практикую "отметить как прочитанное" не читая содержимое ленты. Если вкратце, в эти 194 ленты входят
- Коммиты из github-а. С фильтрацией
- твиты разных людей и компаний (nitter.privacydev.net)
- лиды с хабра, weblancer или пикабу
- инстрамы твиты телеграмы вк конкурентов (https://feed.eugenemolotov.ru - я там админю)
- подкасты
- прочее
Пользуюсь не инструментом, который тут рекламируется, а Tiny Tiny RSS.
Разрешить сервисам уведомления - равно
открыть портал в адъполучать спам. Мы тут же утрачиваем контроль над тем, что, где и когда мы получаем.
Если что, разрешение на получение уведомлений отзывается парой кликов.
Сейчас это сервисами элегантно обходится замешиванием спама и полезных сообщений в один канал. Т.е., например, банковское приложение будет спамить своей рекламой, а если отключишь то потеряешь и сообщения о движении средств на счете.
Нет, например, чтобы удалить половину своих подписок вам потребуется:
Вспомнить их все
Пройти по каждому и разобраться в уникальном способе отписки "парой кликов". Может быть. Ну если повезет. Ой, у нас отписка сломалась, позвоните в поддержку. Ваш звонок очень важен для нас.
Вы издеваетесь? "Настройки" - "Конфиденциальность и безопасность" - "Настройки сайтов" - "Уведомления" - и там виден список ВСЕХ сайтов, которым дано разрешение на уведомления. Что тут, блин, вспоминать-то?
Но на самом деле это требуется только если приходится помогать кому-то другому избавиться от спама. Потому что лично у меня необходимость удалить подписку может возникнуть только в том случае, когда с какого-нибудь сайта прямо сейчас пришёл раздражающий спам. Нет нужды вспоминать тот сайт, который прямо сейчас у тебя открылся по клику.
И вот тут разрешение на уведомления отзывается ровно в два клика (в три если считать открытие сайта):
Картинка
Подписки бывают не только "разрешением сайту уведомлять". Есть ещё email, моб приложения и что-нибудь ещё, о чем так сразу и не вспомнить
Awakari не хранит никаких данных пользователей, всё отдано на откуп сторонним сервисам
В наш век утечек, взломов и таргетированной рекламы "сторонние сервисы" звучит как ругательство...
Для любителей RSS есть RSS-Bridge
https://github.com/RSS-Bridge/rss-bridge
В котором есть и Телеграм и ВКонтакте и прочие новостные безRSSные сайты...
Буду говорить о себе - меня не устраивает такое решение.
RSS интерфейс означает поллинг. Это означает, что придётся обрушивать весь поток информации с множества источников на клиента. Если я хочу выбирать из как можно большего числа источников, в пределе - со всего интернета? Это работать не будет.
Нет фильтрации.
Минимальная задержка примерно равна периоду поллинга. Это может быть слишком много для некоторых use case.
Awakari - polling terminator, то есть работает наоборот.
Буду говорить тоже о себе. Tiny Tyny RSS как раз в паре с RSS-Bridge и решают все Ваши вопросы и с даже фильтрацией со всего интернет, извините. Ну разве кроме 3-го пункта если для него есть use case...
Фильтрациии я не нашёл среди фич
Придётся хостить самому и собирать все источники, невозможно использовать общую коллекцию источников. То есть выборка ограничена теми источниками, о которых вы итак уже знаете
Проблема поллинга не столько задержка, сколько в вынужденном выборе между холостой нагрузкой и большей задержкой
В TTRSS Кроме фильтрации ещё есть возможность самому создавать каналы на базе фильтров. И подписываться на них :) .Т.е. почти Ваш функционал...
По вопросу self-hosting это большой плюс.
Никому не должно быть интересно, что мне интересно.
Фильтрациии я не нашёл среди фич
Она есть.
Регулярные выражения - это то, от чего я отказался на самых первых этапах прототипирования. Должно быть что то вроде текстового поиска с поддержкой стемминга.
Не нашёл способа группировать условия в более сложные с применением логики "и", "или" и тп
Не нашёл численных условий. Например, матчить сообщения, где поле "цена" меньше 1000
RSS интерфейс означает поллинг. Это означает, что придётся обрушивать весь поток информации с множества источников на клиента.
RSS это не интерфейс, а формат файла (как и HTML). Как его обрушивать зависит от программы (агрегатора), которой этот RSS контент пользователь собирает и просматривает. Ведь ваш сервис таким же агрегатором и является, с той лишь разницей, что просмотр осуществяется через телегу. И занимается, помимо прочего, тем же самым поллингом RSS источников.
Да, авакари - агрегатор. Но разница в том, что он получает сообщение один раз для всех клиентов и направляет его только тем, кому оно интересно. Rss раздаёт всем одно и тоже, в том числе то, что не нужно.
Rss раздаёт всем одно и тоже
Это почему? В протоколе нет такого ограничения. Можно хоть токен тонко настроенного запроса включить в URL и получать строго то, что надо. Я не теоретизирую - у меня довольно тонко настроены RSS с rutracker и nnm-club.
Тогда это вырождается в поллинг по подписке (токену). Но зачем поллинг? Ради лишних запросов и задержки?
Какие-то серверы, так или иначе, должны быть нагружены этой задачей - деления общего потока на интересы юзеров, и распихивание разных кусочков юзерам.
Большой разницы нет, работает это на облаке сервиса (youtube, vk, или facebook - все давно уже решили эту задачу), или на вашем облаке. Пока всё выглядит так, как будто вы хотите себе взять кусочек работы, с перспективой потом получить за это какой-то профит.
Но главное - решать какую-то задачу пользователя, чтобы пользователь к вам пошёл. А она уже или решена (как с гибким rss у торрент-трекеров), или не может быть решена (как фильтр публикаций Хабра по автору, мониторинга нужного товара на avito, или скрейпинг инфы с крупных соц. сетей - как только они вас заметят, то забанят или засудят).
Большая разница в том, что YouTube не пришлёт вам из Facebook и наоборот. Это не агрегаторы. Более того, они не предлагают прозрачного механизма фильтрации. В авакари вы можете настроить подписку и проверить как она работает.
Пока всё выглядит так, как будто вы хотите себе взять кусочек работы, с перспективой потом получить за это какой-то профит.
Разумеется. А почему нет?
мониторинга нужного товара на avito
Это ещё почему? Дело техники
Это ещё почему? Дело техники
Потому что сервис не обладает способностью к телепатии и к само-апгрейду по потребностям пользователя. Вы не знаете, что у пользователя есть потребность искать айфоны дешевле 15к. Пользователь посмотрит, увидит, что сервис в данный конкретный момент не умеет решать решать его задачу. И всё, разошлись, как в море корабли...
Инстаграм не работает, правда, для меня это стало поводом забить на Инстаграм
Или Huginn https://github.com/huginn/huginn
(вроде он понастраиваемей, но я RSS-bridge не пробовал - по диагонали их readme пролистал)
>В современном мире важно быстро получать новости
Нет. Неважно. Это зачастую ведет как раз к стрессу, выгоранию и прочему - желание быть обо всем в курсе.
Нужные новости вас сами найдут. А без остальных можно обойтись
Тут важно, чтобы новости были релевантными. Речь как раз об избавлении от шума при ожидании нужного сигнала. Допустим, вы захотели купить айфон 15 дешевле 100 рублей. Вы заходите на условное авито и делаете поиск по параметрам. Ничего не найдено. Чтобы позже проверить, не появился ли данный товар, вам нужно повторять поиск снова и снова. И вот, надоело. Тем временем товар появился и его уже купил тот, кто быстрее проверял наличие.
Awakari позволяет задать критерии и ждать. Доставка релевантного сообщения занимает десятки миллисекунд.
А можно пример как сконфигурить этот ваш авакари, чтобы вот он мониторил авито на тему 15 айфонов дешевле какой то суммы?
Мне чет кажется на формирование запроса который работает всегда и правильно я потрачу больше времени, чем на периодическое обновление страницы.
Вообще если честно из статьи понятно ровынм счетом ничего. В чем преимущество сервиса? Он не поллит сервисы? Поллит же, иначе как он получит обновления? Тогда к чему это сравнение с РСС?
Вот так.
Авито вам не нужен, вам нужен айфон 15.
Если очень нужно именно Авито, то можно в продвинутом режиме указать условие "source: avito.ru"
Численные условия поддерживаются, но на практике контент с Авито пока не парсится так, чтобы цена была отдельным атрибутом.
Авакари не использует поллинг если на входе телеграм канал, но поллит ленты типа RSS и делает это "один раз для всех". И избавляет клиента от необходимости поллить.
Вы опять предлагаете централизованное решение, которое будет собирать информацию по интересам пользователей, и в итоге может использоваться произвольным методом. Использование RSS из-за своей природы ограждает от этого. А нагрузка даже миллиона пользователей будет не существенной, как тут уже заметили т.к. это фактически раздача статического файла.
Не совсем так. Файл ленты RSS меняется в произвольный момент времени и не может быть закэширован.
Но в остальном так, получается, что я предлагаю поделиться вашими интересами в обмен на то, что сервис может найти нечто даже из неизвестных вам источников. Тут надо подумать...
Я думаю, что я могу доказать, что я не собираю никакой информации о пользователях. Код, отвечающий за аутентификацию открыт:
https://github.com/awakari/webapp/blob/bb79dbc3cd7e43b87b5404b7012dbcbd9c30a3bd/web/login.js#L10
В качестве юзер ид используется префикс identity provider и сторонний юзер id из которого я не могу понять, кто это.
Например, для телеги юзер ид выглядит так:
tg://user?id=34955377
Этот юзер добавил какое то порно в источники. Как я могу узнать имя нашего первого героя?
Как я могу узнать имя нашего первого героя?
Это не сложно. https://qna.habr.com/q/704345
Т.е. это все равно RSS, но перенесенный с моего клиента на ваш сервер? Почему вы тогда пишете о преимуществах для удаленного сервера, предоставляющего RSS? Ведь для него разницы нет. Ну и непонятно чем отличается это все от innoreader например.
Ваш запрос по айфону ломается элементарно. Объявление 15 iphone и всЕ, ну и как выяснили - цены не парсятся. Мой вам совет - смените таргетирование своего сервиса. Пока ваш промоушн его не выдерживает совершенно.
Сервис читает RSS один раз сразу для всего множества пользователей. Кроме RSS поддерживаются и другие типы источников (пуш)
Как минимум Innoreader платный и не делает пуш
Объявление 15 iPhone найдёт указанную в примере подписку. Здесь вы не понимаете, о чем говорите
Но читает же его.
Похоже надо делать сервис по подписке на уведомления, но с учётом взаимных подписок, чтобы избавиться от спама.
А рекламируемый сервис не станет платным при повышении нагрузки от набежавших пользователей и увеличении количества источников?
Сервис имеет защиту от эксплуатации. Каждому пользователю дан лимит на 1 бесплатную и не ограниченную по времени подписку + публикация до 10 сообщений в день. Когда пользователь добавляет источник, то источник публикует сообщения из лимита этого пользователя. Если хочется больше, то можно обратиться в поддержку. В будущем для увеличения лимитов потребуется оплата. Пока что только донаты, тк нет юридического лица.
Собственно, я решил сделать сервис публичным, тк я решил проблему поллинга обратным поиском. Это значит, что стоимость при прочих равных будет расти не линейно в зависимости от кол-ва подписок, а логарифмически. То есть приходите и пользуйтесь, хоть миллиард пользователей
То есть, Хабр так не почитать, потому что более 10 сообщений в сутки
Нет
Хабр уже там со своим лимитом
Если не хватает, можете запросить "проапгрейдить"
Вот так. Авито вам не нужен, вам нужен айфон 15
Тогда вы промахиваетесь с продакт плейсментом. RSS нужен, когда я точно знаю, откуда и какую информацию получить. Ваш кейс это "давайте я подберу вам ленту по вашим интересам". И это уже заход на поле tiktok/dzen/youtube shorts и т.п., только возможно в текстовом режиме.
Ну и сделайте, как эти мастодонты: начните показывать пользователю любую ленту и попробуйте под него подстроиться, показывая посты, которые его скорее всего заинтересуют, не требуя сложной настройки подписок.
Я просто не понимаю use-case awakari. Что-то настраивать-настраивать и в итоге не получить список дешёвых айфонов на Авито, с чем я изначально пришёл, а получить "мы лучше знаем, что вам показать".
Не понял, 1000 запросов в секунду для статического XML в, пусть, пару сотен Кб - это много чтоли? Купите еще один ВПС за 200 руб, раз уж у вас миллион подписчиков, не разоритесь.
Много или мало - но это лишняя нагрузка на сервис. К тому же и на клиент, который делает холостые запросы, которые не приносят нового результата. Это всё может быть мало, пока мало клиентов и они редко запрашивают обновления. И для клиента - пока у него мало лент.
И это ещё не всё - добавьте лишнюю задержку
По идее, это многовато, причём большая часть запросов бесполезная, надо делать обратную связь.
То чувство, когда прочитал полученную по rss статью о плохости rss. Про 1k rps - ну вы обновляйте фид чуть реже, да положите его в кэш, сделайте пагинацию. Можно подумать, что тысяча rps это нонсенс в век, когда системы автоматического мониторинга собирают десятки тысяч метрик в секунду, а добавить еще ядро на виртуалку стоит 50 центов в месяц и две минуты времени.
Выше уже отвечал
Реже = больше задержка
Чаще = больше холостой нагрузки
Поддержка сервисами RSS слабеет с каждым годом
Не из-за нагрузки, а потому что хотят чтобы пользователь больше времени оставался на их говноплощадке.
А чем заменить? Один сервис это не вариант.
Ваше мнение про то, что новости нужно получать в ту же секунду, как только произошло событие, сильно преувеличивает реальное положение дел, на мой взгляд. Прелесть RSS как раз во многом в том, что оно совершенно асинхронное. Кто-то выпускает новости, а ты заходишь потом и читаешь. Оставьте мне решать, как распорядиться моим временем, пожалуйста, не надо бороться за мое внимание.
Что же касается "Поддержка слабеет" - она поэтому и слабеет, внимание пользователя так не удержишь. Но я вот искренне надеюсь, что рано или поздно мы зайдем на новый виток спирали и поддержка RSS на сайте-агрегаторе будет фичей удержания аудитории. По большому счету так оно и есть - я вот в RSS получаю заголовки и первых пару абзацев почти везде, а потом читать иду на сайт, если новость интересная. Сайт от этого только выигрывает - просто так на Хабр я не приду, мне интереснее условного Клеппмана перечитать - а из RSS-фида перехожу регулярно.
Зависит от кейса. В некоторых случаях минимизация задержки может давать конкурентное преимущество, например в торговле или какой-нибудь крипте.
Кто-то выпускает новости, а ты заходишь потом и читаешь. Оставьте мне решать, как распорядиться моим временем, пожалуйста, не надо бороться за мое внимание.
Не аргумент. Вы же телеграм не удалили с мобильного телефона из-за этого? Правильно, вы включаете заметные уведомления когда вам это удобно. Поэтому пуш ничем не хуже для клиента, чем поллинг RSS читалок. Мой сервис должен доставить клиенту сообщение, телеграм клиента его сохранить для прочтения потом. На доставке работа моего сервиса закончена. Когда вы прочитаете сообщение - это вам решать.
По большому счету так оно и есть - я вот в RSS получаю заголовки и первых пару абзацев почти везде, а потом читать иду на сайт, если новость интересная.
Самое смешное, что в этом же треде критиковали RSS за одни лишь заголовки, что надо идти на сайт и читать полное содержание.
Самое смешное, что в этом же треде критиковали RSS за одни лишь заголовки, что надо идти на сайт и читать полное содержание.
Для этого есть rss2full, я для ленты с хабра его использую.
То чувство, когда прочитал полученную по rss статью о плохости rss
В которой продвигается программа, использующая rss.
Awakari is Great!
Does Facebook serve Awakari?
OK, Awakari is dead.
Нет проблем интегрировать фэйсбук, инстаграм, твиттер или что там ещё. Сервис пока только появился. Если будет спрос на конкретную интеграцию - можно сделать
Как я понимаю, проблема будет та же, что и с RSS - корпорация не захочет сотрудничать. И вероятно при превышении лимита запросов от ваших серверов просто вас забанит.
А так-то, можно и для RSS сделать посредника, который бы вытягивал контент из соц. сетей.
Это не проблема клиента.
В принципе решается путем партнерства в будущем.
Если вы не поддерживаете facebook, vk, instagram, twitter, discord и прочий зоопарк, то это проблема клиента - вы наобещали, что всё будет в одном месте, и обманули.
Это в принципе никак не решается, потому что фейсбуку выгодно, чтобы пользователь сидел в его приложении и читал его ленту, а не сидел в вашем приложении и читал вашу ленту. Непримиримое противоречие.
Если проблема решена, то это не проблема клиента. Пока что такой проблемы нет, так как нет и клиента, который бы просил что то, кроме того что есть. Будет запрос - будет сделано. И тогда это будет моей проблемой.
Это в принципе легко решается, всевозможных способов достать контент из фэйсбука - тьма. В тч "официальных" https://developers.facebook.com/docs/
Куда ни ткни, там всё закрыто юридическими запретами.
Например, Meta Platform Terms:
a. Prohibited Practices. v. Placing Platform Data on, or otherwise making Platform Data available to, a search engine or directory without our prior express written consent
Instagram Platform:
Don't use the Instagram Platform to simply display User Content, import or backup content, or manage Instagram relationships, without our prior permission.
Официальных способов транслировать контент меты в своё приложение - не существует.
Как оказалось, чтобы быть в топе поиска гугла, многие сервисы публикуют машиночитаемые и структурированные метаданные. Поэтому популярные сервисы все равно принесут все сами на блюдечке:
"Многие" - это те, которые даже не мечтают побороться с Гуглом.
Найдите такую разметку на страницах facebook/instagram, X/Twitter, vk.com.
Я говорю о том, что крупняк не даст вам себя парсить (в промышленных масштабах). Можете поиграть в доморощенного гугла и попробовать поиндексировать все-все-все остальные сайты, которые не борются с парсингом, и свою ленту сделать на этом. Конечно, если хватит ресурсов.
По крайней мере последние мероприятия достать из фэйсбука легко. И это только навскидку.
И что показывает этот пример? А если ключевое слово на 5-й строке, которая не попала в выдачу ddg?
Кроме того, это гуглу можно, а вам - нельзя
https://facebook.com/robots.txt
User-agent: *
Disallow: /
Что касается ddg, у него вроде не свой поисковый движок, а какие-то подковёрные непрозрачные соглашения с гуглом. Не удивлюсь, что это проект гугла и цру, прикидывающийся "поисковиком для параноиков", чтобы специально ловить искателей всякой запрещёнки (как tor и signal).
Я получаю новые статьи с Хабра через RSS (из настроенной под себя ленты). Ваш сервис будет фильтровать статьи только с нужных хабов? Если же, например, ваш сервис просто по RSS берет данные с Хабра, тогда не понимаю почему в статье говорится, что RSS - это плохо.
Прочитал статью. Так и не понял, почему конкретно для меня это должно быть лучше RSS.
Прочитал комменты - вероятно речь идет о том, что помогать это должно владельцам вебсайтов. Это сомнитлеьно. К примеру, flickr поддерживает RSS по каждому автору. Авторов, само собой over 100500. Значит нужно полагаться, что куча народа выберет одни и те же фиды (хотя бы с каким-то пересечением). Это сильное допущение.
На всякий случай сходил, зарегистрировался, добавил пару фидов с опросом через 5 минут. Убедился, что в RSS появились новые записи. Полчаса прошло - где я их должен искать? В телеграмме? на вебстраничке?
Вероятно, это какой-то демонстратор технологий без реального интерфейса. тогда сорри.
Много лет в качестве клиента RSS использую почтовый клиент The Bat! (и прямому назначению - почты, конечно, тоже).
Настроек немного, но оно работает, вполне удобно.
Подписки на Хабр, уведомления с каналов Youtube и т.д.
Почему не RSS?