Archives for category: Flock

Dominique Hazael-Massieux Last week Flock sponsored the W3C Workshop on the Future of Social Networking in Barcelona, and I had the honour of attending on behalf of the company.  The purpose of the 2-day workshop was to help determine what role the W3C should play, if any, in the emerging field of social networking services.  The event was chaired by Dominique Hazael-Massieux and Christine Perey.

About 80 people were in attendance, and 72 position papers were submitted beforehand to help provide some background and context for discussion.  That’s a lot of papers to read.  I got through most of them, but not all, prior to the workshop.  A nice short synopsis of each paper can be found here (and part two).  There was also some ongoing Twitter conversation during the workshop and the #w3csn topic was trending on Twitter for a while.

The breakdown of attendees was roughly one-third academics, one-third mobile industry, and one-third “other” including businesses involved to various degrees in social networking.  Conspicuously absent were representatives from any of the major social network operators; no one from Facebook, MySpace, Twitter, Flickr, etc.  (YouTube and Bebo submitted position papers, but did not give presentations and I didn’t notice them in attendance.  If someone from YouTube or Bebo was actually there, sorry I missed you!)  Geographic representation at the workshop was also predominantly European.

Day 1 – Thursday, January 15th

Presentations and discussion centered around “architectures for social networking”.  Many attendees (and indeed many of the submitted position papers) lamented the current “walled garden” model wherein social network operators are incentivised to closely guard their users, content and media.  Rather than moving towards an SNS monopoly or oligopoly, the SNS landscape is likely to become increasingly fragmented.  Despite the meteoric rise in usage of Facebook and MySpace in the last couple of years, other SNS operators are also seeing considerable growth.  In fact, someone noted that the “long tail” of regional/corporate/special interest social networks accounts for about 500 million users!  (Unfortunately I didn’t catch who said that or where the statistic came from.)  Ultimately, users would be better served by a model that allowed them to have data portability between networks, to manage fragmented identities (by either combining them or keeping them completely disconnected, as desired), and to use different providers for the services and specialties they provide (eg. LinkedIn for resumes, MySpace for music, etc…) without being tied to particular network operators.

There were two concurrent breakout sessions in the morning: one on Distributed Social Networking (which I attended) and the other on Data Mining.

The Distributed Social Networking session had some high quality discussion, but did not result in any concrete recommendations as to potential roles for the W3C.  Some architectures for distributed/decentralized social networking systems were discussed, and it is clear that the barrier to implementation is not a technical one.  Existing data format standards, protocols and APIs such as OpenID, OAuth, OpenSocial, FOAF and XMPP are sufficient to implement such systems, but they don’t address the business forces shaping the walled-garden problem that is the status quo.  That will require business model innovation, rather than technical, and as such isn’t really in the W3C’s realm.

The Data Mining breakout session apparently had more concrete results.  The recommendation was for W3C to define a standardized data interchange format as a harmonization/extension of existing formats such as FOAF, Atom, etc.  There were strong assertions from the academic crowd that RDF is the appropriate way to model social network data, but the idea of using it as an interchange format was generally poopooed due to its complexity.

After lunch, there were concurrent breakout sessions on Privacy and Trust (which I attended), and Distributed Architecture Business Models.

The Privacy and Trust session did not result in any strong recommendations for the W3C’s course of action.  The issue of identity fragmentation (ie., users having multiple profiles on multiple services) was discussed at length.  Some users consider it an inconvenience to manage multiple online identities, whereas others absolutely rely on it to maintain privacy — they don’t ever want their LinkedIn account to be associated with their MySpace account, for example.

The W3C’s existing P3P initiative was mentioned as needing to be extended in order to really be applicable for SNS sites.  Other than that, user education/awareness was cited as the main issue needing to be addressed.  One person said something to the effect of, “Wherever I go, it should be obvious to me what my current privacy and security context is.”

Blaine Cook Blaine Cook (of BT, formerly of Twitter) threw out an interesting idea about using capabilities-based cloud data stores so that users could maintain better access controls over their data, AND the data could not trivially be associated with the user unless they wanted it to be.  Worth some more thought.

The Distributed Architectures and Business Models breakout considered whether there are viable business models for a more distributed/decentralized model of online communities; in other words, can we escape the walled garden paradigm?  There was apparently some disagreement between web and mobile operators in these discussions.  Everyone agreed that selling in a social context has been shown to work.  A sizeable contingent further believe that a widely adopted micropayments system would go a long way towards enabling economies between SNS operators, rather than just within their closed communities.  In response to this, W3C may look at restarting its work on micropayment systems, which has been stagnant for a few years now.

Day 2 – Friday, January 16th

The presentations and most of the discussion on the second day of the workshop centered around the topic of “context and communities”.  That is, enriching social applications and online social interactions with contextual data such as location, relationship, engagement mode, etc.  There was a fair bit of discussion about geolocation and privacy controls for geodata.

Julian Pye Julian Pye of Vodafone gave an interesting presentation (paper, slides) on adapting user interface according to context.  For instance, automatically stemming the flow of friend activity updates according to my relationship with the contact, whether I’m at home, work, or school, on a holiday or a business trip, my proximity to the source, etc.

Simon Hay from the University of Cambridge got more than a few chuckles for his entertaining use of Harry Potter analogies in his presentation (paper, slides) on the use of sensor arrays tied to social networks.  They implemented something akin to the Marauder’s Map, which shows the location of every student on campus (or in the case of UC, just those students who chose to participate) and could notify you if, for example, several of your friends were heading down to the coffee shop.

There was also an interesting side-discussion about the validity of “Dunbar’s number” (usually cited as being 150) as the theoretical cognitive limit on the number of friends one can maintain.  Harry Halpin asserted that this number was fallaciously extrapolated from studies on primate sociology, and that it’s much more useful to think in terms of a graduated scale of 12 intimate friends, 150 frequent contacts, 1500 infrequent contacts and 1,500,00 lifetime contacts as averages for humans.

Outcomes

As mentioned above, suggestions for the W3C’s course of action include:

  • Put forward a recommendation for a data interchange format for social/identity data (as a harmonization/extension of existing data formats such as FOAF, etc.)
  • Look at extending P3P to be more applicable to SNS sites and communities.
  • Look at restarting Micropayments standardization work — there may be more business interest in this now than there was a few years ago.

In addition, Harry Halpin put forward a draft charter for a W3C Social Web Incubator Group to continue discussing standardization of the social web technology stack.

There was also a suggestion that a follow-up workshop be planned in 6 months’ time, probably in North America.

Update 2009-02-03: The official W3C report is now available on their site, and includes a couple of photos by yours truly. :)

Blogged with the Flock Browser

One of my first tasks upon starting at Flock was to design/clean up the XPCOM interfaces we use to represent web service components (Flickr, Facebook, etc.), accounts on those services, and specific APIs implemented by those services. We made great strides in that regard at the end of 2006 and beginning of 2007. Then some cleanup happened over the last two months or so. We now have a pretty workable model as described here.

We’re continuing to refine it, however. What follows are some changes we plan to make on trunk, probably over the course of the next month or so.

Web Service Interfaces
The major changes here are the introduction of flockILoginWebService, a slight reorganization of the inheritance hierarchy, and the elimination of flockIManageableWebService.

  • flockIWebService – Any web service that Flock integrates with. Does not necessarily have to support accounts. All account-related functions would be moved to flockILoginWebService.
    • flockIMediaWebService – A web service that supports the concept of media streams and/or queries.
      • flockIMediaEmbedWebService – A media service for which we support embeddable media (ala the Flock Magic overlay).
    • flockIPeopleWebService – A service that has a concept of “people”, but not necessarily of friends or a social graph. This would replace the current flockIMediaWebService#supportsUsers flag.
    • flockILoginWebService *NEW* – Any service that supports the concept of user accounts. (This would include every service except for Truveo in the current roster.) All account-related methods from the current flockIWebService interface would move to here. This interface would also subsume everything currently in flockIManageableWebService.
      • flockIBlogWebService – A service that supports blogging.
        • flockICustomBlogWebService – Used to support self-hosted blogs.
      • flockIMailWebService – Webmail services.
      • flockIBookmarkWebService – Online bookmarking services.
      • flockISocialWebService – A service with a social graph, wherein users can have friends in the People sidebar, etc. These services will also implement flockIPeopleWebService. (If XPIDL let us do multiple-inheritance then this interface would inherit from flockIPeopleWebService as well. It doesn’t, sadly.)
      • flockIMediaUploadWebService – A service to which users can upload media using Flock’s Uploader. (This interface would also inherit from flockIMediaWebService if possible.)

Account Interfaces
These are basically just being renamed to make them more readable.

  • flockIWebServiceAccount – Can be associated with any flockILoginWebService.
    • flockIBlogAccount – renamed from flockIBlogWebServiceAccount.
    • flockIBookmarkAccount – renamed from flockIBookmarkWebServiceAccount.
    • flockIWebmailAccount – renamed from flockIMailWebServiceAccount.
    • flockIMediaAccount – renamed from flockIMediaWebServiceAccount.
      • flockIMediaUploadAccount – stays the same.
    • flockISocialAccount – renamed from flockISocialWebServiceAccount.

API Interfaces
Web service API implementations should be XPCOM components, but not XPCOM services. This is because we may want multiple instances of them. For instance, both Delicious and Magnolia use the Delicious API. Therefore we should have an instance of flockIDeliciousAPI for each service, so that the API states can be maintained separately.

  • flockIWebServiceAPI *NEW* – defines generic authenticate(), deauthenticate() and call() methods, and an isAuthenticated property.
    • flockIFacebookAPI
    • flockIMovableTypeAPI
    • flockIWordpressAPI
    • flockIDeliciousAPI
    • etc…

Blogged with Flock

Flock is a browser with some unique capabilities, but that also means it has some unique problems to solve as far as browsers go. Core to the Flock experience is the tight integration we provide with various online services — including social, media, blog and bookmarking services.

Many of these services have APIs that we call in order to perform certain tasks, but there are some things we must do without API support… some tasks that require us to examine the actual HTML content of the pages the user is loading up and look for certain patterns. We need to be able to detect when a user logs in to (or out of) a supported service, for example, since some integration features will only work when the user is logged-in. We also need to detect when there are “media streams” available from a given page so that we can allow the user to open them in the media bar.

How do we know if a user is logged in to Service X? Well generally speaking, if you’re logged in to a service then there’s a button or link on the page to allow you to log out. Spotting that button or link is a great clue for the browser to know you’re logged in. If we’re lucky, the button has an id that makes it especially easy to spot, for instance: id=”logoutButton”.

But the thing about web services is that they’re likely to change their HTML at some point. Since that “logoutButton” isn’t part of a published API, there’s nothing to stop Service X from changing it to a link, and perhaps dropping the id attribute. This is a problem for Flock, since it would break our integration. We would no longer be able to detect that the user had logged in to the service, and some Flock functionality would be broken or disabled as a result.

To combat this problem, we have developed a technology called Web Detective. Web Detective lets us specify detection “rules” in an updateable XML file for each service. So if ServiceX ever changes their HTML and breaks Flock’s integration, we can just update the serviceX.xml file and within a few hours Flock users will be running with the new rules and all will be good with the world again.

Here’s documentation on Web Detective and how to understand and write the rules files:
http://developer.flock.com/wiki/Web_Detective

Ideally, the services we support would never change the IDs of key HTML elements (like the example “logoutButton” above), so that Flock’s integration would never break. It’s not really reasonable to expect services to keep the same HTML forever, however. The best case scenario would be if all supported services provided META tags in their HTML HEAD sections on every document. For example:

<meta name=”session-loggedin” content=”y” />
<meta name=”session-userid” content=”JoeUser23″ />

The first tag, “session-loggedin”, would simply have a content of “y” if the user was currently logged in and “n” otherwise. The second tag need only be present if the user is logged in, and would have as content the unique user ID of the logged-in user. For some services this is the same as the username or email addy used to log in, but other services use a separate unique identifier.

If all services supported something along those lines, it would be easy for us to detect and it wouldn’t have to be in danger of breaking when they changed the visual HTML markup on their pages.

Blogged with Flock

Being built upon Mozilla’s Firefox platform means that Flock benefits from all the great work that Mozilla and its contributors have done, and continue to improve. It also means that we have inherited an enormous codebase. Firefox has somewhere in excess of 2 million lines of active code, with over a thousand individual interfaces defined. Flock only adds to that.

Seasoned Flock developers have learned their way around the parts of the code relevant to the components they have worked on, but for a novice the cumulative immensity is overwhelming.

The following diagram highlights some key components and pieces of UI that Flock adds.

[FULL SIZE]

This is not comprehensive, but it pretty closely represents the major components and their relationships as of Flock 0.9, the most recent major release. Of course, the imminent release of 1.0 means that this diagram will soon need to be updated to reflect the new 1.0 features.

Ever-improving documentation for Flock-specific interfaces can be found here:
http://lxr.flock.com/doxygen/flock/trunk/

Blogged with Flock

Flock’s corporate headquarters have always been and will continue to be located in sunny Mountain View, California. Last August, however, the company opened an office in Victoria, BC. (We like to call it Flock North.)

Yesterday Flock was represented at the 2007 Camosun College Capstone Symposium here in Victoria. This annual event gives students in the Computer Systems Technology Program (including our very own Brij Charan) a place to showcase their skills to the local IT industry, potential employers and the general public.

Some clips of our booth were also featured in a local TV new broadcast, as a part of Victoria’s booming tech industry. The new Flock 0.9 beta build gets some air time! The response from those who got to try it out was very positive.

Blogged with Flock