Opening flickr
Friday, June 17th, 2005There seem to be two models of publishing on the internet for individuals: Arranging your own hosting and publishing on your own site, or using a packaged solution and posting on a large, standardised site. In the blog world, we can see both models:
- Movable Type, blosxom and all the home-grown blogging systems out there use the DIY approach.
- LiveJournal embodies the latter model – every blog lives at *.livejournal.com, and (more importantly) all the users commenting in blogs there are registered in a centralised place.
- Blogger et al. sit somewhere between these two – they manage the weblog and comments centrally, but require the user to host it.
With the DIY approach are that you aren’t restricted: Your layout, URL, bandwidth and features are up to you. However, it’s a lot more work to set something like this up.
A huge advantage to the LiveJournal approach is the centrally managed comment system: Because users are known to the LiveJournal system, there is less problematic anonymity than in standalone DIY blog comments. In other words, the users of LJ together form a community rather than the author + peanut gallery imbalance that seems to exist on DIY blogs.
But the LiveJournal model has a flaw, from the user’s perspective – it’s a monopoly. Other sites exist that replicate its functionality (some even using LJ’s code – it’s free software), but LJ has enough user lock-in (I believe the marketing term is ‘stickiness’) that it remains dominant. Good for the owners of LJ, bad for its users.
Wasn’t this supposed to be about flickr?
Yes. I’m getting to that now:
Flickr is in a similar situation to LiveJournal: It’s a centralised system where users upload their photos. But it has an extra challenge – digital photos are really large! They can easily be 1MB each. That’s a challenge for storage on the flickr servers and for bandwidth. So unlike LJ which is essentially free (you can buy a few extra features, but the core set is free), flickr needs to charge users who want to upload more than 20MB a month, or share high resolution versions of their photographs – both common requirements.
I don’t think this is a good candidate for centralisation: Over time, users will want to have thousands of photographs online, but won’t want to keep paying explicitly for this. Why not let them keep those photos wherever they want? To do that (and to allow the same kind of advantages described at the end of the LJ section above), we need to make a decentralised flickr-like system.
Decentralised flickr
Core features that make flickr good:
- Tags – the ability to filter photos from multiple sources according to user-provided keywords
- RSS everywhere – pretty much every flickr page that has updating content can be subscribed to as an RSS feed
- Thumbnails – in certain views where many photos will be displayed, photos appear as small squares, making them easy to browse at-a-glance
- Comments – just like LiveJournal, once users are logged in they can comment on each other’s photos.
I propose the following system:
- Web-based software which displays users’ photographs and descriptions and provides URLs for the photo at a number of different sizes, a title, and tags in a standardised RSS feed. The software could take any form – a simple PHP app which shows photos in a list (like my photoblog), or a big multi-user photo-hosting web site with complex features of its own, or even something that isn’t a web application at all.
- A centralised system which grabs all known RSS feeds, and essentially emulates flickr’s main features. For example, the equivalent of flickr’s latest photos page would be generated by ordering the timestamps on all the latest photos from the RSS feeds available, and generating a page which displays the thumbnails of those images. Importantly, the central system never needs to download or upload these thumbnails – it has a URL for each of them in the RSS data, so merely links to them. In this way, it never inherits the bandwidth or storage challenges of flickr, as each user is hosting the photos herself (or paying another large third party to do so, of course – it’s up to her).
Some nice things about this system are that it doesn’t rely on the central system for much – most RSS feeds that come from just one user can be sourced directly from the user’s own photo system – only those involving tag filtering or multiple users need to be sourced on the centralised system. Also, at least with the features mentioned above, there’s no lock-in – multiple centralised servers can compete on equal footing.
Questions
- How much of the flickr feature set should the central server implement? When you click on a single thumbnail, should you go to the photographer’s own page, or a central page which links to a larger version of the photo, and displays other metadata available from the RSS?
- How should comments be implemented? The simplest way would be to manage users and comments directly on the centralised server – but this brings lock-in back, which is bad. Perhaps a good compromise might be a third-party authentication system of some sort: Photo apps implement their own comment systems, rules, etc, but beat the anonymity issue by verifying users’ identity with a third party. This third party could provide the user’s info as well: URL of avatar, homepage, contact information, signature line, etc. I realise that I haven’t removed centralisation entirely, but I don’t think that’s possible while retaining the advantages of centralised systems like flickr and livejournal.
- Is there a way to implement private and ‘friends only’ features?