One I wrote myself. I think all the feed readers that look like mail readers or news readers or that show you N boxes with feeds from N blogs are the reason why "nobody uses RSS" and it's telling that people are still making failing RSS readers with the same failing interfaces obsessed with making you ignore items you already saw that failed 20 years ago.
This one is different.
It gathers content through Superfeedr, stores the content in an ArangoDB database, processes it with scikit-learn, huggingface transformers and all that. The user interface is written in Python w/ aiohttp and is all SSRed. It runs as fast as a desktop application, is accessible on my tablet from anywhere through Tailscale, and doesn't have any loading spinners because it is too fast for that.
The primary interface looks like TikTok for text (it shows me one thing at a time that I classify) but there are some other rudimentary screens for viewing lists of classified content. It scores 73% on a metric that TikTok gets 80% on with a very simple model so I feel like I am not doing so bad.
On a good day it ingests 1200 articles, proposes to show me 300, maybe I really see 200.
If there was one glaring deficiency it's that Superfeedr is only cost effective for high volume feeds (say arXiv CS papers or The Guardian newspaper), I couldn't afford to subscribe to 2000 blogs that publish once a week.
There are many directions to improve it but the most interesting ones are to move away from the "non-social social media" use case and towards ones that support "filter 5000 abstracts from PubMed", "filter through a huge number of profiles looking for sales prospects/possible employees/etc."
There's the possibility of a self-hostable source code release, also the possibility of a service, these have their strengths and weaknesses. For the latter I'd probably want to partner up with somebody.
I am not so sure how well it competes with collaborative filtering, if it becomes a service that targets the "anti-social" media market it probably will get some collaborative filtering for better or for worse. For very strong filtering I think it needs both a "popularity" and a "relevance" score the same way Google has PageRank and a relevance score. When I fed it all comments from HN it was really overwhelmed but when I feed it comments with a high score it does remarkably well. Collaborative filtering automatically gets information about popularity, but the content-based approach works better when your topics are obscure.
I also don't know about the market. The smart RSS reader for a broad audience has Twitter Blue pricing (no ads, never) but a similar product aimed at people who sort through a lot of content for a living has more like Salesforce.com pricing. Not to say that you couldn't have plans for each market.
Hard to say. Right now Superfeedr feels like a great value (less than $5/month) with the caveat about low-volume feeds. I think the API to add and remove feeds is silly (wet not dry) but getting updates through a webhook is nice.
If I had a lot of people using it I wouldn't mind a $500/month Superfeedr bill and I know their pricing goes down if I have a lot of feeds and I'm sure they'd love to talk if I was a bigger customer -- but there are all the agency problems that come up when one business depends on another business.
That said, web crawlers, scanners, and things like that were a subject I was interested in in the aught's and the last thing I want to work on now and Superfeedr frees me up to focus on the models and UI now.
Superfeedr also seems completely unmaintained since Medium bought them. The blog is dry, other feed-related projects are frozen, they still don't support newer WebSub standards and the offical Medium hub for Medium blogs doesn't send updates. I suspect that Medium doesn't care about feeds anymore now that they are big so they are doing just enough to keep the current service running.
I wouldn't want to build a service on top of them. But I guess if it does shut down switching to polling youself wouldn't be the hardest thing to do.
Right now there is just one category being trained which is "will I like this?" but this is silly in many ways, particularly throwing arXiv papers and articles about sports and projects from GitHub into one big pot I will never be able to get my numbers up (like AUC) until I divide and conquer into better defined problems.
The data structure I have in mind is something like a "tag" from flickr except that the tag can have a positive, negative or indeterminate (it wants to know what I think and might have a probability score) valence. Thus the tag could be "dog", "not a dog", "is this a dog?" all of which are different from no tag.
There's the need to define some kind of ontology that schedules certain questions to be asked based on the answers to other questions but that's another step.
In the interest of long-term scalability but some short-term pain I want a single system to be able to handle a few "projects" simultaneously, for instance I also like sorting and categorizing images and I might want to look at 5000 abstracts from PubMed that match a query and would like to do all this without making new instances of the system.
My own app concoction, written in Ruby & Sinatra and JS-less at the moment, one of these days going to upgrade and enhance as I wrote it while I was out of work during COVID days. As I age I don't have the energy to keep pace with side projects anymore.
After Google Reader I used Feedly for years, even ponying up for a Pro subscription. But I was forced out as they capped on sub total (even as a Pro customer) and I was unable to add new feeds & the tools to identify and prune "dead" feeds (even there, I treat my RSS pool as a stream to wade in when needed / desired and didn't want to delete even inactive feeds, just feeds that got hijacked by spam farms). So I wrote my own.
Initially had grandiose vision of opening it up to anyone but it needs some UX work 1st (and a better DB model than a SQLite DB on a shared host lol).
If you're going to discuss these things in public, you should be providing a way for people to keep an eye on it, e.g. an RSS feed or an email newsletter.
After a fairly exhausting search of alternatives, I ended up with Newscracker .. it copes well with a large number of feeds, has good capability for classification, and I can tolerate the single ad up front (on about 60% of starts).
Feedly and sadly not feeling it these days. Would like to switch to something self-hosted and open source, but haven't been impressed with what I've tried.
I've setup my instance of FreshRSS, but unless I'm missing something, full-text fetching doesn't come out of the box. Is there a setting or a plugin I'm missing?
TT-RSS (Tiny Tiny RSS). Best thing I've find for my needs. I'm not excited about how they started doing updates a few years ago, but it just keeps on working.
Feedly Classic. Would love to move though since they are doing their best to worsen the service every year. I guess there isn't much money in RSS applications.
This one is different.
It gathers content through Superfeedr, stores the content in an ArangoDB database, processes it with scikit-learn, huggingface transformers and all that. The user interface is written in Python w/ aiohttp and is all SSRed. It runs as fast as a desktop application, is accessible on my tablet from anywhere through Tailscale, and doesn't have any loading spinners because it is too fast for that.
The primary interface looks like TikTok for text (it shows me one thing at a time that I classify) but there are some other rudimentary screens for viewing lists of classified content. It scores 73% on a metric that TikTok gets 80% on with a very simple model so I feel like I am not doing so bad.
On a good day it ingests 1200 articles, proposes to show me 300, maybe I really see 200.
If there was one glaring deficiency it's that Superfeedr is only cost effective for high volume feeds (say arXiv CS papers or The Guardian newspaper), I couldn't afford to subscribe to 2000 blogs that publish once a week.
There are many directions to improve it but the most interesting ones are to move away from the "non-social social media" use case and towards ones that support "filter 5000 abstracts from PubMed", "filter through a huge number of profiles looking for sales prospects/possible employees/etc."