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 an n-gram search index of each git repository, but also store "scope graphs". 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 a file. 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. A file is a good boundary to draw around a unit of the index.

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!