gonna run an rpg with two guards one of whom always lies and one of whom always tells the truth. whatever the players ask one will say "sorry, I'll be right with you" and the other will say "I don't have to answer your fuckin questions"

I have spent too much time in Manhattan to have a hope in hell of answering this question accurately. Sometimes a random hotel room or whatever is on the 80th floor and you barely notice

I take pride in my cocktail mixing. I've put in a lot of work into honing my judgment of flavor combinations, learning how to construct an effective cocktail recipe, and building a stable of excellent ingredients. Whenever anyone comes to visit my house, I do my best to give them a beverage experience that's perfectly tailored to their desires, whether it's sweet or bitter, punchy or mild, alcoholic or not. Although sometimes experimentalism takes me in a direction that is not worth repeating, by and large I believe the drinks I make are excellent.

But excellent is not always what's called for.

Liz and I used to love going out to bars. Our signature move was to take off work early of an afternoon, show up just as the doors opened around 4pm or so, and just shoot the breeze with the bartender during the easiest hours of their shift. Bartenders are great conversation because they're always up to something else in their lives, and the best ones also care a lot about the craft of serving people just what they want. We'd stick around for a few hours, get some snacks, maybe order dinner if the bar served it or head out for pizza, and end up home by 8pm feeling like we'd had a full night out.

All that ended, of course, in 2020. Other than a few mostly-outdoor visits during the vaccine honeymoon^[1], we haven't been back to a bar since, and every day I miss that experience of lazily sipping on the latest Negroni variant while merrily chatting with someone who an hour ago was a total stranger to me.

For Liz, that experience was wrapped up inseparably with the particular flavors of happy hour, during which bars served cheaper drinks off a special menu to draw customers. Happy hour drinks are usually well-known classics such as a Manhattan, and they're usually substantially less fancy than a cocktail bar's primary menu. They'll often use only "well" ingredients, the inexpensive stuff that the bar buys in bulk to form the backbone of cocktails that are then made more flavorful with higher-shelf ingredients.

So when that's where Liz's mood takes her, I put away my high-end vermouth and adulterate my usual mixing whisky. Sometimes an excellent experience calls for mediocre flavor, and I try never to let my pride get in the way of mixing the right drink for the moment.

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",…

my favorite discord feature is when it randomly decides to give me a notification for a conversation no one has said anything in for ages