Skip to content

[attestations 1] attestations-core: shared attestation infrastructure - #249

Draft
mdgeorge4153 wants to merge 1 commit into
mainfrom
mdgeorge/attestations-core
Draft

[attestations 1] attestations-core: shared attestation infrastructure#249
mdgeorge4153 wants to merge 1 commit into
mainfrom
mdgeorge/attestations-core

Conversation

@mdgeorge4153

Copy link
Copy Markdown

The shared base for the attestation work, factored out of the feature stack so it can land independently and either feature can rebase onto it.

What's here

The plumbing both the security-tab (#245) and source-verification (#247) features import — nothing feature-specific, nothing UI:

  • lib/attestations.ts — trust config + per-subject box derivation (mirrors the on-chain derived_object::derive_address).
  • hooks/useGetAttestations.ts — the box read + enumerateAttestationTypes (used by both features).
  • providers/client-provider.tsx — the GraphQL client wiring.
  • utils/types.ts, CheckIcon, attestation-config.example.ts, ATTESTATION-INTEGRATION.md, .env.example.

Compiles standalone (tsc clean). #245 (security) and #247 (SV) each rest only on this — verified: #245 typechecks with no source-verification code present.

Testing note

The mvr frontend has no test suite, so this is tsc-validated only. The box derivation is a pure mirror of the Move derived_object logic and would be worth a unit vector test if we add a runner.

🤖 Generated with Claude Code

@vercel

vercel Bot commented Aug 7, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
mvr Ready Ready Preview Aug 20, 2026 11:07am

Request Review

Comment thread app/src/lib/attestations.ts Outdated
mvrName: "@pkg/attestations-demo-auditor",
originalId: "0xa44c54ed294089b0fe2f4d1620d86aa5cb4e05d25e60f4dff935670accfbbc6b",
lineage: [
"0xa44c54ed294089b0fe2f4d1620d86aa5cb4e05d25e60f4dff935670accfbbc6b",

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this should be encoded here - I think we wanted to allow it to auto-update if a trusted attestor publishes a new type, no?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[CLAUDE] Agreed, and this is now the case (landed after this comment during the config refactor). TrustedAttestor no longer carries a lineage — attesters are configured by originalId only (app/src/lib/attestations.ts:29). The full lineage is resolved at load from packageVersions in app/src/hooks/useTrustedAttestors.ts (lineageOf, line 17), and enumerateAttestationTypes enumerates every store datatype across all of those versions (useGetAttestations.ts:115). So a trusted attester that publishes a new type in an upgrade is picked up automatically, no config edit.

Comment thread app/src/lib/attestations.ts Outdated
Comment on lines +71 to +74
* Testnet attesters today: **Demo Auditor** (our `examples/auditor` template),
* **Asymptotic** (a partner-surfaced third-party auditor, pre-authorized so its
* audits render trusted the moment it issues any), and **Source Verification**
* (the sv-service; `role: "source-verification"` routes it to the source panel).

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd drop this comment, it's the wrong place to list the trusted attestors.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[CLAUDE] Done — dropped the attester list from the loader doc comment; the attesters live in app/src/lib/attestation-config.json now, and allConfigs in attestations.ts no longer narrates them.

"name": "Asymptotic",
"mvrName": "@asymptotic/attestation",
"iconUrl": "https://www.asymptotic.tech/favicon.svg",
"originalId": "0xbd7f5ade9c9dd44fce79a34bbc468cebe1f89255984475eddc0d6454c445bcdb"

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe "role": "auditor" for these?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[CLAUDE] role is currently only a routing flag — the UI acts on "source-verification" (routes into the source panel); anything else, including undefined, renders as a Security-tab endorsement card (see the filter in useGetAttestations.ts:98, x.attestor.role !== "source-verification"). So "auditor" would be self-documenting but behaviorally identical to undefined today. Also not every endorser is an auditor — the demo has an "Example Security Scanner" endorser — so if we make the role explicit I would rather add the full vocabulary (auditor / scanner / source-verification) and decide whether the endorsement card should surface it. Happy to do that, or leave undefined = generic endorsement for now. Which do you prefer?

Factor out the plumbing shared by the security-tab and source-verification
features — the config/box-derivation lib, the read hook (incl.
enumerateAttestationTypes), the GraphQL client wiring, and shared types/icons —
as a clean base off main. Compiles standalone, so either feature can rebase onto
this to land independently when ready.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant