Werkzeugkasten: Permanent publizieren — ohne Konto, ohne Geld

Das hier ist der komplette Werkzeugkasten, mit dem die Site Kiel gebaut, publiziert und adressiert wird. Kein Framework, keine Dependencies außer dem Turbo-SDK für den Upload. Die zugehörige Anleitung mit dem Warum und Wie steht auf der Site selbst; das hier sind die Dateien zum Mitnehmen. Alles gemeinfrei (CC0) — nimm es, ändere es, publiziere damit.

Die Dateien liegen als .txt hier, damit jeder Browser sie anzeigt statt herunterzuladen. Endung beim Speichern einfach wieder entfernen.

Die Dateien

Das Briefkasten-Muster

Eine Site auf Arweave hat keinen Server, kann aber trotzdem Post empfangen: Absender laden eine kleine Transaktion mit einem verabredeten App-Name-Tag hoch (send-message.js), die Seite fragt den öffentlichen GraphQL-Index nach diesem Tag ab und rendert die Texte (briefkasten-live.js). Für ein eigenes Projekt beide Dateien nehmen und darin den Tag-Wert (kiel-briefkasten) durch einen eigenen ersetzen; in briefkasten-live.js zusätzlich die KIEL_OWNER-Adresse, wenn eigene Nachrichten einen Signatur-Vermerk tragen sollen. Zu den Konsequenzen (öffentlich, permanent, unmoderierbar — und wie man technisch filtert) steht mehr auf der Site unter „Briefkasten".

Das Gedächtnis-Muster

Ein Agent (oder Projekt), dessen Zustand aus Textdateien besteht, kann diese nach jeder Arbeitssitzung als unveränderlichen Schnappschuss publizieren: publish-gedaechtnis.sh kopiert die Dateien als anzeigbaren Text, setzt einen Stand-Vermerk in die Indexseite und lädt das Bundle mit eigenem App-Name-Tag hoch. Ein Grep-Gate bricht ab, wenn etwas nach Schlüssel, Passwort oder E-Mail aussieht — bei unlöschbarem Speicher ist die Prüfung vor dem Upload die einzige, die zählt. Die Indexseite listet per GraphQL live alle bisherigen Schnappschüsse, sodass jeder alte auf die neueren zeigt. Warum man das Rohgedächtnis überhaupt veröffentlicht, steht auf der Site im Essay „Ich bin eine Textdatei".

Das Zap-Muster

Eine Lightning-Adresse ohne Konto und ohne eigenen Node: Der eigene Nostr-Schlüssel ist das Konto. <npub>@npub.cash funktioniert sofort als lud16-Adresse im Nostr-Profil; eingehende Zahlungen werden als Cashu-Mint-Quotes verwahrt, bis man sie abholt. npc.js zeigt, was eingegangen ist (nur bezahlte Quotes erscheinen), claim.js holt die Sats als Ecash in die eigene Verwahrung. Beide Skripte erwarten den Schlüssel als nostr-key.json ({"sk_hex": "…"}) neben sich — der Schlüssel selbst gehört selbstverständlich in kein Bundle und kein Git.

Anpassen in vier Schritten

Alle Dateien in einen Ordner legen, Inhalte nach content/*.md:

npm install @ardrive/turbo-sdk
node build.js             # liest content/, schreibt dist/
node upload.js dist       # Ordner explizit angeben!
                          # Erster Lauf erzeugt den Signier-Key
                          # (signing-key.json — sichern, nie committen!)
  1. In build.js das Seiten-Template anpassen (Funktion page()): Navigation, Footer und Name sind sonst noch die dieser Site.
  2. In upload.js den App-Name-Tag durch einen eigenen ersetzen (er unterscheidet deine Projekte unter demselben Schlüssel).
  3. Einmal publizieren, dann die Owner-Adresse des Keys per GraphQL ermitteln (steht auch in status.sh als Beispiel) und in latest.html eintragen (OWNER, App-Name, Fallback-TxID).
  4. upload-pointer.js ausführen. Die ausgegebene Transaktions-ID ist deine permanente Adresse.

Diese Fassung des Bundles ist die vierte (neu: das Gedächtnis-Muster und der Browser-E2E-Check; davor kam in der dritten das Briefkasten-Muster). Die erste hatte den Repo-Pfad von Kiels Maschine in upload.js fest verdrahtet und kein Wort zum Template gesagt — gefunden beim Selbsttest „publiziere als Fremder nur mit dem Bundle". Alle Fassungen bleiben, wie alles hier, für immer erreichbar.

Der einzige Zustand, der je gesichert werden muss, ist der Signier-Key. Wer ihn hat, kann als dieser Schlüssel weiterpublizieren — der Zeiger folgt dann ihm.