• Philly Cops Admit That They’re Tracking “First Amendment Activity” Critical of AI

this is probably the most on brand thing for cops to be plugging themselves into these days. this is just plain surveillance state biz.

total sidebar - i’m still shocked and amazed that people are using big social media to do any kind of organizing. i get that the interface and the familiarity is baked in. but it should be assumed that it’s feeding into the apparatus.

• US Law Enforcement Warns of ‘Anti-Tech Extremism’ as AI Hatred Grows | WIRED

solid reporting from wired in much the same vein.

this is some pretty cogent discussion of some of the tensions that i suspect are piling up around the industry as AI tooling is integrated into software engineering. i think this says more about human and organizational structures than it does about the new tools. but at the end of the day, it’s people that need to get things done here.

i suspect that at ${DATEJOB} we’ve managed to avoid much of this tension by keeping one fundamental precept at the core of our work. that is … “a human must own the code”. we’re seeing what seem to be significant productivity gains and we’re investing like mad in automated testing infrastructure (this is our feedback loop), but at the end of the day ownership and measurement drives behavior.

No, Artificial Intelligence Is Not Conscious - The Atlantic

some of the best writing on AI and consciousness i’ve read as of late. i’ve always found ted chiang’s take on this space to be very interesting and well considered. this is well worth the read.

the following struck me as a succint and useful point for defining emotion.

This brings us back to my earlier contention that having a body is a prerequisite to having emotions. Experiencing an emotion such as desperation is inseparable from having stress hormones such as cortisol and epinephrine flood one’s body. Similarly, having a conscience means feeling sadness or moral repulsion at the idea of taking a certain action, and those emotions entail a physiological response, a remnant of having once felt sick with guilt after committing an immoral act. It’s interesting that an LLM can generate descriptions of actions that conscientious fictional characters would either take or refrain from taking, but this is not a replacement for a conscience.

fear strikes me as an emotion that has a tight coupling here. there’s certainly the ability the evince fear on the part of an LLM, but what does it mean to genuinely be in fear?

chiang closes with roughly this bit here …

if you think there is any chance that what you’re building might become a moral patient, you should think about what protections it deserves before you deploy it as your company’s economic engine, not after. Slave owners were not the ones to ask about the humanity of enslaved people, and factory-farm owners are not the ones to ask about the rights of animals. If we imagine Claude to be conscious, Anthropic could not possibly be entrusted with evaluating its moral status; the company has too much invested to be objective.

the level of capture here is insane. we’re less than 2 years into this administration and the institutions are crumbling at a rate i never would have imagined. i’ve only watched 60 minutes on youtube over the past, i don’t know how many, years. still, this is not a good sign for those worried about media capture.

i’m honestly not sure what to make of this. i like, and agree, with a lot of what he’s saying here. the practicalities bear some discussion. i like that he’s coming from a place of technological acceptance and working through the implications.

one of the more fascinating reads in recent months. i had to goo^h^h^hDDG something every couple of paragraphs. this was also referenced in The Dead Economy Theory - by Owen McGrann - The Palimpsest (TDET) which also happens to lean heavily on Opinion | Silicon Valley Is Bracing for a Permanent Underclass - The New York Times. all worth spending time on and working through in detail. TDET is clearly coming from the perspective of someone who’s poking at this themselves and reading widely on the topic. i suspect the writeup has triggered all sorts of vitrol.

there’s no small amount of shit to unpack in all of these articles. to say that we’re societally unprepared for any of this probably goes without saying. though i was amused by the TDET tagline We can laugh at them but we have to take this seriously. which is, unfortunately, very true.

i mean, like who could have seen this coming? right? 🙄

some solid writing on the part of mountain gazette on the tensions surrounding REI as of late.

a few paragraphs at the end here felt worth noting.

Inside the world of outdoor culture, REI has functioned as something more than your traditional retailer. For decades, it’s felt (intentionally) like an entry point into outdoor life–a place where beginners could ask basic questions without signaling inexperience, where knowledge was structured as access rather than gatekeeping, and where the boundary between consumer and participant felt unusually thin.

the above is spot on - for our household, REI hs been the gateway to all sorts of travel and outdoor experiences. we could go in figure out where we landed on the spectrum of introduction to an activity and get pretty solid guidance from experienced staff.

For me, that’s what makes the current conflict feel culturally significant. It’s not just a labor dispute, it’s a labor dispute over what kind of institution REI actually is, and what it means when a cooperative structure operates at the scale of a national retail chain.

As organizations grow, founding principles tend to compete with operational requirements. Over time, structure shapes culture more than intention does, and the gap between cooperative language and corporate-scale operations is showing.

this is one of the core questions that we probably need to be thinking about as a society. how big should things be allowed to get? #LateStageCapitalism abhors things that don’t scale. so much of what we’re dealing with are the second+ order effects associated with unchecked actors attempting to scale.

in this case a co-op, with the cliche ethics or social orientation that are associated with a co-op, has become a retail force in the outdoor industry writ large. it’s being bent in the capitalist direction. what comes of this?

i would be remiss if i didn’t also note that going into an REI the past few years has been an increasingly shitty experience. the quality of the products seem to be on the decline, the stock seems to be moving in the athleisure direction and the coverage for specialty gear seems to be on the wane. i suspect i’d be happier if they went back to less mass market appeal and focusing on the demographics of 1990s-2010s. but we (waves arms about wildly) seem to be doing something else.

For shoppers, the immediate question is more practical than structural. Memorial Day has passed, but if you’re still looking to gear up for summer, you’ve got options. And of those options, try thinking local, won’t you?

here’s anothe rub. even in a solid market like minneapolis/st. paul, we haven’t been able to sustain local alternatives to REI. midwest mountaineering (pour one out for our homies) closed up shop a couple of years ago. we have an incredible bike shop scene. but there are no real alternatives for backpacking, etc. we have solid ski shops, but there’s no alternatives for winter camping / hiking gear. canoe/kayak gear is yet another challenge.

POSSE stands for “Publish on your Own Site, Syndicate Elsewhere”. it’s an indieweb pattern where your own site is the canonical source of truth for what you write, and the social platforms get pointers/copies that link back home. the inverse of the more typical mode, where you write on twitter/mastodon/bluesky and your blog (if you even have one) is an afterthought.

i’ve been meaning to wire this up for botwerks for a while. the goal is simple: when i merge a new post to main, something picks it up, waits for the deploy to settle, and pushes a short link to both mastodon and bluesky. that’s the whole thing. no fancy webmentions, no rich embeds, no salmention shiz. just a link with a title and (when it fits) a description.

the moving parts

there are three elements:

1. a python script that does the syndicating: bin/posse.py
2. a github action that runs that script on every push to main
3. a state file at data/syndicated.json that tracks what’s already been posted so nothing gets double-posted

i’ll provide an overview of all of these elements.

the script

bin/posse.py is a single-file python script that uses uv for dependency management. the inline script metadata at the top of the file declares the runtime requirements - atproto, Mastodon.py, python-frontmatter, grapheme, and requests. no requirements.txt, no virtualenv setup, just uv run bin/posse.py. this is one of the nicer python developments of the last couple of years.

note: the following is an embedded gist

at a high level it does this:

1. walks content/posts, content/til, and content/links looking for markdown files
2. filters out drafts, future-dated entries, and anything with syndicate: false in the frontmatter
3. for content/links/ entries it also requires a syndicate tag. most links are ephemeral and don’t deserve a social post by default
4. builds the canonical permalink from the file’s date and basename to match hugo’s permalink config as defined in my hugo.toml (:year/:month/:contentbasename)
5. compares that against data/syndicated.json to find new entries
6. for each new entry it polls feed.json until the entry actually appears live (so we don’t post a link before cloudflare has propagated the build), then posts to mastodon and bluesky
7. updates the state file after each successful post

a couple of details worth calling out:

• bluesky has a hard 300 grapheme (yeah, i had to dig into this. a grapheme is a user perceived character.) limit on post length. the script measures with the grapheme package rather than len() because emoji and combining characters will throw off naive character counting. if a post would overflow, the description gets truncated with an ellipsis until the whole thing fits.
• mastodon doesn’t have the same tight limit (500 chars by default, higher on my instance), but i format both posts identically for consistency.
• bluesky needs an explicit text builder with a URL facet to make the link clickable. mastodon parses URLs from text automatically.
• the script writes the state file atomically (write to .tmp, then rename). an interrupted run can’t leave a half-written JSON blob behind.

the github action

the workflow lives at .github/workflows/posse.yml. it triggers on push to main when any of these paths change:

• content/posts/**
• content/til/**
• content/links/**
• bin/posse.py
• the workflow itself

note: the following is an embedded gist:

before running the script the workflow sleeps for 120 seconds. that’s a buffer for the hugo build on cloudflare pages plus cloudflare’s edge propagation. it’s not strictly necessary - the script polls feed.json for each entry before posting anyway - but it cuts down on wasted polls.

the workflow uses a github environment to gate access to the social account credentials. the environment holds:

• MASTODON_INSTANCE_URL (variable)
• MASTODON_ACCESS_TOKEN (secret)
• BLUESKY_HANDLE (variable)
• BLUESKY_APP_PASSWORD (secret)

after a successful run, if data/syndicated.json has been modified the workflow commits it back to the repo. the commit message ends with [skip ci] so the resulting push doesn’t trigger another run of the workflow. without the [skip ci] token the workflow would loop on its own state commits, burning CI minutes for no reason.

there’s also a workflow_dispatch trigger with a dry_run input. this lets me run the workflow from the github UI in a non-destructive mode if i want to verify what would happen without actually posting.

state management

data/syndicated.json is the source of truth for what’s already been syndicated. it looks roughly like this:

{
  "entries": {
    "https://botwerks.net/2026/05/20260522-130616/": {
      "posted_at": "2026-05-22T18:30:42+00:00",
      "mastodon_id": "112345678901234567",
      "bluesky_uri": "at://did:plc:abc.../app.bsky.feed.post/xyz..."
    },
    "https://botwerks.net/2009/01/2009-01-01-some-old-post/": {
      "init": true,
      "posted_at": "2026-05-30T17:49:36+00:00"
    }
  }
}

the canonical URL is the primary key. there are two flavors of entry:

• normal entries have posted_at, mastodon_id, and bluesky_uri
• init entries (marked with init: true) were bulk-seeded when POSSE was first turned on. these exist purely to prevent the script from going back and posting every entry in the archive at once. no sense spamming folks with old news.

the file is sorted alphabetically by key on write so diffs are readable when the workflow commits state updates. you can scroll the file and see the chronology of new posts at the bottom (sort by key happens to roughly track sort by date because of the date-based slugs).

opting out

there are a few knobs to keep something from being syndicated:

• draft: true in frontmatter (also keeps it out of the build, obviously)
• syndicate: false in frontmatter for a specific entry
• for content/links/ entries: leave off the syndicate tag. by default link posts don’t syndicate

future-dated posts also don’t get syndicated until they’re actually live. this matters because i sometimes write something now and schedule it for later. (ha! in theory)

bootstrap

the script has an --init flag. this is what i used to backfill the state file with every existing post on the site before turning on the action. without that step, the first real run would have tried to syndicate seventeen years of archive in one go.

uv run bin/posse.py --init

the script also takes --dry-run which prints what it would post without making API calls or modifying state. i leaned on this heavily during setup.

what i’d change

honestly, i’m not sure. it’s all a little new and i don’t really anticipate “syndicating” much. the polling-for-live behavior is the part i’m least sure about. it would be cleaner to have the deploy notify the script directly when a new entry is live, rather than the script polling for the entry to appear. but the polling is cheap, it works, and it doesn’t require me to run a service somewhere to receive the webhook. simple wins.

it might also be nice to surface failures more loudly. if a post fails to syndicate the workflow run gets marked as failed, but i have to actually go look at github actions to notice. some kind of notification would be useful, but i’d rather not add more infrastructure for what is a very low-volume tool.

more in the vein of be afraid! no seriously, calm down

i got a burr up my ass and decided to poke at this whole POSSE thing. given that pretty much all of this site is driven out of github, using github actions (even with all of their flaws) seemed like the right move. having things generated out of hugo with actual serving/hosting via cloudflare has some fun little quirks in the operational flow.

operational overview

bin/posse.py is a standalone script that will do the needful with the associated POSSE destinations (currently mastodon and bluesky). there’s a small bit of GHA environment chicanery associated with creating the necessary linkages to the targets. nothing out of the ordinary there.

this all gets triggered via a GHA action against the hugo publication branch and action. GHA itself does a little bit of waiting to make sure that the posts actually exist on the internet writ large. (i.e., they got through the cloudflare pipeline) then parses the posts and publishes to the destinations. munging the contents as appropriate.

there’s a little bit of nuance in the rate limiting and the handling of link/posting storms as well as state management across what are inherently stateless GHA runs. more details should probably be provided here, but honestly. this is more of a test post.

want to get uninvited to the party? start making people feel uncomfortable with the facts about home ownership. ask them to keep track of how much they’ve poured into the improvements on their place, zillow it and see if they’re gonna recoup the “investment”. it’s a non-stop cycle of trying to hold your head above water. spend as little as you can get away with.

this was a beautiful piece.

first off, it’s claude and not codex or co-pilot. second, it really feels like we’re going to start waking up to the real costs of things here.

long. quite long. lots of god stuff. solid message.

setting aside the questions and digressions on theology/deism. this is something that more people should probably sit down, read and think about.

some solid discussion on clanker tooling in the age of clanker tooling.

when there’s so much money swimming around here. what did you honestly think was going to happen in this case?

i find this to be incredibly amusing given that uber decided to subsidize the hell out of rideshare early on and got a lot of folks hooked on cheap taxi service via app. to have this be something that bites them in the ass on the development side of things gives me a bit of a chuckle.

having access to claude code does not make you a software engineer. any more than having a cordless circular saw makes one a carpenter. armed with claude code and any number of software AI tools, it’s now possible to create remarkably complex tools or sophisticated looking/sounding presentations and documents. i think this is, on balance, a good thing.

these artifacts can be incredibly useful. but they are not built to be sustainable and maintained outputs unless there’s the application of some real skill in their assembly. this is the engineering part.

i don’t know how we’re going to collectively weather this. i’m just writing this down for future me. i can’t be the only one seeing this. but currently, i’m just really hoping that the we some how manage to rectify our collective thinking here.