Decentralized social RSS feed / article recommendations could totally happen if the community came up with a standard way to implement it.
Re-posting / paraphrasing a comment I made in a discussion about decentralized recommendation algorithms for RSS feed content:
People used to post a "blogroll" (and sometimes an OPML file) to their personal blogs showing the 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.
OMPL files in well-known locations 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. My feed reader could emit machine-readable recommendation posts based on ratings I give while browsing articles. My feed reader could consume these recommendations from others, and then lots of fun could be had weighting recommendations based on social graph, algorithmic summary of the article body, trustworthiness of the poster, friend-of-friend status, etc.
I thought about some of this stuff back in '05 when I tried to contribute to ttrss. The maintainer didn't have much interest so I dropped it. I've thought about it periodically but never had the initiative to do anything with it.
What if all we need is for bloggers to post a recommended feed with links to external posts in a separate RSS feed? The feed readers ingest the recommendation feeds and count them. I've been following ActivityPub and other protocols, by damn that stuff becomes a mess quick. The absolute simplest approach is probably the right one for now.
The fundamental problem with recommendation engines are the platforms are forcing content on the users based on what increases engagement (and possibly ad $) on their platform -- not what is valuable to the user.
If I'm following a particular blogger, and their signal to noise ratio is 9:1, if they recommend an article it would be vrey likely I am also interested in it. If I'm following a larger group of people, I may be interested, in aggregate, what they are interested in. All very basic stuff that seems to have been abused and forgotten. Other than e-mail, rss is the odd man out in 2025 which also makes it so much more valuable.
Any third party RSS feed service could ingest these feeds and spit out whatever other type of recommended feed they want. The could just view a hn/reddit style feed solely with counts of the people they want to follow along with "vote" counts and some decay algorithm. They could have a chronological feed that just shows everything. The users are in control again, not Meta/Facebook/IG, Reddit, Bytedance, or etc.
Basically linkblogging. I'm not sure this needs to be a separate feed; JSON Feed has a dedicated `external_url` field:
> If `url` [optional] links to where you’re talking about a thing, then `external_url` links to the thing you’re talking about.
I'd be shocked if Atom/RSS didn't have equivalents.
This kind of "repost"-ish behavior may just be obscured in the tools people use to construct feeds, so they remain obscure features of the standards. The designers had syndication in mind, very much like what you're describing — ingesting feeds, reprocessing/mixing/extending them, and exposing the result as another feed.
Using RSS for this seems reasonable for people who already have the ability to host a feed. I was thinking more about the Twitter-alikes for the "normies" who don't have a place to host a feed. I don't just want to see recommendations from bloggers. I'd like to be able to pull recommendations from a wider net of "content consumers" as well as "content creators".
I can't come up with an economic model that would work to run a hosting service for feedreader-generated feeds except in the case of for-profit feedreaders. There's abhorrent models there like, say, peppering the recommendation feeds with "sponsored content", or extracting demographic data from the participants and selling it. Making the recommendation feed a fee-based service also seems like a bad model, too.
That was why I look at the Twitter-alikes for the recommendation feeds-- because the transport is "free" (or, at least, not something where I'd have to worry about the business model).
The RSS spec has the 'source' sub-element, which should point to the original source feed to give credit while forwarding/reposting. I guess one can apply this spec loosely and point it to a webpage url instead of an RSS feed.
Re-posting / paraphrasing a comment I made in a discussion about decentralized recommendation algorithms for RSS feed content:
People used to post a "blogroll" (and sometimes an OPML file) to their personal blogs showing the 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.
OMPL files in well-known locations 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. My feed reader could emit machine-readable recommendation posts based on ratings I give while browsing articles. My feed reader could consume these recommendations from others, and then lots of fun could be had weighting recommendations based on social graph, algorithmic summary of the article body, trustworthiness of the poster, friend-of-friend status, etc.
I thought about some of this stuff back in '05 when I tried to contribute to ttrss. The maintainer didn't have much interest so I dropped it. I've thought about it periodically but never had the initiative to do anything with it.