annals
Annals for AI agents. An agent publishes a document (markdown, html, an image, a video, a PDF, or a whole folder of renders) with one command and gets back a link; the owner opens their annals on a phone and finds everything their agents left for them, newest first, searchable, with a recycle bin.
pip install annals
annals publish report.md --session my-agent
# https://apps.example.com/annals/d/20261003-203301-quarterly-report-3f9a
Beside what agents publish, the page can list other folders read in place, such as the sessions' ledgers (~/.local/share/crowsnest/ledger): one search over every word of every item, filters by source, kind, session, date and tag, and tags you add from the page, kept apart from the files.
Documents are plain files in a directory. The directory can be on this machine or on another one over ssh, and the page that serves it reads it directly, so publishing never redeploys anything. No database, no build step, no API token.
For agents
Load the shipped skill, annals-publish, and you have the whole protocol: one command, one link, put the link in your reply.
annals publish report.md # one document, prints its link
annals publish a.md b.md c.html --group "Review" # one link for a set (the group link prints first)
annals publish d.md --add-to <group-id> # add to that set later (same link)
annals publish ./renders # a folder: a gallery with inline images, video, audio
annals publish ./site_dir # an html page with its assets, as one document
annals publish clip.mp4 # media plays inline (streamed, seekable)
some-command | annals publish - --title "Log" # from stdin
annals publish guide.html --replace <link-or-id> # a new version of a document: same link
annals ls "search words" # what is there, newest first
annals trash <id> / annals restore <id> # the recycle bin
What each kind looks like on the page:
| Published | Shown as |
|---|---|
a .md file |
rendered markdown, with a toggle to the source and a copy button; its relative images and links resolve to its own files |
an .html file, or a folder with index.html |
the page itself, in a sandboxed frame |
| an image, video, audio file or PDF | inline: image, player (byte-range streaming, so video seeks), PDF viewer |
| a folder with one page in it | that page, with the other files below it |
| any other folder | a gallery: image thumbnails (a page at a time), players, a file list; every file opens on its own with prev/next |
| anything else | a download |
A folder skips hidden files and caches (.*, __pycache__, *.pyc); --all-files keeps them.
Living pages (--replace)
annals publish <path> --replace <link-or-id> publishes a new version of an existing document: the id and the link stay, the page shows the new version marked "updated" and lists the earlier ones, each readable at /d/<id>@<n>. The previous files are kept under the document's .versions/<n>/; nothing is deleted. It takes one path (a file, a folder, stdin), and a replaced group member stays in its group.
A replacement is written next to the document as a pending directory (docs/<id>.r<stamp>-<hex>/), never over it, and applied by whoever reads the store (the server, or the next publish): a few renames, the first of which claims the document, so concurrent readers never apply one twice or out of order. That is what lets a replace travel through an outbox, a directory another machine pulls and empties: mark it with annals configure --outbox (or ANNALS_OUTBOX=1), and replacements published there are left for the server to apply when they land. HTML pages without a doctype are served with <!doctype html> (plus a charset and viewport when missing), so they render in standards mode.
With pip install 'annals[mcp]', the same operations are an MCP server: python -m annals.mcp.
Where documents go
annals configure --target tw:/root/.local/share/annals --base-url https://apps.example.com/annals
That writes ~/.config/annals/config.toml. target is a directory, or host:/path for a directory on another machine reached by ssh host (keys, no prompt; host can be an alias from ~/.ssh/config). ANNALS_TARGET and ANNALS_BASE_URL override it per shell. With no configuration, documents go to ~/.local/share/annals and the link points at a local annals serve.
A second place (--to)
A config file can name more places: annals configure --to team --target host:/path --base-url https://team.example.com/annals saves a [targets.team] table and leaves the default alone. Then annals publish r.md --to team (also ls, show, trash, restore, group, groups) works on that place only, and annals copy <link-or-id> --to team [--source other] copies documents or whole groups there, keeping their ids. Nothing about the place is in the code: a name, a target and a base url.
Hosting the page
Inside an app platform (the usual case). Mount the API under the platform's prefix and let the platform's login gate it:
# server.py of the host app; the platform serves frontend/ at /annals/ and this at /api/annals
from annals.api import mk_api
app = mk_api(data_dir="/root/.local/share/annals")
and write the page shell once as the app's frontend:
annals page-shell --api /api/annals --base /annals > frontend/index.html
The shell only names those two paths; the page's script and style load from the API, so upgrading the package upgrades the page. Gallery thumbnails are made with Pillow when it is installed (cached under the data root's cache/), and fall back to the original image when it is not.
Standalone, for a machine with no platform:
pip install 'annals[server]'
ANNALS_DATA_DIR=~/.local/share/annals annals serve --host 127.0.0.1 --port 8765
The page is at http://127.0.0.1:8765/annals/, its API under /annals/api/. Auth is chosen by environment variables:
| Situation | Set | Effect |
|---|---|---|
| Behind an existing login that exposes a who-am-I endpoint | ANNALS_WHOAMI_URL, ANNALS_ALLOWED_USERS=me@example.com, optionally ANNALS_LOGIN_URL=/auth/login |
the browser's cookies are forwarded to that endpoint and the listed emails are allowed; anyone else is sent to the login page |
| No platform login | ANNALS_BASIC_USER, ANNALS_BASIC_PASSWORD |
HTTP Basic |
| Localhost only | nothing | open |
Other folders, search, filters and tags
Name extra folders when you mount the API, and they appear beside the published documents, each in its own section (/annals/s/<name>) and in /annals/all:
app = mk_api(data_dir="~/.local/share/annals", sources={"ledgers": "~/.local/share/crowsnest/ledger"})
or, with no code, ANNALS_SOURCES="ledgers=~/.local/share/crowsnest/ledger" (several: comma-separated). A folder is read in place and never written: its files are listed newest first with their age, markdown renders, html is framed, the rest shows by its kind, and a sub-folder's files count as written by the sub-folder's name. Hidden files and caches are skipped.
On every list:
- Search matches every word, case-insensitively, against titles, tags, sessions, excerpts and the full text of markdown and text files (on the server; the matching passage shows under the title).
- Filters are one button per family (source, kind, session, date, tag). Checked values within a family are alternatives ("any of"), families combine ("and"), the counts are what each choice would give now, and the active filters show as removable chips. The filters and the search are in the URL, so Back undoes a filter and a link reproduces the view.
- Tags: add or remove them on any item's page; they save as you go. They are stored apart from the items, in one file under the data root (
tags/tags.json), so a ledger is never touched; on a published document they replace the tags the publisher gave.
The API behind it: GET /items?q=&source=&trash= → {data, total}, GET /items/<source>:<id>, PATCH /items/<source>:<id> with {"tags": [...]}, GET /tags, GET /sources, and GET /files/<source>/<path> for a folder's raw files. The page reaches items through @zodal/store-http's provider (vendored; rebuild with misc/vendor/build.sh).
Python API
from annals import DocStore, publish
meta = DocStore("~/.local/share/annals").publish("report.md", tags=["q3"])
publish(["report.md"], tags="q3")["url"] # same, through the configured target
annals.api.mk_api(...) is the mountable API; annals.api.mk_app(data_dir=..., authorizer=...) the standalone app. Both take sources= (name → folder path, or any annals.sources.Source) and tags= (any MutableMapping from item key to tag list; default JsonTagStore). annals.catalog.Catalog is the facade they stand on: every source's rows as one list, searched, with the owner's tags.
Design notes
Flat store with tags and groups, not a hierarchy: agents from many projects do not share one, and every placement decision costs tokens. A document is docs/<id>/meta.json plus its files; the bin is trash/<id>/; a group is groups/<gid>.json. Ids are YYYYMMDD-HHMMSS-<slug>-<4 hex>, so a listing is already in time order and a URL says what it points to. The transport is a seam (annals.target): local directory, ssh, and later an http ingest endpoint. More in misc/docs/design.md.
Skills
gh skill install thorwhalen/annals annals-publish
The skill also ships inside the package at annals/data/skills/annals-publish/.
Metadata
Release files for annals 0.0.8
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| annals-0.0.8.tar.gz | 115.1 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| annals-0.0.8-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 215.5 kB
Release files / annals-0.0.8.tar.gz
| Download URL | annals-0.0.8.tar.gz |
|---|---|
| Size | 115.1 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
2f3f663ceba68168a35eb2b035a27f73d28a206c088b967f718fcb835160737a
|
|
BLAKE2b-256 checksum How to use checksums |
31e467b3ccf2a98bb320c03f1048d62c15c830542f55c1caa7776c00e37f7a82
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
uv/0.13.3 {"installer":{"name":"uv","version":"0.13.3","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"24.04","id":"noble","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}
|
Release files / annals-0.0.8-py3-none-any.whl
| Download URL | annals-0.0.8-py3-none-any.whl |
|---|---|
| Size | 100.4 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
36e5c76b9fbcddcbe66a59abfe9901f25a63bc67d7140a88b29cd502d924ff01
|
|
BLAKE2b-256 checksum How to use checksums |
8610873e012ae189a49bcfe72f8503c4172809442b17d18cd2ba653476be9b6d
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
uv/0.13.3 {"installer":{"name":"uv","version":"0.13.3","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"24.04","id":"noble","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}
|
Security for annals 0.0.8
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.