Skip to content

What does a note's signature commit to, and when does it seal? #229

Closed

Description

@brianorwhatever

Part of #227

Question

What does a note's signature commit to, and at what moment does it seal?

listEnvelopes holds an append-only signed CEL event log — that is what makes a list's did:cel verifiable. Prose is continuously mutable in a way an item row is not: if every edit is an event the envelope grows without bound, and if edits are not events the signature stops meaning "this text, at this time."

The decision needs to name: what bytes the proof covers, what triggers a seal (explicit publish? idle timeout? every save?), and what a reader is entitled to conclude from a verified note — "this exact text existed at time T" vs "this note has a history and here it is."

Blocked by the prose-location decision, and informed by the CEL research ticket.

Activity

  1. brianorwhatever commented on Sep 30, 2026

    @brianorwhatever
    ContributorAuthor

    Resolution

    • A note is sealed on publish only. Each publish or re-publish appends one version of the body resource (Where does a note's prose live in the lists model? #228). Drafts are never sealed.
    • What's kept: the latest sealed version's text stays inline in the envelope, so verifying the current note needs nothing else. Older versions are stripped to their hash, and their text is stored in the bucket keyed by sha256 (the pattern attachments already use), so the full history can still be checked. The research (How does CEL handle a large, frequently-mutated text field? #233) confirmed that the SDK verifies hash-only resources and that keeping every version inline breaks the 1 MiB limit.
    • What a verified note tells a reader: this exact text was sealed by the author's key at publish time N, and the earlier published versions existed with these hashes (and this text, fetched from the bucket).
    • The device-bound key is a separate problem. Signing keys live only in the creating device's localStorage, so a note can only be sealed from that device. That's split into its own in-scope ticket. It decides who can seal, not what a seal commits to.
    • Follows from this: because the log can't be compacted and each append re-verifies the whole log, append cost grows with the number of publishes, not the number of edits. That's acceptable.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions