I strongly cosign this post. The command line does a good job of being a lenticular system: one that's easy to use in simple straightforward ways while also providing a large amount of power when necessary^[1]. Here are some absolute basics:

• To access the command line from a desktop, run a program called something like "Terminal" or "Console". The exact program will depend on which flavor of Linux you're using, but it'll almost always come up if you search for "term". This application will look like a big old text box something like this:

  

  This text that's displayed there, nex3@framework16:~$ is called the "command prompt", since it's prompting you to enter a command

• The terminal is your window to the command line. You can type commands in here, and the output of those commands will appear below. For example, if I use the ls command^[2], it'll print the names of all the files and directories in the working directory.

  nex3@framework16:~$ ls
  bin  code  Desktop  Documents  Downloads  Music  Pictures  Public  src  Templates  Videos
  

• "Wait," I hear you ask, "what's the working directory?" Good question, friend! Every command line session takes place in a particular directory…

All I'm saying is that the first government to start funding grants for working on the fun parts of software instead of betting on machine learning as the be-all end-all is gonna have an incredible leg up on prestige and talent acquisition when it comes to shaping the digital world over the next half century. The USA's place as the center of software gravity isn't just eroding, it's being purposefully gutted by short-sighted fools who think they can save labor costs by farming out a medium that requires both creativity and precision to machines that are fundamentally capable of neither. Jobs are scarce and prestigious, fun jobs are scarcer. A huge orchard of talent is ripe for the picking.

And I don't just mean funding grants for open-source libraries or public-service web infrastructure or things like that (although they should do that too). I mean fully arts grants, blank checks to create experimental digital media, video games, demoscene demos, wacky hardware, video game mods. Fund the stuff that engineers do in their spare time as long as they do it on your soil and make it available in your language. Build goodwill, build local networks of skill and renown, and you'll have a lock on the whole culture as America continues to collapse.

I guess there isn't much about this up anywhere particularly easy to find, is there? Sure, let's get into the history.

It All Starts with Haml

So, before Sass (not SASS), there was Haml. Haml was created way back in the summer of 2006 by Hampton Lintorn-Catlin^[1], when Ruby on Rails had lit the web development world on fire and everyone was rushing to invent cool new ways of writing server-side-rendered web applications with light AJAX support. Rails used YAML for its configuration and Hampton liked the terseness and indentation, so (as he once described to me) he took a template written in ERB (the dominant templating language at the time) and just deleted redundant characters until he got something that felt more DRY. After some tweaks, the result looked essentially like modern Haml:

%section.container
  %h1= post.title
  %h2= post.subtitle
  .content
    = post.content

That fall, just as Haml was released to the public, I was in college taking a Software Design and Development course^[2] in which the instructor encouraged us to get involved with open source projects. Rails being the big thing at the time, I hung out on the mailing list^[3] looking for good opportunities to dip my toes in. When Haml got announced, it was a perfect opportunity: it was still small and easy to understand, and it had a number of clear tasks that needed doing. I started sending patches, and pretty quickly (at least in part by virtue of having a lot more free time between classes than Hampton did with a full-time job), I became the de facto lead developer.

Sass Emerges

Haml quickly becomes quite popular in the Rails world. Writing HTML closing tags by hand kinda sucks, it turns out, and we're not the last to try to solve this in various ways (although we may have been the first). Hampton is a big ideas guy, and he's always excited to find another big thing to dig into. By this point we're working together pretty closely, so at some point in late 2006 he messages me about his idea for "Haml for CSS", which he wants to call "Sass".

That was the original pitch Hampton sold to me: just like Haml was basically just a different syntax for HTML (or more accurately, for ERB, since it did include the ability to inject Ruby code), Sass was going to be just a different syntax for CSS. The first…

So I'm trying to add support for automatically embedding Fediverse posts on this blog, right? And yeah I could use the Mastodon API for it, but I'd really rather be able to make it work with anything that speaks ActivityPub. So okay, I look up the ActivityPub spec. It's a bit confusing, but I figure out how to at make a GET request for an ActivityPub resource: just add Content-Type: application/ld+json; profile="https://www.w3.org/ns/activitystreams". I can even make a request for one of my statuses and it works! Fantastic!

Just to verify, I make a request to another server, and that's where things start getting hairy. Instead of a nice JSON representation of the post, I get back a 401 Unauthorized with a body that says "Request not signed". This is a public post, but after some digging it turns out Mastodon (and by extension ActivityPub as a whole) has a "secure mode" where all requests have to be signed.

Signed by what though? This is a distributed system—there's no central authority to distribute authorization in the first place.

To answer that I looked in the spec. I searched for "signature" and found nothing particularly relevant. Eventually I found the Authentication and Authorization section, which says "Unfortunately at the time of standardization, there are no strongly agreed upon mechanisms for authentication." Well, shit. Clearly some people agree enough for it to be implemented, but I guess not enough for it to be actually specified!

This does, mercifully, link to a wiki page that purports to lay out "some possible directions" and, under the Server to Server section, seems to describe the scheme that this StackOverflow post describes as "an odd, somewhat well-known ActivityPub quirk"^[1]. This wiki page may not be an official specification, but at the very least it describes the publicKey field that I can see in the actor JSON on Mastodon.social.

This is all fundamentally busywork. Because the whole thing is decentralized, the receiving instance has no choice but to trust whatever public key a new requesting instance provides. All this scheme really does is prove that someone making requests runs a server somewhere that speaks basic ActivityPub, and even then this constraint only exists for ActivityPub requests—HTTP requires no authentication at all.

{
  "id": "https://mastodon.social/users/nex3",
  "type": "Person",
  /* ... */
  "publicKey": {
    "id": "https://mastodon.social/users/nex3#main-key",
    "owner": "https://mastodon.social/users/nex3",
    "publicKeyPem": "-----BEGIN PUBLIC KEY-----\n...\n-----END PUBLIC KEY-----\n"
  }
}

Or does it? The publicKey link there points to https://web-payments.org/vocabs/security#publicKey, a URL that at time of writing is refusing HTTPS connections entirely. Naturally I looked it up on archive.org, only to find that the specification for the publicKey field is not only totally different from what I'm observing in the wild, its one-sentence specification is essentially useless: "A public key property is used to specify a URL that contains information about a public key." The example included doesn't even have a publicKey field.

{
  "@context": "https://w3id.org/security/v1",…

I love that people are thinking about how to make chunks of the web reusable in standalone contexts, but I really truly deeply wish that all the solutions like htmx and web components weren't so hopelessly intrinsically tied to JavaScript. I cut my teeth on the ideals of the semantic web and I strongly believe that a web page should be fundamentally usable with JavaScript disabled. For highly interactive applications I concede this as a lost cause, but it breaks my heart to think that personal websites and blogs, which are essentially plain hypertext, are being built on technologies that simply can't work without scripting.