Discussion on "The Globe: Following Your Reasoning Into Other People's Repositories"

Oliver Zehentleitner · 2026-10-01T15:17:36.552Z

A decision rarely stands alone. We retry three times may exist because the payment provider counts every attempt against our error budget. We pinned this WebSocket library may exist because the upstre

The cross-origin fetch part is what stands out most to me here -- the browser reads another repo's .keep-the-why, then fetches that repo's state.json directly, no server in between. GitHub Pages happens to serve everything with permissive CORS by default, which is probably why this works smoothly for the examples here, but the post calls out "GitHub Pages or another static host." For a host that doesn't set Access-Control-Allow-Origin -- a bare S3 bucket without CORS configured, a plain nginx box serving static files -- does the Globe just silently drop that wave, or is there a visible failure state distinguishing "nothing there" from "blocked by CORS"? That seems like exactly the kind of thing that would be invisible until someone hits it.

Should be fixed with PR #585 and #586, released in dashboard 0.6.8. In the status bar at the bottom of the dashboard (https://keepthewhy.com/dashboard/live/) it says something like "10 states · 628.3 KB" - click on that. That's the "State Monitor": it lists every state the page loaded, and from now on also every one that failed, with the reason (e.g. "network error or blocked by CORS") and the address. A failed repository is also named in the globe's legend.

That's a fast turnaround - PR shipped within the hour of the question. Naming CORS explicitly next to "network error" in the State Monitor is the right fix, since a bare "failed to fetch" really could mean five different things and a reader has no way to tell host-down from CORS from the repo just not existing. Having the legend call out the specific failed repository too closes the exact gap I was poking at - that's the detail that would otherwise have cost someone a long debugging session assuming their own export was broken.

Thanks for the hint :)

Really like the idea of keeping the repository as the source of truth instead of turning project memory into another centralized service. Curious to see how this works once the graph gets much larger.

Yes, that's the experiment :) Maybe it turns out to be a fit for small and mid-sized teams only, but I'm curious how far it goes too.

I like that the graph only draws relations that were actually recorded — inferred edges would quietly undermine the provenance the whole thing is built on. Question: does the registry also help with the reverse direction, i.e. finding out who references your decisions? Or is that only visible once you load the citing project?

Thanks - that was exactly the reasoning: an edge in the graph means someone wrote it down, nothing else. On the reverse direction: right now only by loading. The registry index is just the list (where each export lives, versions, size), not who cites whom. The globe can load everything listed in one wave, and from then on the graph shows citations both ways - so with the registry you do see who references you, but you pay for loading them, and that won't scale forever. Since the registry build already reads every export, it could write a small reverse index on the side, so a dashboard sees who cites it without loading them all. Not there yet, but it's one possible way if more projects get listed.

Now with dashboard 0.6.14 it can! See the "cited by" filter in the graph. Turn off friends to see it in this setup: https://keepthewhy.com/dashboard/live/#graph

Search Hashnode

The Globe: Following Your Reasoning Into Other People's Repositories

Responses(10)