From 47be626d8823f127b766ba15cda09a156ab835d8 Mon Sep 17 00:00:00 2001 From: Sharfy Adamantine Date: Tue, 24 Mar 2026 21:10:30 -0700 Subject: [PATCH] Remove roadmap page The roadmap is being removed for now. Deletes the page and cleans up all references in navigation, index, FAQ, certified-identity docs, search index, and lastUpdated metadata. Co-Authored-By: Claude Opus 4.6 --- lib/generate-search-index.js | 1 - lib/lastUpdated.json | 1 - lib/navigation.js | 1 - pages/core-concepts/certified-identity.md | 2 +- pages/index.md | 3 - pages/reference/faq.md | 1 - pages/roadmap.md | 343 ---------------------- public/search-index.json | 42 +-- 8 files changed, 3 insertions(+), 391 deletions(-) delete mode 100644 pages/roadmap.md diff --git a/lib/generate-search-index.js b/lib/generate-search-index.js index f78fcf1..0e148e6 100644 --- a/lib/generate-search-index.js +++ b/lib/generate-search-index.js @@ -96,7 +96,6 @@ function getSection(path) { if (path.startsWith("/lexicons")) return "Reference"; if (path.startsWith("/reference")) return "Reference"; if (path.startsWith("/ecosystem")) return "Ecosystem & Vision"; - if (path === "/roadmap") return "Reference"; return "Other"; } diff --git a/lib/lastUpdated.json b/lib/lastUpdated.json index 1f4f60f..6f19671 100644 --- a/lib/lastUpdated.json +++ b/lib/lastUpdated.json @@ -37,7 +37,6 @@ "/lexicons/introduction-to-lexicons": "2026-03-05T19:42:38+08:00", "/reference/faq": "2026-03-06T22:56:46+08:00", "/reference/glossary": "2026-03-05T20:14:26+08:00", - "/roadmap": "2026-03-05T20:17:36+06:00", "/tools/hyperboards": "2026-03-09T15:56:42+08:00", "/tools/hypercerts-cli": "2026-03-05T12:30:00+06:00", "/tools/hyperindex": "2026-02-20T19:42:03+08:00", diff --git a/lib/navigation.js b/lib/navigation.js index 0500fe7..4f31c04 100644 --- a/lib/navigation.js +++ b/lib/navigation.js @@ -159,7 +159,6 @@ export const navigation = [ }, { title: "Glossary", path: "/reference/glossary" }, { title: "FAQ", path: "/reference/faq" }, - { title: "Roadmap", path: "/roadmap" }, ], }, { diff --git a/pages/core-concepts/certified-identity.md b/pages/core-concepts/certified-identity.md index 4b20d51..b5f43b3 100644 --- a/pages/core-concepts/certified-identity.md +++ b/pages/core-concepts/certified-identity.md @@ -59,7 +59,7 @@ To receive onchain funding, a DID needs to be linked to an onchain wallet addres 3. Signs an EIP-712 typed message proving ownership 4. Stores the attestation in the user's PDS -The attestation is self-sovereign (stored in your PDS, not a central database) and verifiable by anyone. See the [Roadmap](/roadmap) for current IdentityLink status. +The attestation is self-sovereign (stored in your PDS, not a central database) and verifiable by anyone. ## Next steps diff --git a/pages/index.md b/pages/index.md index e3e4ff6..e3a8799 100644 --- a/pages/index.md +++ b/pages/index.md @@ -98,9 +98,6 @@ Key terms used across the documentation {% card-link title="FAQ" href="/reference/faq" icon="" %} Common questions about building with Hypercerts {% /card-link %} -{% card-link title="Roadmap" href="/roadmap" icon="" %} -Development priorities and phased delivery plan -{% /card-link %} {% /card-grid %} ## Ecosystem & Vision diff --git a/pages/reference/faq.md b/pages/reference/faq.md index 4b8b64c..ebf9256 100644 --- a/pages/reference/faq.md +++ b/pages/reference/faq.md @@ -46,4 +46,3 @@ The on-chain funding layer is not yet implemented. The planned design freezes re #### Where do I get help? - [GitHub](https://github.com/hypercerts-org) โ€” source code, issues, and discussions -- [Roadmap](/roadmap) โ€” what's being built and what's next diff --git a/pages/roadmap.md b/pages/roadmap.md deleted file mode 100644 index ac9de81..0000000 --- a/pages/roadmap.md +++ /dev/null @@ -1,343 +0,0 @@ ---- -title: Roadmap -description: Development priorities, infrastructure components, and phased delivery plan for Hypercerts v0.2. ---- - -# Roadmap - -This page outlines the infrastructure components, build priorities, and phased delivery plan for Hypercerts v0.2 โ€” a decentralized system for tracking, evaluating, and funding impactful work on the open internet. - -{% callout type="note" %} -This roadmap reflects the current plan and is subject to change as we gather feedback from real users and contributors. Status labels indicate where each component stands today. -{% /callout %} - ---- - -## Infrastructure overview - -The Hypercerts infrastructure divides into six functional areas. Each area has a different ownership model: - -| Color | Meaning | -|-------|---------| -| ๐Ÿ”ต Blue | Hypercerts Infrastructure โ€” core protocol components this roadmap covers | -| ๐ŸŸข Green | Hypercerts Collective Infrastructure โ€” community-governed components | -| โฌœ Grey | Third-party Infrastructure โ€” leverage existing services, don't rebuild | - ---- - -## Build priorities - -| Component | Priority | Status | Owner | -|-----------|----------|--------|-------| -| Lexicons | ๐Ÿ”ด Critical | Active | Hypercerts Foundation | -| Hyperindex AppView | ๐Ÿ”ด Critical | Active | GainForest โ†’ Foundation | -| IdentityLink | ๐ŸŸ  High | Live | GainForest โ†’ Foundation | -| EVM Indexer | ๐ŸŸ  High | Planned | TBD | -| Evaluators | ๐ŸŸ  High | Active | Hypercerts Collective | -| Hypercerts Labeller | ๐ŸŸ  High | Active | Hypercerts Collective | -| AI-Ready Docs | ๐ŸŸ  High | In Progress | All | -| StorageLink | ๐ŸŸก Medium | Planned | TBD | -| Hypercerts PDS | โšช Low | Optional | โ€” | -| Hypercerts Relayer / Firehose / Jetstream | โšช Low | Future | โ€” | - ---- - -## Lexicons ๐Ÿ”ต - -### Lexicons - -**Priority:** ๐Ÿ”ด Critical ยท **Status:** Active ยท **Owner:** Hypercerts Foundation - -Lexicons are the schema definitions that specify the structure of all Hypercerts records on ATProto. They are the "contracts" that define how data is structured, validated, and referenced across the network. Without standardized schemas, interoperability between applications would be impossible. - -**`app.certified.*` โ€” Certified application lexicons** - -| Lexicon | Purpose | -|---------|---------| -| `app.certified.badge.definition` | Badge type definitions | -| `app.certified.badge.award` | Badge awards to users | -| `app.certified.location` | Georeferenced location data | -| `app.certified.link.*` | Identity attestations (DID to EVM) | - -**`org.hypercerts.*` โ€” Hypercerts protocol lexicons** - -| Lexicon | Purpose | -|---------|---------| -| `org.hypercerts.claim.activity` | Core hypercert records tracking impact work | -| `org.hypercerts.claim.evaluation` | Evaluations of activities by third parties | -| `org.hypercerts.claim.measurement` | Quantitative data attached to claims | -| `org.hypercerts.collection` | Projects/portfolios grouping multiple activities | -| `org.hypercerts.claim.attachment` | Attachments, reports, documentation | -| `org.hypercerts.funding.receipt` | Funding flow records | - -{% callout type="note" %} -**Migration:** `org.impactindexer.link.attestation` will migrate to `app.certified.link.*`. -{% /callout %} - -**Resources:** -- Repository: [github.com/hypercerts-org/hypercerts-lexicon](https://github.com/hypercerts-org/hypercerts-lexicon) -- Documentation: [impactindexer.org/lexicon](https://impactindexer.org/lexicon) - ---- - -## Data layer - -### Hypercerts PDS - -**Priority:** โšช Low ยท **Status:** Optional - -Personal Data Servers operated by the Hypercerts ecosystem that host user repositories containing hypercert records. - -**Why we're not prioritizing this:** Users can use any ATProto PDS (Bluesky's, self-hosted, community-operated). The data layer is solved. However, dedicated Hypercerts PDSs could eventually provide guaranteed uptime for impact-critical data, support for larger blobs, federation across multiple servers, and organizational sovereignty. - -| PDS | Type | Example users | -|-----|------|---------------| -| `pds.bsky.app` | Third-party (Bluesky) | General users | -| `pds1.certified.app` | Optional Hypercerts | climateai.org, daviddao.org, hyperboards.org | -| `pds2.certified.app` | Optional Hypercerts | Additional users | - ---- - -## Network & streaming layers - -### Current approach โฌœ - -We subscribe to Bluesky's relay and filter for `org.hypercerts.*` and `app.certified.*` collections. Bluesky's Jetstream provides filtered JSON streams by collection. This is sufficient for current needs. - -### Future options ๐Ÿ”ต - -**Priority:** โšช Low ยท **Status:** Future - -If needed later, dedicated Hypercerts infrastructure could include: - -- **Hypercerts Relayer** โ€” Aggregation service that crawls PDSs hosting hypercert records, validates cryptographic signatures, and provides a unified event stream. -- **Hypercerts Firehose** โ€” WebSocket endpoint providing real-time stream of all hypercert-related commits in CBOR format. -- **Hypercerts Jetstream** โ€” Filtered, JSON-formatted stream allowing consumers to subscribe only to specific collections with reduced bandwidth and lower resource requirements. - -{% callout type="note" %} -These are not needed today. Bluesky's relay (`bsky.network`) and Jetstream handle this. We will revisit if the network outgrows third-party infrastructure. -{% /callout %} - ---- - -## Moderation layer ๐ŸŸข - -Community-governed evaluation and labeling infrastructure, managed by the Hypercerts Collective. - -### Evaluators - -**Priority:** ๐ŸŸ  High ยท **Status:** Active ยท **Owner:** Hypercerts Collective - -Services producing structured evaluations for hypercert records. Types include AI-powered evaluators (automated analysis), human expert panels (domain expertise), and hybrid approaches (AI-assisted human review). - -**Lexicons:** `org.hypercerts.claim.evaluation`, `app.gainforest.evaluator.*` - -### Hypercerts Labeller - -**Priority:** ๐ŸŸ  High ยท **Status:** Active ยท **Owner:** Hypercerts Collective - -Lightweight annotations using ATProto's labeler pattern. Use cases include quality indicators, verification status, category tags, and warning labels. - ---- - -## Application layer - -### Hyperindex AppView ๐Ÿ”ต - -**Priority:** ๐Ÿ”ด Critical ยท **Status:** Active ยท **Owner:** GainForest โ†’ Foundation - -The primary AppView server that indexes hypercert records and exposes them via a GraphQL API. Name origin: **Hyper**sphere **Go** **AT**Proto AppView. - -**Why it matters:** Raw ATProto data is distributed across PDSs. The AppView consumes the Firehose/Jetstream, builds queryable indexes, hydrates records with context, provides search and aggregation, and serves the `app.certified.*` and `org.hypercerts.*` API endpoints. - -**Technical details:** - -| Feature | Detail | -|---------|--------| -| API | GraphQL (HTTP + WebSocket subscriptions) | -| Schema | Dynamically generated from uploaded lexicons | -| Pagination | Relay-style cursor pagination | -| Real-time | WebSocket subscriptions for new records | -| Search | Full-text search across hypercert content | - -**Endpoints:** -- GraphQL: `hyperindex.certified.app/graphql` -- GraphiQL: `hyperindex.certified.app/graphiql` - -### Frontends ๐ŸŸข - -Applications built on the infrastructure, governed by the Hypercerts Collective: - -| Frontend | Purpose | Status | -|----------|---------|--------| -| **Ma Earth** | Regenerative land funding, community onboarding | Active | -| **hyperboards.org** | Hypercert visualization and management | Active | -| **Other frontends** | Third-party applications | Ecosystem | - -**How records flow:** - -1. User creates a hypercert record via a frontend (Ma Earth, hyperboards.org, etc.) -2. Frontend writes the record to the user's PDS -3. PDS syncs to the network via the relay -4. Hyperindex indexes the record -5. Record becomes available for queries and evaluations - ---- - -## Bridge layer ๐Ÿ”ต - -### IdentityLink - -**Priority:** ๐ŸŸ  High ยท **Status:** Live - -A system for linking ATProto DIDs to Ethereum/EVM wallet addresses via cryptographic attestations. This enables contributors to receive onchain payments, verification that a DID controls a specific address, integration with onchain attestation layers (EAS), and cross-chain identity resolution. - -**Flow:** - -``` -1. User authenticates with ATProto via OAuth -2. User connects EVM wallet -3. User signs EIP-712 typed message -4. Attestation stored in user's PDS -5. Anyone can verify cryptographically -``` - -**Properties:** - -- **Self-sovereign** โ€” Attestations in user's PDS, not a central database -- **Cryptographic** โ€” EIP-712 signatures verifiable by anyone -- **Wallet-agnostic** โ€” EOAs, Coinbase Smart Wallet, Safe, ERC-1271 - -**Live:** [identitylink.vercel.app](https://identitylink.vercel.app) - -{% callout type="note" %} -**Migration:** Lexicon migrating from `org.impactindexer.link.attestation` to `app.certified.link.*`. -{% /callout %} - -### StorageLink - -**Priority:** ๐ŸŸก Medium ยท **Status:** Planned - -A service that creates immutable backups of hypercert records on decentralized storage (Filecoin/IPFS). ATProto repositories are mutable โ€” records can be updated or deleted. For high-stakes impact claims, immutable archival provides permanence, verifiability, and compliance with funding mechanisms that require immutable records. - -``` -User's PDS record โ†’ StorageLink โ†’ Filecoin Cloud (immutable backup) -``` - -### EVM Indexer - -**Priority:** ๐ŸŸ  High ยท **Status:** Planned - -An indexer that tracks onchain events related to Hypercerts (token mints, transfers, funding distributions). Creates a unified view across ATProto records and blockchain state โ€” indexing tokenization events, tracking funding flows, and enabling queries like "show all funded activities for this project." - -``` -Blockchain events โ†’ EVM Indexer โ†’ Hyperindex (unified view) -``` - ---- - -## AI agent readiness - -**Priority:** ๐ŸŸ  High - -Most applications will be built via AI coding assistants. Infrastructure must be AI-native. - -**Requirements by component:** - -| Component | Requirements | -|-----------|-------------| -| Lexicons | Complete field descriptions, clear constraints, examples, consistent patterns | -| AppView | GraphQL introspection, complete schema docs, consistent queries | -| Docs | OpenAPI/JSON Schema, `AGENTS.md` files, copy-pasteable examples | - -**Action items:** - -| Action | Priority | Status | -|--------|----------|--------| -| Add OpenAPI spec for Hyperindex | High | Todo | -| Create `AGENTS.md` in repos | High | Todo | -| Ensure all lexicon fields have descriptions | High | In Progress | -| Publish example workflows | Medium | Todo | -| Create MCP (Model Context Protocol) server | Medium | Todo | - ---- - -## Governance: the Hypercerts Collective - -**Priority:** ๐ŸŸ  High - -Open governance body for the ATProto impact ecosystem. Coordinates decisions about shared infrastructure (๐ŸŸข green components). - -**Repository:** [tangled.org/gainforest.earth/hypercollective](https://tangled.org/gainforest.earth/hypercollective) - -**What the Hypercerts Collective governs:** - -- Evaluators -- Hypercerts Labeller -- Frontend applications (Ma Earth, hyperboards.org) -- Lexicon standards adoption - -### Lexicon Indexing Requests (LIRs) - -Formal proposals to add lexicons to Hyperindex's indexing. The community decides what becomes shared infrastructure. - -| LIR | Description | Status | -|-----|-------------|--------| -| LIR-0001 | GainForest Lexicons (Darwin Core, Evaluator, Organization) | Approved | -| LIR-0002 | Impact Indexer Review System (comments, likes) | Approved | -| LIR-0003 | Hypercerts Lexicons (claims, funding, badges, locations) | Approved | - -### Infrastructure transitions - -| Component | Current owner | Future owner | -|-----------|--------------|--------------| -| Hyperindex AppView | GainForest | Foundation + Community | -| IdentityLink | GainForest | Foundation + Community | -| Impact Indexer | GainForest | Foundation + Community | -| Lexicon Repos | Various | Hypercerts Collective coordination | - ---- - -## Development phases - -### Phase 1: Make it work (current) - -- End-to-end staging tests: create activity โ†’ evaluate โ†’ fund โ†’ distribute -- Integration tests across AppView โ†’ IdentityLink โ†’ EVM -- Basic functionality before optimization - -### Phase 2: Make it right (next) - -- Deploy to real users (Ma Earth, GainForest, community) -- Gather feedback on pain points and missing features -- Iterate on lexicon design based on actual usage -- Improve developer experience based on feedback - -### Phase 3: Make it fast (future) - -- Performance optimization based on real usage patterns -- Caching strategies for AppView -- Query optimization -- Only after validation and stability - ---- - -## Next steps - -1. **Finalize Lexicon v1.0** โ€” Lock core schemas for `org.hypercerts.claim.*` to enable stable application development -2. **Productionize Hyperindex** โ€” Harden for production traffic, add caching, improve query performance -3. **AI documentation sprint** โ€” OpenAPI spec, `AGENTS.md` files, copy-pasteable examples -4. **IdentityLink integration** โ€” Complete EIP-712 attestation flow with certified.app frontend -5. **Infrastructure transitions** โ€” Begin handoff to Foundation stewardship - ---- - -## Links & resources - -| Resource | URL | -|----------|-----| -| Lexicon Documentation | [impactindexer.org/lexicon](https://impactindexer.org/lexicon) | -| Hyperindex API | [hyperindex.certified.app/graphql](https://hyperindex.certified.app/graphql) | -| IdentityLink | [identitylink.vercel.app](https://identitylink.vercel.app) | -| Governance Repo | [tangled.org/gainforest.earth/hypercollective](https://tangled.org/gainforest.earth/hypercollective) | -| Hypercerts Foundation | [hypercerts.org](https://hypercerts.org) | diff --git a/public/search-index.json b/public/search-index.json index 4a22a3b..d4d75cc 100644 --- a/public/search-index.json +++ b/public/search-index.json @@ -116,7 +116,7 @@ "Wallet linkage", "Next steps" ], - "body": "Certified Identity Every hypercert record has an author. Every evaluation carries a signature. Every funding receipt traces back to a DID. Identity is a core primitive of the protocol โ€” it determines who owns records, who can be trusted, and who receives funding. Identity in the Hypercerts Protocol The Hypercerts Protocol uses AT Protocol's identity system. Every participant โ€” whether an individual contributor, an evaluator, or an organization โ€” is identified by a DID (Decentralized Identifier). A DID like did:plc:z72i7hdynmk6r22z27h6tvur is: - Permanent โ€” it never changes, even if you switch servers or handles - Portable โ€” your records, reputation, and history follow your DID across platforms - Cryptographically verifiable โ€” every record you create is signed by your DID's key pair, and anyone can verify the signature Your DID resolves via the PLC directory to a DID document containing your current PDS, public signing keys, and handle. How identity connects to the protocol | Layer | How identity is used | |-------|---------------------| | Data | Every record (activity claims, evaluations, measurements) carries the author's DID. The PDS signs records into a Merkle tree, making authorship tamper-evident. | | Trust | Evaluators build reputation tied to their DID. Applications can weight evaluations based on the evaluator's history and credentials. | | Funding | Funding receipts link funder DIDs to the work they support. Wallet linkage (work-in-progress) connects DIDs to onchain addresses for payment flows and tokenization. | | Portability | Switching PDS providers doesn't change your DID. Your entire history โ€” claims, evaluations, contributions โ€” migrates with you. | Certified: the reference identity provider Certified is the identity provider built for the Hypercerts ecosystem. It provisions the full identity stack in a single sign-up: - A DID โ€” your permanent identifier - A PDS โ€” your Personal Data Server, where records are stored - Low-friction sign-in โ€” email and code, no passwords or protocol knowledge required Certified exists because most Hypercerts users are not Bluesky users. Researchers, land stewards, open-source maintainers, and funders need an entry point that doesn't require knowledge of ATProto or decentralized protocols. Certified provides that โ€” a neutral identity provider that isn't tied to any single application. Handles (your public username) Handles are not needed to log in to the Hypercerts ecosystem, but every user has one. They serve as human-readable names for publicly addressing others and for interacting with other applications in the AT Protocol ecosystem that haven't implemented email-based login with Certified. Your handle (e.g., alice.certified.app) is human-readable but not permanent โ€” it's a pointer to your DID. Organizations can use custom domain handles (e.g., numpy.org) to prove organizational identity through DNS verification. For setup details, see Account & Identity Setup. Compatible with Bluesky and other AT Protocol accounts Hypercerts is fully interoperable with the AT Protocol ecosystem. If you already have a Bluesky account or any other ATProto identity, you can log in with your existing handle (e.g., alice.bsky.social) and use all Hypercerts applications โ€” no additional account needed. Wallet linkage To receive onchain funding, a DID needs to be linked to an onchain wallet address. This is handled by IdentityLink โ€” a cryptographic attestation system that binds a DID to one or more onchain addresses via a signed proof stored in your PDS. For the Ethereum ecosystem this looks like: 1. Authenticates the user via ATProto OAuth 2. Connects an EVM wallet (EOA, Smart Wallet, or Safe) 3. Signs an EIP-712 typed message proving ownership 4. Stores the attestation in the user's PDS The attestation is self-sovereign (stored in your PDS, not a central database) and verifiable by anyone. See the Roadmap for current IdentityLink status. Next steps - Account & Identity Setup โ€” create an account, configure custom domains, manage app passwords, and set up organization accounts - Architecture Overview โ€” how identity fits into the protocol stack - Quickstart โ€” create your first hypercert Next: Why AT Protocol? โ€” how identity and records stay portable across apps." + "body": "Certified Identity Every hypercert record has an author. Every evaluation carries a signature. Every funding receipt traces back to a DID. Identity is a core primitive of the protocol โ€” it determines who owns records, who can be trusted, and who receives funding. Identity in the Hypercerts Protocol The Hypercerts Protocol uses AT Protocol's identity system. Every participant โ€” whether an individual contributor, an evaluator, or an organization โ€” is identified by a DID (Decentralized Identifier). A DID like did:plc:z72i7hdynmk6r22z27h6tvur is: - Permanent โ€” it never changes, even if you switch servers or handles - Portable โ€” your records, reputation, and history follow your DID across platforms - Cryptographically verifiable โ€” every record you create is signed by your DID's key pair, and anyone can verify the signature Your DID resolves via the PLC directory to a DID document containing your current PDS, public signing keys, and handle. How identity connects to the protocol | Layer | How identity is used | |-------|---------------------| | Data | Every record (activity claims, evaluations, measurements) carries the author's DID. The PDS signs records into a Merkle tree, making authorship tamper-evident. | | Trust | Evaluators build reputation tied to their DID. Applications can weight evaluations based on the evaluator's history and credentials. | | Funding | Funding receipts link funder DIDs to the work they support. Wallet linkage (work-in-progress) connects DIDs to onchain addresses for payment flows and tokenization. | | Portability | Switching PDS providers doesn't change your DID. Your entire history โ€” claims, evaluations, contributions โ€” migrates with you. | Certified: the reference identity provider Certified is the identity provider built for the Hypercerts ecosystem. It provisions the full identity stack in a single sign-up: - A DID โ€” your permanent identifier - A PDS โ€” your Personal Data Server, where records are stored - Low-friction sign-in โ€” email and code, no passwords or protocol knowledge required Certified exists because most Hypercerts users are not Bluesky users. Researchers, land stewards, open-source maintainers, and funders need an entry point that doesn't require knowledge of ATProto or decentralized protocols. Certified provides that โ€” a neutral identity provider that isn't tied to any single application. Handles (your public username) Handles are not needed to log in to the Hypercerts ecosystem, but every user has one. They serve as human-readable names for publicly addressing others and for interacting with other applications in the AT Protocol ecosystem that haven't implemented email-based login with Certified. Your handle (e.g., alice.certified.app) is human-readable but not permanent โ€” it's a pointer to your DID. Organizations can use custom domain handles (e.g., numpy.org) to prove organizational identity through DNS verification. For setup details, see Account & Identity Setup. Compatible with Bluesky and other AT Protocol accounts Hypercerts is fully interoperable with the AT Protocol ecosystem. If you already have a Bluesky account or any other ATProto identity, you can log in with your existing handle (e.g., alice.bsky.social) and use all Hypercerts applications โ€” no additional account needed. Wallet linkage To receive onchain funding, a DID needs to be linked to an onchain wallet address. This is handled by IdentityLink โ€” a cryptographic attestation system that binds a DID to one or more onchain addresses via a signed proof stored in your PDS. For the Ethereum ecosystem this looks like: 1. Authenticates the user via ATProto OAuth 2. Connects an EVM wallet (EOA, Smart Wallet, or Safe) 3. Signs an EIP-712 typed message proving ownership 4. Stores the attestation in the user's PDS The attestation is self-sovereign (stored in your PDS, not a central database) and verifiable by anyone. Next steps - Account & Identity Setup โ€” create an account, configure custom domains, manage app passwords, and set up organization accounts - Architecture Overview โ€” how identity fits into the protocol stack - Quickstart โ€” create your first hypercert Next: Why AT Protocol? โ€” how identity and records stay portable across apps." }, { "path": "/core-concepts/common-use-cases", @@ -480,7 +480,7 @@ "description": "Common questions about building with Hypercerts.", "section": "Reference", "headings": [], - "body": "FAQ --- What is a hypercert? A structured digital record of a contribution โ€” who did what, when, where, and with what supporting documentation. You create one by writing an org.hypercerts.claim.activity record to your PDS. See the Quickstart. How is this different from the previous (EVM-based) Hypercerts? The new protocol stores data on AT Protocol instead of purely on-chain. This gives you richer schemas, data portability, and lower costs. On-chain anchoring for funding is planned but not yet implemented. Do I need a blockchain wallet? Not to create or evaluate hypercerts โ€” you only need an account on certified.app or any ATProto provider. A wallet will be needed for on-chain funding once the tokenization layer is built. Can I use my Bluesky account? Yes. Bluesky accounts are ATProto accounts. Your existing DID and identity work with Hypercerts out of the box. Is my data public? Yes. All records are public by default. Do not store sensitive personal information in hypercert records. See the privacy section in Testing & Deployment for guidance on what to include and what to keep off-protocol. Can I delete a hypercert? You can delete records from your account. However, cached copies may persist in indexers temporarily. Once data is published, treat it as potentially permanent. Who can evaluate my hypercert? Anyone with an ATProto account. Evaluations are separate records created by the evaluator, linked to your hypercert via a strong reference. You don't control who evaluates your work. See Working with Evaluations. How do I query hypercerts across the network? Use the Hyperindex GraphQL API at https://api.hi.gainforest.app/graphql. It indexes all hypercert records across the network and supports filtering, search, and real-time subscriptions. How do I fund a hypercert? The on-chain funding layer is not yet implemented. The planned design freezes records before funding to ensure funders know exactly what they are paying for. See Funding & Value Flow. Where do I get help? - GitHub โ€” source code, issues, and discussions - Roadmap โ€” what's being built and what's next" + "body": "FAQ --- What is a hypercert? A structured digital record of a contribution โ€” who did what, when, where, and with what supporting documentation. You create one by writing an org.hypercerts.claim.activity record to your PDS. See the Quickstart. How is this different from the previous (EVM-based) Hypercerts? The new protocol stores data on AT Protocol instead of purely on-chain. This gives you richer schemas, data portability, and lower costs. On-chain anchoring for funding is planned but not yet implemented. Do I need a blockchain wallet? Not to create or evaluate hypercerts โ€” you only need an account on certified.app or any ATProto provider. A wallet will be needed for on-chain funding once the tokenization layer is built. Can I use my Bluesky account? Yes. Bluesky accounts are ATProto accounts. Your existing DID and identity work with Hypercerts out of the box. Is my data public? Yes. All records are public by default. Do not store sensitive personal information in hypercert records. See the privacy section in Testing & Deployment for guidance on what to include and what to keep off-protocol. Can I delete a hypercert? You can delete records from your account. However, cached copies may persist in indexers temporarily. Once data is published, treat it as potentially permanent. Who can evaluate my hypercert? Anyone with an ATProto account. Evaluations are separate records created by the evaluator, linked to your hypercert via a strong reference. You don't control who evaluates your work. See Working with Evaluations. How do I query hypercerts across the network? Use the Hyperindex GraphQL API at https://api.hi.gainforest.app/graphql. It indexes all hypercert records across the network and supports filtering, search, and real-time subscriptions. How do I fund a hypercert? The on-chain funding layer is not yet implemented. The planned design freezes records before funding to ensure funders know exactly what they are paying for. See Funding & Value Flow. Where do I get help? - GitHub โ€” source code, issues, and discussions" }, { "path": "/reference/glossary", @@ -490,44 +490,6 @@ "headings": [], "body": "Glossary --- Hypercert A structured digital record of a contribution: who did what, when, where, and with what evidence. The core primitive of the protocol. Technically, a hypercert is an activity claim record with linked contributions, attachments, measurements, and evaluations. Activity claim The central record in the hypercerts data model. Describes the work that was done, when, and in what scope. AT-URI The permanent, globally unique identifier for a record. Looks like at://did:plc:abc123/org.hypercerts.claim.activity/3k7. You'll see these in every API response โ€” they're how records reference each other. DID (Decentralized Identifier) A permanent identifier for a user or organization. Looks like did:plc:abc123xyz. You get one when you create an account on certified.app or Bluesky. Your DID never changes, even if you switch servers or handles. Every record you create carries your DID as the author. Strong reference A reference to another record that includes both the AT-URI and a content hash (CID). Used when one record points to another (e.g., an evaluation referencing an activity claim). The CID makes the reference tamper-evident โ€” if the target record changes, the hash won't match. Evaluation A third-party assessment of a hypercert. Created on the evaluator's own account, not the original author's. Attachment Supporting documentation linked to one or more records โ€” a URL, uploaded file, or IPFS link. Measurement A quantitative observation attached to a hypercert (e.g., \"12 pages written\", \"50 tons COโ‚‚ reduced\"). Contribution Who contributed to a hypercert. Can be as simple as a DID string, or a richer record with display name, image, role, and timeframe. Collection A named group of hypercerts and/or other collections, with an optional weight per item. Each collection has a type (e.g., \"favorites\", \"project\") so the same hypercert can appear in different collections for different purposes. Lexicon A versioned schema that defines the structure of a record type. Lexicons enable interoperability โ€” any app that knows the schema can read the record. See Introduction to Lexicons. Work scope The \"what\" dimension of a hypercert โ€” what work is being claimed. Can be a simple free-text string or a structured CEL expression for machine-evaluable scopes. See Work Scopes. Hyperindex A reference indexer that indexes hypercert records across the network and exposes them via a GraphQL API. Other indexers exist โ€” see Indexers & Discovery. PDS (Personal Data Server) The server where your records are stored. You interact with it through the ATProto API โ€” you don't need to manage it directly. You can use the Hypercerts Foundation's PDS, Bluesky's, or self-host one. Records are portable between PDS instances. Certified The identity provider for the Hypercerts ecosystem. We built Certified to give the ecosystem a unified entry point โ€” one account that works across all Hypercerts applications. When you sign up at certified.app, you get a DID, a PDS, and an embedded wallet. See Account & Identity Setup." }, - { - "path": "/roadmap", - "title": "Roadmap", - "description": "Development priorities, infrastructure components, and phased delivery plan for Hypercerts v0.2.", - "section": "Reference", - "headings": [ - "Infrastructure overview", - "Build priorities", - "Lexicons ๐Ÿ”ต", - "Lexicons", - "Data layer", - "Hypercerts PDS", - "Network & streaming layers", - "Current approach โฌœ", - "Future options ๐Ÿ”ต", - "Moderation layer ๐ŸŸข", - "Evaluators", - "Hypercerts Labeller", - "Application layer", - "Hyperindex AppView ๐Ÿ”ต", - "Frontends ๐ŸŸข", - "Bridge layer ๐Ÿ”ต", - "IdentityLink", - "StorageLink", - "EVM Indexer", - "AI agent readiness", - "Governance: the Hypercerts Collective", - "Lexicon Indexing Requests (LIRs)", - "Infrastructure transitions", - "Development phases", - "Phase 1: Make it work (current)", - "Phase 2: Make it right (next)", - "Phase 3: Make it fast (future)", - "Next steps", - "Links & resources" - ], - "body": "Roadmap This page outlines the infrastructure components, build priorities, and phased delivery plan for Hypercerts v0.2 โ€” a decentralized system for tracking, evaluating, and funding impactful work on the open internet. This roadmap reflects the current plan and is subject to change as we gather feedback from real users and contributors. Status labels indicate where each component stands today. --- Infrastructure overview The Hypercerts infrastructure divides into six functional areas. Each area has a different ownership model: | Color | Meaning | |-------|---------| | ๐Ÿ”ต Blue | Hypercerts Infrastructure โ€” core protocol components this roadmap covers | | ๐ŸŸข Green | Hypercerts Collective Infrastructure โ€” community-governed components | | โฌœ Grey | Third-party Infrastructure โ€” leverage existing services, don't rebuild | --- Build priorities | Component | Priority | Status | Owner | |-----------|----------|--------|-------| | Lexicons | ๐Ÿ”ด Critical | Active | Hypercerts Foundation | | Hyperindex AppView | ๐Ÿ”ด Critical | Active | GainForest โ†’ Foundation | | IdentityLink | ๐ŸŸ  High | Live | GainForest โ†’ Foundation | | EVM Indexer | ๐ŸŸ  High | Planned | TBD | | Evaluators | ๐ŸŸ  High | Active | Hypercerts Collective | | Hypercerts Labeller | ๐ŸŸ  High | Active | Hypercerts Collective | | AI-Ready Docs | ๐ŸŸ  High | In Progress | All | | StorageLink | ๐ŸŸก Medium | Planned | TBD | | Hypercerts PDS | โšช Low | Optional | โ€” | | Hypercerts Relayer / Firehose / Jetstream | โšช Low | Future | โ€” | --- Lexicons ๐Ÿ”ต Lexicons Priority: ๐Ÿ”ด Critical ยท Status: Active ยท Owner: Hypercerts Foundation Lexicons are the schema definitions that specify the structure of all Hypercerts records on ATProto. They are the \"contracts\" that define how data is structured, validated, and referenced across the network. Without standardized schemas, interoperability between applications would be impossible. *app.certified. โ€” Certified application lexicons* | Lexicon | Purpose | |---------|---------| | app.certified.badge.definition | Badge type definitions | | app.certified.badge.award | Badge awards to users | | app.certified.location | Georeferenced location data | | app.certified.link. | Identity attestations (DID to EVM) | *org.hypercerts. โ€” Hypercerts protocol lexicons | Lexicon | Purpose | |---------|---------| | org.hypercerts.claim.activity | Core hypercert records tracking impact work | | org.hypercerts.claim.evaluation | Evaluations of activities by third parties | | org.hypercerts.claim.measurement | Quantitative data attached to claims | | org.hypercerts.collection | Projects/portfolios grouping multiple activities | | org.hypercerts.claim.attachment | Attachments, reports, documentation | | org.hypercerts.funding.receipt | Funding flow records | Migration:* org.impactindexer.link.attestation will migrate to app.certified.link.. Resources: - Repository: github.com/hypercerts-org/hypercerts-lexicon - Documentation: impactindexer.org/lexicon --- Data layer Hypercerts PDS Priority: โšช Low ยท Status: Optional Personal Data Servers operated by the Hypercerts ecosystem that host user repositories containing hypercert records. Why we're not prioritizing this: Users can use any ATProto PDS (Bluesky's, self-hosted, community-operated). The data layer is solved. However, dedicated Hypercerts PDSs could eventually provide guaranteed uptime for impact-critical data, support for larger blobs, federation across multiple servers, and organizational sovereignty. | PDS | Type | Example users | |-----|------|---------------| | pds.bsky.app | Third-party (Bluesky) | General users | | pds1.certified.app | Optional Hypercerts | climateai.org, daviddao.org, hyperboards.org | | pds2.certified.app | Optional Hypercerts | Additional users | --- Network & streaming layers Current approach โฌœ We subscribe to Bluesky's relay and filter for org.hypercerts. and app.certified. collections. Bluesky's Jetstream provides filtered JSON streams by collection. This is sufficient for current needs. Future options ๐Ÿ”ต Priority: โšช Low ยท Status: Future If needed later, dedicated Hypercerts infrastructure could include: - Hypercerts Relayer โ€” Aggregation service that crawls PDSs hosting hypercert records, validates cryptographic signatures, and provides a unified event stream. - Hypercerts Firehose โ€” WebSocket endpoint providing real-time stream of all hypercert-related commits in CBOR format. - Hypercerts Jetstream โ€” Filtered, JSON-formatted stream allowing consumers to subscribe only to specific collections with reduced bandwidth and lower resource requirements. These are not needed today. Bluesky's relay (bsky.network) and Jetstream handle this. We will revisit if the network outgrows third-party infrastructure. --- Moderation layer ๐ŸŸข Community-governed evaluation and labeling infrastructure, managed by the Hypercerts Collective. Evaluators Priority: ๐ŸŸ  High ยท Status: Active ยท Owner: Hypercerts Collective Services producing structured evaluations for hypercert records. Types include AI-pow" - }, { "path": "/tools/hyperboards", "title": "Hyperboards",