HackerTrans
TopNewTrendsCommentsPastAskShowJobs

timeproofs

no profile record

Submissions

[untitled]

1 points·by timeproofs·il y a 5 mois·0 comments

[untitled]

1 points·by timeproofs·il y a 5 mois·0 comments

[untitled]

1 points·by timeproofs·il y a 5 mois·0 comments

[untitled]

1 points·by timeproofs·il y a 6 mois·0 comments

[untitled]

1 points·by timeproofs·il y a 6 mois·0 comments

Show HN: TimeProofs – Prove when data existed without uploading it

3 points·by timeproofs·il y a 6 mois·9 comments

How do you reliably prove when data existed?

1 points·by timeproofs·il y a 7 mois·2 comments

Show HN: Turning noisy webpages into clean JSON for LLMs

1 points·by timeproofs·il y a 7 mois·0 comments

[untitled]

1 points·by timeproofs·il y a 8 mois·0 comments

comments

timeproofs
·il y a 6 mois·discuss
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.
timeproofs
·il y a 6 mois·discuss
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.
timeproofs
·il y a 6 mois·discuss
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.
timeproofs
·il y a 6 mois·discuss
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.
timeproofs
·il y a 6 mois·discuss
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.
timeproofs
·il y a 7 mois·discuss
That’s exactly the right framing — those questions matter.

In many cases, a secure hash alone is enough to prove integrity (“this file hasn’t changed”). The gap usually appears around time and independence.

A hash answers what, but not always:

when the hash existed,

who can verify that claim later,

or whether the timestamp depends on the same system that controls the data.

In practice, people handle this today with a mix of:

hashes stored in internal systems,

logs,

emails,

screenshots,

or third-party platforms.

These work operationally, but during disputes or audits they often collapse back to “trust the system that says so”.

The approach I’m interested in is minimal:

hash the data locally,

bind that hash to a point in time via an external, neutral timestamp,

keep verification possible long after the fact, without access to the original system or data.

Not as a legal silver bullet, but as a technical primitive: integrity + existence at time T, independently verifiable.

Curious to hear what you’ve seen work reliably when trust in the original system is no longer assumed.