devouch

Demo

About

Devouch lets an issuer recommend an open-source contributor once, then lets independent repositories decide whether to accept that recommendation. The issuer signs a GitHub numeric account ID, purpose, expiry, and publishing location using EIP-712. They publish the complete signed JSON to their own ENSv2 Permissioned Resolver on Sepolia. Contributors carry the original JSON in their pull requests. A Ruby CLI and a read-only GitHub Action verify the signature, the actual PR author's account, the publication history, and the receiving repository's policy. Withdrawing the ENS record invalidates the endorsement on the next check. Restoring an old JSON cannot resurrect it. The static wallet workspace handles setup, publication, key permissions, withdrawal, and transaction recovery. Anyone can try it without a wallet: the verification page [*](https://geeknees.github.io/devouch/?name=masusanou.vouches.geeknees.eth#verify) reads a live endorsement from ENS on Sepolia, shows who vouched by their primary ENS name, and compares two example repository policies side by side. Add the issuer to repository B's trusted list and its decision changes from rejected to accepted, while the evidence stays the same. Issuers can also keep many endorsements and agent identities under their own ENS name. Each endorsement gets its own subname, such as `masusanou.vouches.geeknees.eth`, with its own record and withdrawal history, so publishing another endorsement never overwrites it. An AI agent can have its own subname that holds a declared GitHub identity and wallet, and the issuer grants or revokes individual profile fields through ENSv2 Enhanced Access Control. Publishing, withdrawing a single endorsement, and granting, using and revoking an agent's permission have all been done with real wallets on Sepolia. Maintainers can paste a public pull request URL to check its endorsement against the repository's base policy and explore the result as a trust map. Before opening a pull request, an agent can run `devouch check` against the destination repository, also packaged as a portable SKILL, and continue only when that repository's policy accepts its endorsement. No Devouch-operated API, database, signing service, publisher key, or unique storage service is required. The project still depends on Ethereum/ENS, name maintenance, a wallet, GitHub for PR identity, and a reliable historical RPC provider. Recommendations do not prove humanity, code quality, delegation, or merge approval.

How it's made

The command-line interface is Ruby and uses the standard library for bounded file handling, policy evaluation, and read-only GitHub API access. A bundled TypeScript helper uses viem for EIP-712 recovery, ENS normalization, contract reads, and event decoding. The static HTML/CSS workspace connects to an injected wallet and sends transactions directly to the official ENSv2 factory, registry, and dedicated resolver. The complete signed JSON is stored in devouch.vouch, so another verifier can retrieve it without the Devouch website. Verification checks a pinned chain snapshot, the resolver's deployment origin, exact publication bytes, subsequent text updates, and transient binding or upgrade changes. The wallet-free verification page reuses the same TypeScript verifier, resolves the issuer's primary name with viem's `getEnsName` (the ENSv2 Universal Resolver confirms it resolves back to the same address), and evaluates repository policies in the browser; shared test cases check that the browser and the Ruby CLI reach the same decisions and reason codes. Subname registries use the pinned official ENSv2 UserRegistry implementation. For a subname, the verifier walks the whole hierarchy up to ten labels and checks each parent registry, link and implementation history, so a change higher in the tree cannot silently restore or forge an endorsement. The pull-request verification page and the `check` command reuse the same verifier: they read the destination repository's policy from GitHub and the endorsement from ENS, send no transaction, and need no wallet or GitHub token for public repositories. A composite GitHub Action uses the PR author's numeric ID, the base commit's policy, and the head commit's endorsement without checking out PR code. Tests combine Minitest, Bun, Playwright, and a disposable Hardhat EVM running pinned official ENS bytecode. No new smart contract, backend service, database, or shared signing key was added.