2026-19

Evidence based vouching

Vouch on Tangled is evolving a bit more with evidences. If you recieve a PR on Tangled, the UI helpfully suggests that you vouch/denounce the submitter for their contribution. The ATURI of that PR is attached as a piece of evidence to your vouch record of that user, and is visible to your circle. They can now use this piece of evidence to inform their descision.

Code-navigation with tree-sitter

I have a semi-complete architecture in mind for this piece of work now. The Tangled code-indexing service will maintain a n-gram search index of each git repository, but also store a "scope graph". Scope-graph is an informal term I came up with as a midground between stack-graphs and ctags. Allow me to explain:

• tree-sitter-graph is a DSL that lets you map a program's syntax graph, its AST, to a new graph
• one such graph could be a graph of interesting lexical regions of a single file
• I have coined the term "scope graph" to refer to such a graph

A "scope graph" keeps track of definitions, references, scopes and imports in any program. Not all programs have such concepts, but many do, by being generic, we take off some of the implementation load.

We can build such a graph by walking a file's syntax tree and mapping regions to defs, refs, scopes or imports. A DSL known as tree-sitter-graph exists to do such a thing. This part is language-specific, but is quite simple to write.

Once a graph is built, a generic algorithm can be used to query references, given a definition, or vice-versa. It incorporates some basic lexical scoping rules. If no results are found, it can fall back to the n-gram index to perform a text-based search.

At index time, a graph is generated for each file in the worktree, at query time, each graph is stiched together to get defs/refs across a project. Thus, only one file in the index needs an update when one file in the worktree changes.

Package repositories on AT

I have had a project in my graveyard of projects to write a crate registry on AT. The idea is to simply use a user's PDS as a single-tenant package registry. The following are steps needed to achieve that:

• the lexicon will include a .crate file blob, as well as the registry manifest (which is just a Cargo.toml file + a checksum)
• an ingester, or a super-registry, will simply ingest these records and namespace them accordingly, and expose them as sparse indices
• users can use the super-registry to find a registry of their choice, and install a package from there by invoking:

[registries]
oppili = { index = "https://super.registry/oppi.li" }

...

cargo add foo --registry oppili

I have learned over lunch today with Mark Elvers that the opam ecosystem is not all that different!