Comment by jasode
>, but I don't see why AaaS or server-side anything would be required to have non-chronological feed algorithms.
You assume gp's idea of "non-chronological" feed means taking the already-small-subset-downloaed-by-RSS and running a client-side algorithm on it to re-order it. I'm not debating this point because this scenario is trivial and probably not what the gp is talking about.
I'm saying gp's idea of "non-chronological" feed (where he emphasized "curation is not the problem") means he wants the huge list of interesting but unknown content filtered down into a smaller manageable list that's curated by some ranking/weights.
The only technically feasible way to do curation/filtering algorithm on the unexplored vastness out on the internet -- trillions of pages and petabytes of content -- is on servers. That's the reasonable motivation for why gp wants Algorithm-as-a-Service. The issue is that the companies wealthy enough to run expensive datacenters to do that curation ... want to serve ads.
Maybe you're right about what they meant. I'll not debate that.
I will say that, for my purposes, I would definitely like an RSS reader that has more dynamic feed presentation. Maybe something that could watch and learn my preferences, taking into account engagement, time of day, and any number of other factors.
What's more, with primarily text-oriented articles, the total number of articles can be extremely high before overwhelming the server or the client. And a sufficiently smart client needn't be shy about discarding articles that the user is unlikely to want to read.