Module ics_feeds 

Calendar feed tokens — Phase 24.3.

A feed is a bearer credential of its own kind: 32 random bytes, shown once, stored here only as a SHA-256 hash — the same shape users::create_user_token already uses for API tokens, for the same reason. GET /ics/{token}.ics looks a presented token up by its hash and never needs the plaintext again.

user_id = NULL means the feed belongs to the vault owner and is built from every entry, unfiltered. A non-null user_id means the feed must be re-filtered through filter_vault_for_user on every fetch, not once at creation — a permission revoked after the feed was minted has to shrink it, or the feed outlives the access it was issued under.

Structs

FeedRecord

Functions

create_feed

Mints a feed. Returns the record and the plaintext token — the only time the plaintext exists outside the requester’s own response.

find_active_feed_by_token

Looks a presented token up by its hash. Revoked feeds are excluded here rather than filtered by the caller, so a revoked token can never be reached by forgetting one check site.

init_schema

Creates the table if absent. Called from crate::init_schema.

list_feeds

Feeds visible to the caller: every feed for the owner, only the caller’s own otherwise.

revoke_feed

Revokes a feed. An owner may revoke any feed; a sub-user only their own — enforced here rather than trusted to the caller, since this is the one place that decides whether a URL someone thought they killed still works.

touch_feed

Stamps the last-fetch time. Deliberately not an audited write — a calendar client polling hourly would grow the hash-chained audit log without bound, the same reason vault reads stopped being audited.