Knowledge Base
Browse the concepts behind Truestamp. Follow the links between concepts, or search across everything.
Tagged: item
23
Glossary
Authorship
The immutable audit-trail record of who submitted an item (its creator), set once at submission, never consulted for rights decisions, and deliberately excluded from every cryptographic hash, so a Truestamp proof makes no claim about who authored the underlying data.
Claims
The user-supplied data map an item is made of - a required name plus optional external content hash and algorithm, description, URL, location, freeform metadata, and user timestamp, JCS-canonicalized so the claims hash stays independently reproducible by the submitter.
Claims hash
The claims fingerprint, a SHA-256 hash, under the item-claims byte prefix 0x11, of the JCS-canonicalized claims a user submitted and nothing else; independently reproducible by anyone holding the claims, and one of the two fingerprints bound into the item's composite fingerprint.
Claims-only submission
Submitting an item without an external hash so the claims themselves are the timestamped content of record; requires a description of at least 32 characters or non-empty metadata, and the JCS-encoded claims must fit the team billing owner's per-plan byte budget (256 B Free up to 16 KB Enterprise).
Committed
The normal resting state on both Truestamp ledgers - an item is committed once its item hash is a leaf in a finalized block (Item Commitment), and a block is committed once its block hash is covered by an epoch recorded on a public blockchain (Block Commitment).
Item
A single unit of data submitted to Truestamp for timestamping - identified by its composite fingerprint, belonging to exactly one team, with a transferable owner and an immutable creator, advancing through the created, processing, and committed states.
Item Commitment
The first Truestamp commitment event: an item's item_hash becomes a Merkle-tree leaf in a finalized block, recorded with a compact inclusion proof, moving the item to the committed state and proving it was submitted within that block's submission window.
Item hash
The item's composite fingerprint, a SHA-256 hash (prefix 0x13) binding an item's ULID, claims hash, metadata hash, and signing-key ID into one value; it becomes the item's Merkle-tree leaf in a Truestamp block and is the value Truestamp signs, with authorship and ownership deliberately excluded.
Item retention
The per-plan window a Truestamp item is kept - 90 days on the Free tier (expired items enter the deleted_expired state with an email warning and a 7-day cancellable grace period), unlimited on paid tiers; team-owned items follow the team billing owner's plan.
Item states
The lifecycle states of a Truestamp item - created (waiting), processing (assigned to a block being built), committed (a leaf in a finalized block), redacted, plus the deletion states deleted_user and deleted_expired (7-day cancellable grace).
Item visibility
The per-item read scope - private (default; only the item's user-owner plus the owning team's admins and owners), team (any member of the owning team), or public (readable by anyone, including anonymous visitors); visibility controls who can read an item, ownership controls who can change it.
Metadata hash
The timing fingerprint, a SHA-256 hash (prefix 0x12) over the small system-generated record naming the witnesses an item was submitted after, committing to the submitted-after edge without touching user data; a bundle carries the record itself, so the hash is recomputed, never trusted.
Ownership
The transferable rights holder of a Truestamp item, either a single user or a team, that every rights decision (read, update, redact, restore, delete, reassign) is authorized against; ownership can change hands without altering any hash, so an existing proof stays valid across transfers.
Redaction
Removing a committed item's claims content while preserving every hash (claims, metadata, item) so the inclusion proof stays valid - restoring requires claims that canonicalize and hash to the preserved claims hash, making unredaction verifiable rather than a blind overwrite.
Items
Item Lifecycle
The states a Truestamp item moves through from created to committed, plus the terminal redacted and deletion states, what each means to a user, how an item advances to committed, and how ownership governs who can act at each stage.
Item Ownership vs Authorship
The Item split between immutable authorship (audit-only creator record excluded from every hash, with one exception when the author's account is deleted) and transferable ownership (the user or team rights holder driving all rights-based decisions), plus the creator-retains vs team-retains model.
Item Visibility
The three item visibility levels (private, team, public), who can read an item at each level, how public items are discovered through anonymous search and the public verification page, who can set and change visibility, and why visibility changes never affect an item's hashes or proof.
Submit an Item
How to timestamp data by submitting an item on the web form, JSON:API, GraphQL, console WebSocket, CLI, or an MCP agent, with every claims field (name, hash and hash type, description, URL, location, timestamp, metadata), hash mode versus plan-gated claims-only mode, and the limits that apply.
The Item's Composite Fingerprint
How an item's claims fingerprint and timing fingerprint are bound into the composite fingerprint (item_hash) so user data stays independently verifiable, the witnesses that open the submitted-after edge are committed, and authorship is deliberately excluded from every hash.