Skip to content

Add optional machine-readable output for ots info / ots verify#163

Open
bilalobe wants to merge 2 commits intoopentimestamps:masterfrom
bilalobe:master
Open

Add optional machine-readable output for ots info / ots verify#163
bilalobe wants to merge 2 commits intoopentimestamps:masterfrom
bilalobe:master

Conversation

@bilalobe
Copy link

Summary

This PR adds optional machine-readable output for the OpenTimestamps client CLI.

Initial scope:

  • ots info --json
  • ots verify --json

Default human-readable output is unchanged.

Motivation

Downstream automation currently has to parse human-oriented strings such as:

  • Pending confirmation in Bitcoin blockchain
  • BitcoinBlockHeaderAttestation(...)
  • Success! Bitcoin block ...
  • Failed! Timestamp not complete

That makes integrations brittle and makes it hard to distinguish:

  • incomplete / pending timestamp vs hard verification failure
  • manual-check-required cases (for example --no-bitcoin)
  • attested block heights and other useful metadata already visible to the client

This PR adds a structured interface for those cases without touching the timestamp format or consensus-critical proof
logic.

Scope

This PR adds:

  • ots info --json
  • ots verify --json

It does not:

  • change the OpenTimestamps proof format
  • change attestation validation semantics
  • add block explorer verification
  • change the default text output

Behavior

ots info --json

Outputs structured information about a detached timestamp, including:

  • file hash algorithm
  • file digest
  • tree rendering
  • known attestations

ots verify --json

Outputs structured verification information, including:

  • overall status
  • verification result
  • attestation list
  • target metadata
  • exit code semantics for machine consumers

For verify --json, the exit codes are:

  • 0 = verified
  • 2 = pending / not yet complete
  • 1 = hard verification failure

This allows downstream tools to distinguish incomplete timestamps from genuinely invalid or failed verification cases.

Design notes

This change is intentionally implemented in the client CLI layer (otsclient.args / otsclient.cmds) and does not
modify opentimestamps.core.

That keeps the feature focused on operability and integration rather than proof semantics.

Why this is useful

This improves:

  • CI and automation wrappers
  • monitoring / reporting integrations
  • external verifier tooling
  • downstream projects that need to distinguish pending timestamps from hard failure

Tests

Added tests for:

  • JSON serialization of pending attestations
  • JSON serialization of detached timestamps
  • verify --json pending status
  • verify --json verified status
  • command-level pending vs failure exit code behavior

Documentation

README examples were added for:

  • ots info --json
  • ots verify --json

Related

This is related to #127, but intentionally narrower.

This PR does not attempt to solve explorer-backed verification.
It provides a stable machine-readable CLI surface that makes downstream tooling and future verifier work much easier.

Introduce optional --json output for `ots info` and `ots verify'  without changing the default human-readable CLI behavior.

For `verify --json`, distinguish incomplete/pending timestamps from
hard verification failure with a dedicated pending exit code:
  - 0 = verified
  - 2 = pending / not yet complete
  - 1 = hard failure
Also add tests for the JSON helpers and document the new mode in the README.
Copilot AI review requested due to automatic review settings March 13, 2026 13:37
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds optional machine-readable JSON output to the OpenTimestamps client CLI for ots info and ots verify, enabling automation to consume structured verification/status data without parsing human-oriented strings.

Changes:

  • Introduces --json flag for ots info and ots verify and emits structured JSON payloads.
  • Adds JSON serialization helpers for detached timestamps and attestations, plus a JSON-oriented verify path with exit-code semantics.
  • Adds unit tests and README examples for the new JSON output.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

File Description
otsclient/cmds.py Implements JSON serialization and --json output paths for info/verify, including exit-code computation.
otsclient/args.py Adds --json CLI flags for verify and info.
otsclient/tests/test_json_output.py Adds tests covering JSON serialization and JSON-mode verify exit codes.
README.md Documents the new --json usage with examples and exit-code notes.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +108 to +113
upgrade_timestamp(timestamp, args)

result = {
"status": "failed",
"verified": False,
"upgraded": True,
verify_result = verify_timestamp_json(detached_timestamp.timestamp, args)
result.update(verify_result)
result["exit_code"] = 0 if verify_result["verified"] else (
EXIT_VERIFY_PENDING if verify_result["status"] == "pending" else EXIT_VERIFY_FAILED
Comment on lines +652 to +653
else:
result["target"] = {"type": "file", "value": args.timestamp_fd.name[:-4]}
Comment on lines +108 to +155
Machine-readable JSON output is also available for `info`:

$ ots info --json examples/two-calendars.txt.ots
{
"command": "info",
"file": "examples/two-calendars.txt.ots",
"file_digest": "efaa174f68e59705757460f4f7d204bd2b535cfd194d9d945418732129404ddb",
"hash_algorithm": "sha256",
"timestamp": {
"attestation_count": 2,
"attestations": [
{
"calendar": "https://alice.btc.calendar.opentimestamps.org",
"status": "pending",
"type": "PendingAttestation"
},
{
"calendar": "https://bob.btc.calendar.opentimestamps.org",
"status": "pending",
"type": "PendingAttestation"
}
]
}
}

Likewise, `verify` can emit structured status output:

$ ots --no-bitcoin verify --json examples/incomplete.txt.ots
{
"command": "verify",
"status": "pending",
"verified": false,
"exit_code": 2,
"attestations": [
{
"chain": "bitcoin",
"height": 428648,
"reason": "bitcoin_disabled",
"status": "manual_check_required",
"type": "BitcoinBlockHeaderAttestation"
},
{
"calendar": "https://alice.btc.calendar.opentimestamps.org",
"status": "pending",
"type": "PendingAttestation"
}
]
}
Set `upgraded` from the actual upgrade result, treat
  `manual_check_required` as a non-hard-failure pending exit, make the
  JSON target path explicit in `verify_command()`, and update the README
  examples to match the emitted schema.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants