Zum Hauptinhalt springen

Concepts & glossary

Diese Seite definiert jede zentrale DIG-Network-Entität einmal, in einfacher Sprache, und verlinkt jede mit der ausführlichen Dokumentation dazu. Sie ist das menschenlesbare Rückgrat der Dokumentation — und, weil jeder Begriff auch als maschinenlesbare strukturierte Daten ausgegeben wird, die Karte, die ein Agent abgrasen kann, um das Vokabular des Netzwerks zu lernen. Überflieg sie zur Orientierung; folge einem Link, um tiefer einzusteigen.

Die capsule​

Eine capsule ist eine unveränderliche store-Generation: das Paar (storeId, rootHash), kanonisch geschrieben als storeId:rootHash. Sie ist die atomare Einheit des Netzwerks — für Kompilierung (ein WASM-Modul fester Größe), Preisgestaltung (ein einheitlicher Preis pro capsule zum Minten oder Committen, bezahlt in $DIG), Abruf (eine URN benennt eine capsule), Caching und Herkunftsnachweis. Ein store ist eine Sequenz von capsules, eine pro Commit. Diese Definition ist identisch in DigStore, dem dig RPC und dem DIG Browser. → Die capsule, vollständig

Store​

Ein store ist eine Identität plus ihr Inhalt und ihre Historie: eine Sequenz von capsules, eine pro Commit. Seine Identität ist eine 64-Hex-store id, die identisch mit ihrer on-chain-Chia-Singleton-Launcher-ID ist — das Chain-Singleton ist die Autorität für den aktuellen Root des stores. Ein store ist das DIG-Äquivalent einer Website. → Store-Struktur

Generation​

Eine generation ist ein einzelner committeter Zustand eines stores, identifiziert durch einen Root-Hash (ein Merkle-Root über die Per-Ressource-Blätter der generation). Jeder commit versiegelt den aktuellen Inhalt in einer neuen, append-only generation — dasselbe, was eine capsule benennt. Generations wachsen monoton, wie eine Git-Historie. → Generations & Root-Hashes

URN​

Eine URN ist die Adresse und der Schlüssel von DigStore in einem String: urn:dig:chia:<storeId>[:<rootHash>][/<resource>]. Sie lokalisiert eine Ressource und leitet den Schlüssel ab, der sie entschlüsselt — den Besitz der URN zu haben ist notwendig und hinreichend, um eine öffentliche Ressource zu lesen. Die browserseitige Kurzform ist das chia://-Protokoll. → URNs & Verschlüsselung

Retrieval key​

Der retrieval key ist SHA-256(canonical_urn) — die einzige Adresse, die den Client jemals verlässt. Er lokalisiert den Chiffretext einer Ressource, ohne ihren Pfad oder ihre URN preiszugeben. Er ist root-unabhängig, sodass derselbe Schlüssel eine Ressource über generations hinweg findet; die ausgelieferten Bytes werden anschließend gegen den korrekten Root Merkle-verifiziert. Der separate Entschlüsselungsschlüssel wird lokal (HKDF) aus derselben URN abgeleitet und nie gesendet. → Zwei Werte, ein String

Merkle proof​

Jede generation baut einen Merkle-Baum mit einem Blatt pro Ressource, der sich auf die exakten ausgelieferten Chiffretext-Bytes festlegt. Ein einzelner Inclusion-Proof begleitet eine ausgelieferte Ressource und beweist, dass diese Bytes zu genau diesem Root gehören — sodass Inhalt verifiziert wird, ohne je entschlüsselt zu werden, und einem Node nie vertraut werden muss, echte Bytes zurückgegeben zu haben. → Merkle proofs

On-chain-Verankerung​

Jeder store ist ein Singleton auf dem Chia-Mainnet. digstore init mintet ihn (die Launcher-ID wird zur store-ID), und jeder digstore commit verankert einen neuen generation-Root on-chain als CHIP-0035-Singleton-Update. Beide blockieren, bis sie bestätigt sind, und geben echte Mittel aus. Die Chain ist die Autorität für den aktuellsten Root eines stores. → On-chain-Verankerung

DIG-Zahlung​

$DIG ist der Token des DIG Network (ein Chia-CAT). Das Minten einer capsule (init) oder das Committen einer solchen kostet einen einheitlichen Preis pro capsule in $DIG, der atomar in derselben on-chain-Ausgabe wie die Verankerung enthalten ist — es gibt keine separate Transaktion, und das Memo trägt die store-ID. → Kosten

DigStore CLI​

digstore ist das Kommandozeilen-Tool, das stores erstellt, committet, teilt und liest — ein Git-förmiger Workflow (init, add, commit, log, clone, push, pull) über das verschlüsselte, on-chain-store-Format. → Kommandoreferenz · CLI-Tutorial

dig.toml​

dig.toml ist das committbare Projektmanifest im Root eines Projekts — store-id, output-dir, build-command und weitere Projektkonfiguration, gemeinsam genutzt von digstore dev, digstore deploy und den Scaffolding-Templates. Es enthält keine Geheimnisse (die kommen aus der Umgebung), daher ist es sicher, es zu committen. → Projektkonfiguration & Build-Zeit-Werte

create-dig-app​

create-dig-app (npm create dig-app) ist die JS-Eingangstür für den Start eines DIG-Projekts: es scaffoldet einen lauffähigen Starter — eine App, eine dig.toml und (für die Wallet-Templates) das eingebundene DIG SDK — aus einem von fünf Templates (static, vite-react, next-static, nft-drop, dapp-window-chia). Scaffolding ist kostenlos — kein Mint, keine Chain, keine Ausgabe; du zahlst den einheitlichen capsule-Preis erst, wenn du eine capsule veröffentlichst. Es ist das npm-seitige Gegenstück zum digstore new der Rust-CLI. → Eine App scaffolden

Die GitHub-Deploy-Action​

dig-network/deploy-action ist die git-push-to-deploy-GitHub-Action: sie installiert die digstore-CLI auf dem Runner, führt digstore deploy aus, um deinen store voranzubringen (mintet nie), und meldet die veröffentlichte capsule + URLs + Kosten als Step-Outputs, PR-Kommentar, GitHub-Deployment und Commit-Status zurück. Mit if-changed (Standard) ist ein bytegleicher Build ein No-op — keine Ausgabe. → Deploy from GitHub Actions

DIG SDK​

Das DIG SDK (@dignetwork/dig-sdk) ist das typisierte npm-Paket für integrierende Entwickler: ein ChiaProvider (bevorzugt injiziertes window.chia, fällt zurück auf WalletConnect → Sage), ein DigClient (liest verifizierten, verschlüsselten Inhalt über den dig RPC), eine Paywall (ein High-Level-Pay-to-Unlock- / NFT-Gated-Access-Helfer, der den Provider mit dem Spend-Builder kombiniert) und der kanonische CHIP-0035-Spend-Builder, re-exportiert unter dem /spend-Unterpfad. → Eine Dapp auf Chia bauen

Der dig RPC​

Der dig RPC ist die netzwerkweite Leseschnittstelle: ein JSON-RPC-2.0-Dienst über HTTPS POST, den jeder Hosting-Node identisch spricht. Er liefert Chiffretext + Inclusion-Proofs per retrieval key, ganze capsules per (storeId, root) und Discovery-Metadaten — durch Konstruktion blind, clientseitig verifiziert und entschlüsselt. Es ist der universelle Lesepfad: jede veröffentlichte capsule ist hier über ihre URN / chia://-Adresse lesbar, sobald sie on-chain bestätigt ist — ohne Registrierung und ohne Zahlung über das Veröffentlichen der capsule hinaus. Der optionale, benutzerfreundliche *.on.dig.net-Handle ist eine Eingangstür zusätzlich zu diesem; der dig RPC selbst ist immer verfügbar. → Was ist der dig RPC?

Das chia://-Protokoll​

chia:// ist das native Inhaltsadressierungsschema des DIG Browser — die eintippbare Frontend-Form der urn:dig:-URN. Füge einen chia://<storeId>/-Link ein, und der Browser holt den Inhalt direkt aus dem Netzwerk, inhaltsadressiert und kryptografisch verifiziert. → Das chia://-Protokoll

window.chia​

window.chia ist der Chia-Wallet-Provider, den der DIG Browser in jede Seite injiziert. Er spricht CHIP-0002, sodass eine Web-App die Adresse, Signaturen und Spends des Nutzers ohne WalletConnect-Setup anfordern kann — eine Drop-in-Alternative für Apps, die bereits CHIP-0002 sprechen. → window.chia verwenden · Die window.chia-Provider-Spezifikation (normativ, versioniert)

DIGHUb​

DIGHUb (hub.dig.net) ist die Web-App zum Veröffentlichen und Verwalten von capsules ohne die CLI — erstelle eine capsule, deploye ein Frontend und sieh dir deine stores im Browser an. Sie ist außerdem die gated Control-Plane, die teure ZK-Ausführungsbeweis-Jobs budgetiert.

dig-node​

Ein dig-node ist der Inhalts-Server des Netzwerks — die Angebotsseite. Er hostet capsules, hält einen lokalen .dig-Cache und spricht den dig RPC identisch zu rpc.dig.net. Du brauchst keinen, um DIG-Inhalte zu lesen (Konsumenten fallen zurück auf rpc.dig.net); einen zu betreiben macht Lesevorgänge local-first und trägt zur Auslieferungskapazität bei. Der Host ist blind — er leitet ausschließlich Chiffretext + Proofs weiter. → Einen Node betreiben

on.dig.net-Handle​

Ein on.dig.net-Handle ist eine optionale, kostenpflichtige benutzerfreundliche Web-Adresse für einen store: <dein-name>.on.dig.net. Ein store bekommt automatisch keine solche Adresse — du registrierst den Handle (eine kostenpflichtige CHIP-54- / on.dig.net-Registrierung in DIGHUb), und diese Registrierung pinnt den store an den Namen. Keine Registrierung bedeutet keine *.on.dig.net-Adresse. Es ist rein eine bequeme Eingangstür: der store ist bereits über den dig RPC via seiner URN / chia://-Adresse lesbar, unabhängig davon, ob ein Handle existiert. (Account-Handles und store-Slugs sind separate Namensräume und legen nicht automatisch eine Subdomain offen.) → Kann ich eine *.on.dig.net-Adresse bekommen?

Für Agenten & LLMs​

Diese Dokumentation ist maschinell extrahierbar. Jede Seite trägt schema.org JSON-LD (diese hier als ein DefinedTerm-Set), und zwei kuratierte Karten liegen an der Wurzel der Website: