Youre right, I conflated two things in my reply to sscaryterry. B-T needs an RFC 3161 token from any TSA. Its only a qualified timestamp under eIDAS that needs a QTSP. Those are separate claims I ran them together.

Although the code already has the path. The signing service uses pyhanko with an HTTPtimestamper pointed at timestamp.digicert.com, and its switched off at every call site. Reason was availability, an external TSA sits on the signing path, so if its slow or down, sealing fails, whereas the anchor is async and can never fail a seal. That reasoning holds for the default and doesnt justify never offering it.

It should be optional, and on where the caller wears the dependency, which also gets pyhanko to embed validation info and go to LTA rather than just B-T. Only thing I want to check first is the terms on those public TSAs, since a few are scoped to code signing. Opening an issue, and thx agaain.

Currently even the person checking if a document/contract is sealed or code is authentic has to also be inside the same Adobe walled garden too. Verification, the part that should be free is the part everyone charges for. Thats the shape Let's Encrypt fixed for TLS, and I wanted the same thing for documents and files.

The core idea therefore needed to go a bit beyond e signatures and i created an open standard (SEAL), plus free tools that implement it.

When you seal a file, three independent things happen.

1. it gets a signature from a certificate authority, chaining to a public root. 2. its record is appended to an RFC 6962 transparency log. and 3. its SHA256 is timestamped on a public blockchain (Bitcoin) via OpenTimestamps. Those three give you integrity, transparency and a timestamped proof. And importantly, none of those depend on Let's Seal and none are gated.

You can verify with the tools you already have, no Let's Seal account and no Let's Seal software. A sealed PDF carries a standard PAdES signature, so any PDF reader validates it. A sealed build artefact carries a cosign compatible signature and a SLSA provenance attestation. The Bitcoin timestamp verifies with stock ots.

3 ways to use it.

1. The free web app. We kindly have backing from Backblaze to cover storage costs for the foreseeable. So you can upload or issue any number of documents, get a public proof page at /d/ and verify it at https://verify.letsseal.org for free. Multiple accounts, multiple seats, enterprise functions. Free.

2. Self host the whole thing. Apache-2.0, one Next.js app plus a signing service that holds the CA key on localhost. Storage is any S3-compatible bucket or local disk. If you'd rather run your own root of trust, you can.

3. Programmatically. via the CLI and a hosted API. This is the Let's Encrypt/certbot angle. Seal or anchor things from CI, or have a backend seal every invoice or report as its generated.

The CLI is sealbot. It runs anywhere Node runs (npx sealbot) and there are native binaries for macOS, Linux and Windows with no runtime needed.

Theres a GitHub Action wrapping the same tool, so a release workflow can seal its own artifacts. Its what proves our own releases.

KYC is semi-handled (to a degree) it's hard to do for free (at least for now), but issuers (your companies or websites) domains can be authenticated with a DNS record added, which proves the issuer has control over a domain. Sign-in can be authenticated to an email via Google Sign in and a few others will be added to the web app in time (Same as Docusign currently). Ideas welcome on future KYC should there be a demand.

Feedback welcome on the standard (SPEC.md in the repo).

Repo: https://github.com/letsseal/letsseal Site: letsseal.org

Thx

Comments URL: https://news.ycombinator.com/item?id=49071365

Points: 70

# Comments: 29

Replen then builds an ontology and knowledge graph across all your repos, to find the relationships and gaps and then runs a self tuning matching loop against the wider oss frontier. It goes looking for libraries, algos, techniques and ideas that you can get your agent to adopt, port, cherry pick or rebuild. Because of the embeddings and ontology, it understands your whole portfolio and can suggest better ways to do things. i.e. I personally do a lot of scraping and Claude always suggests the same way to do it, but /davinchi/scrapling just does it better and gets past CF, now with Replen, it knows this is the better option.

By no means is it perfect and the learning loop needs users and their interactions to get better for everyone so with that in mind, id love feedback on a couple of things.

1. Do you find yourself doing what I do or is this just a me thing? (Validates whether this is useful to anyone but me) 2. Is the ‘quite by design’ about right? (I worked on my own exp of 1-3 suggestions that I actually act on per month being the right cadence, does that feel right?

A couple of things to preempt comments.

No code leaves your machine. No API keys needed. Feel free to fully self host. Engine is Apache 2.0. Npx Replen (MCP and Skill).

Happy to answer any qs on capability graph, self-tuning loop or modality gate in comments. Thx

Comments URL: https://news.ycombinator.com/item?id=48907717

Points: 1

# Comments: 0