Celebrating Interesting Flickr Technologies

Also their use of AJAX and inline editing was revolutionary - probably created the whole industry around first Bootstrap, then jQuery. Man - spent so much time to emulate that light pastel yellow fade when you edited a title and saved it (later provided by jQuery).

I remember using machine tags Last.fm back, back in the day (late 00s, maybe even 2010). That was still the time of the mashup/remixed web pages, and APIs were more open and you could do very fun stuff crossing Google Maps, Facebook, Craigslist and whatever.

Then, Last.fm was a good site to keep track of the events (concerts/festivals) you were planning to go or you had visited.

Every event had an ID (let's say, 3792998), and you could add photos to Flickr with a machine tag with certain prefix (in this case, the tag would be lastfm:event=3792998). So, when you visited an event on Last.fm, it'd query the Flickr API for photos tagged with that machine tag, and show photos from that concert.

It was cool, but I think Last.fm removed that feature at least 10 years ago...

Here you can still list Flickr photos tagged like that:

https://flickr.com/photos/tags/lastfm:event=*

Edit: Oh, I didn't remember that Flickr would also link back to the Last.fm event. The Internet was quite a different thing back then. Flickr blog post about the feature: https://code.flickr.net/2008/08/28/machine-tags-lastfm-and-r...

In a recent thread talking about Flickr URLs I mentioned a couple of interesting technical features that Flickr had also done that I thought were worth celebrating. When gwern mentions that you should write in more detail about those things I feel you have to take that seriously. This is that attempt.

When I saw the headline I immediately thought of the API, this does a great job explaining its relevance in its time! It’s interesting how even programmers then were trying to learn the concept, but now “API” is common language even nontechnical people generally understand and use in conversation

Excellent post. Very nostalgic. Interoperability as advantage was a thing people loved back then. But the advent of aggregators showed that you’d rapidly just become a commodity. The community that was Facebook would instead be FriendFeed because that aggregated Facebook and others. And then you had to lock it down or die. Interesting times.

On the backend side, Cal Henderson published the details of Flickr's architecture in "Building Scalable Web Sites". It was a reference at the time, the "Designing Data-Intensive Applications" of another generation.

Is it just "machine tags" or was it also tags on the web in general?

I feel Flickr and del.icio.us were the first mass adopters of tags, and everyone else followed, but I'm not sure.

then we have companies that went the opposite way with the abomination called graphql

They didn’t mention feature flags! Their blog post on feature flags was seminal.

Flickr was the first site I saw where you could edit some text on the screen inline, without a complete page reload to get an “edit” form.

Today this is utterly ordinary. At the time, it was remarkable.

They didn’t mention feature flags! Their blog post on feature flags was seminal.

Then, Last.fm was a good site to keep track of the events (concerts/festivals) you were planning to go or you had visited.

It was cool, but I think Last.fm removed that feature at least 10 years ago...

Here you can still list Flickr photos tagged like that:

https://flickr.com/photos/tags/lastfm:event=*

Is it just "machine tags" or was it also tags on the web in general?

I feel Flickr and del.icio.us were the first mass adopters of tags, and everyone else followed, but I'm not sure.

Flickr was the first site I saw where you could edit some text on the screen inline, without a complete page reload to get an “edit” form.

Today this is utterly ordinary. At the time, it was remarkable.

then we have companies that went the opposite way with the abomination called graphql

5 min read

Mar 12, 2026

I’m not a big fan of nostalgia. I view with great suspicion the idea of the supremacy of the past, but it’s hard to look at the web today and think it’s better than what we had once thought was possible.

I recently read a piece praising Flickr’s approach to URL design (discussed on Hacker News). It made me think about some of the technical choices and ideas we saw come out of Flickr that we should celebrate.

There was a period on the web, before the walled gardens rose up, where the focus was more towards the interoperability of content. Flickr at its prime was a powerhouse of innovative and experimental features that put this ideal at the forefront. The things they released were genuinely fun and exciting to use as a developer interested in connecting different corners of the web.

Their API

Flickr’s API was one of the first publicly available APIs that took hold of the imagination of users. They had to explain the concept to us from first principles because we didn’t have the intervening decades of experience using them to understand what the point was.

Yet, decades later, it’s still one of the most enjoyable and (importantly) easy APIs to use. The sandbox example site allows you to test every query or call easily. You can call it from a server or from a client with a JSONP request. It’s full of endpoints that do exactly what you’d expect a photo site to offer even if their method names don’t perfectly line up with modern RESTful APIs. Plus it has a swathe of interesting and unusual functionality that can surprise and delight if you take the time to explore it fully.

Did you know, for example, that it’s possible to send the flickr.places.find a street address and the API will try to resolve that address and provide you the relevant place related information for it. A place in Flickr is one of the following types: neighbourhood, locality, county, region, country or continent. You can use that information to make a call to their flickr.places.getShapeHistory method which will return not just the list of latitude and longitude values to make a detailed polygon of that place. It will also return a value containing the URL for downloadable shapefiles which can be loaded into other GIS software to get incredibly detailed boundaries.

If you’ve ever tried to do anything place related on the web you might recognise what an amazing and useful feature this could be. Users don't think in latitude and longitude; they think in more abstract places. Having a service that thought about that and helped provide a consistent idea of what a place is was a massive help in providing a consistent experience to people wherever they were in the world.

Where on Earth ID (WOEID)

Because photo metadata often included latitude and longitude, Flickr obviously thought a lot about location awareness and identity of place. It's one thing to want to see photos from my recent trip to Sydney, but if I want to view the photos I took near Bradley's Head instead of those photos I took near Bennelong Point that's a more complicated ask. Further, if I want to see my Bradley's Head photos because that's where Taronga Zoo is, and I want to see my Bennelong Point photos because that's where the Opera House is, it becomes even more complicated. As a user I'm not going to want to use specific latitude and longitude coordinates to be able to dig ever deeper into my photo collections.

Flickr’s solution for this problem was to implement something called the Where On Earth ID (WOEID) which tried to attribute unique identifiers to specific features on Earth. This gave a way to disambiguate queries exactly in the way described above by allowing specific WOEIDs to disambiguate between the Opera House, Bennelong Point, Circular Quay, Sydney Harbour and the City of Sydney, all of which could conceivably share overlapping latitude and longitude coordinates.

Machine Tags

One of the biggest challenges with building things that aggregated content from different places was figuring out how to get just the content you cared about and not have the things you were pulling in be irrelevant or confusing for your viewers. One of the major features Flickr introduced to help with this was something called a machine tag. These were perfectly normal tags except they took the form of namespace:predicate=value.

These tags allowed people on Flickr, and even developers on other sites, to get exactly the content they wanted depending on increasingly granular machine tag queries. Machine tags are somewhat confusing to wrap your head around if you haven’t encountered them before, so a few examples might illustrate their use:

Show me all the photos related to the ABC Open Project called Faces
Show me all the photos related to all ABC Open projects
Show me all photos that have been tagged with the predicate [place](https://medium.com/@brightcarvings/flickr.com/photos/tags/*:place=*)

That last one is interesting because it shows us that two different primary namespaces used place (foodspotting, a defunct restaurant app, and the Pleiades project looking to curate photos of ancient cultures and architecture)
The Pleiades project allows us to look at curated photos based on their geographical location in ancient times.
The Pleiades identifier for Lugdunum (now Lyon, France) allows us to use that unique id in the URL to query Flickr for all photos showing artefacts from that location.
Machine tags were powerful and fun on Flickr, but it was their adoption across other sites that allowed some incredible remixing and aggregation of content. It allowed photos of live bands and artists to be tagged with their MusicBrainz identifiers. It allowed event sites to pull in photos for specific events on specific dates. Communities given access to perfectly normal tagging systems have done some extraordinary things. It's a shame we never got to see machine tags reach the same level of adoption and commitment.

It’s a massive testament to Flickr’s remarkable longevity that all of the examples above still work even as the groups, projects, individuals and applications that generated them initially have long since vanished.

I’m not across enough details to speculate on the eventual downfall and failure of Flickr, but as a developer I enjoyed the things it did well, the experiments it tried, and the openness it encouraged. They advocated for a vision of the web as an open and remixable aggregation of personal interests that resonated with me then and continues to resonate with me now. That it wasn’t the vision that won the war of attention is a great shame.

Hacker Times