Thank you! This is the concept I've been looking for. I always had the sense that compositional data transformation frameworks like PRQL or LINQ should have a clean categorical interpretation. I was exploring how this could be expressed in terms of monads but they usually start with the data while I was trying to formalise the composition of the transformations. I think transducers are it.
Transducers are just the morphisms in the category of the reducing-functions. No problem!
I like this and think it's a great idea. Leveraging git makes a lot of sense (content addressed filesystem, efficient storage and sync protocol with pack files etc ..., widely deployed).
From a cursory look my impression is that it deviates from git too much and therefore I can't use my git knowledge to predict how it will behave. I'm quite rusty on git internals but afair .git/refs/ is great because you can do what you like in there but the downside is that it doesn't hook into the rest of the git structure.
So how does this work with branches, worktrees, etc...? Having a jsonl message log in .git/refs/h5i/msg seems very linear. Presumably you store commit refs in the json obj or context dag, but what if I rebase the branch and the original commits are dropped because they're not referenced anymore? Or say I follow the conversation and want to rewind a few messages and branch from there in a separate worktree, how does that work?
Your repo README does say:
- "It uses dedicated refs, so it doesn’t pollute your working tree or your normal branch graph."
- "Because these are Git objects, they are content-addressed, deduplicated, pushable, fetchable, and survive `git gc`."
- "Because the log lives in refs/h5i/msg, a conversation survives clones, machines, and branches — it travels with h5i share push / pull, and divergent sends from two machines union-merge with no message lost."
Therefore these look like design decisions and it would be nice to understand them better.
My first instinct would be to put most of what you have under .git/refs/h5i/ in a .h5i folder in the repo itself and manage some shadow branches under .git/heads/.h5i/ with multi-parent commits pointing at the context commit as well as the previous h5i message commit along with some hooks to handle rebases etc ... . That way battle hardened git machinery gets used and more importantly to me, I can leverage my existing git knowledge to understand dependencies. That would go against your "it doesn’t pollute your working tree or your normal branch graph" goal but I'm of the "explicit is better than implicit" Python school so I like to have the details exposed as long as I can filter them out easily (or by default).
Test Drive 2 (and 1) used a pseudo-3D renderer with scaled sprites (see https://www.mobygames.com/game/2107/the-duel-test-drive-ii/s...)
TD3 used a 'real' 3D engine, but as a result it needed a beefy machine for the day. Driving felt a lot slower too, I never found it as much fun as TD2.
You can do this with ATProto / Bluesky! You can self-host your own PDS (or use Bluesky) and clients are super simple. I just had Google Search AI Mode vibe code as a 60 line shell script.
$ curl -O https://raw.githubusercontent.com/snth/radar/refs/heads/main/radar
$ chmod +x radar
$ ./radar [email protected]
[RADAR] Scanning for snth.bsky.social...
[RADAR SCREEN]
User: Tobias Brandt (@snth.bsky.social)
Status: Active
Last Seen: 2026-05-28T19:42:15.865Z
--------------------------------------------------
Just vibe coded a 60 line POSIX script Bluesky client in the style of `finger` of old:
github.com/snth/radar
--------------------------------------------------
If you wanted to be more authentic to the original you could implement a custom Lexicon.
Transducers are just the morphisms in the category of the reducing-functions. No problem!
reply