Weeknotes 242

This week is very AI/LLM heavy for which I apologise. It feels as if it is dominating my life. That’s not even hyperbole. Every conversation I have seems to end up talking about it some how, even with “normal” people who don’t have skin in the game.

It’s amazing. It’s awful. It’s happening regardless.

This week’s project was to setup SSO (Single Sign-on) for my services at home. I have ignored Single Sign-on for years, not having really had to deal or come into contact with it at all. The name seems fairly self-describing, but it is also quite a nebulous term for software that allows you to authenticate a user and have them “logged in” to some other software, without the need to login to each service separately.

OIDC, based on OAuth 2.0, seems to be the modern protocol for achieving this.

I’ve been lurking on Reddit for a while and subconsciously keeping note of the solutions proffered to this problem. I decided upon the combination of Pocket ID and Tinyauth along with Caddy (which I’m already using as reverse proxy).

It is seemingly working. Maybe there’ll be a blog post on how I set it up.

See what the environment variables are from a running Docker Container.

docker inspect <container> --format '{{range .Config.Env}}{{println .}}{{end}}'

If you were to, for example, completely hypothetically, accidentally, maybe, delete your *.env files containing all your secrets, you could recover them using this.

Setting up an IRC server

Setting up an IRC server for use amongst friends is very tempting. But does it solve anything for me really? People I know are already scattered over different Slacks, Signals, WhatsApps, and others. And if I setup an IRC server then I’m asking them to add IRC to their own list communication channels.

peon-ping - “Stop babysitting your terminal”

Warcraft III Peon voice notifications (+ more!) for Claude Code, Codex, and other IDEs. Stop babysitting your terminal.

This is what software is about.

TIL that you can specify hostname mappings at build time with Docker Compose. My use case for this was, once again (I am sorry) DNS. It is…always DNS.

Since I don’t have a DNS server on my network I have been relying on NextDNS Rewrites and /etc/hosts. This works for my client devices. However the server I am running at home does not use NextDNS, so it cannot resolve the same hostnames that I can on my clients (my laptop).

Until now that hasn’t been a problem because when Docker containers need to talk to one another, I can use Docker networking. Docker networking is a magical feature where running containers appear on the internal Docker network using their container name as hostname. For example, if I have two containers running, foo and bar. If bar has a web server running on port 3000, I can reach it from foo with http://bar:3000 without having to do anything else.

This is great for a lot of use cases, but not for the OIDC flow I was setting up this week. To simplify a lot (because I don’t fully grasp it like all OAuth related topics) the flow starts in the web browser and you are redirected to the OIDC provider. This works because we’re on the client, so we have properly resolving DNS. The OIDC provider then POSTs the initiator – server to server. This is the part that fails, we don’t have working DNS on the server, just client.

To fix this I need the server to be able to resolve initiating service. I could setup hardcoded DNS entries on my home server, but it seems like my /etc/hosts habit is already getting out of hand, so instead I found I could use the extra_hosts directive in a docker-compose.yml to specify the mapping.

extra_hosts:
  - "service.custom.domain:192.168.0.1"

This feels like a slight hack, we’re putting DNS stuff where you might not expect to find it, but I think it’s reasonable for now.

Vouch — A community trust management system

Historically, the effort required to understand a codebase, implement a change, and submit that change for review was high enough that it naturally filtered out many low quality contributions from unqualified people. For over 20 years of my life, this was enough for my projects as well as enough for most others.

Unfortunately, the landscape has changed particularly with the advent of AI tools that allow people to trivially create plausible-looking but extremely low-quality contributions with little to no true understanding. Contributors can no longer be trusted based on the minimal barrier to entry to simply submit a change.

But, open source still works on trust! And every project has a definite group of trusted individuals (maintainers) and a larger group of probably trusted individuals (active members of the community in any form). So, let’s move to an explicit trust model where trusted individuals can vouch for others, and those vouched individuals can then contribute.

exe.dev

exe.dev is a subscription service that gives you virtual machines, with persistent disks, quickly and without fuss. These machines are immediately accessible over HTTPS, with sensible and secure defaults. You can share your web server as easily as you can share a Google Doc. With built-in optional authentication, so you can focus on your thing.

Your VMs share CPU/RAM—you pay for underlying resources, not per VM. Make a bunch!

I think this service looks really interesting, I’m just not sure what my workflow would look like using it. On the one hand I like that it keeps everything isolated, but to make it useful I’m going to need to give it access to things, so I don’t know. scp-ing files around doesn’t seem like fun. FUSE SSH filesystem? Something else?

Undeniably great domain name though.

envy — “A terminal based tool for managing secrets with both tui and cli support

A secure encrypted vault for managing API keys, secrets, and environment variables. Built for developers who live in the terminal.

I do have the problem of .env files being scattered around 🤔

How I program with LLMs

Sometimes the LLM is wrong. So are people.

Exactly. You don’t believe anything you read or are told by other people either do you?

disco

Disco is the self-hosted Open Source Heroku alternative: git push deploys, zero-downtime releases, automatic SSL, on your own servers at hardware cost.

This sounds somewhat like Hatchbox.io? Opaque pricing means a no from me though.

Stop generating, start thinking – Thoughtful takes.

On Programming with Agents

Focus on the thinking and let agents do the typing. Use the three rules to guide your workflow: plan first so you know what you’re building, stay engaged so you never lose the thread, and review the output so you can stand behind what ships.

Vanilla CSS is all you need – This was quite an education for me.

We mourn our craft

Ultimately if you have a mortgage and a car payment and a family you love, you’re going to make your decision. It’s maybe not the decision that your younger, more idealistic self would want you to make, but it does keep your car and your house and your family safe inside it.

Why Elixir is the best language for AI

I keep seeing various posts from people about how their particular tools are “the best” for use with LLMs. And here I am doing the same, but I’m also linking to a study that I looked at for up to 1 minute.

The Greenfield

This is the single most expensive delusion in engineering.

The silent death of Good Code