That feels like a false dichotomy. There are many more attitudes then only rudeness and obsequiousness.
That said, FOSS has a big problem with maintainer burn-out. It seems that projects like SQLite demonstrate more sustainable models, such as source-available and a closed group of maintainers who are exposed to limited demands from users.
While I very much appreciate the story, I wish it was written in a more straightforward style. The cross-paragraph callbacks from a Google employee to someone living in a basement... well, that's fine for fiction (although I'd still find it tiring) but for this I found it needlessly difficult to follow.
But maybe that's just me. I appreciate this is a stylistic complaint, so I doubt everyone will agree. Still, for a factual piece that I expected to read more like reportage, I found this article fiddly to process.
(Ah, it’s fun reading through that document a bit again. A few things I’d need to update now, like the Hashids name, or in the UUID section how UUIDv7 is no longer a draft, and of sidenote 12 I moved to India and got married and so took a phone number ending in 65536, replacing my Australian 32768. :-) )
> I would not recommend it to anyone for any purpose
The most likely purpose for this kind of encoding is to discourage users (as in other developers) from trying to derive meaning from the values that is not actually there.
This happens all the time: Another developer using your API observes sequential IDs, for example, and soon they start building their software on top of that observation, assuming it to be an intended property of the system. It even works perfectly for a while... until you want to change your implementation and break those assumptions. Which you now can't do, because breaking users is the cardinal sin of software development, leaving you forever beholden to implementation details that were never intended to leak out. That's not a good place to be. Making the IDs "opaque" indicates to the user that there is no other meaning.
That they are guessable doesn't matter. I dare say it may even be beneficial to be able to easily reverse the strings back into their original form to aid with things like debugging. Software development is primarily about communicating with other people, and using IDs that, at first glance, look random communicates a lot — even if they aren't actually random.
There may be a time and place for actually secure IDs, but more often than not you don't really need them. What you do regularly need, though, especially in large organizations, is a way to effectively work with others who don't read the documentation.
> It’s just bad
This is the first I've heard of Hashids, so I'll take your word for it, but I'm not sure you actually articulated why. I'll grant you that excluding profanity is a stupid need, but it is understandable why one might have to accept that as a necessary feature even if ultimately ridiculous.
I'd never use hashids/sqids for anything secure. It's reversible by design.
However, it is fit for purpose if your purpose is showing user-facing ids that can't be trivially incremented. For example, in a url, or in an api response. It does, in fact, "protect" against the "attack" of "Oh, I see in the url that my id is 19563, I wonder what I get if I change it to 19564.”
Now, the system should absolutely have authorization boundaries around data, but that doesn't mean there's no value in avoiding putting an "attractive nuisance" in front of users.
If it's not a real attack, it's not worth protecting against even in the slightest. If it's a real attack, it doesn't matter if it's trivial or not, does it?
It very much can be worth protecting so that your users don't become dependent on thinking that increment IDs is a feature. It's not a security concern in that context, but it is a future maintainability concern where you don't intend to provide that as a feature in environments where you don't have a tight leash on how users are using your APIs.
Hey Chris, that's a really nice blogpost. Not only the content but also the design / sidenotes. What kind of software stack do you run your block with?
It’s lasted for three years of use and three years of disuse, and I hope to replace it with something utterly different (stylistically and technically) by the end of this year, though it may slip to next year. The replacement will be based on handwriting.
Thanks. I like it very much, perfect dark mode. The serif font could be a tiny bit bigger for readability. Not a fan of handwriting fonts but you do you :-)
(I’m not a fan of handwriting fonts either. They’re never truly satisfying, though some with quite a few variants for each character get past the point of feeling transparently inauthentic. But when you can write and draw what you choose, where you choose, that’s liberating.)
Oh thanks for sharing this. Many years ago I was asked to code such a thing during an interview and I totally screwed it up, and of course I forgot the name of this technique.
I wanted to use it many times in project for non-iteratable IDs but never found it again.
Agreed -- in that I also don't know, and am slightly peeved at the time I spent reading the page, then re-reading it to see if I missed the point, then going to are.na to see what exactly they do, the re-reading that page and still being none the wiser.
They copied a font? Okay, I guess? Yeah licensing yadda yadda. And yeah, doing The Thing for the experience of doing The Thing. But really... talk about burying the lede. The article is not only indistinguishable from parody but comes across as self-congratulatory navel-gazing.
And are.na is... some kinda social snippet/meme sharing? Kinda? Ooookaaaay...?
I don't like being negative, here or anywhere. After all, these are real people doing real stuff, and presumably they're proud of their hard work and could do with a pat on the back just like everyone else. But maaaaan.... I honestly have no idea how it's okay to spend subscribers' money on 'refreshing' a near-ubiquitous font then posting about it in this manner.
So, in the spirit of constructive criticism, I'd suggest ripping out the interviews, replacing it with an article that makes a compelling case about why this was done. Even if it amounts to an art project any artist worth their salt can make an engaging case for what they're doing and why.
But clearly I'm not the target audience. So if font nerds here enjoy this sort of article, I guess there's one reason I'm not a font nerd.
Indeed. I'm a long time Emacs user (emacs-nox in the terminal). After spending a day getting LSP and eglot working, I'm loving the "IDE" experience. Reliable indentation, auto-complete, intelligent var renaming, real-time(ish) warnings and error messages, etc, all the good stuff. I'd been ignoring IDE features in Emacs for years, thinking I didn't need them, but I have to admit they're a luxury I don't want to give up.
That said, FOSS has a big problem with maintainer burn-out. It seems that projects like SQLite demonstrate more sustainable models, such as source-available and a closed group of maintainers who are exposed to limited demands from users.
reply