(no title)
mixcocam | 5 months ago
RSS is just a protocol. You could make a reader now with any algorithm you want that displays feeds. In fact, I can’t imagine that no one is using the AI boom to say they will build a decentralized Twitter using rss plus ai for the algorithm
jasode|5 months ago
Your proposal to filter on the client side where the RSS reader runs can't do what the gp wants: algorithmic suggestions on the _server_ side.
The issue of an AI algorithm applied to client-side-RSS is it's limited to the closed set items of the particular feed(s) that RSS happened to download of whatever websites the user pre-defined in the white-list.
Example of inherent client-side limitation would be how Youtube works:
- a particular Youtube channel about power tools : can use RSS to get a feed of that channel. Then use further customized client filtering (local AI LLM) to ignore any videos that talk about politics instead of tools.
- the Youtube algorithm of suggested and related videos to discover unknown channels or topics : RSS can't subscribe to this so there's no ability to filter on the client side. Either Youtube itself would have to offer a "Suggested Videos as RSS feed" -- which it doesn't -- or -- a 3rd party SaaS website has to constantly scrape millions of Youtube videos and then offer it as a RSS feed. That's not realistic as Google would ban that 3rd-party scraper but let's pretend it was allowed... getting millions of XML records to filter it client-side to throw away 99% of it is not ideal. So you're still back to filtering it on the server side to make the RSS feed managable.
In the "explore-vs-exploit" framework, the "explore" phase is more efficiently accomplished with server-side algorithms. The "exploit" phase is where RSS can be used.
- "explore" : use https://youtube.com and its server-side algorithms to navigate billions of videos to find new topics and content creators. Then add interesting channel to RSS whitelist.
- "exploit" : use RSS to get updates of a particular channel
EvanAnderson|5 months ago
I thought about this problem a long time ago but never did anything substantive with it. I guess I'll articulate it here, off-the-cuff:
People used to post a "blogroll" (and sometimes an OPML file) to their personal blogs describing feeds they followed. That was one way to do decentralized recommendations, albeit manually since there was no well-known URL convention for publishing OPML files. If there was a well-known URL convention for publishing OPML files a client could build a recommendation graph. That would be neat but would only provide feed-level recommendation. Article-level recommendation would be cooler.
One of the various federated/decentralized/whatever-Bluesky-is "modern" re-implementations of Twitter/NNTP could be used to drive article-level recommendations. I could see my feed reader emitting machine-readable recommendation messages based on ratings I give while browsing articles. I would consume these recommendations from others, and then could have lots of fun weighting recommendations based on social graph, algorithmic summary of the article body, etc.
jcgl|5 months ago
To your points about YouTube-style algorithmic discovery, I do agree that that would require the server to do things like you describe. So I think that there could be both client-side and server-side algorithms. In time, who knows? Maybe even some client-server protocol whereby the two could interact.
emschwartz|5 months ago
It also works well for feeds that are too noisy to read through manually, like HN Newest.
https://scour.ing (I’m the developer)