{"id":1302,"date":"2008-10-25T14:47:32","date_gmt":"2008-10-25T21:47:32","guid":{"rendered":"http:\/\/briantroy.com\/blog\/2008\/10\/25\/friendfeed-to-xmpp-bridge-why-how-and-the-plan\/"},"modified":"2008-10-25T14:47:32","modified_gmt":"2008-10-25T21:47:32","slug":"friendfeed-to-xmpp-bridge-why-how-and-the-plan","status":"publish","type":"post","link":"https:\/\/blogarchive.briantroy.com\/index.php\/2008\/10\/25\/friendfeed-to-xmpp-bridge-why-how-and-the-plan\/","title":{"rendered":"FriendFeed to XMPP Bridge – Why, how and the plan."},"content":{"rendered":"

Yesterday I took about and hour and created a FriendFeed<\/a> to XMPP bridge. The advantage I had was that I was already running a XMPP server and had a working XMPP bot – these existed for my own personal use as well as for cosinity<\/a>.<\/p>\n

Why?<\/p>\n

Primarily this is about information discovery. The ability to participate is challenging (see below) as FriendFeed is an aggregator.<\/p>\n

As I said in an earlier post<\/a> – I believe FriendFeed’s Real-Time functionality is missing two important capabilities.<\/p>\n

    \n
  1. The ability to filter the feed by keyword(s).<\/li>\n
  2. The ability to get real-time for the public timeline.<\/li>\n<\/ol>\n

    While there is nothing I can do about access to the public timeline – I can, via the API, create the ability to filter a feed by keyword(s).<\/p>\n

    Additionally, XMPP is a clean way to distribute the information – so why not have it published via XMPP?<\/p>\n

    How?<\/p>\n

    Since FriendFeed had not released any sample code or a Python\/PHP library for real-time yet I had to modify the existing libraries to support real time. This turned out to be trivial – I simply made a new {fetch_RT} function which looks much like the existing {fetch} function. With that complete I could simply use this modified PHP library to grab a user’s real-time stream.<\/p>\n

    As I mentioned earlier I already had an XMPP server running and had created a bot for other reasons. I simply re-used that bot and the over the network XML API defined by the bot to send the FriendFeed stream out as XMPP messages.<\/p>\n

    There are several important things to note here about the architecture:<\/p>\n

      \n
    1. De-Coupling the FriendFeed real-time processes from the XMPP bot processes is a very efficient model.<\/li>\n
    2. Keeping the XMPP stream bot a “dumb pipe” (i.e., outbound message streaming only) is also very efficient.\n
        \n
      1. Clicking on the link at the front of the XMPP message opens the FriendFeed “conversation” in a browser.<\/li>\n<\/ol>\n<\/li>\n
      2. Since FriendFeed is an aggregator, participation via XMPP will be very problematic.\n
          \n
        1. For Example: If the message is a tweet do you want to reply with a tweet – or comment on the tweet in FriendFeed’s conversation?<\/li>\n
        2. The bot would have to track a large number of variables for each message in order to properly distribute your comment\/message\/etc.<\/li>\n
        3. This overhead would directly affect the ability of the service to scale.<\/li>\n<\/ol>\n<\/li>\n
        4. The scope of the feed (e.g., the apple room or My Home feed or my “the cool people list”) and the keywords for which you’d like an XMPP notification would be configured via a web interface.\n
            \n
          1. This – again – goes directly to keeping the service as scalable as possible.<\/li>\n
          2. The down side is you can’t change scope or keywords via XMPP messages.<\/li>\n
          3. There is the possibility of creating a separate “ffstreamcontrol” bot which would take these commands. It remains to seen if this is really required or a nice to have.<\/li>\n<\/ol>\n<\/li>\n
          4. Since the stream bot acts as a dumb pipe – it can rapidly scale by running multiple instances with the same UID and a different resource string. You won’t know (or care) which bot you are connected to – they all look the same. If one dies – the FriendFeed real-time processes will be programed to try the next one… and the next one… etc.\n
              \n
            1. Again – this is a very efficient model.<\/li>\n
            2. Will provide high levels of redundancy<\/li>\n<\/ol>\n<\/li>\n
            3. The bots will all connect to a dedicated XMPP server – the XMPP messages will then be distributed via XMPP federation.\n
                \n
              1. XMPP federation protocols are very efficient.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n

                The Plan:<\/p>\n

                My current plan is to build something similar to what you see below. The user will create XMPP streams based on scope (i.e., FriendFeed scope – For Example: the Debates 2008 room) and keyword(s). The user will be allowed multiple XMPP streams. All XMPP stream creation, deletion and modification will be done via a web interface.<\/p>\n

                The XMPP bot(s) will serve as a dumb pipe for content delivery.<\/p>\n

                Participation is problematic – and as such will be set aside for now. User’s can still participate by clicking on the link in the XMPP message – this link will open the FriendFeed conversation (here is one for example<\/a>). This will allow the user to participate, subscribe to the user’s involved in the conversation, etc.<\/p>\n

                \"ff.tiff\"<\/p>\n

                Please feel free to comment – let me know if you think this is headed in the right direction.
                \nNOTE: This was written very quickly based on a prototype made yesterday. Please excuse any less than completely thought through concepts… it is a work in progress.<\/p>\n","protected":false},"excerpt":{"rendered":"

                Yesterday I took about and hour and created a FriendFeed to XMPP bridge. The advantage I had was that I was already running a XMPP server and had a working XMPP bot – these existed for my own personal use as well as for cosinity. Why? Primarily this is about information discovery. The ability to… Continue reading FriendFeed to XMPP Bridge – Why, how and the plan.<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4,5,12],"tags":[78,135,158,258],"_links":{"self":[{"href":"https:\/\/blogarchive.briantroy.com\/index.php\/wp-json\/wp\/v2\/posts\/1302"}],"collection":[{"href":"https:\/\/blogarchive.briantroy.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogarchive.briantroy.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogarchive.briantroy.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blogarchive.briantroy.com\/index.php\/wp-json\/wp\/v2\/comments?post=1302"}],"version-history":[{"count":0,"href":"https:\/\/blogarchive.briantroy.com\/index.php\/wp-json\/wp\/v2\/posts\/1302\/revisions"}],"wp:attachment":[{"href":"https:\/\/blogarchive.briantroy.com\/index.php\/wp-json\/wp\/v2\/media?parent=1302"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogarchive.briantroy.com\/index.php\/wp-json\/wp\/v2\/categories?post=1302"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogarchive.briantroy.com\/index.php\/wp-json\/wp\/v2\/tags?post=1302"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}