"Sick of popping open a link to the original item in Google Reader and seeing people's dumb feedburner parameters on the end of the link? Automatically removes those." I know you don't care, but I use IRC. Also, I like URL hashes to actually be useful. Shame Chrome's not my primary, though.

I never use the homepage, which is handy, because it's just got worse. Do I look like I care about related posts on Twitter? I'm more likely to want a from-my-network filtered view of hot news. Also, non-ASCII in the URL? As Tom says, " they can't even write an urlslug generator what are they doing writing a bookmarks site?" Sigh.

Why Tom Taylor doesn't care about URL shortening, and other thoughts.

Les Orchard on the speed of rev-canonical's spread amongst the alpha geeks, the fact that it's not consumer ready yet, and... oh, just go and read it, ok? (I think I'm now also convinced by the choice of rev not rel="shortened" or similar, though.)

In which I note that flic.kr/blech works, and kellan notes that it's not supported (yet) but works for now. Also, discussion on the UI to make the short form URL useful to people who don't write code on bank holidays for fun.

kellan explains the base 58 encoding used for turning a photo ID into the hash used in the flic.kr/p/hash/ short form URL for a Flickr page (which might, hopefully, see people using Flickr instead of Twitpic when doing short status updates).

Ben Goldacre on the susceptibility of badly-hacked newspaper CMSes to prank URLs, something I've been doing (mainly to get them a bit shorter) for a while now. The really baffling thing to me is that, after the stories get passed around with a joke URL, they take them down, killing both the original and the gag. Of course, they never fix the underlying problem, which is that they have awful codebases and care too much about bad search engine "optimisation".

I can't live on an IRC channel without a bot to read out URL titles these days. How handy, then, that this is already written for me.

From Zeldman's comments, discussing the thinking behind a well-designed personal deeply aggregated site, pulling content from the usual suspects as well. Another example of verb-based URL design on a content site, too.

"Their jobs page is omniti.com/is/hiring. A client page is omniti.com/helps/ning." Interesting design for URLs, although I wonder how much it's inspired by the Rails conventions for routing. It seems to work, anyway.

Not exactly a groundbreaking observation ("good URLs are hackable"), but it's nice to see people thinking about them. I mention the del.icio.us tag navigation, as it's an interesting (failed?) experiment in the field.

Piers Cawley on returning URLs in RESTful APIs. I think generally he's right but I wonder if there are cases where the individual bits are better.

The first of a series (of two?) posts about the new Flickr places feature (which is also cropping up repeatedly at the API level with flickr.places API calls)

"Within a few minutes, I realised that I needed something like URI.pm, in order to resolve URIs into an absolute form." Could be useful for Zimki stuff (and indeed Mark's already looking at it).

See also: /photos/tags/interesting/interesting /photos/tags/tags/interesting/ and finish up with /photos/tags/clusters/interesting/ vs /photos/tags/interesting/clusters/