← Alle Beiträge

9 Min. Lesezeit

Wie du CardanoWall ohne die Website nutzt

Die Website ist eine Oberfläche, nicht das ganze Produkt. Du kannst Label-309-Einträge über eine CLI, SDKs, eine Gateway-API, eine Desktop-App oder deinen eigenen Dienst veröffentlichen und verifizieren.

Du kannst CardanoWall nutzen, ohne jemals die Website zu öffnen. Dieselben Existenznachweise lassen sich über ein Kommandozeilen-Werkzeug, ein SDK in deinem Anwendungscode, eine Gateway-API, eine Desktop-App oder einen Dienst, den du selbst betreibst, erzeugen, veröffentlichen und verifizieren. Die Website ist nur eine Oberfläche für einen offenen Standard – Label 309 – und der Standard ist das, worauf es wirklich ankommt.

Genau auf diesen Unterschied kommt es an. Ein Existenznachweis ist oft keine einmalige menschliche Handlung. Er gehört in eine Build-Pipeline, eine Compliance-Routine, ein Provenienz-System für KI, einen juristischen Beweismittel-Workflow oder ein Produkt, das jemand anderes baut. Keines davon sollte voraussetzen, dass sich ein Mensch durch eine einzige Web-Oberfläche klickt.

Was leistet die Website eigentlich?

Die Website macht Existenznachweise zugänglich. Sie gibt dir einen visuellen Composer, eine Konto- und Guthabenansicht, Eintragsseiten, eine Identitätsverwaltung, einen Upload-Ablauf und geführtes Veröffentlichen. Für die meisten ist sie der richtige Einstieg.

Aber sie sollte nicht die einzige Möglichkeit sein, den Standard zu nutzen. Wenn ein Nachweis nur funktioniert, wenn sich ein Mensch durch eine Oberfläche klickt, kann er nie zur Infrastruktur werden. Unternehmen brauchen Automatisierung. Entwickler brauchen APIs und SDKs. Operations- und Sicherheitsteams brauchen wiederholbare, skriptbare Abläufe. Manche Nutzer wollen ihre Einträge und Dateien auf der eigenen Maschine. Manche Betreiber wollen die ganze Pipeline selbst fahren.

Die Web-App ist die Eingangstür. Sie ist nicht das ganze Gebäude.

Welche anderen Wege gibt es, sie zu nutzen?

Es sind mehrere, und sie laufen alle auf dasselbe Artefakt hinaus – einen standardkonformen Label-309-Eintrag, der auf Cardano verankert ist und den jeder unabhängig verifizieren kann:

  • die CardanoWall-Web-App;
  • das quelloffene Kommandozeilen-Werkzeug cardanowall;
  • die offiziellen SDKs (TypeScript, Python, Rust) für Anwendungscode;
  • eine Label-309-Gateway-API, erreichbar über ein kontospezifisches Token;
  • CardanoWall Desktop, der quelloffene, local-first arbeitende Client;
  • ein Gateway, das du selbst hostest;
  • dein eigenes Produkt, aufgebaut auf einem Gateway.

Die Oberfläche kann sich ändern. Das Nachweisformat nicht. Dieser gesamte Code ist quelloffen unter github.com/cardanowall, lizenziert unter Apache-2.0, mit dem Text der Spezifikation unter CC-BY-4.0.

Wann sollte ich die Gateway-API verwenden?

Verwende die API, wenn das Veröffentlichen oder Lesen von Nachweisen Teil eines Systems sein soll statt eines manuellen Schritts. Zum Beispiel:

  • ein SaaS-Produkt erzeugt für jedes Kundendokument einen Nachweis;
  • eine Build-Pipeline veröffentlicht nach jedem Build Release-Belege;
  • eine KI-Plattform verankert Stapel generierter Ausgaben;
  • ein Compliance-System veröffentlicht täglich einen Kontroll-Snapshot;
  • ein Workflow versiegelt Beweise für bestimmte Empfänger;
  • ein internes Dashboard liest Veröffentlichungsstatus und Kontoguthaben;
  • eine Partner-Integration reicht Einträge ein, ohne die CardanoWall-Oberfläche zu berühren.

Über den API-Weg ruft deine Software ein Gateway direkt auf, während du deine eigene Nutzererfahrung behältst. CardanoWalls eigene Web-App und der Worker erreichen das Gateway über genau diese öffentlichen Endpunkte – es gibt keine private Hintertür, also kannst du alles, was das Referenzprodukt kann, ebenso tun. Wenn du hier tiefer einsteigen willst, sieh dir auf der CardanoWall-API aufbauen an.

Wie funktionieren API-Tokens und Scopes?

Ein Gateway unterscheidet zwei Arten von Anmeldedaten, und sie sauber zu trennen, ist das Wichtigste, was du richtig machen musst.

Account-Tokens handeln als einer deiner Nutzer. Dein Backend stellt für ein bestimmtes Konto ein kurzlebiges Token aus, und der Aufruf läuft unter diesem Konto ab: einen Kostenvoranschlag anfordern, Inhalte hochladen, veröffentlichen, das Guthaben dieses Kontos lesen. Genau diese Tokens – und die API-Keys, die auf demselben Modell aufbauen – gehören in Skripte, CI-Jobs und Integrationen. Sie sind bewusst eng gefasst. Der aktuelle Satz an Scopes ist klein und zweckgebunden:

  • poe:create – Kostenvoranschläge anfordern, Inhalte hochladen, Einträge veröffentlichen;
  • poe:read – Einträge und Veröffentlichungsstatus lesen;
  • inbox:read – das verschlüsselte Inbox-Sync-Bookmark lesen;
  • account:read – das Kontoguthaben lesen.

Das ist die gesamte programmatische Fläche, und sie ist mit Absicht eng zugeschnitten. Ein schreibgeschütztes Dashboard-Widget braucht nur account:read. Ein Veröffentlichungs-Job braucht poe:create. Keines braucht das andere. Es gibt bewusst keinen Scope für Entschlüsselung auf dem Server: Versiegeln und Entsiegeln sind clientseitige Operationen, private Empfängerschlüssel erreichen also nie ein Gateway, und kein API-Key könnte den Server jemals dazu autorisieren, versiegelte Inhalte für dich zu lesen. Ebenso sollte ein CI-Job niemals den Identity Seed eines Nutzers halten, es sei denn, lokales Signieren ist ein bewusster Teil deines eigenen Designs, unter deinen eigenen Kontrollen – Seeds und private Schlüssel bleiben prinzipbedingt auf dem Client und sind nichts, was ein Gateway je zu sehen bekommt.

Operator-Anmeldedaten sind die zweite Art, und sie sind keine API-Keys. Sie autorisieren die Steuerebene – Konten bereitstellen, Guthaben-Anpassungen vornehmen, wenn dein Abrechnungssystem Geld einzieht, Margen setzen, die oben genannten Account-Tokens ausstellen. Sie dürfen nur auf einem vertrauenswürdigen Backend liegen, niemals in einem Browser, einer Mobil-App oder einem Skript. Ein geleaktes Account-Token sollte ein kurzlebiges Ärgernis sein; ein geleaktes Operator-Anmeldedatum wäre ein echter Vorfall.

Die Faustregel: Gib Clients das eng gefasste, kontogebundene Token, das sie brauchen, und halte die Operator-Befugnisse hinter deinem eigenen Backend.

Wann sollte ich die CLI verwenden?

Verwende das Kommandozeilen-Werkzeug, wenn ein Nachweis in ein Skript gehört. Die cardanowall-Binary ist gateway-unabhängig und raw-seed-first, was sie zu einer natürlichen Wahl macht für:

  • einen Eintrag lokal verifizieren, ohne eine Website zu öffnen;
  • Merkle-Nachweise über viele Dateien bauen und prüfen;
  • Einträge signieren;
  • Einträge aus der Automatisierung heraus einreichen;
  • Inbox-Sync und Probeentschlüsselung aus dem Terminal.

Die CLI ist gerade deshalb am wichtigsten, weil sie Existenznachweise nah an den Systemen hält, die die Artefakte erzeugen. Eine Build-Pipeline kann ihre Ausgaben hashen und einen Eintrag als Teil des Release veröffentlichen. Ein Compliance-Job kann täglich ein Manifest festschreiben. Ein lokaler Nutzer kann einen Eintrag offline verifizieren. Die Website ist großartig für Menschen; die CLI ist großartig für wiederholbare Abläufe. Für Muster und Beispiele sieh dir die CLI in der Automatisierung nutzen an.

Wann sollte ich ein SDK verwenden?

Verwende ein SDK, wenn Label 309 Teil deiner Anwendung sein soll. Die SDKs für TypeScript, Python und Rust helfen beim Konstruieren von Einträgen, beim Hashen von Inhalten, beim Verifizieren von Transaktionen, beim Signieren außerhalb des Hosts, beim Versiegeln und Entschlüsseln von Nutzdaten, beim Ableiten einer Identität aus einem Seed und beim Kommunizieren mit jedem beliebigen Gateway.

Drei SDKs zu haben ist nicht Bequemlichkeit – es ist Interoperabilität. Sie sind byte-identische Zwillinge, validiert gegen dieselben kanonischen Testvektoren, sodass ein Eintrag, der von einem veröffentlicht oder signiert wurde, unter den anderen identisch verifiziert. So bleibt ein offener Standard ein offener Standard, statt in gegenseitig inkompatible „kompatible“ Formate zu zerfallen. Eine nützliche Eigenschaft, die hervorzuheben sich lohnt: Der eigenständige Verifizierer braucht nur die Transaktions-Metadaten, optional die Inhalts-Bytes und einen öffentlichen Cardano-Explorer – kein Herausgeber-Server sitzt im Vertrauenspfad.

Wann sollte ich Desktop statt der Website verwenden?

Verwende die Desktop-App, wenn lokaler Besitz zählt. CardanoWall Desktop ist ein quelloffener, plattformübergreifender, offline-first arbeitender Client, gebaut in Rust mit Tauri auf dem Rust-SDK, und er funktioniert wie ein Mail-Client: Er gibt dir

  • lokale, verschlüsselte Identitäts-Tresore;
  • Offline-Zugriff auf alles, was bereits synchronisiert ist;
  • Erkennung versiegelter Inbox-Inhalte und zwischengespeicherten Chiffretext auf deiner eigenen Maschine;
  • lokale Suche über den öffentlichen Eintragsindex;
  • mehrere Identitäten und deine Wahl des Gateway-Anbieters.

Die Website bleibt schnell und bequem, während die Desktop-App die bessere Heimat ist, wenn du willst, dass deine Einträge, Identitäten und zwischengespeicherten Dateien lokal liegen und ohne Netzwerk weiterarbeiten. Für viele wird die Antwort beides sein. Mehr zum Design steht in CardanoWall Desktop und Offline-Nachweise.

Wann sollte ich ein Gateway selbst hosten?

Hoste selbst, wenn du die Veröffentlichungs-Pipeline selbst betreiben willst – aus Gründen der Compliance, der Kostenstruktur, des Volumens, der Datenverarbeitungsrichtlinie, der Infrastrukturkontrolle oder der Produktstrategie.

Ein selbst gehostetes Gateway veröffentlicht weiterhin standardkonforme Label-309-Einträge; der Unterschied ist, dass du den Dienst betreibst, der Kostenvoranschläge erstellt, hochlädt, einreicht, bestätigt, indexiert und das Veröffentlichen abrechnet. Das Gateway ist eine quelloffene Rust-Single-Binary plus Postgres, mit einem eigenen Cardano-Transaktionsbauer, der baut, einreicht, bestätigt, Chain-Reorganisationen behandelt und bei dauerhaftem Fehlschlag automatisch erstattet.

Selbst-Hosting ist nicht „kostenlos“. Du zahlst weiterhin die zugrunde liegenden Cardano- und Arweave-Kosten und übernimmst die operative Verantwortung für den Betrieb. Was du entfernst, ist jede Abhängigkeit von einem gehosteten CardanoWall-Gateway für das Veröffentlichen. Sieh dir dein eigenes Gateway betreiben und was ist ein Label-309-Gateway? an.

Kann ich mein eigenes Produkt auf einem Gateway bauen?

Ja – und genau diese Trennung ist der Grund, warum das Gateway eine eigene Schicht ist, getrennt von der Web-App. Du kannst ein Notarisierungs-Produkt, ein Beweisportal, ein Compliance-Archiv, ein Veröffentlichungs-Werkzeug, einen Provenienz-Dienst für KI oder ein internes Dashboard auf einem Label-309-Gateway bauen.

Das Gateway besitzt die Basisebene: Chain, Speicher, Preisbildung, den gemeinsamen On-Chain-Eintragsindex, Guthaben und Veröffentlichungsstatus. Dein Produkt besitzt die Anbieterebene: Nutzer, Abrechnung, UI, Workflows, Benachrichtigungen, Support und welche produktspezifische Bedeutung auch immer du den Einträgen aufsetzt. Damit können sich weit mehr Produkte einen Nachweisstandard teilen, ohne dass jedes Team zum Cardano-Transaktions- und Speicherbetreiber werden muss. Die Schritt-für-Schritt-Anleitung steht in auf einem Label-309-Gateway aufbauen.

Kann ich ganz ohne CardanoWall verifizieren?

Das ist das Ziel, und es ist der stärkste Grund, warum der Rest existiert. Die Verifizierung darf nicht von der CardanoWall-Website abhängen. Jeder sollte in der Lage sein, die Transaktions-Metadaten zu lesen, den Label-309-Eintrag zu rekonstruieren, seine Struktur zu validieren, etwaige Eintragssignaturen zu prüfen, den Content-Hash neu zu berechnen und – mit dem richtigen Schlüssel – einen versiegelten Eintrag lokal zu entschlüsseln.

Ein Nachweis, den nur eine einzige Website verifizieren kann, ist ein schwacher Nachweis. Offene SDKs, eine offene CLI und eine offene Spezifikation sind das, was einen Label-309-Nachweis für jeden verifizierbar macht, auch für Dritte, die CardanoWall nie berühren. Wenn du das selbst tun willst, beginne mit einen Label-309-Eintrag verifizieren.

Was ist mit den Kosten?

Die Oberfläche zu wechseln entfernt nicht die zugrunde liegenden Kosten. Ob du von der Website, der Desktop-App, der CLI, der API oder deinem eigenen Produkt aus veröffentlichst – jemand zahlt weiterhin echte Cardano-Transaktionsgebühren plus den Speicher, der für Dateien oder Chiffretext verbraucht wird. Ein gehostetes Gateway schlägt eine Marge obendrauf, um Betrieb, Funding, Infrastruktur und Support zu decken; der Preis ist also Kostenweitergabe plus diese Marge.

Wenn du CardanoWalls gehostetes Gateway nutzt, nutzt du dessen Modell aus vorausbezahltem Guthaben und Preisbildung. Wenn du selbst hostest, betreibst und finanzierst du dein eigenes Gateway direkt. So oder so macht der Standard den Eintrag portabel – er macht Blockchains oder Speicher nicht kostenlos. Die Begründung steht ausführlich in warum Veröffentlichen einen Preis hat.

Eine wichtige Grenze

Ein Label-309-Nachweis zeigt, dass bestimmte Bytes zu einem bestimmten öffentlichen Zeitpunkt existierten und sich seitdem nicht verändert haben. Er beweist nicht, wer den Inhalt verfasst hat, wem er gehört, ob er wahr ist oder ob jemand Rechte daran hat. Ein versiegelter Eintrag hält seinen Klartext nur für die vorgesehenen Schlüsselinhaber lesbar, aber er kann keine Anonymität garantieren und einen Empfänger nicht daran hindern, den Klartext zu leaken, sobald er ihn entschlüsselt hat. Behalte diese Grenze im Kopf, egal von welcher Oberfläche aus du veröffentlichst.

Die Kurzfassung

CardanoWall ist nicht nur eine Website. Die Website ist die einfachste Oberfläche für Menschen; das Gateway ist die Veröffentlichungsschicht; die CLI und die SDKs sind die Entwicklerflächen; die Desktop-App ist der lokale, offline-first arbeitende Client; Selbst-Hosting ist der Betreiberweg. Sie alle erzeugen dasselbe: einen standardkonformen Label-309-Eintrag, der außerhalb der Oberfläche verifiziert werden kann, die ihn erstellt hat.

Wähle die Oberfläche, die zur Arbeit passt. Nutze die Website für Menschen, die CLI für Skripte, die SDKs für Produkte, die API für Systeme und ein selbst gehostetes Gateway, wenn Anbieterunabhängigkeit oder operative Kontrolle das ist, was du brauchst.

Weiterführende Lektüre

developersapigatewayself-hosting