from HTYP, the free directory anyone can edit if they can prove to me that they're not a spambot
Jump to navigation Jump to search


FeedFerret is a proposal for web-based feed-aggregation software with some additional features not generally found in feed aggregators:

  • the ability for users to comment on feed items
  • the ability for users to categorize/tag feed items
  • the ability to see what comments others have left on items, and respond to those comments in a threaded way
  • the ability to export the commentary in a format which the original sources could incorporate in their on-site comments (like trackbacks)

The basic design of FeedFerret will be platform-agnostic (any device could be a node); the only component which must be specified in detail is the data exchange format.

Since that is the key piece, it should use existing open formats as much as possible (starting with RSS/Atom), and where necessary extend an existing format rather than creating a completely new one.

With the addition of a blogging feature, FeedFerret would then be one core component of a distributed social network.


Although any device could be a node, I will be focusing on web servers initially as the fastest way to start creating a network.

Since MediaWiki is what I know, I'm going to develop my prototype as a MediaWiki extension -- but the concept should be platform-independent (as explained above).

Software components to be adapted:

  • Extension:RSS: RSS/Atom reader for MediaWiki -- mainly useful as sample RSS/Atom reader code. If it already stores the feed data, then that's a good start, but I think I want it to create a permanent wiki page for each feed item (for a number of reasons), and I doubt it does that.
    • This would be the first of several "feed interface drivers", eventually including drivers for Facebook, Google+, etc. so they can be at least read-only (and maybe writable somehow). Is there an API for G+ yet?

Software components I'm currently hunting down:

  • a MediaWiki hook that will let me periodically poll each RSS feed in turn (I know there is something like this which is triggered, I think, every time a page is viewed, because MW uses it to run jobs in the "job queue").
  • Semantic MediaWiki API. I will probably need to be able to output custom formats for the /talkback and other feeds.

Other stuff to be done:

  • LiquidThreads needs to be callable from non-talk pages. They may be working on this, and they may get to it before I do. Probably their implementation will not be as flexible as what I need. Not sure what I need yet, but it needs to be flexible.


core functionality

  • the core de la core: kernel which accepts massaged feed data and creates properly-formatted wiki pages
    • should also have some functionality to check for duplication -- some formats (RSS/Atom) are prone to this
  • Input plugins for each type of feed we want to be able to receive:
    • RSS/Atom (move this out of core design and into a plugin)
      • adapt Extension:RSS or maybe start fresh with PHP XML functions
        • may need some checking to prevent duplication; desktop feed readers sometimes aren't so good at this
        • should use an editable template, wherein we can specify basic SMW markup for each item
    • Twitter -- adapt from ThinkUp
    • Facebook -- adapt from ThinkUp
    • Google+ -- start with data upload, see if there's an API or a way to page-scrape
    • other microblogs as requested
    • Diaspora?
    • Orkut, Friendster?
  • Unified feed-out for aggregated feeds-in
    • needs to support transfer of media (images, audio, video)
      • recipients may choose whether to copy or link, so media URLs need to be permanent
  • Feed-out for comments and categories
  • On-site blogging, status posting
  • Avatars
  • Visibility and notifications ("circles" in G+speak) -- this needs to be thought through, but the basic idea is:
    • choose who can see your posts
    • choose who may receive notifications of your posts (if they want them)
    • choose whose notifications you want to see

refined functionality

  • types of tags: node-wide, user-specific
    • system for mapping node-wide categories on one site to node-wide categories on individual other sites
  • rating system
  • means of forwarding posts around censorship walls -- if the architecture is done right, any user should be able to post to any node that hasn't actively blocked them, without affecting who receives the post

aesthetics / polish

  • some way for users to choose tags from a list, as well as being able to add their own in a user-friendly way
    • possible types of tags: global, node-wide, and user-specific
  • dynamic user interface (posts and comments appear without entire page reloading)