I just invented this for that.
Even Shorter Syndication [ESS] AND No Nonsense Outline [NNO]
http://go-here.nl/ess-and-nno
Ill try a simplified explanation:
An NNO file is the end result of aggregation that can be used for the next session but is primal intend is publication/sharing.
It it s a comma separated text document that starts with a unix build time followed by a sorted list of items 1) feed url, 2) minutes before build, 3) title checksum
For example:
1503411304088,
http://example.com/rss.xml,223432,27,
http://example2.com/rss.xml,453223,44,
http://example3.com/rss.xml,5432242,125,
http://example4.com/rss.xml,23143231,241
The file is build after the aggregator aggregates the users hundreds, thousands or millions of ESS, RSS and/or Atom subscriptions while reducing the result list by a configured amount. (say 3000)
When published a 2nd user can load the NNO into their aggregator which should fetch the top feed items listed in the NNO until they have a screen full of results. (scrolling loads more)
The 2nd aggregator can then proceed to fetch that users own subscriptions and/or parse additional NNO files into the result set.
When done they can publish their own NNO file to be used the same way.
Ideally the aggregators maintain their own manually unsubscribed feed list and implement a configurable filter like a word and a word combination filter, a Bayes filter, a machine learning implementation or some other filters. The news items displayed should have an indication about their origin (which NNO file) and they could provide an auto translate link or do inline-translation of headlines/articles.
Like you suggested, the point of the entire exercise is to have people access the internet without a multinational man in the middle.
I also coin ESS in the document, it is not required to make NNO work:
An ESS is a tiny comma separated text document with a unxi build date, an url for an RSS or Atom feed then, for each news item, 1) a publication date that is an offset in minutes from the build date and 2) a tiny check sum.
For example:
1503411304088,http://example.com/rss.xml,
0,27,
3600,22,
7890,142,
23421,17
Like RSS is much smaller than the HTML document the ESS is much smaller than the RSS. The example is 71 bytes long. That is considerably smaller than a killobyte.
I would describe the problem with RSS with an analogy with juggling chain saws. :) When you toss the chain into the air it needs to land into your hand at the right moment for you to be able to toss it again.
When you request an RSS feed (or more like x per second) the results arrive with a random offset. The parser at times just sits there waiting for something to do then it is drowned in results arriving all at the same time. If that pile is large enough additional results arrive faster than the old ones can be parsed into the result set. Parsing feeds is not trivial the way it is with ESS. There are multiple formats (RSS and Atom), there can be multiple link elements with different attributes, the pubdate (or updated) has to be dug out and is not a number and lastly the feed can be quite huge.
With ESS you just take a substring (up to the first comma) and compare the number to a desired age or your oldest item.
If you or anyone else is interested in non-corporate technology just for the sake of making things great again feel free to contact me: gdewilde@gmail.com
Thanks,