Comment by jcgl
GGP does express interest in Algorithm-as-a-Service (AaaS), but I don't see why AaaS or server-side anything would be required to have non-chronological feed algorithms. Client-side is perfectly suitable for the near-univeral case where feed servers don't overwhelm the client with spam (in which case you remove the offending server from your feed).
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.
>, 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.