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 dig-store, 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 dig-store 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. digs init mintet ihn (die Launcher-ID wird zur store-ID), und jeder digs 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

dig-store CLI​

dig-store 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 digs dev, digs 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 digs 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 dig-store-CLI auf dem Runner, führt digs 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: