docs: SDK + plugins documentation overhaul#28
Conversation
Add top-level Plugins tab with overview, mock, proofmode, witnesschain, and custom plugin pages. Update SDK Reference nav to include stamps, location-proofs, and plugins pages. Remove sdk/verify from nav and add redirect to sdk/stamps.
Update overview to show all 5 modules (location, compute, stamps, proofs, plugins), add apiKey to config, and link to all SDK pages. Update installation with plugin submodule imports and registration examples.
Add sdk/stamps.mdx covering StampsModule: collect, create, sign, verify with accurate signatures from source. Add sdk/location-proofs.mdx covering ProofsModule with local and TEE verification modes, full CredibilityVector type documentation (4 dimensions, no single score), and multi-stamp examples.
Document LocationProofPlugin interface, PluginRegistry API (register, get, has, list, all, withMethod), runtime detection, MockPlugin quick reference, and custom plugin authoring guide.
Document both submit() input formats (DelegatedAttestation and
{attestation, delegatedAttestation}), add VerifiedLocationProof
as input type, confirm options is required for spatial methods.
Add top-level Plugins section with five pages: - overview: plugin ecosystem, pipeline, status table - mock: built-in test plugin with full pipeline example - proofmode: ZIP bundle parsing, create, verify, signal fields - witnesschain: network triangulation concept, development status - custom: guide for building custom plugins
johnx25bd
left a comment
There was a problem hiding this comment.
Submitting pending review to unblock.
| "name": "SDK", | ||
| "url": "sdk" | ||
| }, | ||
| { |
There was a problem hiding this comment.
plugins should be the second tab
Concepts - Plugins - SDK - API.
Nice and tidy
Detailed review: SDK + plugins documentation overhaulThis PR is a significant improvement — it replaces inaccurate docs (the old That said, I found several issues worth addressing before merge, organized by severity. HIGH — Accuracy issues to fix1. ProofMode
The plugin status table in Suggestion: Verify whether 2. The PR removes Suggestion: Delete 3.
Suggestion: Verify against the SDK source and either restore the type or add a brief note explaining the removal. MEDIUM — Content and consistency issues4. Content overlap between Both pages contain a custom plugin writing guide with nearly identical code examples. Suggestion: Keep the full guide in 5. Complete example removed from The PR deletes the end-to-end compute example (creating an attestation, checking proximity, estimating gas, submitting). This was the most practical example on the page — it showed the full flow from attestation to onchain submission. While the individual method docs are solid, losing the integrated example makes it harder for developers to see how the pieces connect. Suggestion: Consider keeping a shorter version of the complete example, or at minimum link to a guide that demonstrates the full compute workflow. 6. Float timestamps in claim examples In time: { start: Date.now() / 1000 - 60, end: Date.now() / 1000 }
Suggestion: Use 7.
Suggestion: Add a brief note — even one sentence — explaining when LOW — Style and polish8. Sentence case corrections — good The PR consistently corrects title case headers to sentence case throughout ("Compute Module" → "Compute module", "Input Types" → "Input types", etc.). This matches the project style guide and improves consistency. 9. WitnessChain interface is aspirational
10. Navigation ordering is well-considered The SDK Reference nav progression (overview → installation → location → stamps → location-proofs → plugins → compute → eas → migration) moves from core concepts through the new plugin system to existing modules. Logical and well done. SummaryThe PR is a substantial quality improvement over the existing docs. The core documentation (stamps, proofs, CredibilityVector, plugin interface) is accurate against the SDK source. The main things to address before merge:
Everything else is polish. Nice work on this overhaul. |
ProofMode does not implement the standard create(signals) interface method. Update status tables and docs to reflect that stamp creation uses the bundle-based parseBundle() + createStampFromBundle() flow.
Content replaced by sdk/stamps.mdx and sdk/location-proofs.mdx. File contained inaccurate types (flat confidence score, fictional CredibilityAssessment). Redirect already in mint.json.
- Restore complete example in compute.mdx showing full workflow - Use Math.floor() for timestamps in claim examples - Clarify apiKey is for TEE verification and hosted endpoints
ProofMode now implements the standard create(signals) method, accepting ZIP data via signals.data.zipData. Update docs to show the standard pipeline flow and restore create: Yes in status tables. Keep parseBundle/createStampFromBundle as documented lower-level helpers. Refs: location-proofs/plugin-proofmode#5
Summary
@decentralized-geo/astral-sdksource (all 5 modules: location, compute, stamps, proofs, plugins)sdk/verify.mdx(fictional types, flat confidence score) with accuratesdk/stamps.mdxandsdk/location-proofs.mdxdocumenting the realCredibilityVector(4 dimensions, no single score)New pages (8)
sdk/stamps.mdx— StampsModule (collect, create, sign, verify)sdk/location-proofs.mdx— ProofsModule (local + TEE verification, CredibilityVector)sdk/plugins.mdx— Plugin system and PluginRegistry APIplugins/overview.mdx— Plugin ecosystem overview and status tableplugins/mock.mdx— MockPlugin configuration and usageplugins/proofmode.mdx— ProofMode ZIP parsing, verification scopeplugins/witnesschain.mdx— WitnessChain concept and development statusplugins/custom.mdx— Custom plugin authoring guideUpdated pages (4)
mint.json— Plugins tab, updated SDK nav, verify→stamps redirectsdk/overview.mdx— Full 5-module architecturesdk/installation.mdx— Plugin imports and registrationsdk/compute.mdx— Corrected submit() signatures, VerifiedProof input typeTest plan
npx mintlify devand verify all pages render/sdk/verifyredirects to/sdk/stamps