DEV Community

Edison Flores
Edison Flores

Posted on

Re: @topstar_ai (Luis Cruz) — yes: three concrete contribution paths (and one honest answer about budget)

Re: @topstar_ai — yes. Here are the three places where help actually moves the needle

This is a reply to Luis Cruz's comment on the UTA v1.0.0 status report. (dev.to retired comment replies via API, so this article is the reply channel — the same way I answered @anp2network across the vectors v1.3.x thread.)

Luis — thank you, and yes: the interest is mutual. You said implementation, testing, integrations, or future Python/AI tooling — three of those four map directly onto open work right now. No audition project; these are the real items.

1. Python reference verifier (the biggest gap)

The JavaScript reference scorer under uta-repo/tests/conformance/ is now itself under test (24 self-checks + 10 caught mutants, v1.3.3), but there is no independent Python implementation of the ATC verification path: JCS (RFC 8785) canonicalization, Ed25519 (RFC 8032) verify, two-sided validity window, pinned-anchor key selection. An outside party already re-derived the canonicalization in Python once — that's how two real bugs got found. A maintained, pip-installable uta-verifier with the same test vectors wired into CI is the single most valuable contribution available. The vectors are public and byte-pinned: https://www.marketnow.site/uta/conformance/vectors/_index.json — 14 vectors, every one with published canonical bytes, SHA-256/512, and expected per-stage outcomes.

2. atc-spec — the sprint board is literal

github.com/eddyflores100-lang/atc-spec has open issues labeled [Sprint 1.x] — Python package structure, jcs.py (RFC 8785), did_key.py (parse did:key → Ed25519 public key), CI for Python + TypeScript. They are written as self-contained tasks with acceptance criteria. Pick any issue number, comment "taking it," and it's yours.

3. Integrations: trust-card verification as an MCP tool

The trust layer only matters if agents can call it. @marketnow/mcp exists on npm; what's missing is a thin tool layer that takes a card URL or inline ATC, verifies signature + anchor + window + status locally, and returns a verdict with per-stage reasons — so any MCP-capable agent gets verification without trusting the marketplace's own word for it. That's a contained, well-specified Python project.

On the "paid project or ongoing opportunity" part — honest answer: this is currently a bootstrapped trust-infrastructure project (AliceLabs LLC), the immediate budget is small, and the compensation model on the table is: paid bounties on specific issues + co-authorship on the pieces above + first position if/when funding allows hiring. If that trade works for you, say so and I'll open a concrete first issue with a fixed bounty this week.

Fastest path: reply here, or open an issue on alicelabs-llc/universal-trust-adapter titled [contributor] <your name> and I'll route it.

Top comments (0)