Huddle » Blog » Huddle news » The Future of Huddle: Bet on Openness; Build Trust

The Future of Huddle: Bet on Openness; Build Trust

Posted on 31 Mar, 2009 by in Huddle news | 14 comments

I want to take a break from writing about code and spend a bit of time on blue-sky stuff, our approach to standards, and the technologies we want to adopt. I’ll try to keep the jargon to a minimum.

At Huddle we work to a tightly controlled schedule, from a prioritised list of business requirements. A typical business goal might be to improve our calendar, for example, or to make our notification emails easier to read.

Alongside these business goals, we have an overall technical vision. Nobody else in the company knows about it yet, because it’s written on a Rizla packet next to my workstation, but it says Bet on Openness; Build Trust.

I originally started writing about the first part of that warm and fluffy dictum: about how Huddle is building trust with its customers, but it sounded like marketing swill and I had to stop before I made myself poorly – you’ll just have to trust me when I say we’re trustworthy – the first part is far more interesting to write about as a geek.

Huddle.Net is quickly gaining a reputation for being one of the best collaboration tools available on the internet. We want to go a step further than our competitors, and build the best possible *platform* for collaboration, where Huddle.Net is only one client for that platform.

Traditionally, we’ve built new functionality into the website and worried about how we expose it to end-clients later. Now that we’ve managed to get our house in order with respect to extensible security and sane layering for business logic, we want to do things the other way round. In the future, we should build functionality into our API and consume it from our website. This has tangible benefits for scaling our application, because it is trivial to place our service layer on a separate server from the presentation layer, but it has more interesting benefits for our customers.

Firstly, if we’re using our API to offer our service, then you can be certain that we’re looking after it properly. We’ve recently had a couple of glitches in the API, because it’s been a second-class citizen. That will have to change: our APIs are every bit as business critical as our site. More so, even.

Secondly, it will force us to design our APIs in terms of real-world usage. It’s easy to knock out an unusable ball of mud when you’re designing a web service, unless you actually have to write a client for it.

Thirdly, it will mean that if you are paying us to host X Gb of files, and for Y minutes of teleconferencing, then you can consume those quotas from whatever Rube Goldberg contraption you can cook up. It means that cool little apps like AlertThingy will be able to get all the data they need, because ALL our functionality will be exposed. It means that you are free to use Huddle’s services in whatever ways you can dream up, and we’ll help you do so because we’re geeks and get excited about that kind of thing.

The business case for this is clear: we expect that a *very* significant portion of our traffic will come from third parties in the next two years. If we can charge for workspaces and file storage, just as we do now, then there is NO downside to allowing other people to provide services on top of Huddle – more consumers == more subscriptions.

What does that mean in concrete terms?

Okies. So I’m expressly forbidden from guaranteeing anything to anybody, particularly when it comes to the product roadmap: if I say that the Earth is in orbit around the sun, or that we’re going to revamp our calendar, then you *can’t hold me to it* mmmkay? I’m just a programmer. That said, there are some things that we know we want to do. Eventually. No promises.

1) OAuth and OpenID

I’m not a fan of Facebook Connect, because I think it … er… *spits* … in the face of the web community; it’s an atavistic throwback to the bad old days of AOL and MSN, when everyone was building walled gardens, and we were all going to have internet-enabled refrigerators .

We currently work with a few OpenSocial providers, and OAuth their lingua franca for identity provision. If we properly support OAuth then we can drop support for our legacy SOAP API – the one you guys don’t want to know about – and move all the functionality to the RESTful API – the one that you guys can play with.

OAuth will likely be the auth protocol that we use when our website talks to our API, and by using three-legged OAuth, you can plug your own website into our API and build services on top of Huddle in a secure way.

OpenID is of less immediate use to us, but I really like the user experience of Windows CardSpace, and would love to be an early adopter for that framework. Identity management is a key part of building enterprise software, and we need to make it easy for external partners to plug their existing identity data into our application.

2) OpenSocial

We were one of the launch partners for LinkedIn’s OS offering, and we’re putting the final touches on a couple of other projects that are still under wraps. OpenSocial is going to be an important part of our platform moving forward, and is accounting for a large chunk of our traffic.

We’re considering becoming an OpenSocial provider – it wouldn’t be too hard if we get our API layer right, because there’s a fairly simple mapping from our API to the standard OS APIs – this would mean, amongst other things, that you could write your own OpenSocial gadgets and have them display on the Huddle dashboard.

We’re keen to support a proper widget system, because we get a lot of requests for functionality that we simply don’t have time to implement – if we open up the dashboard as an OpenSocial container then you can write whatever funky widgets you like and build them into the site, with full access to your data. There’re obvious security considerations here, but we’ll burn those bridges when we come to them.

3) Synchronisation and open formats

The current version of the Huddle API provides access to data in JSON format because it’s easy to consume from JavaScript. With the next version of our API (watch this space), we want to support proper content negotiation. This will mean that you can download data in a variety of formats. The obvious targets are JSON and XML, but we’d like to open up through AtomPub, too. Using Atom for data feeds gives us some more options for integrating with Live Mesh, and with Google Data and it’s got some nice properties that make it a good fit for our API.

The other major format on our list is iCalendar . I’ve recently been looking at our iCal handler, which we inherited, and looking at the iCal specification to see what we can do better. It turns out that we can do a LOT of things better. In the next few weeks, the development team will stop scheduling meetings in Outlook, and schedule them in Huddle instead. This means developers are free to use Google Calendar, or 30boxes, or iCal to view their tasks and meetings from Huddle. It also means that we’ll have to implement the missing functionality we need ASAP.

We’d like to do bidirectional sync, so that if you add a new meeting into your Google Calendar, then Huddle will pick it up and add it to your Huddle Calendar – I mean, why the hell not? Properly supporting iCal will make it much easier for you to access your Huddle schedule on an iPhone, or on your corporate intranet.

If someone in Huddle creates a new task and assigns it to you, you should be able to view and work with that task in Outlook, or RememberTheMilk or in HiveMinder. This is what we mean when we say “Bet on Openness”.


  1. Nicholas Lovell

    March 31, 2009 at 2:39 pm

    Great to see your thinking, Bob. I can see why you are “expressly forbidden from guaranteeing anything to anybody”, because I’m desperate to know more specifics. I guess I’ll just have to keep watching the blog.

  2. Bob

    March 31, 2009 at 2:47 pm

    Get me drunk enough, Nicholas, and I’ll tell you everything.

  3. Tom Woolway

    March 31, 2009 at 2:57 pm

    Great post Bob, more openness from web companies is definitely the way forward.

    I think OAuth (especially three-legged OAuth) has a little way to go before it is a commonly accepted solution, because my feeling is that it is hard to understand (and maybe trust?) by a non-technical audience. Facebook Connect has done well because people are used to giving Facebook permission to distribute contact details as a side-effect of their application platform.

    Apologies for anything I may have had to do with the SOAP API – dark times! Looking forward to seeing more endpoints added to the REST API – there are a few ideas and integrations I’ve wanted to do but haven’t quite had the methods to support them.

  4. emily_hatchpr

    March 31, 2009 at 4:28 pm

    Can’t say I understood every bit, but on the whole I think it’s fantastic that Huddle is open and open about your openness. x

  5. Bob

    April 1, 2009 at 11:07 am

    @Tom – while I recognise the usability problems with OAuth in its current incarnation, we’re not eager to encourage our clients to share their username and password across multiple websites.

    There’s been a rash of this on teh internets of late, and I think it can only be a bad thing for security. We should teach users to keep their passwords safe.

    Which features would you like to see on the API?

  6. Tom Woolway

    April 2, 2009 at 9:49 am

    Bob, I completely agree with you about people sharing their passwords across multiple sites – especially as it eliminates any control you may have over access restricting other applications using your site/api.

    I think that OAuth will be the way forward, but it needs to be in a form that people can recognise and trust whilst still making them think about whether they want to divulge their personal details. I believe that people are more likely to stop and think about this when they have to enter a password than if they just have to click a page saying ‘Allow’.

    For me, OAuth is a better method than passwords because of the ability to layer app permissions, but the problems with both should be recognised.

    The API methods I’d like to see would be something like ‘get_users_in_huddle’ – at the moment it is fairly easy to build an app for one user but not to build anything to aid collaboration. Please correct me if I’ve missed something in the docs.

  7. Bob

    April 2, 2009 at 9:56 am

    More membership data is coming to an API near you very soon.

    I think we’ll probably support both

    GET /workspace/{wid}/members and
    GET /peers

    where peers returns the list of all people I am working with, where /workspace/members is the list of people in a particular workspace.

    I’m not sure where /peers lives just yet. If we use the intuitive, simple URI then we end up having to inspect headers to work out cacheability, which is a nuisance; otherwise you end up with /users/{my-username}/peers which is possibly better but has more complex security requirements.


  8. sticky

    April 2, 2009 at 10:28 am

    Adding widgets to the Dashboard would be nice to have, and RSS widget being an obvious one. Will we eventually have the ability to add Huddle tasks from outside Huddle? or the abiltiy to add files? This would be useful for us, I could easily see our support system integrating with Huddle and generating Huddle tasks.

  9. babul

    April 2, 2009 at 3:37 pm

    Another great blog post Bob. Agree with almost all of what you said and as per comments above.

    Will definitely need to make a trip to London on a DrinkTank night and also get more details first hand like Nicholas ;)

  10. Tom Woolway

    April 3, 2009 at 12:36 pm

    @Bob Those new methods sound great. Basically, as you say in the post, it would be great to do anything that you can do on the site through the API, but appreciate the hard work!

  11. bob

    April 6, 2009 at 12:39 pm

    @Sticky You will be able to create an assign tasks from the API in the next few months (with the usual caveats).

    You can currently add files through the API, and we’ll be overhauling the whole upload process to make it much slicker in the near future (ditto).

    Andy is hassling me about an RSS widget, I’m sketching something out in my head, but it’ll have to wait until I’ve got a free weekend ;)

  12. vince stevenson

    May 7, 2009 at 1:22 pm

    I used to be really into code development but these days I much prefer to work with people. Thanks for all the hard work. I know how much work and midnight oil goes into producing an excellent product. Rgds Vince

  13. Andrew J Scott

    May 7, 2009 at 3:48 pm

    Sounds sound to me – utilising our own API for our own service is exactly what we’ve done from scratch with Rummble mobile clients – the first being Rummble for iPhone.

    If our partners have problems, so do we! That means, as you rightly say, hopefully nobody ends up a second class citizen….

    Here here.

  14. Bill Bartmann

    September 1, 2009 at 11:02 pm

    Cool site, love the info.

Join the discussion