Timeline providers

Provider responsibilities

A timeline provider is the trust anchor between a participant and a document. Its core responsibilities:

1. Verify identity. Establish, at some level of assurance, who controls a timeline.
2. Sign and store entries. Maintain an append-only, hash-linked log of entries.
3. Attribute actors. Distinguish a principal acting directly from an agent acting on behalf of the principal.
4. Order entries. Provide timestamps and a stable ordering processors can rely on.
5. Signal completeness. Tell processors whether a window of entries is fully delivered, so multiple processors can converge.
6. Make entries queryable. Expose entries to processors and other participants under appropriate permissions.

Identity verification levels

Different interactions require different levels of identity assurance. Providers commonly support a spectrum:

• Self-attested — "I claim to be Alice." Cheap, fast, low trust.
• Email or device verified — proof of access to an email or device.
• KYC'd — verified personal identity, used by banks and regulated providers.
• Government-grade — eIDAS-style or national digital identity. Highest assurance.

Minimal provider API shape (illustrative)

Real providers will publish their own APIs. As a directional sketch, the operations a provider needs to expose look like this:

# Append a new entry to a timeline
POST /timelines/{timelineId}/entries
Body: signed Conversation/Timeline Entry
→ { entryBlueId, ackTimestamp }

# List entries for processors
GET /timelines/{timelineId}/entries?since={cursor}
→ { entries: [...], cursor, completeUpTo }

# Resolve an actor for attribution
GET /actors/{accountId}
→ { actorType, accountId, attestations: [...] }

Treat the above as illustrative — exact endpoint names and shapes will vary by provider.

Different kinds of timeline providers

Blue is designed so there does not have to be only one kind.

Commercial providers

Example: MyOS. Good for fast onboarding, product usage, personal and SMB contexts, and lower-friction identity. Trade-off: identity assurance is good for everyday use, not bank-grade.

Bank-grade providers

Example: a bank using its KYC'd customer identity. Good for financial workflows, high-value transactions, and stronger institutional trust. Trade-off: more onboarding friction.

Government-grade providers

Example: a national digital identity service. Good for formal identity assurance and signature-heavy or regulated processes. Trade-off: jurisdictional, not universal.

Self-hosted / enterprise providers

Example: an enterprise running its own provider tied to corporate SSO and PKI. Good for maximum control, privacy, internal agent environments, and compliance. Trade-off: you operate it.

Why multiple provider types matter

Different interactions need different trust. A low-stakes collaboration might only need commercial identity. A large B2B payment might want bank-grade identity. An internal enterprise workflow might want a self-hosted provider tied to corporate identity.

Self-hosting and openness

Self-hosted timeline providers are important because:

• they reinforce openness
• they make enterprise adoption realistic
• they show that Blue is not locked to one runtime

Coming next

The deeper provider docs are still being written. Upcoming pages:

• Self-hosting a timeline provider — operational guide.
• Provider on AWS — reference deployment.
• Provider API specification — formal contract for read/write/list/attribute.

If you want to be involved in shaping these, follow the repo and tell us what you need.