[HN Gopher] Unsung heroes: Flickr's URLs scheme
___________________________________________________________________
Unsung heroes: Flickr's URLs scheme
Author : onli
Score : 254 points
Date : 2026-02-21 13:36 UTC (3 days ago)
(HTM) web link (unsung.aresluna.org)
(TXT) w3m dump (unsung.aresluna.org)
| Tepix wrote:
| Concise URLs deserve more praise.
|
| Also, when you look at a site and see URLs like
| /wiki/index.php/MyPage it tells you about the skill level and
| care of the site administrators.
| theshrike79 wrote:
| And a bit about the skill of whoever made the wiki software,
| they need better documentation and automation to help even
| less-skilled admins to have clean URLs
| flexagoon wrote:
| They do have a guide for it
|
| https://www.mediawiki.org/wiki/Manual:Short_URL
| DoctorOW wrote:
| Ironically XWiki doesn't use their own short URLs: https://
| www.xwiki.org/xwiki/bin/view/Documentation/AdminGuid...
| akares wrote:
| However, getting rid of the /photos prefix would be a terrible
| improvement.
|
| Having the /{username} at the root of the routing logic means
| that every URL should either query the user database for a match
| or use /{username} as a catch-all fallback if no other patterns
| match. But this makes resolving real 404 pages much more
| expensive.
| dcminter wrote:
| If you delete the photos path element they do actually have a
| fallback resolver that redirects you to the appropriate path
| under photos.
|
| E.g. flickr.com/mwichary/sets/72177720330077904 does take you
| to flickr.com/photos/mwichary/sets/72177720330077904
| outofmyshed wrote:
| The shift from URLs accessing resources on file systems to more
| abstract resources (implicitly HTML unless the headers said
| otherwise) occurred around 1999/2000. Suddenly we were all doing
| it once we'd figured out the necessary Apache directives. It
| wasn't just Flickr, although it and its APIs were a good example
| of clean URL design
| socalgal2 wrote:
| > I would also try to add a human-readable slug at the end,
| because...
|
| No? Because what would it be based on and if you edited the thing
| that it's based on then the URL would either change, or get out
| of sync which woudl suck. You could ignore the suffix meaning
| flickr.com/mwichary/sets/72177720330077904-<everything-past-the-
| previous-dash-is-ignored> I'm not sure if that would be a
| positive, although I guess S.O. does something like that. The
| issue is other sites really want to know if it's a link to the
| same resource or a different resource. And while you could
| redirect to the new one that just makes more work for everyone.
|
| > I would get rid of /photos
|
| I wouldn't because then you'd had have
| https://flickr.com/settings but that would not be a user named
| "settings" and the same for every other alternate purpose URL
| KomoD wrote:
| > You could ignore the suffix meaning
| flickr.com/mwichary/sets/72177720330077904-<everything-past-
| the-previous-dash-is-ignored> I'm not sure if that would be a
| positive, although I guess S.O. does something like that.
|
| That's usually how people do it.
| onli wrote:
| Yes, I saw that multiple times in blog engines, with the
| entry title being the optional part.
| dylan604 wrote:
| I've seen these types of things break because of characters
| used after the dash separator would be deemed illegal by some
| part of the chain. However, if you delete everything after
| the separator just leaving the ID, the page would load. So
| some URL parser is choking because someone forgot to encode
| the URL somewhere upstream.
|
| Just another reason to say who cares to human readable bits
| in the location. Most browsers hide that data anyways.
| shakna wrote:
| > The issue is other sites really want to know if it's a link
| to the same resource or a different resource.
|
| Thats what the canonical link is for, isn't it? [0]
|
| RFC 6596 introduced it in 2012. Other websites, like search
| engines or social media, have been using it for a while.
|
| [0] https://developers.google.com/search/docs/crawling-
| indexing/...
| socalgal2 wrote:
| Yes, and? That's a boil the ocean solution. Every app and
| site needs to look up urls and update where as they didn't
| before.
| Macuyiko wrote:
| What I typically end up doing is just recalc the slug and see
| if it matches the provided one. If it doesn't redirect to the
| most up to date slug matching the id. Though who knows if those
| old SEO patterns still matter these days...
| croisillon wrote:
| i don't understand the heat under ?&
|
| ?set=2546&pic=8597 is much easier to decipher than /2546/8597
| wiradikusuma wrote:
| From my experience, query param is usually optional, also
| `?foo=1&bar=2` and `?bar=2&foo=1` should open the same page.
| fshr wrote:
| If it's a permanent reference to a record wouldn't
| /sets/2546/pics/8597 make more sense?
| sixeyes wrote:
| oh yeah i remember as a kid into webdev and php how some sites
| would have these CLEAN urls. seemed like magic to me.
| KomoD wrote:
| > Alternatively, I would consider getting rid of numerical ids
| altogether and relying on name alone. Internet Archive does it at
| e.g. archive.org/details/leroy-lettering-sets, but that has some
| serious limitations that are not hard to imagine
|
| They don't rely on title alone, it's a separate identifier. You
| can set it to anything and you can't change it afterwards but you
| can change the title.
| steerpike wrote:
| Flickr deserves a lot of praise for a number of technical
| advances that I wish had seen wider adoption. Their API was one
| of the first and honestly still one of the most enjoyable to
| actually use as a developer. It's still full of incredibly
| interesting API calls that you wouldn't expect from it unless you
| read carefully. Did you know, for example, that flickr API will
| provide you with the bounding box co-ordinates of different types
| of places? From a neighbourhood all the way up to a continent?
|
| They implemented the Where On Earth ID (WOEID) which was a super
| useful way of disambiguating different places that shared
| latitude and longitude (for example, being able to disambiguate
| the Sydney Opera House, Circular Quay and Sydney Harbour which
| all can potentially share the same lat/long co-ords).
|
| They implemented machine tags which are tags in the form of -
|
| namespace:predicate=value
|
| Which, when it was implemented by _other_ sites with machine tags
| allowed you to get and group all kinds of interesting
| combinations of content.
|
| Yeah, honestly flickr had some _incredible_ tech the was so much
| fun to explore and use. That their vision of what the web could
| be wasn 't the one that won is one of the great losses of the web
| IMO.
| mv4 wrote:
| They were also publicly in "beta" for a few years, which
| provided a great example that it was okay to roll out
| experimental features to the public.
| mv4 wrote:
| Don't forget their "interestingness" algorithm that would
| determine which photos get to the top position in groups and
| other shares views. Way before ML ranking.
| lich_king wrote:
| Funnily enough, I think it was also one of the early warnings
| of what's coming. The problem with the Flickr algorithm was
| that it ended up promoting a very predictable style of photos
| - mostly HDR landscapes - which in turn encouraged more
| photographers to emulate it. In its early years, it was a
| fantastic place to learn photography. In the "final" years,
| it was extremely homogenous and, frankly, boring.
| mv4 wrote:
| Yes, I remember gaming the algo to get to the top page! HDR
| was much harder to produce back then lol
| est wrote:
| > Flickr deserves a lot of praise for a number of technical
| advances that I wish had seen wider adoption.
|
| Flickr + MechanicalTurk == ImageNet
|
| The priceless legacy of Web 2.0 golden age
| amadeuspagel wrote:
| > (Alternatively, I would consider getting rid of numerical ids
| altogether and relying on name alone. Internet Archive does it at
| e.g. archive.org/details/leroy-lettering-sets, but that has some
| serious limitations that are not hard to imagine.)
|
| I could try to imagine these limitations and how the Internet
| Archive overcomes them, but I'd prefer reading about it.
| Springtime wrote:
| I'm always surprised that archive.org's URL scheme is still
| used. To this day uploads will have URLs like `/details/hey`
| and IIRC the only thing to distinguish them from other
| submissions with matching names is the auto appending of a
| digit. It feels like `New Folder (1)` for URLs.
|
| Edit: I misremembered. They append the date to the URL to avoid
| name conflicts, like `/details/hey_20260122`.
|
| I think Youtube got it right early. Make it short enough but
| random, so users won't be tempted to manually type it out and
| make mistakes but if they _really_ do need to manually type it
| the length is reasonable. It also made sharing via SMS /Twitter
| limits more feasible.
| Markoff wrote:
| TIL Flickr still exists
|
| Stopped caring about them when they cancelled their 1TB free
| storage after 5 years, company which can't be trusted long term
| with your data. Plus the UI was horrible anyway.
| lucketone wrote:
| Free storage expectation registered
| secretsatan wrote:
| I've gone back to flickr for my photo sharing, I've had a pro
| account for, checks account, oh jeez, 20 years. I stopped using
| facebook and meta, and it's a solid photo sharing service. I can
| send links and people just get the photos, imagine that!, no ads,
| clean interface, lovely.
| karel-3d wrote:
| In one of their transitions, they seemed to somehow deleted
| most of my photos. I don't know which one exactly, maybe it's
| my fault somehow.
|
| I just know I didn't log in for 10+ years and now when I do,
| most of my photos are gone. Oh well
| alias_neo wrote:
| They're also holding the photos that are left hostage; unless
| you pay them, you can't download the photos you have left
| there.
| karel-3d wrote:
| I thought it's that and they have them behind a paywall but
| no - they just somehow don't have them
|
| maybe I will check again
|
| edit: yep they have only my latest 50 photos (from 2014).
|
| edit2: ah they did that in 2024 apparently. oh well
| whatever.
| NKosmatos wrote:
| I agree 100% with the author, clean, easily readable and well
| structured URLs make the web a better place. URL is a
| hierarchical structure as introduced in the RFC1738 by a guy you
| might have heard, Tim Berners-Lee, the inventor of the World Wide
| Web :-) https://www.rfc-editor.org/rfc/rfc1738
|
| Easily readable URLs is something I learned in the 90s and I
| still try to enforce in everything I create.
| noduerme wrote:
| I'm a big fan of writing little bits of code into my URL
| routers that check for pages and try to correct typos. So if
| someone types https://some-awesome-site.org/jhon-davisdon it
| will check and correct it to /john-davidson. What's nice is
| always delivering the "canonical" link rel when you serve the
| correct page that way, too. I make the assumption that people
| still try to type links, sometimes ;)
| xnx wrote:
| Sounds like mod_speling for Apache:
| https://httpd.apache.org/docs/current/mod/mod_speling.html
| noduerme wrote:
| Hah. Cool. Similar. But I implement it usually by having
| the whole page hierarchy in a SQL table and using
| wildcards.
| tclancy wrote:
| This was a big thing around the time of Flickr and, if my
| memory is still working, del.icio.us. There was a push for "url
| is the new command line" which I wish had gotten more traction
| because there were some fun things happening. I feel like Yahoo
| Labs was involved in a lot of it, including Pipes and their
| ahead of its time JavaScript framework. It's a strange sliding
| doors moment for me because I turned down a job there right
| around this time.
| benterix wrote:
| Unfortunately things are going in the opposite direction with
| media platforms creating an encoded blob impossible to edit by
| hand so that you (or a tool) cannot strip tracking etc.
| nkrisc wrote:
| Isn't the /photos kind of necessary since usernames are UGC? What
| if a username is "about" or "contact"?
|
| I would be very confused if flickr.com/contact went to a user
| page.
| dgl wrote:
| GitHub manage to do it. Most URLs you'd think of are either
| redirects to other bits of the site, or accounts owned by
| GitHub themselves. It just takes a bit of planning.
| deaux wrote:
| > It just takes a bit of planning.
|
| Haha, no it just takes forcing user account name changes.
|
| github.com/copilot, github.com/claude, github.com/models,
| basically everything you can think of for the last few years
| has been through this approach.
| stavros wrote:
| "Hey, remember the username you've had for twenty years?
| Yeah we want it now"
| account42 wrote:
| It's what you get for being a tenant rather than owning
| your own site.
| stavros wrote:
| And yet it's worth it for the network effects, sadly.
| These companies should be regulated, the moats are just
| too deep.
|
| I like that the EU recognised this and did start to
| regulate that these companies need to interoperate.
| efilife wrote:
| I wonder how they prompted these users to change their
| usernames. Was it just a "we need your username for our
| business, so comply" notice?
|
| https://web.archive.org/web/20210702114132/github.com/copil
| o... some proof this was an actual user
| varun_ch wrote:
| Looks like he's now https://github.com/ogcopilot
| varun_ch wrote:
| Some more discussion on similar things:
| https://news.ycombinator.com/item?id=38380344
| nkrisc wrote:
| You can plan every "top level" path you'll ever want on the
| site from now until forever? Or do you mean planning as in
| plan to force account name changes on users when someone's
| username conflicts with a new feature name?
| account42 wrote:
| You could probably get away with banning all common english
| words as usernames if you wanted to.
| nkrisc wrote:
| Or put all user pages under some top level path and then
| you never need to ban anything as this problem becomes
| completely moot.
| teddyh wrote:
| Even if you don't ban _all_ words, there are some you
| _should_ filter:
|
| * <https://ldpreload.com/blog/names-to-reserve>
|
| * <https://xkcd.com/1963/>
| plutaniano wrote:
| I really like tiktok's solution to this problem. Every user
| page is prefixed with a @-sign.
|
| tiktok.com/@about
|
| vs
|
| tiktok.com/about
| account42 wrote:
| This has been around for way longer than tiktok but with ~
| instead of @.
| reddalo wrote:
| I wonder why we left ~ for @.
|
| Maybe become some foreign keyboard layouts don't have the ~
| symbol?
| andrewshadura wrote:
| Wikipedia claims it was invented as an ad-hoc convention
| by some Twitter users, and eventually it became so
| popular Twitter started turning @username into links.
| syncsynchalt wrote:
| The ~ character for home directories was an old
| convention that dates from the ADM-3A (1976) terminal
| used by some early Unix users. The keyboard on that
| terminal happened to have the cursor control word "Home"
| on the "~" key. This shorthand was adopted by shells like
| sh/csh and emerged in HTTP urls as /~user/ being the
| shorthand for a user's personal web page on a site.
|
| Much later in history Twitter popularized the form
| "@user" to refer to a personal identity. I'm not sure if
| they invented the usage or not. This is distinct, but
| probably somehow cognitively related, to the use of
| "user@host" for email addresses after bang paths fell out
| of favor.
|
| For reasons I can't quite put my finger on @user seems a
| much better sigil than ~user to me, so I'm not bothered
| that it's become popular.
| varun_ch wrote:
| It makes sense in a chatroom if you direct a message
| @someone (at someone), or if you direct a tweet @someone.
| So I guess the natural progression of that is @someone
| becoming the identifier.
| giantrobot wrote:
| > For reasons I can't quite put my finger on @user seems
| a much better sigil than ~user to me, so I'm not bothered
| that it's become popular.
|
| I think this makes sense if you pronounce the action. On
| Twitter you'd tweet [at] user(s). I think it made even
| more sense back in the Twitter via SMS where you had to
| send a message _to_ Twitter 's number but direct _at_ a
| particular user.
| reddalo wrote:
| YouTube had the same problem.
|
| The oldest account have a direct URL in the form of
| youtube.com/username. Newer account had
| youtube.com/user/username (I think most account have both
| URLs).
|
| Then YouTube was bought by Google and they introduced
| "channels", so some channels had youtube.com/channel/username.
|
| Then YouTube wanted to become like TikTok and they forced at-
| usernames some years ago, so now accounts have a URL like
| youtube.com/@username
| arcfour wrote:
| I remember signing up for an AI inference provider, noticing my
| profile page was "/<username>" and changing my name to logout
| which worked but caused some amusing errors. Oops!
| DonHopkins wrote:
| Aww, they finally depreciated the .gne file extension? It was
| supposed to never end!
|
| https://gamicus.fandom.com/wiki/Game_Neverending
| antonyh wrote:
| Flickr was a hero, then yahoo/smugmug killed it. It's still
| there, but along the way all changes reduced it to an also-ran.
| It's still a nice tool, but I just don't see myself using it
| again. The URL scheme, as neat as it was, I never noticed or
| cared to hack at. I just wanted to upload photos.
| embedding-shape wrote:
| > I just wanted to upload photos.
|
| Flickr is an unsung hero in this. I uploaded photos back in
| 2011 when I purchased my first DLSR camera, and had forgotten
| about them until this day, and seems they're still up! Did some
| other checks for content I uploaded back then, and seemingly
| only my YouTube and Vimeo videos are still up, everything else
| I spot checked from the same period seems to be gone by now.
|
| Kind of neat for a free photo hosting platform.
| dewey wrote:
| > then yahoo/smugmug killed it
|
| I understand the Yahoo part, but what do you mean with smugmug?
| My impression was that they bought it and "revived" it but I
| might misremember the history there.
| tclancy wrote:
| They bought it but the revival was just the corpse moving
| around from heavy handed cpr attempts. It still lives thanks
| to the guy from Pinboard, but only as an archive really.
| dewey wrote:
| Are you confusing Flickr with Delicious (Which was what
| Pinboard guy bought from Yahoo) or am I missing something?
| kome wrote:
| you are confused :) you are thinking about del.icio.us
|
| flickr is alive and well
| antonyh wrote:
| Revived might be too strong a word, it's still a shadow of
| what it used to be. Besides, wasn't it Smugmug that
| introduced the 1000 photo limit for free users? I too could
| be misremembering here.
| dewey wrote:
| I'd say that's hardly the fault of the acquisition but more
| the change of the landscape for photo communities. Everyone
| moved to Instagram and online storage space alone isn't
| such a big selling point any more as everyone has their
| image in Google Photos / iCloud already.
|
| That's like saying Tumblr/MySpace got ruined by
| acquisitions, in reality people just moved on to other
| platforms like it always happens with social networks over
| time.
| tristor wrote:
| > I just wanted to upload photos.
|
| You can absolutely still do this. I'm still a Flickr Pro
| subscriber since 2015, and I still regularly upload photos to
| Flickr. I don't think there was a set of changes that reduced
| Flickr to an also-ran, the entire market shifted. First, there
| was a shift away from photography being focused on what I will
| short hand as "quality" towards being focused on what I'll
| short hand as "moments" with services like Instagram, which had
| 100m users by the end of 2013 and continued growing
| exponentially from there, which was deeply interconnected with
| the introduction of reliable fairly high-quality phone cameras
| built into smart phones.
|
| Flickr was, and continues to be, a place where people who use
| actual camera equipment post photos that are taken not just to
| capture a moment, but to express a scene, using technique and
| artistry to do so. That type of high quality photography
| doesn't really get much traction in more contemporary social
| media, because the photos of moments shared on Instagram
| weren't about the photo, they were about the moment. It was
| about proving that you were in a place or experienced a thing,
| and the place or thing giving you social value. "Pics or it
| didn't happen."
|
| Instagram has now largely been supplanted by TikTok, because
| short video is now much more of a common, engaging, and desired
| format than photography, and thankfully this means Flickr in
| 2026 is once again a refuge of die-hard photographers sharing
| their works, and not seeing much attempt to change it into
| Instagram 2.0. Many (maybe most) of the photos on Flickr are
| now taken with smartphones, but there is still an expectation
| from the community to focus on expressing a scene using
| technique and artistry, and modern smartphones now have good
| enough cameras to do just that without detracting from what
| you're trying to express.
| TrackerFF wrote:
| I don't know how much Flickr is used these days, but I remember
| it was quite popular some 15 years ago. I decided to search
| around, and discovered that it is a treasure trove of photos from
| the period 2005 - 2015, and incredibly easy to search / filter.
|
| Internet archeology is something I've always found fascinating,
| and I don't think people realize how much data has been lost
| after we moved to the modern "big tech" internet of today. So
| many data hosting services disappear back in the mid/late 00s,
| and with that, the data too. After social media exploded, many
| just stared storing all their photos there.
| eloisius wrote:
| It still has plenty of active users (myself included) but it
| feels much smaller than the 2010s. The groups are great if you
| can find ones that match your taste, and it's way more fun to
| do that and share you photos with human-curated communities
| than with the algorithmic feed.
| jaffa2 wrote:
| from the article : > This might seem silly. The user interface of
| URLs? Who types in or edits URLs by hand? But keyboards are still
| the most efficient entry device.
|
| Can someone let Apple know this ? Safari URL bar is a disaster.
| If I edit a URL say to remove a part and hit enter 9/10 times it
| searches the internet.
|
| It seems to forget that it's a url it's displaying despite it
| cutting the front off, even after telling it to use long urls in
| address bar. It's so annyoing I actually use another browser
| since I often need to paste in or modify urls for the work I do.
| Safari sucks hard. Any solutions to disabling 'search' in the
| address bar ? I want it to be a URL bar only, and anythign typed
| in it should be resolved and not searched.
| koiueo wrote:
| You can let Apple know by not buying their products
| tenpa0000 wrote:
| The flip side is enumerable IDs. Back when I was scraping a site
| for a side project, sequential photo IDs were basically a free
| sitemap. YouTube's random-ish IDs aren't just branding -- they at
| least make bulk harvesting annoying.
| jeffbee wrote:
| You cannot afford to "bulk harvest" YouTube.
| Yolopix wrote:
| Bulk harvesting doesn't necessarily mean downloading every
| video, there is still useful metadata. But in this case non-
| enumerable IDs are on purpose, it would defeat the "unlisted
| video" system.
| thesuitonym wrote:
| I thought Photobucket did it better, with the exception of having
| to know which server an individual's bucket was on.
|
| It's been a long while, but if I recall, the url schema was
| something like a00.photobucket.com/albums/username/someimage.jpg
|
| But what was really cool about it was that you could change
| someimage.jpg to someimage.png and Photobucket would serve a PNG
| instead. Or you could change someimage.jpg to th_someimage.jpg
| and Photobucket would serve a thumbnail of the picture. It was
| very cool.
| dylan604 wrote:
| I use a couple of JS libraries to serve image galleries, and
| they conform to the Flickr _[a-z] type of naming to indicate
| resolution. The library will load the appropriate size based on
| the available real estate.
|
| The auto serving of the chosen output extension is interesting.
| Wonder if they were automatically created when making the
| various image sizes, or only on the first time it was
| requested. And how many formats were supported? The one that
| got me was hitting an API and tagging with xml|json to get the
| response as needed instead of sending it as a dedicated query
| paramter
| dizlexic wrote:
| > No parameters with their unpleasant ?&= syntax.
|
| I'm sorry what? URL params are just a thing.
| briandoll wrote:
| Good post on URL design (GitHub design team):
| https://warpspire.com/posts/url-design/
| pwdisswordfishy wrote:
| What's so special about "https:"?
| wackget wrote:
| Strange, because I always remember Flickr having horrible UX. You
| could never just open an image file directly; if you tried,
| Flickr would always redirect you to a page which obscured the
| image behind an invisible layer which obscured pointer events
| such as right-click.
|
| I learned quickly to avoid Flickr links.
| onli wrote:
| Maybe it was like that for a while? But flickr allowed image
| downloads, there was a dropdown in the UI with the available
| sizes for years. And it had an API (+stable URLs) to download
| images.
|
| It's possible they did not allow the way you tried to access
| images directly, to enable control of the downloads for the
| photographer. But I think you misjudged the behaviour back
| then, they were pretty open.
| PpEY4fu85hkQpn wrote:
| I believe that is to prevent hotlinking, which isn't the
| purpose of the service.
| mullingitover wrote:
| Can't say enough good things about flickr. Those people nailed it
| in 2004 (I've been a paying subscriber since their first year)
| and everyone else has been making bad copies ever since. Tagging,
| friends (pretty much inventing social media without any of the
| diabolical dark patterns), full-resolution archival storage, a
| solid API, all over two decades ago. I'm frankly embarrassed for
| things like Instagram, it's like they're not even trying.
___________________________________________________________________
(page generated 2026-02-24 23:01 UTC)