Shellsharks Blogroll - BlogFlock

Forgejo Support for EchoFeed - Robb Knight • Posts • Atom Feed

2026-02-04T12:38:55.000Z

I've just merged in support for Forgejo to EchoFeed. Forgejo is a "self-hosted lightweight software forge" aka "We have GitHub at home"^[1]. Adam is running an instance as part of omg.lol.

It works the same at the GitHub integration with one exception: no OAuth. Forgejo can exist on any domain, like Mastodon, but it doesn't allow for creating applications (like EchoFeed) on-the-fly. Instead, it uses access tokens which isn't as convenient but I didn't want to create applications on every instance someone might want to use. Here's a screenshot of the required permissions but check the docs for the details on setting the right permissions.

Forgejo support is available to everyone right now.

I don't intend this to be mean but the uncanny valley of how close the UI is to GitHub is hard to miss ⤾

Book Review: The Examiner - Janice Hallett ★★★★⯪ - Terence Eden’s Blog

2026-02-04T12:34:22.000Z

I've thoroughly enjoyed all of Janice Hallett's previous crime books. The Examiner is, frankly, more of the same - and I'm happy with that!

You, the reader, are given a series of transcripts and have to work out what crime (if any) has been committed. You don't find out who the victim(s) is/are until reasonably far through the story. The characters are well realised (although a little similar to some of her others). The twists are shockingly good and will make you flick back to see if you could have spotted them.

Hallett is exquisite at building tension through the slow drip-drip-drip of reveals. OK, so the transcripts are a bit unrealistic but they make a good scaffold. While it might be nice to include user avatars on the WhatsApp messages, the characters' voices are unique enough to distinguish them easily.

Much like The Mysterious Case of the Alperton Angels, the book plays around with symbolism and the nature of faith. You may find yourself sympathising with the characters and then quickly recanting!

Technical Issues

Viper, the publisher, seem to have messed up the structure of this eBook. Despite being published in 2024, they're using an ancient and obsolete version of the Blitz ePub CSS which itself was archived back in 2020. As well as strange indents, there's a hard-coded 2em margin only on the right.

Accessibility is poor. All the abbreviations use the <abbr> element. But some kind of automated find-and-replace has mangled most of them. For example, the "Masters degree in Multimedia Art (Full-Time Programme)" is shortened to "MMAM(FTP)" and then given the nonsensical abbreviation of "Molecular Area Per Molecule (File Transfer Protocol)"!

Much like before I've written to them asking them to correct it.

Boob Tube Activity - Cool As Heck

2026-02-03T19:17:29.000Z

My wife and I are still watching a lot of the Taskmaster back episodes. We've slowed down a bit so we don't go through them so fast. We are watching the seasons in ordered chunks, but the chunks are out of order. We started with series 19 because of Jason Mantzoukas, then we watched series 20. Then we went back and watched 17, 18, and 19, but then skipped further back to series 4 and have been watching in order from there. I think now we're about to finish series 12 now. At some point we'll watch 1-3. We were so bummed we couldn't get tickets to the US live show in DC.

This week we started watching Wonder Man, the new Marvel TV show. He's a bit more obscure Marvel comics character, but the show is high quality and reminds me a bit of Loki. I highly recommend it.

Another show we jumped into this week is A Knight Of The Seven Kingdoms. This is another show set within the Game of Thrones universe, but about 90 years before that show, I think. It's based on a series of novellas, one of which is The Hedge Knight. It has a much lighter and more comical tone than Game of Thrones or House of the Dragon. We're two episodes in and so far we are loving it.

The cost of running OpenBenches.org - Terence Eden’s Blog

2026-02-03T12:34:16.000Z

After my recent presentation at FOSDEM, someone asked a pretty reasonable question. What does it cost to run OpenBenches?

It is, thankfully, surprisingly cheap! In part, that's because it is a relatively simple tech stack - PHP, MySQL, a couple of API calls to external services. It was designed to be as low cost while also being useful. Here's the breakdown:

Hosting - £171 per year

Our biggest expense but, I think, our most reasonable. Krystal charges around £342 for a 2 year contract. That includes unlimited bandwidth and storage, as well as the domain name. We have nearly 400GB of photos and bot scraping means we can use over 900GB of bandwidth per month - so Krystal give us a rather good deal!

Use this affiliate link and code EDENT to get a small discount.

Stadia Maps - US$20 / month

Geocoding is surprisingly hard to do locally. We need to transform latitude and longitude into addresses, and then back again. Stadia Maps cost about the same as our hosting! What's rather annoying is that we only use about half the API calls in our plan. We need to find a cheaper solution.

Mapping - Free!

When we used Stadia for drawing maps, we regularly ran over our quota. So we switched to OpenFreeMap which produces gorgeous interactive maps.

The service has been rock solid and very responsive to bugs on GitHub.

Logo - US$5

I'm not a good designer, so we bought a logo from The Noun Project and then coloured it in. Bargain for a fiver!

Image CDN - Free!

Although we have unlimited bandwidth with Krystal, we're only located in one region - the UK. WeServ. It's also pointless serving full resolution images to small screens.

So WeServ offers free image resizing and global CDNs. Personally, I'm not a fan of CloudFlare (their CDN partner) so I'm looking to change provider.

OCR - Free!

People don't want to type in the inscription of the photo, so we use Google Cloud Vision.

We send less than 1,000 requests per month - so we're inside their free tier. If we get more popular, that'll get more expensive. But I don't know of a local-first OCR which is as good as Google's. Sadly, Tesseract is rubbish for extracting text from photos.

Authentication - Free!

We don't want to store anyone's passwords. The free tier of Auth0 allows us to do social login for up to 25,000 monthly users. Which is more than enough for us.

Sadly, Auth0 don't support the Fediverse, so I had to build my own "Log-in with Mastodon" service.

As much as we'd like to run social login locally, we simply don't want to be responsible for securing users' details & API keys.

Software - Free!

As per the OpenBenches colophon we use a lot of cool FOSS. Small JS libraries, big PHP frameworks, and everything in between.

Income

Thanks to GitHub Sponsors we make a whopping US$3 per month!

Similarly, our OpenCollective Sponsors brings in about £3 per month.

Merchandising! You can buy OpenBenches branded t-shirts, mugs, and hats. That nets us about £20 per year

Call it roughly £80 income. OK, it is better than nothing - but doesn't even cover a quarter of our costs. Sometimes people give us a higher donation privately, which is also very welcome. These people are listed on our README.

Total

On the assumption that our time is worthless (ha!) and that we only rarely go over our providers' API limits, and we get in some revenue, the cost of running OpenBenches is less than £300 per year.

That's not bad for a fun little hobby. People certainly spend more than that on Funkopops, vaping, and mechanical keyboards!

Nevertheless, I'm always slightly worried that we'll go viral and have an unexpectedly high bill from our API providers.

I would love to be able to hire a proper designer to make the site look a bit nicer. I also want to be able to buy a modern iPhone so that I can test it in the latest Safari.

If you have any suggestions for cutting costs, or non-scummy ways to help us raise funds, please drop a comment below.

22.00.0182 JDex deep-dive: data and storage options - Johnny.Decimal

2026-02-03T10:59:56.000Z

JDex deep-dive: data and storage options

This post is a deep-dive into two aspects of your JDex: whether or not you use it to store data, and the different ways you can store the JDex itself. This article is long, and isn't a tutorial; this is reference material that I can now link to when common questions arise.

Our analogy: the library

This analogy courtesy of Moriarty on Discord, who said:

…the revelation was realising that my filesystem, (long-form) notes folder, physical filing cabinet etc were the bookshelves in a library, and my JDex was the index card drawer. One (the card index) describes the shelves and what's on them, the other (the shelves) have the content.

That's brilliant. Let's make it really explicit. Put yourself in your local city library, some time in the 1960s. 🕺🏼

Index cards

Before computers, libraries kept records of books on index cards.

Figure 22.00.0182A. The good old days.

Crucially, you can think of the index card as a representation of the book itself. If a card doesn't exist, the book might as well not exist. To find a book in a library you don't start at a bookshelf. You start with the index of books. Here's the process.

Go to the index.
Using the structure of the index (Dewey, in the case of your library) find the book in question.
The index card will tell you where the book is physically located.
Assuming the book is in the building -- it might be out on loan -- walk to the location indicated on the card and get the book.¹

Your JDex

Your Johnny.Decimal index (JDex) was designed to work exactly the same way. Your Johnny.Decimal IDs are the index cards. Each ID belongs to a category, which is analogous to the drawer. And -- not shown here because the diagrams are busy enough already -- we understand that each category belongs to an area just like each drawer is housed in a cabinet.

Figure 22.00.0182B. Categories hold IDs.

This is why I say the JDex is the most important thing in your system. A library without a catalogue is no longer a library: it's just a room full of books. Your life without a JDex is no longer a Johnny.Decimal system: it's just a bunch of files (even if they are neatly organised).

Metadata

Metadata is 'data that defines and describes the characteristics of other data' (Wikipedia). So if data is a book's contents, metadata is its publication date, ISBN number, current location, and so on.

We use this all the time without being conscious of it: the last modified time of a file is metadata. The fact that some piece of knowledge is in your email is metadata. (The knowledge itself being data.)

The thing about metadata is that it's typically tiny in comparison to the thing that it represents. As a result, we don't have to find some new place to store it. We already have one: the index entry.

For the library, this means writing this stuff directly on the index card. For your JDex, it means that your IDs' metadata is always stored directly with the JDex entry. Metadata is a fundamental component of the entry: it's not some separate thing to manage.

Here's how that might look with a handful of entries from the Life Admin System. Remember: purple box = category. Blue note = ID.

Figure 22.00.0182C. IDs from the Life Admin System with metadata.

Metadata should be standardised

You should decide on a common set of metadata 'keys' and use them consistently. This allows you to query it later: for example, finding all entries where Last updated: is after '2026-01-29', or all entries where Location: is 'fireproof lock box'.

This is only possible if you always call it Location. If you sometimes call it Where is it?, that's now a different thing.

Nerd note: we call these key/value pairs. Keys are standard. Their values change. As keys are special, I'll show them like this in this post.

This is an important distinction as we consider what's metadata vs. data, below.

In the near future, the Johnny.Decimal system will recommend a standard set of metadata keys. If I use it in this post, you may assume it will be in that standard.

'Above the line'

Note the horizontal line in these diagrams. That's deliberate: in my JDex, I use a line to separate metadata from data. Metadata is always 'above the line'. We'll see data 'below the line' shortly.

Above the line: the book's metadata.
Below the line: the book's contents.

Storing data in your JDex

In contrast to metadata, your library's index cards weren't designed to store the data that they represent. They aren't the book's contents.

But nor are computers 5×7" pieces of cardboard stored in a little metal box. So in this new world, you might choose to extend the usefulness of your index entries by using them to store data.

Figure 22.00.0182D. An ID entry with data 'below the line'.

Here, we're still recording the location of your passport as metadata 'above the line'. But we're also storing a bunch of other data 'below the line'.

Nerd note: we call this 'structured' vs. 'unstructured' data. Here metadata is structured, with standard keys. Our below-the-line data is unstructured: it's different for each entry.

This is what I do and recommend. It's simple. Everything's in one place. It's very hard to lose information, and very quick to retrieve it.

To address the alternative scenario, we need to expand this model.

Storing data outside your JDex

Back to the physical library. There, index cards point at books, and books contain data.

Figure 22.00.0182E. A book's index card points to the book's contents.

In exactly the same way, we can move the data out of our JDex note and into its own file.

Figure 22.00.0182F. A JDex entry points to its data.

Here, 11.12 Passports, residency, &… is an ID folder in our filesystem (orange). We've created 2 files there (yellow): one for our partner's passport, and one for our own. And we've moved the data out of the index entry into these text files.

To be sure we don't forget about this data, we've reminded ourselves about it using a Data property. (This is optional. But if in doubt, it's worth doing. It takes no time.)

A note on `Location`

Remember that this metadata relates to our passports. As in, the little book you show at immigration: not the Johnny.Decimal ID that is the concept of your passport.

That's why Data is split from Location. We have data about the passports, which is in some place. And, separately, the (physical) location of the passports.

But let's not get distracted. I'll have more to say about Location in a future post.

Recap

To recap, we've introduced two scenarios.

You store data in your JDex entry, below-the-line.
You store data externally, and (optionally) reference it above-the-line.

It might be interesting to note that here at JDHQ we use both of these methods. Johnny tends to prefer the first. Lucy, perhaps because of her career as a copywriter and editor, leans towards the second. They happily co-exist.

Quadrant chart

Let's introduce the beginnings of what will become a quadrant chart. This will help us to orient these concepts relative to each other.

The left/right split represents the scenarios just discussed.

Figure 22.00.0182G. All quadrant charts are born as two rectangles. True fact.

This is a continuum

There's a hard line down the middle of this diagram, but life isn't like that. The reality is that this is a continuum, with most cases somewhere in the middle.

To the far left of this diagram is the situation where you exclusively store data in your JDex. This is unrealistic: will you never save a file? Files are data. So when I say that you 'store data below-the-line', I mean some data: usually textual data, as it's natural to add that to the existing JDex entry. As soon as you also save a file, or keep any artefact related to this ID outside the JDex entry, you've moved away from that left edge.

The right edge of this diagram is somewhere you might actually exist. In this situation, you never store any data in your JDex. For example, your JDex might be an Excel spreadsheet, with one row for each ID.² Excel is a terrible place to try to write any sort of long-form text, so it would make sense for no data to be stored there.

This diagram is just useful for us to map out all the ways we can do it. But none of them is more correct than the others. It's all preference.

Where is your JDex stored?

There's another fundamental question to be addressed, and it relates to the storage of your JDex. We've established that you have a JDex. Where is it?

This is another continuum, the opposing sides being:

Store your JDex as individual files in your filesystem.
Store your JDex as some other artefact, not in your filesystem.

Let's explore these options.

JDex as individual files in your filesystem

What we mean here is simply that each JDex entry is an individual file, usually a text file, often formatted with Markdown.

You could manage these manually, but it's far more common to use an application, and the most common of those is Obsidian. For those who don't know it, you point it at a folder and it'll show you the structure of that folder and all of the Markdown files in it. Select a file from the left, edit it on the right. JDHQ provides downloads for the Life Admin and Small Business Systems that are designed to work with Obsidian.

Figure 22.00.0182H. Obsidian.

People enjoy Obsidian because it sits over your files: it's a convenient utility. But if you get sick of Obsidian, or if they decide to charge $500/year for a licence, or if you want to give some other app a try, you can just stop using it. All of your files are still Markdown files in a folder that you control.

The vertical axis of our chart now represents where your files are stored. Obsidian sits in the top half, where your JDex is 'files in your filesystem'. It spans both top-left and top-right quadrants as you still have the choice of where to store data: in your JDex, or externally.

Figure 22.00.0182J. Quadrant chart with Obsidian represented.

JDex stored elsewhere

There are a lot of options in this bottom half, so let's explore the simplest.

The other app that I love and support (with specifically-formatted downloads from JDHQ) is Bear. Superficially, Bear is identical to Obsidian: list on the left, editor on the right.

Figure 22.00.0182K. Bear.

But there is a crucial difference: Bear manages these JDex entries entirely for you. There's no concept of 'text files on your disk' to manage. There's no option in Bear to change the location of these files. You can't, outside of Bear, go and look at them. Another app can't edit them. You can't put them in a shared folder and collaborate with your partner.

(Technically, in fact, they aren't even a collection of text files. Rather, Bear manages them using a database which they 'highly recommend' that you do not touch.)

This sounds limiting, and in many ways it is. Why would you want this? Well, it's a lot simpler. You load your JDex files into Bear once, and then never have to think about where they are. Want them on your iPhone? Just install Bear and they'll appear. They're harder to lose because Bear stores them in your iCloud Drive so if you drop your laptop in a lake, no worries.³

Many apps work like this: Apple Notes, Craft, Evernote, Google Keep, Notion, and OneNote to name a few.⁴

Let's keep it simple and add Bear to our quadrant chart.

Figure 22.00.0182L. Quadrant chart with Bear represented.

The point of this distinction is that when you're using a method in the bottom half of this chart -- more of which we'll see shortly -- the decision of where to store your JDex is made for you. This is one less thing for you to have to manage.

Where are your JDex files?

A question naturally arises: if we're talking about you storing your JDex as 'files in your filesystem', where are those files? As usual, there are a few options.

Ignoring your JDex for a moment, here's a simple representation of your filesystem. As in, the Johnny.Decimal structure, probably in your Documents folder or on a cloud drive, where you save all your stuff.

▓ 10-19 Life administration/

▓ └── 11 Me & other living things/

▓     ├── 11.11 Birth certificate & proof of name

▓     ├── 11.12 Passports, residency, & citizenship

▓     └── …and so on

__________________

Figure 22.00.0182M.

The dark blocks on the left will make sense shortly. These tree diagrams don't work well on mobile, sorry. I've made sure that they are clear and flow properly at larger sizes.

It's pretty obvious that if you had a PDF that you needed to save -- say your latest passport renewal -- you'd put it in 11.12. Because it's a file, that you're saving in your filesystem. No new concepts there.

So if we're storing our JDex as files in our filesystem, it must be in here somewhere. Where else would it be?

This is one of the IDs that are reserved by the Johnny.Decimal system, and I hope the ID is obvious. It's the very first thing you should encounter in your system, the top of the tree: 00.00. It lives inside the system-reserved category 00.

▓ 00-09 System-management area/

▓ └── 00 System-management category/

▓     └── 00.00 JDex for the system

▓ 10-19 Life administration/

▓ └── …and so on

__________________

Figure 22.00.0182N.

Happy with that? There's a lot going on, and it's about to get deep. Get comfortable with that before we move on.

What goes in 00.00?

Above, we noted how Obsidian just watches a folder full of files and lets you edit them. The screenshot (figure 22.00.0182K) shows those folders in the left pane, full of text files. Those folders look like your Johnny.Decimal system. As this is your JDex, they define your system. So they look something like this.

░ 00-09 System-management area/

░ └── 00 System-management category/

░     └── 00.00 JDex for the system.md

░ 10-19 Life administration/

░ └── 11 Me & other living things/

░     ├── 11.11 Birth certificate & proof of name.md

░     ├── 11.12 Passports, residency, & citizenship.md

░     └── …and so on

__________________

Figure 22.00.0182P.

No, I didn't duplicate the previous figure by accident. Note the subtle difference from figure 22.00.0182M: now the IDs are Markdown (.md) files, which is what Obsidian will display in the right pane.

So if we stitch these two diagrams together, this is what your filesystem looks like.⁵

▓ 00-09 System-management area/

▓ └── 00 System-management category/

▓     └── 00.00 JDex for the system/

░         ├── 00-09 System-management area/

░         │   └── 00 System-management category/

░         │       └── 00.00 JDex for the system.md

░         └── 10-19 Life administration/

░             └── 11 Me & other living things/

░                 ├── 11.11 Birth certificate

░                 │         & proof of name.md

░                 └── 11.12 Passports, residency,

░                           & citizenship.md

▓ 10-19 Life administration/

▓ └── 11 Me & other living things/

▓     ├── 11.11 Birth certificate & proof of name

▓     ├── 11.12 Passports, residency, & citizenship

▓     └── …and so on

__________________

Figure 22.00.0182R.

Be really comfortable with that before we continue. At first glance this looks bonkers. But when you understand that 00.00 is a Johnny.Decimal ID that just happens to contain a folder structure that mirrors the overall structure … it's fine. And you're never spending any time in there yourself: let Obsidian manage it.

This is the 'partially nested' pattern

When you download your JDex files from JDHQ, there are a handful of options for Obsidian. This is the 'partially nested' pattern, in that the ID files are nested within an area/category structure. Obsidian shows this structure in the left pane.

There's an alternative 'flat' structure, in which those Markdown files aren't nested within an area/category structure. Some people just prefer that. I'll leave it as an exercise to the reader to imagine how this looks in your filesystem. (You can download these files from JDHQ as many times as you like: try it out. Note that you'll need to select Obsidian as your JDex app first. Both links require a JDHQ account.)

Let's place a dot on the diagram that represents these patterns. We're not concerned with whether we're storing data in our JDex or not, so we'll stick it in the middle.

Figure 22.00.0182S. Obsidian on the quadrant chart.

The 'fully nested' pattern

In the scenario just described, your JDex files were separate from the rest of your files: they're all saved at 00.00 while the rest of your stuff is below.

What if you didn't want to do this? What if you wanted to merge these two structures -- JDex and filesystem -- so that there was only one? This is possible, of course, and we call it the 'fully nested' pattern.

In this pattern, folder 00.00 goes unused.⁶ Instead, each of the Markdown files that are your JDex entries are scattered through your filesystem. Again, I've used the dark and light blocks to represent which components come from the original diagrams.

▓ 00-09 System-management area/

▓ └── 00 System-management category/

▓     └── 00.00 JDex for this system/

░         └── 00.00 JDex for this system.md

▓ 10-19 Life administration/

▓ └── 11 Me & other living things/

▓     ├── 11.11 Birth certificate & proof of name/

░     │   ├── 11.11 Birth certificate

░     │   │         & proof of name.md

▓     │   └── Photograph of birth certificate.jpg

▓     ├── 11.12 Passports, residency, & citizenship/

░     │   ├── 11.12 Passports, residency,

░     │   │         & citizenship.md

▓     │   └── Passport application.pdf

▓     └── …and so on

__________________

Figure 22.00.0182T.

On the surface, this feels like a good idea. Why wouldn't you want it all integrated? But me and many others have tried this and the universal consensus is that this doesn't work.

The point of this article is to explain these methods, not to tell you why one of them is worse than the others. So, just briefly:

The clean separation of JDex from filesystem is a nice mental separation. It reinforces your JDex as being the more important thing. Merging them breaks that.
Previously, you were pointing Obsidian at a folder full of tiny text files. Now, you're pointing it at your entire filesystem. There might be terabytes of data in there. This can slow it down significantly.
You're no longer able to selectively synchronise folders because the folder is the JDex entry. This was the killer blow for me.

So you probably shouldn't do this. For completion, let's add it to the diagram.

Figure 22.00.0182U. Two Obsidian options.

I've placed this item nearer the top of the chart as your JDex files are more 'in your filesystem' using this method than they were with the previous method.

Core concepts finished

That's it for core concepts. In the next section, let's fill out the diagram with some examples.

Examples

There are a handful of scenarios that we already understand. The diagram's getting busy so I'll extract some meaning to a table.

Figure 22.00.0182V. I honestly thought I was going to run out of letters for the captions on this one. Close call.

	Data stored	JDex stored
Obsidian 1	in JDex	'fully nested'
Obsidian 2	in JDex	'partially nested'
Obsidian 3	externally	'fully nested'
Obsidian 4	externally	'partially nested'
Bear 1	in JDex	managed by Bear
Bear 2	externally	managed by Bear
Excel	externally	as an .xlsx in your filesystem
Google Sheets	externally	in your Google Drive
Notion	within Notion	by Notion in their cloud
SQLite database	within the database	as a .db file in your filesystem
Airtable	externally	by Airtable in their cloud

Nit-picky points

We're getting in the weeds here, but I positioned those dots carefully so we might as well explain why.

The left/right split isn't so interesting: you either store data in your JDex, or you don't. Your choice here might be limited by the method you use to store your JDex. As we've already said, a spreadsheet is a terrible place to keep long-form notes; spreadsheets tend towards the right edge.

If you use a database like Notion, it's up to you. In this diagram I've designed a Notion where you do keep data there. Given Notion's power, this feels like a realistic scenario. But you could just have well designed a pure JDex-only database and stored all data externally.

Where the files are, on the vertical axis, is a touch more interesting. Google Sheets is in the lower half while Excel is in the upper because the Excel sheet is a file that you need to manage, and the Google Sheet exclusively lives in your Google Drive.

That said, you do still need to specify where in your Google Drive the file exists. You still need to file it somewhere, even if that somewhere happens to be in the cloud. Which is why Google Drive is above Airtable, an online database. With Airtable there is no consideration at all 'where' your database is stored. You don't get a folder structure that you have to 'file your database' in. (Other than a rudimentary dashboard that you can rearrange.) Your database is just at Airtable.

Similarly, Notion is at the bottom, because all of your stuff is in the Notion cloud. Conversely you might prefer to build yourself a SQLite database which is now a file that you need to manage. As we now know, that database should be stored at 00.00.

That'll do

I wrote this article to set up a framework that I can use in the future; a diagram into which I can slot more scenarios. This isn't meant to be comprehensive. There are a thousand scenarios that aren't included here.

100% human. 0% AI. Always.

You might be thinking, 'that's not how I use my library'. But when you go to the library you're likely browsing the shelves. You don't know what you're looking for. That's a different behaviour from going to a reference library and recalling a specific book, which is the analogy here. ↩
A spreadsheet provides a nice way to think about your metadata. If each row is an ID, your columns store metadata. It's easy to see how you'd have one standard column for Location, and that adding another column for Where is it? is obviously silly. Columns define the keys of our key/value pairs. ↩
With the caveat that cloud storage is not a backup. See my mini-series on data, storage, and backups. ↩
If you use these apps, an important consideration becomes 'lock-in'. How easy is it to export your data, if you choose? Bear makes this easy. Others might make it harder, or it might not be practical. Craft and Notion, for example, are database apps. You can't just export a database to a bunch of text files and expect it to make sense. ↩
Actually, I add another folder below 00.00 that contains both of the folders 00-09 and 10-19. This is because Obsidian doesn't allow you to 'rename' a vault: the vault name is just the name of the folder of files that you have opened. In the situation shown, the vault name would be '00.00 JDex for the system'.

I manage multiple vaults and want a more descriptive name. My business system's folder is named 'D25 JDex': D25 is the system identifier. This then appears as the vault name. In the screenshot above (figure 22.00.0182H) you can see the vault name is 'JDex - Life Admin System'. This is how it's downloaded from JDHQ. I left this detail out of the diagram as it's not important to the fundamental concept. ↩
Other than to store its own JDex entry, as shown. ↩

The Coherence Premium - Westenberg

2026-02-02T22:41:04.000Z

I don't necessarily believe in second brains. The notion (pun-intended) that you can offload your thinking to a perfectly organized system of notes and links has always struck me as a fantasy. The people I know who've built elaborate Notion databases or Obsidian vaults mostly end up with digital hoarding problems, where the system becomes the work. And I'm broadly skeptical of the Claude Code productivity discourse, the idea that AI tools will let you 10x your output if you prompt them correctly. (Most people using AI are producing more stuff faster without any clear sense of whether the stuff is good or consistent or even pointed in the right direction.)

But I do believe in something adjacent to both of these ideas, something that borrows from the second brain concept without the hoarding, and from AI tooling without the context-free prompting: I believe in coherence as a system.

In 1937, the British economist Ronald Coase asked a question that seems almost embarrassingly simple: why do firms exist at all? If markets are so efficient at allocating resources, why don't we just have billions of individuals contracting with each other for every task? Why do we need these hulking organizational structures called companies?

His answer, which eventually won him a Nobel Prize, was transaction costs. It's expensive to negotiate contracts and coordinate with strangers, to monitor performance and enforce agreements. Firms exist because sometimes it's cheaper to bring activities inside an organization than to contract for them on the open market. The boundary of the firm, Coase argued, sits wherever the cost of internal coordination equals the cost of external transaction.

This was a brilliant insight in '37, but Coase couldn't have anticipated what happens when transaction costs collapse. When software eats coordination. When a single person with the right tools can do what used to require a department. When AI can execute tasks that once demanded teams of specialists.

We're in a Coasean inversion. The economics that made large firms necessary are reversing. But most people are looking at this transformation through the wrong lens. They see AI as a productivity tool, a way to do more faster. They measure success in hours saved or output multiplied, and this misses the point entirely.

The solopreneur's advantage is not solely speed, and it's certainly not "lower costs" despite what a good too many seem to think.

The advantage is coherence.

what coherence actually means

When I say coherence, I mean something specific: the degree to which every part of an operation derives from the same understanding, the same model of reality and set of priorities and tradeoffs.

When you work alone, you have a problem and you understand the context because you lived it and touched it and experienced it first-hand. You make a decision based on that understanding, execute the decision, see the results, and update your understanding. The entire loop happens inside one mind.

What happens in a large organization facing the same problem? Someone identifies the problem, but they don't have authority to solve it. They write a report explaining the problem to someone who does have authority. That person reads the report, but they don't have the original context, so they ask clarifying questions. The answers come back, filtered through email or a meeting. A decision gets made, but the people who have to implement it weren't in the room. They recieve instructions that encode the decision but not the reasoning. They execute the instructions as best they understand them. The results come back through multiple layers of reporting. By the time the original decision-maker sees what happened, months have passed and the context has shifted again.

This is the basic challenge of coordination across minds. Every handoff loses information, every translation introduces drift, and every layer of abstraction moves further from ground truth.

Organizations have spent decades trying to solve this problem. They've built elaborate systems of documentation, standardized processes, metrics and KPIs, regular meetings, shared values statements, company cultures. All of these are attempts to create coherence across minds. And they all fail, in different ways and to different degrees, because they're fighting against something that won't budge: knowledge is sticky and context is lossy, and understanding doesn't transfer perfectly between humans.

the pathology of process drift

A company starts small, with the founders doing everything themselves. They make decisions quickly because they understand everything about the business, and the business works.

The company grows and the founders can't do everything anymore. They hire people and try to transfer their understanding. But understanding doesn't transfer easily, so they also transfer processes. "This is how we do X. Use this checklist for Y. Follow these steps."

The processes work, mostly. But the new employees don't have the context that generated those processes. They don't know why step three comes before step four, and they don't know which parts are essential and which parts were arbitrary choices. So when situations arise that the process doesn't quite cover, they either follow the process rigidly and get suboptimal results, or they improvise and create inconsistency.

More growth, more employees, more processes. The processes start interacting in ways nobody anticipated. The sales process assumes certain things about the product process. The product process assumes certain things about the engineering process. When those assumptions drift out of alignment, you get friction and delays and finger-pointing.

The company responds by adding coordination mechanisms like project managers, alignment meetings, and cross-functional reviews. These help, but they also add overhead, and they create their own drift: the coordination layer develops its own processes, its own assumptions, its own information loss.

Eventually you reach a point where a significant fraction of the organization's energy goes toward internal coordination rather than actual value creation. A 2022 Microsoft study found that employees in large organizations spend over 50% of their time on internal communication and coordination. Half the payroll, dedicated to getting the organization to agree with itself.

context fragmentation

More information means the coordination problem gets worse, not better. This seems counterintuitive, because shouldn't more information make everyone more aligned?

But information isn't understanding. Understanding = integration, and integration happens in minds. More information means more raw material that each mind has to process differently.

A typical large organization's knowledge base is spilling over with strategy documents from last year and the year before, project postmortems from dozens of initiatives, customer research reports, competitive analyses, technical specifications, meeting notes, email threads, Slack channels, and wiki pages.

Somewhere in there (the elusive somewhere...) is everything you need to know to make a good decision.

But nobody has synthesized it all, and nobody has integrated it into a coherent model. Each person reads a fragment, interprets it through their own context, and forms their own understanding. When they discuss decisions with colleagues, they're not comparing the same mental models but rather different interpretations of different subsets of the available information.

This is context fragmentation. People don't disagree on facts; they're operating from different maps of the same territory. And because the maps are implicit, inside people's heads, nobody realizes they're not looking at the same thing.

The proliferation of AI tools in large organizations means that now each employee has their own AI assistant, trained on whatever context they happen to feed it, producing outputs that reflect their particular understanding of the situation. The AI amplifies individual perspectives rather than creating shared ones.

single-player mode advantage

When you're operating alone, you have one context, one understanding, one model of your business and your market and your customers and your strategy. That model lives in your head, and it's coherent because there's only one mind maintaining it.

If // when you use AI tools, you're feeding them from that single source of truth. The AI doesn't have its own understanding that might drift from yours, and it operates within the context you provide. If you give it good context, it executes within that context. If your understanding is coherent, the AI's outputs will be coherent.

This is the inversion of the traditional organization's problem. In a large organization, you have many minds with their own contexts, trying to coordinate through AI tools that amplify their differences. As a solo operator, you have one mind with one context, using AI tools to execute within that coherent frame.

The AI handles the execution at scale while you maintain the coherence. This division of labor plays to the strengths of each party: humans are good at integration and judgment, while AI is good at execution and volume. The solo operator with AI gets the benefits of scale without the costs of coordination.

But this only works if you actually maintain coherence.

If you're using AI to do random shit faster, you're not capturing the advantage. The advantage comes from having a tight operating model that the AI operates within.

the coherence stack

Think of it as a stack with four layers, each feeding the one below it.

┌─────────────────────────────────────┐
│         MIND LAYER (You)            │
│  Understanding, judgment, strategy  │
│    The source of coherence          │
└─────────────────┬───────────────────┘
                  │ feeds
                  ▼
┌─────────────────────────────────────┐
│         CONTEXT LAYER               │
│  Operating model, constraints       │
│  Voice guidelines, decision logs    │
└─────────────────┬───────────────────┘
                  │ constrains
                  ▼
┌─────────────────────────────────────┐
│        EXECUTION LAYER (AI)         │
│  Content, code, research, analysis  │
│  Customer responses at scale        │
└─────────────────┬───────────────────┘
                  │ produces
                  ▼
┌─────────────────────────────────────┐
│          OUTPUT LAYER               │
│   Coherence-checked artifacts       │
│   What actually ships               │
└─────────────────┬───────────────────┘
                  │ feedback
                  └────────────────────► Mind Layer

At the top is the mind layer, which is you: your understanding, your judgment, your integrated model of the business. This layer can't be automated or delegated, and it's the source of coherence.

Below that is the context layer, where you externalize your understanding into documents that AI tools can consume. Your operating model, your constraints and tradeoffs, your voice guidelines, your decision history. This layer translates what's in your head into something machines can work with.

Below that is the execution layer, where AI operates. Content generation, research, analysis, code, customer responses. The AI works within the constraints provided by the context layer, producing outputs at scale.

At the bottom is the output layer, which is what actually ships. But nothing reaches this layer without passing through a coherence check: does this output reflect my model? Would I have produced something like this? Does it fit with everything else?

The stack only works if information flows correctly. The mind layer feeds the context layer through deliberate documentation, the context layer constrains the execution layer through careful prompting, and the output layer feeds back to the mind layer through review, which sometimes triggers updates to your understanding.

Most people using AI skip the context layer entirely. They go straight from a vague intention to an AI prompt to shipped output. This is how you get drift // how you end up with an operation that feels incoherent, where different pieces don't quite fit together, where customers sense something is off even if they can't articulate what.

building your context layer

The context layer is where the work happens. It's the translation mechanism between your understanding and AI execution. Get this right and coherence becomes automatic; get it wrong and you're constantly fighting drift.

Start with your operating model - a working description of how your business actually functions.

I structure mine around five questions.

┌────────────────────────────────────────────────────────┐
│               OPERATING MODEL                          │
│            (Five Core Questions)                       │
├────────────────────────────────────────────────────────┤
│                                                        │
│  1. PROBLEM & AUDIENCE                                 │
│     What problem do I solve, for whom specifically?    │
│     Not demographics. The person in the moment.        │
│                                                        │
│  2. THESIS                                             │
│     Why does my approach work?                         │
│     The real theory, not marketing language.           │
│                                                        │
│  3. TRADEOFFS                                          │
│     What am I optimizing for, at what expense?         │
│     Make the choices explicit.                         │
│                                                        │
│  4. BOUNDARIES                                         │
│     What do I explicitly not do?                       │
│     The boundaries define the shape.                   │
│                                                        │
│  5. VOICE                                              │
│     How do I actually sound?                           │
│     Words I use. Words I avoid. Stance toward reader.  │
│                                                        │
└────────────────────────────────────────────────────────┘

What problem do I solve, and for whom specifically? Steer clear of demographics; you need a description of the person in the moment they need what I offer. What are they trying to do, and what's getting in their way?
What's my actual thesis for why my approach works? Why does my solution address the problem better than alternatives?
What are the core tradeoffs I've chosen? Every business is a bundle of tradeoffs, and I'm optimizing for X at the expense of Y. Making these explicit prevents drift, because when a new opportunity arises, I can check it against my tradeoffs rather than deciding ad hoc.
What do I explicitly not do? This is more useful than describing what you do, because the boundaries define the shape.
How do I sound? What words do I use, what words do I avoid, what's my stance toward the reader? Capturing this helps AI maintain consistency across outputs.

This document should be short enough to include in AI prompts. If it's longer than a page, you haven't distilled it enough. The goal is compression without loss of generative power.

Next, build your constraints file. These are the decision-making rails that keep outputs on track. I think of them as principles // functional rules that generate answers.

For example: "When choosing between comprehensive and focused, choose focused. Our readers are busy and will bounce if they don't get value in the first paragraph." That's a constraint that actually constrains, telling the AI (and me) how to resolve a common tradeoff.

Include examples. Point to a piece you wrote that exemplifies the voice, and one that doesn't. Concrete examples communicate more than abstract descriptions.

Finally, maintain a decision log. When you make a significant choice, write down what you decided and why. This creates institutional memory for a one-person institution. When similar situations arise later, you (or your AI tools) can refrence how you've handled them before. This prevents the common failure mode where you decide the same question differently each time because you forgot your previous reasoning.

a coherence check

Every output that ships should pass through a coherence check. This can be quick, but it can't be skipped.

┌────────────────────────────────────────────────────────┐
│                  COHERENCE CHECK                       │
├────────────────────────────────────────────────────────┤
│  □ Does this sound like one person wrote it?           │
│  □ Would I explain it this way?                        │
│  □ Does it reflect my specific tradeoffs?              │
│  □ Could a competitor produce this? (Should be no)     │
│  □ Does it fit with everything else I've shipped?      │
│                                                        │
└────────────────────────────────────────────────────────┘

The questions:

Does this sound like one person wrote it? AI tends toward a certain homogeneity, and if an output could have been produced by anyone, it's not coherent with my operation.
Would I explain it this way? The same framing, the examples, the emphasis? If I'd approach it differently, the output needs revision or I need to update my context documents.
Does it show // hold my specific tradeoffs? If I've chosen focused over comprehensive, is this output focused? If I've chosen accessible over technical, is this accessible?
Could a competitor produce this? If the answer is yes, the output isn't coherent enough. It's not distinctive and doesn't come from my particular understanding.
Does it fit with everything else I've shipped? Coherence is cumulative, and each output should feel like it belongs with the others. If this piece would feel out of place next to my other work, something's wrong.

You can automate part of this. Feed your AI tool your recent outputs and ask it to compare a new draft against them, flagging inconsistencies. But the final judgment has to be yours. You're the source of coherence, and the check is really asking: does this feel like mine?

anti-patterns that break coherence

I've watched myself and others struggle with this.

A few failure modes reliably produce drift:

┌────────────────────────────────────────────────────────┐
│            COHERENCE ANTI-PATTERNS                     │
├────────────────────────────────────────────────────────┤
│                                                        │
│  CONTEXT STARVATION                                    │
│  └─► AI works from generic training, not your model    │
│                                                        │
│  OUTPUT ACCUMULATION                                   │
│  └─► Shipping without review; deviations compound      │
│                                                        │
│  MODEL STALENESS                                       │
│  └─► Understanding evolves, documents don't            │
│                                                        │
│  FRAGMENTED TOOLING                                    │
│  └─► Different tools, different contexts, drift        │
│                                                        │
│  DECISION AMNESIA                                      │
│  └─► No rationale logged; inconsistent future choices  │
│                                                        │
└────────────────────────────────────────────────────────┘

Context starvation is the most common. You ask AI to do something without feeding it your operating model, your constraints, your voice. The AI does its best, but it's working from generic training rather than your specific understanding. The output is competent but not coherent.
Output accumulation is context starvation's downstream consequence. You ship AI outputs without proper review, and each one is slightly off from your model. The deviations accumulate. After a few months, your operation no longer reflects your understanding because most of what you've shipped wasn't actually generated from your understanding.
Model staleness happens when your understanding evolves but your context documents don't. You learn something that changes how you think about the business, but you don't propagate that update to your operating model or constraints file. Now your AI tools are working from an outdated picture.
Fragmented tooling = using different AI tools with different contexts. You use one tool for writing and another for code and another for research, and each has different context, different prompts, different understandings of what you're doing. The outputs don't cohere because they're not coming from the same source.
Decision amnesia = making choices without recording the reasoning. You decide something, move on, and three months later face a similar choice with no memory of how you handled it before. You decide differently this time. Now you have inconsistent decisions in your history, and any AI tool referencing your past work will find contradictions.

the fragmentation audit

You should audit your operation for coherence as often as possible. I do this monthly, AI tools or not, AI be damned, but the frequency matters less than doing it at all.

Pull your last twenty or thirty outputs, whether blog posts, emails, product updates, or whatever you've shipped. Lay them out and look for the implied beliefs and positions in each. What does this piece assume about the reader? What does it prioritize, and what stance does it take?

You're looking for drift: places where piece A assumes one thing and piece B assumes something different, places where your voice shifted without intention, places where you contradicted yourself purely because you genuinely forgot what you'd said before.

When you find inconsistencies, you have two options. Either reconcile them by updating your model (maybe you actually did change your mind, and the recent piece reflects your current thinking), or flag them as errors and correct going forward.

This audit also reveals context layer gaps. If you keep finding drift in a particular area, your context documents probably don't cover that area well enough. Add constraints, add examples, make the implicit explicit.

why this beats scale

Large organizations have obvious advantages. They have capital, they have brand recognition, distribution, expertise, redundancy, Las Vegas conferences etc. A solo operator can't compete on those dimensions.

But think what those advantages actually buy. Capital lets you hire more people, and more people means more coordination overhead and context fragmentation. Brand recognition helps customers find you, but it doesn't help you serve them coherently. Distribution gets your product to more places, but each touchpoint introduces opportunities for inconsistency. Expertise is great, but experts in different domains don't automaticaly share mental models.

Meanwhile, the solo operator with a coherent system has advantages that don't show up on traditional metrics. Every customer interaction comes from the same understanding, and every piece of content reflects the same perspective. Every product decision follows from the same model. The operation feels like one thing, because it is one thing.

Customers experience this as quality, even if they can't articulate why. They sense that someone understands what they're doing and why, and they don't encounter the cognitive dissonance of dealing with an organization that can't agree with itself.

The dynamic that makes this sustainable is that coherence compounds. Each decision you make within your model reinforces the model, and each output that reflects your understanding strengthens your position. Your operation becomes more legible over time, both to you and to your customers. Meanwhile, large organizations' incoherence also compounds, with each misalignment creating more misalignment and each process drift opening space for more drift.

The gap widens.

The coherence advantage works best in domains where the value comes from understanding rather than from physical or regulatory scale. Knowledge work, creative work, advisory work, software, content, education, consulting. These are domains where a coherent perspective can outcompete a fragmented organization's superior resources.

And the opportunity is unique: the technology exists to operate at scale while maintaining the coherence of a single mind. The window is open because large organizations haven't figured out how to respond. Their answer to AI so far has been to give everyone AI tools and hope for productivity gains, which accelerates their fragmentation...

the coherence moat

Scale used to be the moat. You built a big organization with lots of resources, and the sheer weight of your operation protected you from smaller competitors. Transaction costs made it hard for anyone to replicate what you'd built.

But transaction costs are collapsing. The activities that used to require organizations can increasingly be performed by individuals with the right tools.

The Coasean logic that justified large firms is weakening.

If there is a new moat (and I'll admit, that's a big "if") it probably looks like coherence; the ability to operate as one mind, one understanding, one model, even as you execute at scale. Large organizations can't have this because they're composed of many minds. Solo operators can have it by default, if they're deliberate about maintaining it.

The solo operator who builds a coherent system and lets AI execute within it has an advantage that doesn't need venture capital, doesn't need hiring, and doesn't ask for the whole apparatus of organizational scaling.

Scale breaks coherence. Coherence is the moat.

Book Review: The Voyage of the Space Beagle by Alfred Elton Van Vogt ★★☆☆☆ - Terence Eden’s Blog

2026-02-02T12:34:39.000Z

This is Star Trek before Star Trek. It is Alien long before Alien. It is the template for so much modern science fiction. What it is not is particularly good.

I don't intend to dump on the classics (and this is undoubtedly a classic) but 1950s sci-fi takes place in an almost alien media environment. Even if you ignore the anachronisms (like having to develop film in order to see photographs) and the archaic language (lots of vibrators being used against a big pussy) it is hard to get over how unconvincing it all is.

In the first story, the crew of the Space Beagle find an alien monster. It probably killed one of them. They bring it aboard and just let it lounge about in the library! Yes, all the science is fun, and the "competency porn" of the professional crew is suitably heroic, but the characters and their motivations are frequently bizarre. It is only through the complete absence of girls (urgh!) that there's no interstellar sexism.

The protagonist, Grosvenor, is a cipher for every geeky kid who ever felt he was smarter than everyone else. He is a sneering, taciturn, and deeply unpleasant character. When given the opportunity, he relishes the chance to become dictator.

Because the book started life as a set of short stories, it works reasonably well as a "monster of the week" show. It is episodic, with well-placed cliffhangers. The science is very sciency with some excellent speculative elements. You've got aliens planting eggs in people (like Alien) and a ship's engineer who says "Nooo! The walls couldn't stand it. They'd melt." (like Scotty) and any number of concepts you'll recognise from your favourite TV shows.

The obsession with hypnotism and mind-control feels a bit icky, especially when understood in association with the author's dalliance with the pseudoscience of Dianetics.

The language (when not steeped in 1950's idiomatic phrasing) can verge on the poetic. Every story includes a chapter or two from the alien's viewpoint. They are deliciously weird and elevate this book beyond what might be a slightly forgettable slice of sci-fi.

It is absolutely worth reading - if only to see how influential it has been - but it can be a bit of a weird slog at times.

IndieWeb Book Club: The Art of Explanation - James' Coffee Blog

2026-02-01T19:36:12.000Z

I am hosting the IndieWeb Book Club for this month, in which everyone interested is invited to read and write a blog post about The Art of Explanation: How to Communicate with Clarity and Confidence [Goodreads link]. The book was authored by Ros Atkins, a BBC journalist whose career has spanned radio on the BBC World Service and television on BBC News.

I read this book toward the end of last year and loved that the advice given was tactical, engaging, and interspersed with stories. I’d highly recommend it to anyone interested in refining their communication or explanation skills.

The Art of Explanation is quite a long read, and may not be easy to fit into a month. I’d highly recommend reading the introduction and a chapter or two that looks most interesting to you – this will be enough to both give you a feel for the book, (hopefully) many insights, and what you need to write a blog post for the Carnival. If you have time and the motivation, keep reading! I wanted to add the caveat that you don’t need to finish the book because I know how hard it can be to finish a book in a month. I still want you to feel encouraged to pick up this book and read a bit!

If you read any of The Art of Explanation and write a blog post about the book this month, please email me at readers [at] jamesg [dot] blog and I will add your submission to the round-up at the end of the month.

Will They Inherit Our Blogs? - Kev Quirk

2026-02-01T18:45:00.000Z

I've been thinking about how this site may be able to live on after I'm gone. Maybe it could become a family heirloom?

I’ve thought about this topic more generally before, but this one is specifically about blogging.

This blog is by far the hobby I have sunk the most time into over the last 13-ish years, and I’d like to think I’ll continue as I head from middle age, to old age. Let’s say I live until I’m 80, I will have spent over 50 years of my time on this earth writing content here at kevquirk.com.

I don’t want all the hard work to disappear in a puff of smoke once I snuff it, so I’ve been thinking. Could this blog become a family heirloom?. Could I pass this site on to one (or both) of my sons and have them continue to write here?

They wouldn’t even need to continue to use kevquirk.com. They could write on their own domain(s), and just redirect this one.

I like to think that many of the other long-time bloggers out there might want the same. Maybe one day it’ll be normal to leave our blogs to our kids?

A question worth asking

I do think it’s something we should consider. I’m part of the first generation that grew up online, and most of us are still very much alive. But as time marches on, more of us are going to leave behind these digital epitaphs.

I’d love it if my sons took up blogging when they’re old enough to (that, and riding motorbikes!). But they’re their own people, and may not want to. If that’s the case, I just hope they’ll agree to keep my waffle online for a little while once I’m gone. 🤷🏻‍♂️

Thanks for reading this post via RSS. RSS is great, and you're great for using it. ❤️

You can reply to this post by email, or leave a comment.

Vanguard - The Government Project to get British Businesses to use the Internet - Terence Eden’s Blog

2026-02-01T12:34:10.000Z

Email isn't an obvious business benefit. Imagine it is the early 1980s and you need to communicate with people across the country. A first-class letter will cost you 17p - about 60p in today's money. The letter will be delivered the next day and you'll have your answer back the day after.

By contrast, a single computer terminal was likely to set you back around £3,000 - and that's before you take into account message transmission costs. That's roughly the same price as sending over 8,000 letters. Is that a sensible investment for the 1980's businessman?

In 1986, British Telecom started producing "The Communications Programme" which was "a new video magazine produced exclusively for the top communications people in the UK's largest organisations".

The show was distributed on video-tape and the archived shows are genuinely fascinating. They're a mixture of business reporting, thinly veiled advertorials, and a glance at the future of digital services.

Buried in the middle of episode 4 is this advert from the Department of Trade and Industry.

There's very little online information about the "Vanguard Project" - it was a VADS initiative (Value Added Data Services) run by DTI, BT, IBM, INS, ISTEL, and FASTRAK. Some of those acronyms survive, some don't!

Its aim was to promote awareness of EDI and its potential for the United Kingdom.

In 1986 the Department of Trade and Industry launched a project called Vanguard to promote the development of this kind of service in 10 different sectors including construction, educational supplies and wholesale food distribution. The major VADS suppliers (BT, IBM, INS, Istel and the Midland Bank) in the UK were heavily involved in the project from the beginning.

Information Sources in Information Technology

What's "EDI"?

Electronic Data Interchange.

A means of transferring data between co-operating enterprises without having to print it out on one computer and key it into another. Requires agreement about standards (proprietary or otherwise).

Did it work? Well, that's hard to say!

There's a paper from 1989 called Survey of Electronic Data Interchange Users and Service Providers in the UK. It dives into the then current challenges of getting British businesses to adopt EDI.

It quotes Sir John Harvey-Jones saying that most people running companies were:

…old people like me not familiar with the technological possibilities! We have great difficulty in making imaginative jumps to see the way in which the whole of our business can be reorganised, revitalised, set up in totally new ways, releasing energy and cost and putting us into the pole position. I can see abundant evidence that the full benefits of EDI will only be reaped by the companies where the Chief Executives is seized with enthusiasm for the potential prize he can grasp.

Which still seems true today! Although over-enthusiasm has led us to a weird AI-in-everything future.

The paper doesn't talk about Vanguard specifically, although it does have this rather cute diagram adapted from one of its reports:

Not quite the Gartner Hype Cycle!

The paper concludes that:

Unfortunately the zealots of EDI tend to be unable to ‘sell’ the benefits to management in most companies, and this is not helped by the way that many companies have been forced to trade electronically. Management tends to think that EDI is about computers, and because they think that computers are technical they abdicate responsibility with the cry of ‘its all too difficult’. This must be wrong. It is up to those who understand EDI to learn how to talk to management, and it is up to management to understand that not only is EDI not about technology, but even if it was it is still their responsibility.

Again, true as it ever was!

Nestled in the bibliography is this tantalising list of publications from the now-defunct Her Majesty's Stationery Office:

None of which appear to be online, although a few are in The British Library - and a few more available on Google Books

The state awarded several contracts for Vanguard - most of which seemed to be in the training space. Here's what The EDI handbook said about it:

(My thanks to Don Thompson, Owen Boswarva, and Ms7821 for digging out some of those references.)

Did it work? By the time I entered the workforce in the 1990s, it seemed like every desk had a computer. Although the Internet was in its infancy, email and electronic ordering was a normal part of business. The various proto-Internet protocols were still around, but were quickly being replaced.

A thesis published in 1991 asked an important question:

why should a non-interventionist Government as Thatchers become directly involved in developing the market and working together with private companies whose normal aim is to increase market share at the expense of their competitors rather, than cooperate with them?

The impact of Electronic data interchange on Irish foreign trade and transport

Metcalfe's Law tells us that there is no value being the only business on a network. It simply isn't rational to invest in connecting to a data service that no-one else is on. But the value of that network increases as more people and businesses get connected. If you've read The Entrepreneurial State, you'll know that governments are often responsible for subsidising technological initiatives like this. The state, its citizenry, and its businesses all benefit from the increased efficiencies of electronic communications, so it is only right that the state should bootstrap these sorts of projects.

I sent an FoI request to find out more but it looks like all the information is now archived.

If you know of any other sources of information about Project Vanguard - please leave a comment.

Completely oblivious people - Cool As Heck

2026-01-31T20:34:14.000Z

We just went to Wild Hare cider in Berryville. We usually love going there, but today we got there a few minutes before they opened at 2pm. We're sitting in the parking lot, and we see a car rush into the parking lot and a guy jumps out of the car and hurries into the building. Clearly, this guy was late for work.

So we give him a few minutes before going inside. He greets us and politely says that he is running a little late and just needs a few minutes to set up. We say "no problem" because we are looking around, as the place has changed a lot since we've been there over a year ago.

We finally sit down at the bar, he turns on Spotify on one of the TVs in the corner and starts playing music at a low volume, then turns on THE SHINING on the TV near us at the bar. Like yeah we just came for a drink and a horror movie.

It's important to know that this place is just a room in an old warehouse. It's not really heated. They have a couple heaters around the area but only one of them is on. We both still have our coats on as we're sitting at the bar, AND THIS DUDE OPENS THE GARAGE DOOR TO THE OUTSIDE. It's 18°F here today. We look at each other like "we gotta drink this shit and get the hell outta here" because we are going to freeze to death. About that time, another couple comes in and they're like "why is this door open? It's freezing!" The guys says "well I thought it was too dark in here." Both my wife and I and the other couple say "we would rather it be dark and warm." So he closes the door, but by that time we are basically done with our drinks and shivering, so we settled up and left.

Now we are home and it is time for a warm nap.

Book Review: With the End in Mind - Dying, Death and Wisdom in an Age of Denial by Kathryn Mannix ★★★⯪☆ - Terence Eden’s Blog

2026-01-31T12:34:55.000Z

Is it possible to "die well"? We have midwives for births, should we have "deathwives" for the other end of our lives? I think this book was recommended to me in the depths of the pandemic. I was too much of a chicken to read it while those around me were dying. The book aims to normalise the process of death and mostly succeeds. Unlike a lot of books, it doesn't just identify a problem - it provides pages of solutions. Every chapter ends with a series of questions to ask yourself (or your loved ones) about death.

At times, it is utterly heartbreaking and more than a little gruesome. Death is emotionally and physically distressing. Similarly, there are several stories which deal with the reality of assisted dying. I think the author comes down against euthanasia - but it certainly helps raise questions of whether repeatedly offering the option amounts to pressuring them into an unwanted decision.

It is a bit homespun and cloying. I felt like it painted quite a rosy picture of what death can look like. All the nurses are angels and the doctors have endless patience, there's always time for a cuppa and deathbed revelations are never awkward.

Oh, and there's a lovely aside about memorial benches being harbingers of doom, which I found quite amusing!

This will probably sit unread on your ebook for far too long - but it is worth cracking it open and thinking about the questions it raises.

Your Life is the Sum Total of 2,000 Mondays - Westenberg

2026-01-31T00:25:46.000Z

We plan our lives like we're editing a movie trailer.

The trip to Portugal, or the product launch, or the transformation photo at the gym. The big moment where everything crystallizes into meaning. We accumulate these peaks in our imagination, and then arrange them into a montage that proves our existence mattered, and that we really lived.

Then we spend the actual substance of our lives doing laundry and feeling crappy about it...

A few years ago, I saw Douglas Coupland (author of Microserfs and Generation X, and one of my personal favorite writers) on a panel at the Sydney Writers' Festival. One of the other panelists - an influencer with a recently published quasi-self-help memoir - delivered a long, dreamy anecdote about finding the true meaning of life while watching butterflies drift over a waterfall in some far-flung locale.

When she finished, the moderator asked Coupland what he thought.

He said butterflies and waterfalls are all well and good, but they're not real life. They're a flash in the pan - a spike of adrenaline and dopamine. And if you can only find meaning in those brief, luminous moments, you're in for a world of trouble.

Put it another way:

If you work a standard career from twenty-five to sixty-five, you'll experience roughly 2,080 Mondays. That's 2,080 alarm clocks set against your biological preferences and 2,080 inbox avalanches, plus 2,080 instances of navigating traffic or public transit while still metabolically processing the weekend. Add in the Tuesdays through Fridays, and you're looking at roughly 10,400 ordinary workdays across a career. Meanwhile, if you're fortunate enough to take two weeks of vacation annually for forty years, you'll accumulate 560 vacation days. The ratio is roughly 19:1 in favor of the mundane.

So we get to a question worth sitting with:

Do you actually like your average Monday?

The peak experience fallacy

Abraham Maslow spent decades studying what he called "peak experiences," those episodes of ecstasy and transcendence that seemed to characterize the healthiest human specimens. His 1964 work on self-actualization celebrated these episodes as evidence of psychological flourishing, and the positive psychology movement that followed made peak experience cultivation into something approaching a secular religion.

(And don't we love a good secular religion.)

But in Maslow's research he deliberately selected subjects he considered "self-actualizing" and then studied what made them tick. The peak experiences he documented were symptoms of people who'd already figured out something more fundamental.

What Maslow's self-actualizers actually had in common was what he would later come to call "plateau living," a sustained capacity to appreciate ordinary existence, to find the sacred in the quotidian. The peaks were outgrowths of the plateaus, not replacements for them.

Somehow, this part of the research didn't make it onto the Instagram motivation accounts.

Romanticism in the nineteenth century made the extraordinary moment into a spiritual imperative. Wordsworth's "spots of time," the vivid memories that restore the imagination, became cultural programming. We inherited the assumption that meaning lives in the exceptional rather than the everyday // that the proof of a life well-lived is a collection of dramatic set pieces.

The tolerated life problem

The psychologist Philip Zimbardo has a framework called "time perspective theory." People differ in how much mental weight they assign to past, present, and future. Future-oriented people tend to achieve more by conventional metrics, but they also exhibit a consistent pattern of sacrificing present satisfaction for hypothetical future rewards. When researchers follow these people over time, they find that the anticipated future keeps receding and the scaffolding remains permanent.

Seneca diagnosed this exact pathology in first-century Rome. He observed that people guard their property vigilantly but waste their time freely, treating it as an infinite resource. "You act like mortals in all that you fear, and like immortals in all that you desire," he wrote.

The barely tolerated Monday is a down payment on a life that never arrives, a perpetual advance payment for goods that don't ship.

Neuroplasticity works both ways. Every Monday you survive without presence, you're training your nervous system that survival is the appropriate response to ordinary life. The brain gets efficient at what it practices, and if it practices endurance, endurance becomes its resting state. You build tolerance in the drug addiction sense: you need more and more peak moments to feel alive because your baseline has been chemically optimized for numbness.

The architecture of an ordinary day

If your life is going to be 80% Mondays and their equivalents, the design specifications for Monday matter more than the design specifications for your vacation.

The three levers that actually move the needle on everyday experience are pretty much consistent: environment, commitments, body, and the way they interact.

The concrete physical and social circumstances of ordinary days are what matter.

Environment shapes behavior more powerfully than willpower. Kurt Lewin, the father of social psychology, called this "field theory" - behavior is a function of the person and their environment simultaneously. The architectural critic Christopher Alexander spent decades documenting how physical spaces create what he called "quality without a name," that feeling of aliveness and coherence that certain places generate. Your Monday morning unfolds in a specific physical context. If that context is cluttered and friction-laden, you're fighting your suroundings before you fight your inbox.

The writer Annie Dillard, in "The Writing Life:"

"How we spend our days is, of course, how we spend our lives."

She was talking specifically of the desk, the chair, the window, and the ritual of beginning. The container shapes the contents.

Commitments function as architecture too, but for time rather than space. Every standing meeting and every obligation you've accumulated is making claims on your Mondays whether you consciously choose it or not. The philosopher Harry Frankfurt distinguished between first-order desires (wanting something) and second-order desires (wanting to want something). Most people have a massive gap between what they'd choose if starting fresh and what they've accumulated through drift. Your calendar is probably full of first-order commitments that violate your second-order preferences for how you want to live.

The economist Albert Hirschman noted that people respond to deterorating situations through exit, through voice, through loyalty, or through some combination of these. Most people default to loyalty with their commitments, enduring obligations that no longer serve them because the activation energy for exit feels too high. But the asymmetry is real: the cost of one difficult conversation is finite, while the cost of tolerating an energy-draining commitment is infinite in the sense that it compounds for as long as you carry it.

Body is the substrate everything else runs on, but it's the lever people most consistently ignore when designing their days. You're not a brain piloting a meat vehicle but a single integrated system, and the state of the body on Monday morning is the state of you on Monday morning. The research on sleep and movement is tediously consistent: the basics matter more than the optimizations. No biohacking compensates for six hours of sleep and a pastry for breakfast. The Monday you experience is manufactured in the preceding twenty-four hours.

The Monday blueprint

Given all this, what would it look like to actually take Monday seriously as a design problem?

The first hour matters disproportionately. What you do between waking and starting work is the foundation that everything else builds on. If that first hour is wasted in ractive scrolling and rushed caffeine, you've primed your nervous system for a day of low-grade stress. If it's spent in intentional movement and even ten minutes of something that feels like choice rather than obligation, you've shifted the baseline entirely.

Most people's work blocks are structurally hostile to focus. Cal Newport has beaten the drum on deep work for years now, and the data supports him: the average knowledge worker can't go more than a few minutes without context-switching, and every switch carries cognitive costs. Your Monday needs a protected window, two hours minimum, where the work that actually matters happens without interruption; it needs the satisfaction that comes from making measurable progress on something that matters to you.

The body work is unglamorous: thirty minutes of movement and food that doesn't spike your blood sugar. Some kind of break from the sedntary. This is maintenance more than optimization, and treating it as optional is how you get to Friday afternoon feeling like you've been through the Somme.

Lastly: relationships.

One genuine human connection per Monday and one conversation that goes beyond the transactional changes the texture of the entire day.

The longitudinal research on wellbeing, from the Harvard Study of Adult Development running since 1938 to more recent epidemiological work, keeps landing on the same finding: the quality of human relationships is the single strongest predictor of flourishing.

...And that's about it.

It's not prescriptive.

There are no lifehacks.

But the blueprint works.

Building identity through iteration

Virtue is a practice, not a possession. You become what you repeatedly do, which means your Mondays are literally building the person you're becoming. Every Monday you survive is training you to be a survivor, and every Monday you engage with is training you to be someone who engages.

James Clear has popularized the notion of identity-based habits: rather than focusing on outcomes, focus on becoming the type of person who naturally produces those outcomes. Applied to Monday, the question shifts from "How do I get through this day?" to "Who is the person I'm becoming through how I spend this day?" The first question optimizes for survival while the second optimizes for construction.

Your life is made of ordinary days, and if those ordinary days are spent waiting for something better, you've wished away your existence.

The goal isn't a life with more peak moments. I think that's a false and ever-elusve pursuit. The goal is a life whose default setting doesn't require escape. Your future is made of boring days done on purpose, and a life you need a vacation from is a design problem rather than a motivation problem.

The most honest mirror you own is your calendar, and if you looked at your calendar for the last month without knowing whose it was, would you want that person's life?

In Louis Malle's 1981 film My Dinner with Andre, two old friends sit in a Manhattan restaurant and talk for two hours. And yes, that's the entire movie. And yes, it's one of the best films I've ever seen.

Andre Gregory, the theater director, has returned from years of seeking transcendence through increasingly elaborate experiences: working with Grotowski in Poland, being buried alive in a forest on Halloween, traveling to the Sahara, and participating in rituals designed to shatter ordinary consciousness. He describes these adventures with genuine wonder, convinced that modern life has anesthetized us and that only extreme experience can wake us up.

Wallace Shawn listens, fascinated but increasingly skeptical, and then he pushes back. Why, he asks, is it necessary to go to Mount Everest or get buried alive to appreciate existence? Why can't the awareness Andre found in a Polish forest be found right here, having a cup of coffee? "I think if you could become fully aware of what existed in the cigar store next door to this restaurant," Shawn says, "it would blow your head off."

This is The Work™️: learning to be fully present in a cigar store rather than accumulating butterflies and waterfalls or optimizing for the highlight reel. The transcendence Andre chased across continents was always available in the texture of an ordinary afternoon, an ordinary Monday. He couldn't access it because he believed that meaning lives in the hard-to-pin-down "elsewhere."

Your Mondays are not obstacles between you and your real life.

They are your real life, and all that remains is whether you're awake for them.

Note published on January 30, 2026 at 3:16 PM UTC - Molly White's activity feed

2026-01-30T15:16:14.000Z

Binance bitcoin bailout

It does not seem to me to bode well that they’re getting this nervous when the bitcoin price hasn’t even dropped below $80,000

Theatre Review: The Hitchhiker’s Guide to The Galaxy - Immersive Experience ★★★⯪☆ - Terence Eden’s Blog

2026-01-30T12:34:41.000Z

You've read the books, listened to the original radio performances, re-read the books, worn the t-shirt - and now it is time to be part of The Hitchhiker’s Guide to The Galaxy.

*Cue the music from Flight of the Sorcerer*

This is a 90-ish minute immersive experience. As well as a full cast of actors and a puppet android, there are ✨celebrity✨ voice cameos.

And songs! So many songs!

Pre Show

I'm always interested in how shows build excitement before a performance. We were encouraged to arrive early to stash our coats (a very reasonable £1 each) and soak up the atmosphere.

It mostly works! We're deposited into the pub with lots of texture. As well as multiple screens displaying a variety on in-jokes, the actors hobnob with the guests. Nifty!

Show

From a technology perspective, the show is astonishingly good. Laser display boards mixed with puppets, dry ice, surround sound, and a hundred little decorations to notice. The actors are witty and talented improvisers. They did well with the matinée audience who needed a little warming up. There's a bar halfway through the experience where you can buy a (typically overpriced) branded beer - but I'd recommend having a warm up Pan Galactic Gargle Blaster in the bar before the show.

Wandering around the Vogon ship is a sonic and visual delight. The chaos of running between the sets feels utterly on-brand for H2G2. The sets are lush and, as mentioned, the technology integrates well with the story.

So, about the story.

There is no continuity in this franchise. Canon is noticeable by its absence and you should throw most of your preconceptions of plot out of the window. This isn't a cosy retread of the books you loved, nor is it a something entirely new. Essentially it is a series of sketches ripped and remixed from various versions. It kind of felt like there was a missing segment in the show - characters disappeared (to go perform for the next set of participants) and then reappeared.

If you have even a passing familiarity with H2G2 (in any of its forms) then I think you'll enjoy it. If not, I think it is a little scattershot. 90 minutes isn't enough to build up much of the complexity or tension in the drama. That said, it is rather jolly fun and surprisingly tender.

Post Show

It isn't quite "exit through the gift shop" but not far off. I remember how the end of the Alien experience in the Trocadero had audience members running out into a public area - here it's a gentle stroll into the bar.

This is a worthy addition to the many different adaptations of Douglas Adams' opus.

The experience runs until the 15th of February at the Riverside Studios. Tickets start at, of course, £42.

Celebrating our 2025 open-source contributions - Trail of Bits Blog

2026-01-30T12:00:00.000Z

Last year, our engineers submitted over 375 pull requests that were merged into non–Trail of Bits repositories, touching more than 90 projects from cryptography libraries to the Rust compiler.

This work reflects one of our driving values: “share what others can use.” The measure isn’t whether you share something, but whether it’s actually useful to someone else. This principle is why we publish handbooks, write blog posts, and release tools like Claude skills, Slither, Buttercup, and Anamorpher.

But this value isn’t limited to our own projects; we also share our efforts with the wider open-source community. When we hit limitations in tools we depend on, we fix them upstream. When we find ways to make the software ecosystem more secure, we contribute those improvements.

Most of these contributions came out of client work—we hit a bug we were able to fix or wanted a feature that didn’t exist. The lazy option would have been forking these projects for our needs or patching them locally. Contributing upstream instead takes longer, but it means the next person doesn’t have to solve the same problem. Some of our work is also funded directly by organizations like the OpenSSF and Alpha-Omega, who we collaborate with to make things better for everyone.

Key contributions

Sigstore rekor-monitor: rekor-monitor verifies and monitors the Rekor transparency log, which records signing events for software artifacts. With funding from OpenSSF, we’ve been getting rekor-monitor ready for production use. We contributed over 40 pull requests to the Rekor project this year, including support for custom certificate authorities and support for the new Rekor v2. We also added identity monitoring for Rekor v2, which lets package maintainers configure monitored certificate subjects and issuers and then receive alerts whenever matching entries appear in the log. If someone compromises your release process and signs a malicious package with your identity, you’ll know.
Rust compiler and rust-clippy: Clippy is Rust’s official linting tool, offering over 750 lints to catch common mistakes. We contributed over 20 merged pull requests this year. For example, we extended the implicit_clone lint to handle to_string() calls, which let us deprecate the redundant string_to_string lint. We added replacement suggestions to disallowed_methods so that teams can suggest alternatives when flagging forbidden API usage, and we added path validation for disallowed_* configurations so that typos don’t silently disable lint rules. We also extended the QueryStability lint to handle IntoIterator implementations in rustc, which catches nondeterminism bugs in the compiler. The motivation came from a real issue we spotted: iteration order over hash maps was leaking into rustdoc’s JSON output.
pyca/cryptography: pyca/cryptography is Python’s most widely used cryptography library, providing both high-level recipes and low-level interfaces to common algorithms. With funding from Alpha-Omega, we landed 28 pull requests this year. Our work was aimed at adding a new ASN.1 API, which lets developers define ASN.1 structures using Python decorators and type annotations instead of wrestling with raw bytes or external schema files. Read more in our blog post “Sneak peek: A new ASN.1 API for Python.”
hevm: hevm is a Haskell implementation of the Ethereum Virtual Machine. It powers both the symbolic and concrete execution in Echidna, our smart contract fuzzer. We contributed 14 pull requests this year, mostly focused on performance: we added cost centers to individual opcodes to ease profiling, optimized memory operations, and made stack and program counter operations strict, which got us double-digit percentage improvements on concrete execution benchmarks. We also implemented cheatcodes like toString to improve hevm’s compatibility with Foundry.
PyPI Warehouse: Warehouse powers the Python Package Index (PyPI), which serves over a billion package downloads per day. We continued our long-running collaboration with PyPI and Alpha-Omega, shipping project archival support so that maintainers can signal when packages are no longer actively maintained. We also cut the test suite runtime by 81%, from 163 to 30 seconds, even as test coverage grew to over 4,700 tests.
pwndbg: pwndbg is a GDB and LLDB plugin that makes debugging and exploit development less painful. Last year, we packaged LLDB support for distributions and improved decompiler integration. We also contributed pull requests to other tools in the space, including pwntools, angr, and Binary Ninja’s API.

A merged pull request is the easy part. The hard part is everything maintainers do before and after: writing extensive documentation, keeping CI green, fielding bug reports, explaining the same thing to the fifth person who asks. We get to submit a fix and move on. They’re still there a year later, making sure it all holds together.

Thanks to everyone who shaped these contributions with us, from first draft to merge. See you next year.

Trail of Bits’ 2025 open-source contributions

AI/ML

Repo: majiayu000/litellm-rs
- By smoelius
  - #3: Specify Anthropic key with x-api-key header
Repo: mlflow/mlflow
- By Ninja3047
  - #18274: Fix type checking in truncation message extraction (#18249)
Repo: simonw/llm
- By dguido
  - #950: Add model_name parameter to OpenAI extra models documentation
Repo: sst/opencode
- By Ninja3047
  - #4549: tweak: Prefer VISUAL environment variable over EDITOR per Unix convention

Cryptography

Languages and compilers

Software analysis/transformation tools

Repo: pygments/pygments
- By DarkaMaul
  - #2819: Add CodeQL lexer
Repo: quarkslab/bgraph
- By DarkaMaul
  - #8: Archive project

Packaging ecosystem/supply chain

Others

Repo: AzureAD/microsoft-authentication-extensions-for-python
- By DarkaMaul
  - #144: Add missing import in token_cache_sample
Repo: SchemaStore/schemastore
- By woodruffw
  - #4635: github-workflow: workflow_call.secrets.*.required is not required
  - #4637: github-workflow: trigger types can be an array or a scalar string
Repo: google/gvisor
- By ret2libc
  - #12325: usertrap: disable syscall patching when ptraced
Repo: oli-obk/cargo_metadata
- By smoelius
Repo: ossf/alpha-omega
- By woodruffw
Repo: rustsec/advisory-db
- By DarkaMaul
  - #2169: Protobuf DoS
- By smoelius
  - #2289: Withdraw RUSTSEC-2022-0044

Published on Citation Needed: "Issue 100 – Freedom of all kinds is worth fighting for" - Molly White's activity feed

2026-01-29T22:38:50.000Z

Published an issue of Citation Needed:

Issue 100 – Freedom of all kinds is worth fighting for

As masked agents execute people and terrorize communities, crypto executives who spent years posting about freedom fall conspicuously silent — except when writing checks for the politicians enabling it

Book Review: The Players Act 1 by Amy Sparkes ★★⯪☆☆ - Terence Eden’s Blog

2026-01-29T12:34:04.000Z

So! Much! Melodrama!

This is a gently funny (and slightly tragic) romp with a band of travelling ~~vagrants~~ actors as they attempt to ply their renditions of Shakespeare to an indifferent 1700ish audience. There's a lot of charm to the characters and the plot is relatively straightforward.

The characters are a bit one-note. The baddie never actually twirls his moustache - but you'll instantly picture him doing it every time he appears. The others very much stay in their lane; the feisty woman who would rather wear trousers, the wide-eyed idealist, the grumpy father. It's rather like they're stock comedia dell'arte tropes come to life.

While there are some lovely lines (and excellent swearing), the story meanders back and forth a bit too much for my liking. I'm possibly not the target audience as I guess this is aimed at the older teen crowd.

I appreciate the book being made available without DRM. How refreshing to pay for a book and receive an unencumbered ePub; no need to liberate it from the clutches of Adobe!

Building cryptographic agility into Sigstore - Trail of Bits Blog

2026-01-29T12:00:00.000Z

Software signatures carry an invisible expiration date. The container image or firmware you sign today might be deployed for 20 years, but the cryptographic signature protecting it may become untrustworthy within 10 years. SHA-1 certificates become worthless, weak RSA keys are banned, and quantum computers may crack today’s elliptic curve cryptography. The question isn’t whether our current signatures will fail, but whether we’re prepared for when they do.

Sigstore, an open-source ecosystem for software signing, recognized this challenge early but initially chose security over flexibility by adopting new cryptographic algorithms as older ones became obsolete. By hard coding ECDSA with P-256 curves and SHA-256 throughout its infrastructure, Sigstore avoided the dangerous pitfalls that have plagued other crypto-agile systems. This conservative approach worked well during early adoption, but as Sigstore’s usage grew, the rigidity that once protected it began to restrict its utility.

Over the past two years, Trail of Bits has collaborated with the Sigstore community to systematically address the limitations of aging cryptographic signatures. Our work established a centralized algorithm registry in the Protobuf specifications to serve as a single source of truth. Second, we updated Rekor and Fulcio to accept configurable algorithm restrictions. And finally, we integrated these capabilities into Cosign, allowing users to select their preferred signing algorithm when generating ephemeral keys. We also developed Go implementations of post-quantum algorithms LMS and ML-DSA, demonstrating that the new architecture can accommodate future cryptographic standards. Here is what motivated these changes, what security considerations shaped our approach, and how to use the new functionality.

Sigstore’s cryptographic constraints

Sigstore hard codes ECDSA with P-256 curves and SHA-256 throughout most of its ecosystem. This rigidity is a deliberate design choice. From Fulcio certificate issuance to Rekor transparency logs to Cosign workflows, most steps default to this same algorithm. Cryptographic agility has historically led to serious security vulnerabilities, and focusing on a limited set of algorithms reduces the chance of something going wrong.

This conservative approach, however, has created challenges as the ecosystem has matured. Various organizations and users have vastly different requirements that Sigstore’s rigid approach cannot accommodate. Here are some examples:

Compliance-driven organizations might need NIST-standard algorithms to meet regulatory requirements.
Open-source maintainers may want to sign artifacts without making cryptographic decisions, relying on secure defaults from the public Sigstore instance.
Security-conscious enterprises may want to deploy internal Sigstore instances using only post-quantum cryptography.

Furthermore, software artifacts remain in use for decades, meaning today’s signatures must stay verifiable far into the future, and the cryptographic algorithm used today might not be secure 10 years from now.

These challenges can be addressed only if Sigstore allows for a certain degree of cryptographic agility. The goal is to enable controlled cryptographic flexibility without repeating the security issues that have affected other crypto-agile systems. To address this, the Sigstore community has developed a design document outlining how to introduce cryptographic agility while maintaining strong security guarantees.

The dangers of cryptographic flexibility

The most infamous example of problems caused by cryptographic flexibility is the JWT alg: none vulnerability, where some JWT libraries treated tokens signed with the none algorithm as valid tokens, allowing anyone to forge arbitrary tokens and “sign” whatever payload they wanted. Even more subtle is the RSA/HMAC confusion attack in JWT, where a mismatch between what kind of algorithm a server expects and what it receives allows anyone with knowledge of the RSA public key to forge tokens that pass verification.

The fundamental problem in both cases is in-band algorithm signaling, which allows the data to specify how it should be protected. This creates an opportunity for attackers to manipulate the algorithm choice to their advantage. As the cryptographic community has learned through painful experience, cryptographic agility introduces significant complexity, leading to more code and increased potential attack vectors.

The solution: Controlled cryptographic flexibility

Instead of allowing users to mix and match any algorithms they want, Sigstore introduced predefined algorithm suites, which are complete packages that specify exactly which cryptographic components work together.

For example, PKIX_ECDSA_P256_SHA_256 not only includes the signing algorithm (ECDSA P-256), but also mandates SHA-256 for hashing. A PKIX_ECDSA_P384_SHA_384 suite pairs ECDSA P-384 with SHA-384, and PKIX_ED25519 uses Ed25519 and SHA-512. Users can choose between these suites, but they can’t create dangerous combinations, such as ECDSA P-384 with MD5.

Critically, the choice of which algorithm to use comes from out-of-band negotiation, meaning it’s determined by configuration or policy, not by the data being signed. This prevents the in-band signaling attacks that have plagued other systems.

The implementation

To enable cryptographic agility across the Sigstore ecosystem, we needed to make coordinated changes that would work together seamlessly. Cryptography is used in several places within the Sigstore ecosystem; however, we primarily focused on enabling clients to change the signing algorithm used to sign and verify artifacts, as this would have a significant impact on end users. We tackled this change in three phases.

Phase 1: Establishing common ground

We introduced a centralized algorithm registry in the Protobuf specifications that defines all allowed algorithms and their details. We also implemented default mappings from key types to signing algorithms (e.g., ECDSA P-256 keys automatically use ECDSA P-256 + SHA-256), eliminating ambiguity and providing a single source of truth for all Sigstore components.

Phase 2: Service-level updates

We updated Rekor and Fulcio with a new --client-signing-algorithms flag that lets deployments specify which algorithms they accept, enabling custom restrictions like Ed25519-only or future post-quantum-only deployments. We also fixed Fulcio to use proper hash algorithms for each key type (SHA-384 for ECDSA P-384, etc.) instead of defaulting everything to SHA-256.

Phase 3: Client integration

We updated Cosign to support multiple algorithms by removing hard-coded SHA-256 usage and adding a --signing-algorithm flag for generating different ephemeral key types. Currently available in cosign sign-blob and cosign verify-blob, these changes let users bring their own keys of any supported type and easily select their preferred cryptographic algorithm when ephemeral keys are used. Other clients implementing the Sigstore specification can choose which set of algorithms to use, as long as it is a subset of the allowed algorithms listed in the algorithm registry.

Validation: Proving it works

To demonstrate the flexibility of our new architecture, we developed HashEdDSA (Ed25519ph) support in both Rekor and the Sigstore Go library and created Go implementations of post-quantum algorithms LMS and ML-DSA. This work proved that our modular architecture can accommodate diverse cryptographic algorithms and provides a solid foundation for future additions, including post-quantum cryptography.

Cryptographic flexibility in action

Let’s see this cryptographic flexibility in action by setting up a custom Sigstore deployment. We’ll configure a private Rekor instance that accepts only ECDSA P-521 with SHA-512 and RSA-4096 with SHA-256, by using the --client-signing-algorithms flag, demonstrating both algorithm restriction and the new Cosign capabilities.

~/rekor$ git diff
diff --git a/docker-compose.yml b/docker-compose.yml
index 3e5f4c3..93e0d10 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -120,6 +120,7 @@ services:
 "--enable_stable_checkpoint",
 "--search_index.storage_provider=mysql",
 "--search_index.mysql.dsn=test:zaphod@tcp(mysql:3306)/test",
+ "--client-signing-algorithms=ecdsa-sha2-512-nistp521,rsa-sign-pkcs1-4096-sha256",
 # Uncomment this for production logging
 # "--log_type=prod",
 ]

$ docker compose up -d

Let’s create the artifact and use Cosign to sign it:

$ echo "Trail of Bits & Sigstore" > msg.txt
$ ./cosign sign-blob --bundle cosign.bundle --signing-algorithm=ecdsa-sha2-512-nistp521 --rekor-url http://localhost:3000 msg.txt
Retrieving signed certificate...
Successfully verified SCT...
Using payload from: msg.txt
tlog entry created with index: 111111111
Wrote bundle to file cosign.bundle
qzbCtK4WuQeoeZzGP1111123+...+j7NjAAAAAAAA==

This last command performs a few steps:

Generates an ephemeral private/public ECDSA P-521 key pair and gets the SHA-512 hash of the artifact (--signing-algorithm=ecdsa-sha2-512-nistp521)
Uses the ECDSA P-521 key to request a certificate to Fulcio
Signs the hash with the certificate
Submits the artifact’s hash, the certificate, and some extra data to our local instance of Rekor (--rekor-url http://localhost:3000)
Saves everything into the cosign.bundle file (--bundle cosign.bundle)

We can verify the data in the bundle to ensure ECDSA P-521 was actually used (with the right hash function):

$ jq -C '.messageSignature' cosign.bundle
{
 "messageDigest": {
 "algorithm": "SHA2_512",
 "digest": "WIjb9UuEBgdSxhRMoz+Zux4ig8kWY...+65L6VSPCKCtzA=="
 },
 "signature": "MIGIAkIBRrn.../zgwlBT6g=="
}

$ jq -r '.verificationMaterial.certificate.rawBytes' cosign.bundle | base64 -d | openssl x509 -text -noout -in /dev/stdin | grep -A 6 "Subject Public Key Info"
 Subject Public Key Info:
 Public Key Algorithm: id-ecPublicKey
 Public-Key: (521 bit)
 pub:
 04:01:36:90:6c:d5:53:5f:8d:4b:c6:2a:13:36:69:
 31:54:e3:2d:92:e0:bd:d5:77:35:37:62:cd:6a:4d:
 9f:32:83:97:a7:0d:4e:48:73:fe:3c:a2:0f:f2:3d:

Now let’s try a different key type to see if it’s rejected by Rekor. To generate a different key type, we just need to switch the value of --signing-algorithm in Cosign:

$ ./cosign sign-blob --bundle cosign.bundle --signing-algorithm=ecdsa-sha2-256-nistp256 --rekor-url http://localhost:3000 msg.txt
Generating ephemeral keys...
Retrieving signed certificate...
Successfully verified SCT...
Using payload from: msg.txt
Error: signing msg.txt: [POST /api/v1/log/entries][400] createLogEntryBadRequest {"code":400,"message":"error processing entry: entry algorithms are not allowed"}
error during command execution: signing msg.txt: [POST /api/v1/log/entries][400] createLogEntryBadRequest {"code":400,"message":"error processing entry: entry algorithms are not allowed"}

As we can see, Rekor did not allow Cosign to save the entry (entry algorithms are not allowed), as ecdsa-sha2-256-nistp256 was not part of the list of algorithms allowed through the --client-signing-algorithms flag used when starting the Rekor instance.

Future-proofing Sigstore

The changes that Trail of Bits has implemented alongside the Sigstore community allow organizations to use different signing algorithms while maintaining the same security model that made Sigstore successful.

Sigstore now supports algorithm suites from ECDSA P-256 to Ed25519 to RSA variants, with a centralized registry ensuring consistency across deployments. Organizations can configure their instances to accept only specific algorithms, whether for compliance requirements or post-quantum preparation.

The foundation is now in place for future algorithm additions. As cryptographic standards evolve and new algorithms become available, Sigstore can adopt them through the same controlled process we’ve established. Software signatures created today will remain verifiable as the ecosystem adapts to new cryptographic realities.

Want to dig deeper? Check out our LMS and ML-DSA Go implementations for post-quantum cryptography, or run --help on Rekor, Fulcio, and Cosign to explore the new algorithm configuration options. If you’re looking to modernize your project’s cryptography to current standards, Trail of Bits’ cryptography consulting services can help you get on the right path.

We would like to thank Google, OpenSSF, and Hewlett-Packard for having funded some of this work. Trail of Bits continues to contribute to the Sigstore ecosystem as part of our ongoing commitment to strengthening open-source security infrastructure.

Are there any open APIs left? - Terence Eden’s Blog

2026-01-28T12:34:01.000Z

One of the dreams of Web 2.0 was that website would speak unto website. An "Application Programming Interface" (API) would give programmatic access to structured data, allowing services to seamlessly integrate content from each other. Users would be able to quickly grab data from multiple sources and use them for their own purposes. No registration or API keys, no tedious EULAs or meetings. Just pure synergy!

Is that dream dead? If so, what killed it?

A decade ago, I posted a plea looking for Easy APIs Without Authentication with a follow up post two years later. I wanted some resources that students could use with minimal fuss. Are any of the APIs from 10 years ago still alive?

Alive

These ones are still around:

Wikipedia - Yes! Still going strong.
Police.uk - Yes! After a brief dalliance with API registration, it is now back to being completely free and open.
Google Books ISBN - Yes! Obviously Google have forgotten it exists; otherwise it would have been killed off by now!
iTunes Lookup - Yes! Possibly the only thing Apple don't charge a premium for.
Pokémon API - and still receiving frequent updates.
MusicBrainz - this Internet stalwart will never die.
Open Notify - a collection of space APIs, although the code hasn't been updated in ages.

Dead

These have shuffled off this mortal coil:

BBC Radio 1 - No.
Twitter URL statistics - LOLSOB No.
Star Wars API - No.
British National Bibliography - No. Dead due, I think to the British Library's cyber attack.
Football Data - gone.

API Key Required

These are still alive, but you either need to pay or register to use them:

What Happened?

Something something … enshittification … blah blah … zero interest rate phenomenon … yadda yadda our incredible journey …

But back in the land of rationality, I've had a lots of experiences running APIs and helping people who run them. The closure and lockdown of APIs usually comes down to one or more of the following.

APIs cost money to run. Yes, even the static ones have a non-zero cost. That's fine if you're prepared to endless subsidise them - but it is hard to justify if there's no return on investment. Anyway, who is using all this bandwidth? Which leads on to:

Lack of analytics. Yes, I know tracking is the devil, but it is hard to build a service if you don't know who is using it. Sure, you can see traffic, but you can't tell if it is useful to the end consumer, or what value you can share. There's no way to communicate with an anonymous consumer. Which, of course, takes us to the next barrier:

Communication is key. If you need to change your API, there's no way to tell users that a change is coming. That might be the announcement of a deprecation, an outage, or an enhancement. You can try smuggling error messages into your responses and hoping someone notices a failing service somewhere - but it's much easier to email everyone who has an API key. And you know what else keys are good for?

Stopping abuse. It'd be nice if everyone played nice online; but some people are raging arseholes. Being able to throttle bad actors (figuratively or literally) is a desirable feature. On a resource constrained service, you sometimes have to put rules in place.

Still, if you know of any good open APIs which don't require registration, and that you think will survive until 2036, please drop a link in the comments.