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."
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.
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.
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.
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?
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.
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.
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).
44 comments
[ 4.0 ms ] story [ 101 ms ] threadThis 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."
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.
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.
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.
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.
Using:
I'm using my own RSS-to-Email service https://feedmail.org but I've also used https://blogtrottr.com/ in the past.
https://gitlab.com/spacecowboy/Feeder https://quiterss.org/
I don't read every entry
I don't hit it every day
But it's what I use