It seems you avoided answering the most crucial question:

What prevents an issuer from generating a proof that something existed arbitrarily far in the past?

Opentimestamps achieves that by Proof of Work. Do you require trusting the issuers instead?

Hi HN,

I’m the creator of TimeProofs, an open, stateless proof-of-existence protocol and API.

The problem it tries to solve is simple: How can you prove that a digital event or file existed at a given time, without uploading or exposing the data?

TimeProofs works by: - hashing data locally - issuing a signed timestamp - producing a portable proof file (.tproof.json) - allowing independent verification later (online or offline)

Key constraints: - no data storage - no metadata collection - no blockchain - no identity or compliance claims

It’s designed as a neutral infrastructure layer, similar in spirit to DNS or TLS, but for timestamped evidence.

One challenge we’re facing is discoverability: search engines often confuse “TimeProofs” with existing timestamping vendors or proprietary services, despite very different goals and architecture.

I’m posting here mainly to get technical feedback: - Is the problem clearly stated? - Is the scope too narrow or too broad? - Does the stateless + bundle approach make sense?

Website: https://timeproofs.io Spec: https://timeproofs.io/proofspec.html

Honest feedback welcome.

Hi HN — I’m the creator.

TimeProofs is a small protocol to prove that some data existed at a given time, without uploading the data itself.

You hash locally, get a signed timestamp, and store a portable proof file (.tproof.json). Verification can be done later, even offline.

No blockchain, no accounts, no tracking.

Happy to answer questions or hear criticism.

That's cool. What's an example of when this would be useful?

For example: you generate a file (code, dataset, document, AI output) and later need to prove it already existed at a certain time. TimeProofs lets you create a small proof file you can keep. Anyone can later verify the timestamp without seeing the original content.

To me that's "what it does" whereas I'm wondering when it would be useful.

In other words, I can't think of a use case in industry or academia or daily life or whatever, where someone needs to prove that a file existed at a specific time

Fair question. It’s useful when you need to prove priority or existence without revealing the content. Examples: – You wrote something (code, research, idea) and want proof it existed before publication or disclosure. – You generated AI output and want to prove it wasn’t altered later. – You exchanged a document (contract draft, design, dataset) and want a neutral timestamp without involving a third party or storing the data. – You want evidence before a dispute, not after one starts. It’s not for everyday files — it’s for moments where “this existed at this time” might later matter. This keeps it grounded, avoids hype, and sounds like a real human explaining a niche tool.

Doesn’t your service have to exist to verify a proof?

You can reply concisely and technically. Suggested answer: No. Verification does not depend on the TimeProofs service being online. A TimeProofs proof is a self-contained, cryptographically signed file. Anyone can verify it offline or with independent tooling by: recomputing the hash, checking the signature, validating the timestamp against the public specification. The service is only required at issuance time to sign the proof. Verification is intentionally decoupled to avoid vendor lock-in and single points of failure. If TimeProofs disappeared tomorrow, all existing proofs would remain verifiable.