V4.5 Place Reward Economy: Neural Place vergütet jetzt zusätzlich tatsächlich gezogene Lotterie-Tipps und aktive, signierte Hunt-Zeit. Draw-Rewards können automatisch mit dem effektiven Beacon-Pfadgewicht multipliziert werden; aktive Zeit wird nur zwischen gültigen Requests innerhalb einer konfigurierbaren Maximalpause aufgebaut, sodass kein Offline-/Idle-Backfill entsteht. Alle Quellen gelten auch für verknüpfte Hosted Worker und landen im Owner-Wallet. Admins können Place-Punkte direkt im RUNTIME-Portal vergeben; Draw-, Zeit- und Admin-Boni besitzen ein dauerhaftes Audit. Details: V4.5_PLACE_REWARD_ECONOMY.md.

V4.4 Neural Place: Neural Hunt besitzt jetzt eine globale, r/place-inspirierte Pixel-Leinwand unter /place. Echte Score-Steigerungen erzeugen Place-Punkte; Fortschritte verknüpfter Hosted Worker werden dem Owner-Wallet zugerechnet. Placements kosten Punkte statt Zeit-Cooldown und werden live über einen eigenen WebSocket synchronisiert. Wallet, Audit-Historie, Canvas und Placement-History liegen dauerhaft in SQLite. Details: V4.4_NEURAL_PLACE.md.

V4.2.9 Worker Recovery & Image Update: Hosted Worker erkennen halb-offene Game-WebSockets per 90s Client-Deadline, erneuern abgelaufene Game-JWTs automatisch mit derselben persistenten P-256-Identity und wiederholen den Wechsel auf einen Folge-Task, bis er verfügbar ist. Hosted Worker fallen bei einem späteren Container-Neustart außerdem von einer inzwischen inaktiven gespeicherten Task-ID auf die serverseitig ausgewählte aktive Task zurück. Neue Worker-Container verwenden RestartPolicy=unless-stopped; eine explizite Lease-Sperre kann diese Recovery nicht umgehen. Im privaten Customer Admin kann CS_WORKER_IMAGE explizit neu gepullt und ein einzelner oder alle bestehenden Worker unter Beibehaltung ihrer Identity-Volumes neu erzeugt werden. Details: V4.2.9_WORKER_RECOVERY_IMAGE_UPDATE.md.

V4.2.8 Admin Control & Ownership: Customer-Admins können das Worker-Limit pro Benutzer aufheben und Worker direkt zuordnen. Server-Admins können Task-Serien als AUSLAUFEND markieren, Collectible-Eigentum ohne Umschreiben der historischen Gewinner-Provenienz übertragen und zufällige ADMIN-DROP-NFTs für bestehende Neural-Hunt-Identitäten erzeugen. Details: V4.2.8_ADMIN_CONTROL_OWNERSHIP.md.

V4.2.7 Admin Live Guess Flash: In der privaten Server-Admin-3D-Map kann TIPPS % optional den Score jedes tatsächlich ausgewerteten Tipps kurz am Client-Knoten einblenden – auch wenn er unterhalb des bisherigen Highscores liegt. Die flüchtigen Werte laufen ausschließlich über einen admin-authentifizierten WebSocket und werden nicht an Spieler oder das öffentliche Leaderboard gesendet. Details: V4.2.7_ADMIN_GUESS_FLASH.md.

V4.2.6.1 Build Fix: Das erste V4.2.6-Release-Archiv enthielt versehentlich nicht internal/data/. Dadurch konnte neuer Server-Code mit einem alten Data-Package kombiniert werden und der Server-Build scheiterte mit fehlenden HostedCreditEvent/Outbox-Methoden. Dieses Archiv enthält den vollständigen Data-Layer. Details: V4.2.6.1_BUILD_FIX.md.

V4.2.6 Customer Engagement + Admin Controls: Der Hosted Customer Service kann neuen Konten ein konfigurierbares Startguthaben geben und Hosted Workern für echte persönliche Best-Score-Verbesserungen konfigurierbare Bonus-Credits gutschreiben. Das Customer Portal blendet PayPal vollständig aus, wenn PayPal deaktiviert ist, und fasst den Credit-Verlauf kompakt nach Tag/Buchungsart zusammen. Im privaten Customer-Admin gibt es Benutzer sperren/freigeben, Worker-Stop, Login-/Registrierungs-Kill-Switches, Registrierungs-Proof-of-Work und optionale einmalige Invite-Codes. Positive-Tip-Rewards werden über eine persistente Game-Outbox idempotent an den Customer Service zugestellt. Details: V4.2.6_CUSTOMER_ENGAGEMENT_ADMIN.md.

V4.2 Pipeline Dockerfiles: Server, Customer Service und Worker besitzen jetzt jeweils ein eigenes Dockerfile (Dockerfile.server, Dockerfile.customer-service, Dockerfile.worker). Das bestehende Dockerfile baut weiterhin den Server, damit vorhandene Single-Image-Pipelines kompatibel bleiben. CS_WORKER_IMAGE zeigt weiterhin direkt auf das veröffentlichte Worker-Image.

V4.0 Beacon Hunt + Hosted PrePaid Service: Optional kann die Task-Lotterie jetzt PULSE/FLUX/ORBIT als vorab signierte Spielerentscheidung verwenden. Der Draw nutzt einen erst nach Fensterschluss verfügbaren drand-Round und speichert Round, Signatur, abgeleitete Randomness und Boost für Audit/Collectible-Traits. Zusätzlich gibt es einen separat aktivierbaren Customer-Service mit PrePaid-Zeitabrechnung, PayPal-Sandbox/Orders-v2-Flow, mehreren Docker-Workern pro Kunde, portablen Worker-Identitäten und delegiertem Reward-Owner. Details: HOSTED_SERVICE.md.

V3.9 Portable Identity + Winner Originals: Der Shell-Client verwendet standardmäßig dauerhaft ~/.neuralhunt/identity.json (0600) und kann dieselbe P-256-Identität als passwortgeschützten, browser-kompatiblen JSON-Export sichern. Browser und CLI validieren beim Import Public/Private-Key-Paar und Client-ID. Nach dem Import derselben Identität sieht der Browser wieder dieselben serverseitig gebundenen Wins. Authentifizierte Gewinner erhalten unter MEINE NFTS Zugriff auf ihr unverändertes Original-Artefakt; andere Identitäten erhalten dafür nur 404. Der CLI besitzt dafür my-nfts und nft original <task-id> <datei>. Öffentliche Leaderboards bleiben weiterhin ausschließlich bei Wasserzeichen-Previews.

V3.5 Random Guess Lottery: Optional kann die Zahl der tatsächlich ausgewerteten Tipps pro Zeitfenster begrenzt werden. Im Admin-Tab RUNTIME steuern Lotterie-Zeitfenster (s) und Max. gezogene Tipps je Task/Fenster die Funktion; 0 deaktiviert sie vollständig. Die Lotterie läuft getrennt pro aktivem Task. Alle gültigen, signierten Tipps werden bis zum Ende des Zeitfensters gesammelt. Im normalen Lotterie-Modus werden sie anschließend mit crypto/rand gleichberechtigt zufällig gezogen; bei aktiviertem Beacon Hunt übernimmt stattdessen der erst nach Fensterschluss verfügbare drand-Reveal die deterministische gewichtete Ziehung. Nur gezogene Tipps werden gegen das geheime Ziel ausgewertet und können Score/Winner/NFT auslösen. Nicht gezogene Tipps verbrauchen ihre Sequenz, damit beim nächsten Fenster ein neuer deterministischer Tipp entsteht, zählen aber nicht als akzeptierter guess_count. Abgebrochene HTTP-Requests verbrauchen keinen Lotterie-Slot. Dadurch wird die mögliche Task-Abschluss-/NFT-Rate gedrosselt, ohne Gewinner oder Styles direkt zu manipulieren.

Neural Hunt — V4.5 Place Reward Economy + Service Controller

V3.1 Admin Profile Cleanup: Im Admin-Tab RUNTIME gibt es ein manuelles Bereinigungstool für alte Identitäten. Die Inaktivitätsdauer ist in Stunden/Tagen/Wochen einstellbar. Vor dem Löschen zeigt PRÜFEN die Anzahl löschbarer Profile. Gelöscht werden ausschließlich Profile, deren letzte Aktivität älter als die gewählte Grenze ist, die aktuell nicht verbunden sind, niemals Gewinner eines Tasks waren und keine dauerhafte Neural-Place-Ökonomie besitzen. Gewinner, Place-Teilnehmer, verknüpfte Worker/Owner und aktuell verbundene Clients werden geschützt. Beim Löschen werden die per Foreign Key abhängigen task_points, client_unlocks und client_task_selection mit entfernt. WebSocket-Verbindungsaufbau und -ende aktualisieren clients.last_seen, damit die Inaktivitätsgrenze tatsächliche Nutzung besser abbildet.

V2.8 RIFT Task-Styles: RIFT-Identität und Rendering-Stil sind jetzt sauber getrennt. /data/artifacts/_collection/character_anchor.png ist ein globaler, neutraler Identity-Lock für den Waschbären RIFT und kann im Admin-Tab ARTIFACT einmalig manuell erzeugt und geprüft werden. Jeder Task kann im Admin-Tab TASK ACTIONS ein eigenes JPEG-/PNG-Style-Referenzbild erhalten; Nutzer sehen dieses Stylebild bereits in der Task-Auswahl und wählen damit indirekt die gewünschte NFT-Art. Bei jeder RIFT-Karte sendet Neural Hunt Image 1 = Character Anchor und Image 2 = Task Style Reference an die Images Edit API. Ohne eigenen Task-Style bleibt internal/artifact/assets/style_reference.jpg nur noch der Default-Fallback. Folge-Tasks erben ihren Style. medium bleibt Standard und die OpenAI-Usage-/Kosten-KPIs aus V2.7 bleiben erhalten.

V2.5.2 Hotfix: Der 3-Sekunden-Telemetrie-Poll hat in V2.5.1 den kompletten Control-Plane-DOM neu aufgebaut. Dadurch wurden native <select>-Dropdowns geschlossen und Cursor-/Scrollzustände in Eingabefeldern zerstört, obwohl die Werte über Drafts erhalten blieben. V2.5.2 trennt Telemetrie-Refresh und Formular-Rendering: Overview, Performance, Taskliste und Map aktualisieren sich weiterhin live, die Formular-Controls werden aber nur noch bei explizitem Tab-/Taskwechsel oder nach einer Admin-Aktion neu aufgebaut. Offene Dropdowns und laufende Eingaben bleiben damit stabil.

V2.5.1 Hotfix: Ein WebSocket-Heartbeat-Fehler in V2.5 konnte Browser-Verbindungen sehr regelmäßig nach ungefähr 90 Sekunden beenden. Der Server hatte zwar eine Pong-Deadline gesetzt, aber nur ein JSON-ping statt eines echten WebSocket-Control-Pings gesendet. Danach fehlte die Presence-Lease und der nächste Tipp erhielt HTTP 409, bis F5 eine neue Verbindung öffnete. V2.5.1 sendet echte Ping-Frames, schützt Reconnects mit generationsgebundenen Presence-Leases und verbindet Browser/Shell automatisch neu. HTTP-409-Antworten besitzen zusätzlich maschinenlesbare Fehlercodes und werden clientseitig selbstständig resynchronisiert.

V2.5: Nutzer wählen ihren Task auf einer eigenen Landing-Page und können jederzeit wechseln. Jeder Task besitzt eigene NFT-Prompt-Anweisungen, Anzeigename und Beschreibung; sein Folge-Task erbt diese Konfiguration. Admin-Formulare behalten ungespeicherte Eingaben auch bei Auto-Refresh und Browser-Reload. Zusätzlich gibt es mit cmd/client einen vollwertigen signierten Shell-Client für unbeaufsichtigten Betrieb.

Die V2.4-SCALE-Architektur bleibt erhalten: Verlierende Tipps bleiben im RAM, Map-Updates werden gebatcht, WebSockets schreiben asynchron und Map-Snapshots sind serverseitig begrenzt. Bitte weiterhin in ein neues/leeres Verzeichnis entpacken.

Neural Hunt ist eine eigenständige Go-Webanwendung für das beschriebene soziale Wahrscheinlichkeitsexperiment. Sie benötigt für den Normalbetrieb nur das Go-Binary und SQLite über modernc.org/sqlite. Es gibt kein PostgreSQL, Redis, S3/MinIO und keinen separaten Frontend-Build.

Die Weboberfläche liegt unter internal/webui/dist/ und wird mit //go:embed in das Binary eingebettet. Der Server lädt beim lokalen Start automatisch eine vorhandene .env (bereits gesetzte Prozess-Umgebungsvariablen haben Vorrang), daher reicht go run ./cmd/server für Backend, Client-UI, Admin-UI und öffentliches Echtzeit-Leaderboard.

HTTPS / Browser-WebCrypto

Die Weboberfläche erzeugt ihre ECDSA-P-256-Identität direkt im Browser über die Web Crypto API. Browser stellen crypto.subtle für normale Remote-Hosts nur in einem sicheren Kontext bereit. Verwende die Weboberfläche deshalb produktiv über HTTPS. http://localhost bzw. Loopback-Adressen werden von Browsern für lokale Entwicklung üblicherweise als vertrauenswürdiger Kontext behandelt. Bei einem Aufruf über http://<IP-or-domain> zeigt Neural Hunt eine verständliche HTTPS-Fehlermeldung statt eines JavaScript-Fehlers.

Schnellstart

cp .env.example .env
# JWT_SECRET, ADMIN_PASSWORD und OPENAI_API_KEY setzen.
# ARTIFACT_MODEL nur ändern, wenn du bewusst ein anderes GPT-Image-Modell nutzen willst.

go run ./cmd/server

oder:

docker compose up --build

Danach:

• Client: http://localhost:8080/
• Echtzeit-Leaderboard: http://localhost:8080/leaderboard
• Neural Place: http://localhost:8080/place
• Admin (private listener): http://localhost:8081/admin

V4.1: drei Docker-Images

Das Runtime-Image ist jetzt nach Rollen getrennt:

neuralhunt-server:local            -> Game/API + Game-Admin
neuralhunt-customer-service:local  -> Customer Portal / Billing / Docker-Control
neuralhunt-worker:local            -> CLI-Agent / Hosted Worker

Alle drei lokal bauen:

docker build -f Dockerfile.server -t neuralhunt-server:local .
docker build -f Dockerfile.customer-service -t neuralhunt-customer-service:local .
docker build -f Dockerfile.worker -t neuralhunt-worker:local .
# oder ohne Bake:
docker compose --profile images build app customer-service worker-image

Für Registry-Tags:

export NEURALHUNT_SERVER_IMAGE=registry.example.com/neuralhunt/server:v4.1
export NEURALHUNT_CUSTOMER_IMAGE=registry.example.com/neuralhunt/customer-service:v4.1
export CS_WORKER_IMAGE=registry.example.com/neuralhunt/worker:v4.1
# In der CI/CD-Pipeline jeweils das passende Dockerfile bauen und pushen.

Der Customer Service verwendet genau CS_WORKER_IMAGE für dynamisch erzeugte Worker. Mit CS_WORKER_AUTO_PULL=true darf er ein fehlendes Image bei Bedarf über Docker Engine nachladen. Für private Registries können dafür CS_WORKER_REGISTRY_SERVER, CS_WORKER_REGISTRY_USERNAME und CS_WORKER_REGISTRY_PASSWORD mit einem read-only Deploy-Token gesetzt werden.

V2.5: Task-Landing-Page und Task-Serien

Der Browser startet nach der Anmeldung nicht mehr stillschweigend in einem zufällig zugewiesenen Task. Stattdessen erscheint eine responsive Task-Landing-Page mit allen aktiven Tasks. Jede Karte zeigt Anzeigename, Beschreibung, Zahlenraum, Teilnehmerzahl, eigenen Score/Rank und Pause-Status. Ein Klick wählt den Task aus; über TASKS kann der Client die laufende Session sauber verlassen und später auf einen anderen aktiven Task wechseln.

Die Auswahl wird serverseitig in SQLite an die kryptografische Client-ID gebunden. Wird dieselbe Identität exportiert und auf einem anderen Gerät importiert, bleibt damit auch die zuletzt gewählte Task-Serie erhalten. Die Regel eine Identity = eine aktive WebSocket-Verbindung gilt weiterhin.

Wenn ein Task gewonnen oder administrativ geschlossen wird, erzeugt Neural Hunt genau einen Folge-Task. Dieser erbt vom Vorgänger:

• Zahlenraum (range_bits),
• task-spezifisches Server- und Client-Tippintervall,
• Anzeigename,
• Landing-Page-Beschreibung,
• NFT-Prompt-Anweisungen,
• task-spezifischen Negative Prompt,
• NFT-Style-Referenz.

paused wird absichtlich nicht vererbt: Ein neuer Folge-Task startet aktiv. Bestehende Client-Auswahlen des Vorgängers werden atomar auf den Folge-Task verschoben.

Task-spezifische NFT-Prompts

Im Admin-Tab TASK besitzt jeder Task jetzt einen eigenen Bereich TASK-KONFIGURATION & NFT-PROMPT. Der globale Artifact-Prompt bleibt die stilistische Basis; die Task-Anweisungen werden anschließend angefügt. Damit kann beispielsweise eine Serie ihren eigenen visuellen Stil oder ihr eigenes Motiv erhalten, ohne die globale Provider-Konfiguration zu verändern.

Beispiel für einen Task:

Anzeigename: Aurora Vault
Beschreibung: 48-Bit-Raum, Gewinner erhält die Aurora-Serie.

NFT-Prompt-Anweisungen:
Create a crystalline aurora data-vault, radial neural filaments,
no readable words, emphasize the winner as a singular luminous core.

Negative Prompt:
text, watermark, logo, duplicated core, low detail

Der Folge-Task übernimmt diese Werte automatisch. OpenAI verwendet die positiven Task-Anweisungen zusammen mit dem globalen Prompt; ComfyUI und A1111 erhalten zusätzlich den kombinierten globalen + task-spezifischen Negative Prompt.

Admin-Entwürfe überleben Refresh

Die dynamischen Admin-Formulare speichern ungespeicherte Eingaben lokal als Draft. Das betrifft Runtime-/Artifact-Settings, Task-Konfiguration und die Felder für geplante Aktionen. Der 3-Sekunden-Auto-Refresh und ein normaler Browser-Reload überschreiben diese Eingaben nicht mehr. Nach erfolgreichem Speichern wird nur der zugehörige Draft-Bereich gelöscht.

Shell-Client

cmd/client ist ein eigenständiger Neural-Hunt-Client ohne Browser. Er verwendet dieselbe P-256-Identität, dieselbe Challenge/Login-Signatur, denselben deterministischen Guess und denselben WebSocket-Presence-Mechanismus wie die Weboberfläche.

Interaktiv starten:

go run ./cmd/client -url http://127.0.0.1:8080

Beim ersten Start wird standardmäßig ~/.neuralhunt/identity.json mit Dateirechten 0600 erzeugt. Danach zeigt die Shell eine Task-Auswahl ähnlich der Browser-Landing-Page.

Diese Datei ist die Identität des Shell-Clients. Solange sie erhalten bleibt, bleibt auch die daraus abgeleitete Client-ID identisch. Für Container/systemd sollte sie deshalb auf einem persistenten Volume bzw. Host-Pfad liegen. Die Raw-Datei enthält den privaten Schlüssel im Klartext und sollte nicht verteilt werden; für Backups und den Wechsel in den Browser immer den verschlüsselten Export verwenden.

Wichtige Befehle:

tasks                         aktive Tasks + eigener Score/Rank
use <nr|id|name>              Task wechseln
status                        aktueller Task, Score, Rank, Sequence, Wins
map [n]                       textuelles TARGET FIELD nach Nähe-Zonen
leaderboard [n]               Echtzeit-Leaderboard abrufen
leaderboard watch             Leaderboard alle 5 Sekunden anzeigen
leaderboard stop              Watch beenden
nfts [n]                      öffentliche Winner-Artefakte mit Wasserzeichen-URLs
my-nfts [n]                   eigene fertige Gewinner-Artefakte
nft get <task-id> <datei>     öffentliche Wasserzeichen-Preview speichern
nft original <task-id> <datei> eigenes unverändertes Original speichern
identity                      Client-ID + persistente Identity-Datei
identity export <datei>       browser-kompatiblen verschlüsselten Backup-Export schreiben
quit

Für tmux, screen, systemd oder einen Server ohne Vordergrund-Browser:

go run ./cmd/client \
  -url https://hunt.example.org \
  -non-interactive \
  -task "Aurora Vault" \
  -max-nodes 250

Im Non-Interactive-Modus bleibt der WebSocket offen, sendet automatisch im vom Task vorgegebenen Intervall signierte Tipps und folgt einem abgeschlossenen Task automatisch auf dessen Nachfolger. SIGINT/SIGTERM beendet sauber.

Für eine feste Binary:

go build -trimpath -o neuralhunt-client ./cmd/client
./neuralhunt-client -url https://hunt.example.org -non-interactive -task "Aurora Vault"

CLI als dediziertes Worker-Image testen

Seit V4.1 enthält das Server-Image absichtlich nur noch den Game-Server. Baue das Worker-Image separat und mounte für die Identität ein persistentes Verzeichnis:

docker compose --profile images build worker-image
mkdir -p ./client-identities

docker run --rm -it \
  --network neuralhunt_backend \
  -v "$PWD/client-identities:/identity" \
  neuralhunt-worker:local \
  -url http://app:8080 \
  -identity /identity/test-cli.json

Bei jedem weiteren Start mit genau diesem Pfad wird dieselbe Client-ID verwendet. Für einen browser-kompatiblen verschlüsselten Export:

export NH_PASS='correct horse battery staple'
docker run --rm \
  -e NEURALHUNT_IDENTITY_PASSPHRASE="$NH_PASS" \
  -v "$PWD/client-identities:/identity" \
  neuralhunt-worker:local \
  -identity /identity/test-cli.json \
  -export /identity/test-cli-browser.json
unset NH_PASS

client-identities/test-cli-browser.json kann anschließend im Web-Client unter IDENTITÄT → IMPORT eingelesen werden. Die Raw-Datei test-cli.json sollte den Host nicht unverschlüsselt verlassen.

Ein minimales systemd-Beispiel:

[Unit]
Description=Neural Hunt Shell Client
After=network-online.target

[Service]
ExecStart=/opt/neuralhunt/neuralhunt-client -url https://hunt.example.org -non-interactive -task "Aurora Vault"
Environment=NEURALHUNT_IDENTITY=/var/lib/neuralhunt-client/identity.json
Restart=on-failure
RestartSec=5
User=neuralhunt

[Install]
WantedBy=multi-user.target

Browser-Identität im Terminal verwenden

Die Browseroberfläche exportiert die Identität verschlüsselt mit PBKDF2-HMAC-SHA256 (250.000 Iterationen) + AES-256-GCM. Der Shell-Client versteht exakt dieses Format:

export NEURALHUNT_IDENTITY_PASSPHRASE='ein-langes-passwort'
go run ./cmd/client \
  -import ./neuralhunt-identity-abc123.json \
  -identity ~/.neuralhunt/identity.json

Um die Terminal-Identity wieder browser-kompatibel zu exportieren:

export NEURALHUNT_IDENTITY_PASSPHRASE='ein-langes-passwort'
go run ./cmd/client \
  -identity ~/.neuralhunt/identity.json \
  -export ./neuralhunt-browser-import.json

Der Export ist selbstbeschreibend (neuralhunt-identity-export), enthält die öffentliche Client-ID und verschlüsselt das eigentliche Schlüsselmaterial mit PBKDF2-HMAC-SHA256 (250.000 Iterationen) + AES-256-GCM. Neue Exporte verlangen mindestens 12 Zeichen Passphrase. Im Browser unter IDENTITÄT → IMPORT Datei auswählen, dieselbe Passphrase eingeben und den Identitätswechsel bestätigen. Danach meldet sich der Browser mit derselben Client-ID an.

Unter MEINE NFTS werden dann die fertigen Gewinner-Artefakte dieser Identität angezeigt. Nur der authentifizierte Gewinner darf das Original herunterladen; die öffentliche Galerie bleibt wassergezeichnet.

Nicht dieselbe Identity gleichzeitig im Browser und im Shell-Client verbinden. Das ist absichtlich durch die Single-Connection-Regel gesperrt. Unterschiedliche Identities dürfen natürlich vom selben Rechner bzw. derselben IP verbunden sein.

Unterstützte Shell-Parameter:

-url                 Server-URL (oder NEURALHUNT_URL)
-identity            persistente Raw-Identity (oder NEURALHUNT_IDENTITY)
-task                Start-Task per Nummer, ID-Präfix oder Anzeigename
-max-nodes           Größe des lokalen Target-Field-Working-Sets
-non-interactive     unbeaufsichtigter Betrieb
-quiet               weniger Konsolenausgabe
-import              Browser-/Terminal-Identity importieren
-export              verschlüsselten Browser-Export schreiben und beenden
-passphrase          Import/Export-Passphrase; bevorzugt ENV verwenden

Faire signierte Tipps

Der Browser darf den Tipp nicht frei wählen. Die Zahl ist deterministisch:

SHA-256(task_id | public_seed | client_id | sequence) mod 2^range_bits

Danach signiert der Browser:

guess|task_id|sequence|guess

mit seinem persistenten P-256-Schlüssel. Der Server berechnet den erwarteten Guess erneut und prüft die Signatur. Standardmäßig akzeptiert der Server höchstens einen Tipp alle 10 Sekunden; der Browser sendet alle 11 Sekunden.

Falsche Roh-Tipps und deren Signaturen werden nicht gespeichert. In V2.4 erzeugt ein akzeptierter Tipp, der den persönlichen Best-Score nicht verbessert, sogar gar keinen SQLite-Write und gar kein WebSocket-Map-Event. next_seq, Rate-Limit, Guess-Zähler und Bestwert liegen auf dem Hotpath im RAM. Erst eine Score-Verbesserung checkpointet den aggregierten Zustand in SQLite; beim Gewinner bleiben zusätzlich der korrekte Guess und dessen Signatur erhalten.

TARGET FIELD — lesbare 3D-Nähe

Die vorherige Visualisierung hatte ein grundsätzliches Wahrnehmungsproblem: Eine echte 3D-Kugel um den Task kann in der 2D-Projektion einen weit entfernten Punkt scheinbar direkt neben dem Task zeigen, wenn er entlang der Kameratiefe liegt. Damit war „wer ist wirklich näher?“ trotz korrekter Daten nicht zuverlässig ablesbar.

V2.3 verwendet deshalb standardmäßig ein 3D-TARGET-FIELD mit unverzerrter Score-Ebene. Der Score bestimmt ausschließlich den sichtbaren Orbitalradius; die Client-ID bestimmt nur den Winkel. Die dritte Dimension wird über Tiefensortierung, Perspektivgröße, Helligkeit und Vorder-/Rückseiten-Cues codiert, verschiebt den Node aber nicht radial. Dadurch kann Kameratiefe die Nähe nicht mehr optisch umkehren. Die Ringe und Nodes benutzen exakt dieselbe Radiusfunktion:

kleinerer Ringradius = höherer Score = näher am Task

Die Wahrnehmungsfunktion ist bewusst im Bereich 90–100 gedehnt:

field radius = 0.045 + 0.955 * (1 - score/100)^0.38

Damit sind z. B. 90, 95, 99 und 99.9 noch klar getrennt. Zusätzlich:

• Score-Ringe bei 0 / 25 / 50 / 75 / 90 / 95 / 99+,
• Vorder-/Rückseite der Ringe mit unterschiedlicher Intensität als 3D-Tiefencue,
• Top-10 und eigene ID mit Score-Label,
• eigene ID mit weißem Doppelring,
• Kandidaten ab 95 mit zusätzlichem Nähe-Ring,
• Hover zeigt Score, Rank und eine verständliche Distanzzone,
• TARGET RADAR zeigt die besten Kandidaten zusätzlich numerisch,
• TARGET FIELD kann weiterhin auf RAW 3D umgeschaltet werden, um die serverseitigen Rohkoordinaten zu inspizieren.

Keine erfundenen Synapsen mehr

Die alte Option SYNAPSEN verband Clients pseudozufällig miteinander. Dafür gibt es im Experiment keine fachliche Beziehung und die Linien erzeugten nur visuelles Rauschen. Diese Darstellung wurde entfernt.

SIGNALWEGE zeichnen jetzt nur noch Client → Task:

• nur Top-Kandidaten und der eigene Client erhalten einen Pfad,
• höhere Scores machen den Pfad deutlicher,
• unter 90 werden Pfade gestrichelt,
• wenn ein Client seinen Best-Score verbessert, laufen drei kurze Signalimpulse entlang genau dieses Pfades zum Task,
• es gibt keine zufälligen Ambient-Partikel und keine Client-zu-Client-Kanten mehr.

Der gleiche Renderer wird im Admin-Bereich verwendet.

Mobile-Modus

Neural Hunt aktiviert auf kleinen Displays bzw. Geräten mit grobem Pointer automatisch einen Mobile-Modus. Er kann über den Button MOBILE auch manuell an- und ausgeschaltet werden; die Auswahl wird im Browser gespeichert.

Im Client reduziert Mobile Mode die Renderlast automatisch (ECO, weniger Nodes, keine optionalen Signalwege/Labels), zeigt Rank/Score/Countdown kompakt im Header und bietet eine einklappbare Detailkarte. Die 3D-Steuerung wird auf die wichtigsten Touch-Aktionen reduziert.

Im Admin-Bereich gibt es auf Mobile drei klare Ansichten MAP / TASKS / CONTROL, damit Task-Liste und Control Plane nicht mehr durch Responsive-CSS verschwinden. Das Leaderboard wechselt auf Karten statt horizontaler Tabellen.

Öffentliches Echtzeit-Leaderboard

/leaderboard ist eine eigene, nicht authentifizierungspflichtige Ansicht. Sie bietet:

• Live-Ranking nach aktuellem Score,
• All-Time-Ranking nach Wins / Best Score,
• Online/Offline-Indikator,
• Best Score, Wins, Tippanzahl und Unlocks,
• Client-ID-Suche,
• WebSocket-getriggerte Aktualisierung bei neuen Punkten, Task-Änderungen und Task-Abschlüssen.

Zusätzlich zeigt das Leaderboard eine Gewinner-Galerie. Die öffentliche API liefert keine Original-Artifact-URI, sondern nur eine Wasserzeichen-Vorschau. Für PNG/JPEG/GIF wird das Wasserzeichen serverseitig in eine neue PNG-Vorschau gerastert; lokale SVG-Artefakte erhalten eine sichtbare, wiederholte SVG-Wasserzeichenebene.

Die Originaldatei und das Manifest sind nur noch über authentifizierte Admin-Endpunkte erreichbar. Der frühere öffentliche /artifacts/*-File-Server wurde entfernt.

API:

GET /api/public/leaderboard?mode=live&limit=500
GET /api/public/leaderboard?mode=alltime&limit=500
GET /api/public/artifacts?limit=96
GET /api/public/artifacts/{task_id}/preview
WS  /api/leaderboard/ws

# nur Admin-JWT
GET /api/admin/tasks/{task_id}/artifact
GET /api/admin/tasks/{task_id}/manifest

Admin: planbare Task-Aktionen

Jeder Task besitzt jetzt einen persistierten Aktionsplan/Audit-Log. Aktionen können sofort oder für einen Zeitpunkt in der Zukunft geplant werden. Ein 1-Sekunden-Scheduler führt fällige Aktionen aus.

Unterstützt sind:

• set_range_bits — Zahlenraum eines laufenden Tasks ändern,
• set_intervals — Tippintervalle pro Task überschreiben,
• clear_intervals — wieder globale Defaults verwenden,
• pause — Tippabgaben pausieren,
• resume — fortsetzen,
• reroll — neues Secret + neuer Public Seed, Scores/Sequenzen zurücksetzen,
• close — Task beenden und Ersatz-Task sicherstellen,
• regenerate_artifact — Gewinnerbild erneut in die Queue legen.

Damit lassen sich z. B. Difficulty-Ramps planen:

20:00  24 Bit
20:15  28 Bit
20:30  32 Bit
20:45  pause
20:50  resume

Zahlenraum live ändern

Es gibt zwei Modi:

preserve

• das geheime Ziel und der Public Seed bleiben bestehen,
• Sequenzen bleiben bestehen,
• Scores werden auf den neuen Bit-Denominator re-skaliert,
• die räumlichen Positionen werden neu berechnet,
• Verkleinern ist nur möglich, wenn das bestehende Secret in den neuen Zahlenraum passt.

reroll

• neues Secret,
• neuer Public Seed,
• Score/Position/Sequenz werden zurückgesetzt,
• kumulative Tippanzahl bleibt erhalten.

Die Clients empfangen task_changed via WebSocket und laden range_bits, Seed, Revision und Intervalle neu. Ein Browser verwendet deshalb nach einer Live-Änderung nicht versehentlich die alte Bitzahl.

KI-/NFT-artige Gewinnerbilder

Ein abgeschlossenes Gewinnerbild ist ein NFT-artiges digitales Artefakt, aber noch kein Blockchain-NFT. Neural Hunt mintet nichts on-chain. Es erzeugt Bild + Manifest mit eindeutiger ID und kryptografischen Bindungen.

Das Manifest enthält u. a.:

artifact_id
artifact_preset
task_id
task_range_bits
winner_client_id
winner_public_jwk
winning_guess
winner_guess_signature
raw_art_sha256
image_sha256
prompt_sha256
collection_character
collection_traits
layout
provider
provider_meta

Wichtig: Die Gewinner-Signatur authentifiziert den erfolgreichen Guess. Sie ist keine nachträgliche Signatur der vom Bildprovider erzeugten Pixel. Das erzeugte Bild wird stattdessen per image_sha256 an das Server-Manifest gebunden.

Provider

Das Standard-Preset raccoon_full_art_v1 ist im Admin-Tab ARTIFACT bewusst auf OpenAI + Character-Anchor-Workflow vorkonfiguriert; dort muss normalerweise nur das Bildmodell geändert werden. Die älteren Provider local, comfyui, a1111 und auto bleiben für artifact_preset=legacy kompatibel.

Provider-Secrets und Provider-URLs bleiben absichtlich ENV-only und werden nicht an den Browser ausgeliefert. Das Dashboard zeigt für OpenAI nur, ob der API-Key vorhanden ist, und ob der kanonische Character Anchor bereits erzeugt wurde.

1. Local

Kein externer Dienst. Erzeugt ein deterministisches SVG wie bisher.

ARTIFACT_PROVIDER=local

2. OpenAI Images API — RIFT Collection (Standard)

Für das neue Full-Art-Preset reichen im Normalfall genau zwei Werte:

ARTIFACT_MODEL=gpt-image-2
OPENAI_API_KEY=...

OPENAI_BASE_URL kann optional überschrieben werden; standardmäßig wird https://api.openai.com verwendet. Provider, Portrait-Größe (1024x1536), Quality (medium) und das Collection-Preset sind bereits als Defaults hinterlegt. Eine mit älteren Projektversionen ausgelieferte lokale 1024×1024-Artifact-Konfiguration wird beim ersten Start einmalig auf das neue Preset migriert.

Die RIFT-Quality wird außerdem einmalig von einem früheren high-Default auf medium migriert. Eine später bewusst gesetzte high-Einstellung wird durch diese Migration nicht erneut überschrieben.

Ablauf:

1. Im Admin-Tab ARTIFACT kann /data/artifacts/_collection/character_anchor.png einmalig manuell erzeugt werden. Der Anchor entsteht nur aus dem neutralen RIFT-Masterprompt und enthält bewusst keinen Task-Style. Ist beim ersten Gewinner noch kein Anchor vorhanden, erzeugt der Worker ihn weiterhin automatisch als Sicherheits-Fallback.
2. Im Admin-Tab TASK ACTIONS kann jeder Task ein eigenes JPEG-/PNG-Stylebild erhalten. Es wird content-addressed unter data/artifacts/_styles/<sha256>.<ext> gespeichert und über tasks.nft_style_reference dem Task zugeordnet. Ein Folge-Task erbt dieselbe Style-Referenz. Ohne Custom-Style wird das eingebettete internal/artifact/assets/style_reference.jpg als Default verwendet.
3. Für jede RIFT-Karte sendet Neural Hunt zwei Bildinputs an /v1/images/edits: Image 1 = globaler Character Anchor (Identität) und Image 2 = Task Style Reference (Rendering-Look). Der Prompt weist das Modell explizit an, Gesicht/Fell/Proportionen aus Image 1 und Rendering-Technik/Material/Licht/Farbverhalten aus Image 2 zu übernehmen. Der Kartenprompt erzwingt dabei bewusst keinen festen 3D-Look mehr: ein Task-Style darf z. B. 3D-Cartoon, Cel-Shading, Comic, malerisch, Watercolor-artig, Clay/Toy, Low-Poly oder Retro-Game sein, solange RIFT als Charakter erkennbar und die Ausgabe nicht fotorealistisch bleibt.
4. internal/artifact/collection.go wählt deterministisch Theme, Outfit, Accessoires, Szene, Mood, Pose, Atmosphäre, Rarity und Akzentfarben. Die Rarity-Verteilung (Common / Uncommon / Rare / Ultra Rare / Special Illustration Rare) ist im Server-Admin unter ARTIFACT prozentual konfigurierbar; die Summe muss 100 % ergeben. Die tatsächlich zugewiesene Rarity wird am Collectible persistiert. Task-spezifische kreative Vorgaben und Ausschlüsse bleiben optionale Overrides.
5. Das generierte PNG wird als art.png gespeichert. internal/artifact/card.go baut daraus anschließend das finale image.svg im Format 1024×1536. Die KI muss daher keine Karten-Typografie oder UI exakt rendern.
6. Das Manifest bindet sowohl Roh-Art als auch fertige Karte per SHA-256 und speichert Collection-Traits sowie die verwendete Task-Style-Referenz/Provider-Metadaten.

Der Character Anchor ist absichtlich global und wird im Admin nach Erstellung als LOCKED behandelt. Ein Wechsel des NFT-Stils erfolgt deshalb nicht mehr durch Austausch des Anchors, sondern durch ein anderes Style-Referenzbild am jeweiligen Task. Das eingebettete style_reference.jpg muss dafür nicht neu kompiliert oder ausgetauscht werden.

OpenAI-Nutzung und Kosten

Jeder erfolgreiche OpenAI-Bildaufruf (Character-Anchor und Gewinnerkarte) wird lokal in artifact_api_usage protokolliert. Wenn OpenAI im Images-Response die Usage-Felder liefert, speichert Neural Hunt die gemeldeten Text-/Bild-Input-Tokens sowie Output-/Total-Tokens und berechnet daraus eine lokale USD-Kostenschätzung. Die Preisbasis ist im Datensatz fixiert, damit historische Werte reproduzierbar bleiben; unbekannte Modelle werden weiter protokolliert, aber ohne erfundene Kostenschätzung.

Im Adminbereich zeigt OPENAI NUTZUNG & KOSTEN die Kosten des heutigen lokalen Kalendertags, den durchschnittlichen Preis pro fertiger Gewinnerkarte und die hochgerechneten Kosten pro 1.000 Karten sowie die letzten API-Aufrufe. Character-Anchor-Aufrufe zählen zu den heutigen API-Kosten, werden aber bewusst nicht in den Karten-Durchschnitt eingerechnet. Die USD-Werte sind eine aus den Provider-Tokens berechnete Standardpreis-Schätzung (ohne separat ausgewiesenen Cached-Input-Rabatt) und keine Rechnungs-/Billing-Abstimmung; dafür ist kein zusätzlicher OpenAI-Admin-Key nötig. Die Rohdaten sind zusätzlich über GET /api/admin/artifact/usage verfügbar.

3. ComfyUI

ARTIFACT_PROVIDER=comfyui
COMFYUI_URL=http://127.0.0.1:8188
COMFYUI_WORKFLOW_PATH=/absolute/path/workflow-api.json
ARTIFACT_MODEL=your-checkpoint.safetensors

Der Workflow muss im API-Format vorliegen. Neural Hunt ersetzt rekursiv folgende String-Platzhalter:

{{PROMPT}}
{{NEGATIVE_PROMPT}}
{{SEED}}
{{WIDTH}}
{{HEIGHT}}
{{STEPS}}
{{MODEL}}

Beispiel in einem KSampler-/Text-Encode-Input:

{
  "text": "{{PROMPT}}",
  "seed": "{{SEED}}",
  "steps": "{{STEPS}}"
}

Der Worker sendet den Workflow an /prompt, pollt /history/{prompt_id} und lädt das erste gefundene Ergebnis über /view.

4. AUTOMATIC1111

A1111 muss mit API gestartet werden, z. B. --api. Optional ist --api-auth user:pass möglich.

ARTIFACT_PROVIDER=a1111
A1111_URL=http://127.0.0.1:7860
A1111_USER=
A1111_PASSWORD=
ARTIFACT_MODEL=my-checkpoint.safetensors
ARTIFACT_STEPS=28
A1111_CFG_SCALE=7

Neural Hunt verwendet /sdapi/v1/txt2img, übernimmt das Base64-Ergebnis und speichert es lokal. Ist ARTIFACT_MODEL kein gpt-image-*-Name, wird es für A1111 als sd_model_checkpoint pro Request gesetzt.

5. Auto

ARTIFACT_PROVIDER=auto

Reihenfolge:

OpenAI (wenn Key gesetzt)
→ ComfyUI (wenn URL + Workflow gesetzt)
→ A1111 (wenn URL gesetzt)
→ lokales SVG

Fehler der fehlgeschlagenen Provider werden im Manifest des lokalen Fallbacks vermerkt.

Docker + lokale ComfyUI/A1111-Instanz

docker-compose.yml enthält host.docker.internal:host-gateway. Dadurch kann der App-Container unter Linux/Windows/macOS typischerweise einen Bildserver auf dem Docker-Host erreichen:

COMFYUI_URL=http://host.docker.internal:8188
A1111_URL=http://host.docker.internal:7860

Ein ComfyUI-Workflow, den der Container lesen soll, muss zusätzlich in den Container gemountet bzw. unter /data abgelegt werden.

Architektur

Browser
  ├─ Client UI + P-256 Identity
  ├─ /leaderboard
  └─ Admin Control Plane
             │ HTTP / WS
             ▼
+------------------------------------------+
| Go Binary                                |
| auth | tasks | scheduler | WS | artifact |
+--------------------+---------------------+
                     │
             modernc.org/sqlite
             /data/neuralhunt.db
                     │
                     └─ /data/artifacts/
                          └─ artifact_<id>/
                              ├─ image.png|svg
                              └─ manifest.json

Optional nur für Bildgenerierung:
OpenAI API ODER ComfyUI ODER A1111

V2.4 Scale-Architektur

Die Standalone-Edition bleibt bewusst ein Go-Prozess auf einem Host. Dafür ist der heiße Pfad jetzt konsequent aus SQLite herausgezogen:

normaler falscher Guess
  -> JWT / Signatur / deterministischen Guess prüfen
  -> Sequence + Rate Limit + GuessCount im RAM
  -> Score berechnen
  -> schlechter als Bestwert
  -> Antwort false

SQLite writes: 0
Map events:    0

Nur Registrierung, erstmaliger Task-Punkt, Score-Verbesserungen, Gewinner, Unlocks, Admin-/Task-Änderungen und Artefakte werden dauerhaft geschrieben. Presence (eine ID = eine aktive Verbindung) liegt ebenfalls im Prozess und verursacht keine regelmäßigen SQLite-Lease-Writes mehr. Die alte Tabelle presence_leases kann aus Kompatibilitätsgründen in bestehenden Datenbanken vorhanden bleiben, wird aber vom V2.4-Hotpath nicht genutzt.

Gebatchte WebSockets

Verbesserungen werden pro Task und Client koalesziert und alle 250 ms als ein points-Frame gesendet. Jeder Socket hat eine bounded Outbound-Queue; ein langsamer Browser blockiert daher niemals einen Guess-Request. Ist seine Queue voll, darf ein transienter Map-Frame verworfen werden. Der persistierte Zustand bleibt maßgeblich.

Server-seitig begrenzte Map-Snapshots

Der Browser lädt nicht mehr pauschal 50.000 Nodes. max_nodes wird an den WebSocket übergeben; der Server liefert höchstens 3 × max_nodes Overscan (hart gedeckelt auf 10.000) und garantiert, dass die eigene Node enthalten ist. Nachfolgende Events werden clientseitig ebenfalls auf dieses Overscan-Budget gekürzt. Das vorhandene LOD arbeitet nur noch auf diesem begrenzten Working Set.

Performance-Telemetrie

GET /api/admin/performance liefert live u. a. Guess/s, Improvements/s, SQLite Writes/s, verworfene Requests, WebSocket Frames/s, WebSocket Bytes/s, Queue-Drops, Goroutines und Heap. Diese Werte erscheinen zusätzlich im Admin-Dashboard.

Lastgenerator

Der integrierte Lastgenerator erzeugt echte P-256-Identitäten, führt Challenge/Login aus, öffnet WebSockets und sendet deterministische signierte Tipps:

go run ./cmd/loadtest \
  -url http://127.0.0.1:8080 \
  -clients 10000 \
  -ramp 60s \
  -duration 5m \
  -max-nodes 250

Für einen realen 10k-Test sollten Server und Lastgenerator nach Möglichkeit auf getrennten Hosts laufen. Die erreichbare Obergrenze hängt von CPU, RAM, TLS, Dateideskriptoren und Netzwerk ab; V2.4 setzt 10.000 gleichzeitige Clients als Lasttest-Ziel, nicht als hardwareunabhängige Garantie.

SQLite und Skalierungsgrenze

SQLite läuft mit Foreign Keys, WAL, busy_timeout und kurzen Transaktionen. Weil normale falsche Tipps SQLite nicht mehr berühren, ist die Single-Writer-Eigenschaft deutlich weniger dominant. Für echtes Multi-Host-Horizontal-Scaling wäre trotzdem wieder eine gemeinsame Koordinations-/Datenbankschicht nötig.

Mehrere lokale Test-Clients

Die IP-Adresse ist nicht Teil der Identität. Mehrere Clients auf 127.0.0.1 funktionieren. Sie brauchen lediglich unterschiedliche Browser-Identitäten, z. B. normales Fenster + Inkognito oder getrennte Browserprofile.

Zwei Tabs desselben Profils teilen localStorage und damit dieselbe ID. Pro ID ist weiterhin nur eine aktive Client-WebSocket-Verbindung erlaubt.

Persistenz / Backup

Relevant sind:

/data/neuralhunt.db
/data/artifacts/

In SQLite liegen u. a.:

clients
tasks
task_points
settings
presence_leases
task_actions

API-Überblick

User:

POST /api/auth/challenge
POST /api/auth/login
GET  /api/tasks/current
POST /api/tasks/{id}/guess
GET  /api/tasks/{id}/points
GET  /api/me
GET  /api/leaderboard
GET  /api/ws

Public:

GET /api/public/leaderboard
WS  /api/leaderboard/ws

Admin:

POST /api/admin/login
GET  /api/admin/overview
GET  /api/admin/performance
GET  /api/admin/settings
PUT  /api/admin/settings
GET  /api/admin/tasks
GET  /api/admin/tasks/{id}/points
GET  /api/admin/tasks/{id}/actions
POST /api/admin/tasks/{id}/actions
POST /api/admin/actions/{id}/cancel
GET  /api/admin/artifact/providers
POST /api/admin/tasks/{id}/close
POST /api/admin/tasks/ensure

Produktions-Hinweise

• TLS erzwingen.
• JWT_SECRET und Admin-Passwort ändern.
• CheckOrigin für WebSockets auf eine Origin-Allowlist begrenzen.
• /data sichern und freien Speicher überwachen.
• API-Keys nur als ENV/Secret injizieren, niemals in Runtime-Settings speichern.
• Bei ComfyUI/A1111 nur vertrauenswürdige lokale/netzinterne Instanzen konfigurieren.
• Datenschutz-/Einwilligungstexte für das soziale Experiment ergänzen.

V2.9: lokaler RIFT-Pipeline-Test

Im Adminbereich unter TASK ACTIONS kann für den ausgewählten Task eine komplette lokale Testkarte erzeugt werden. Der Test verwendet den vorhandenen character_anchor.png als Mock-Character-Artwork und die Style-Referenz des Tasks als Hintergrund, führt die deterministische Trait-Auswahl, das programmatische Kartenlayout und das Schreiben der Testdateien aus, ruft aber keine externe Bild-API auf. Die Dateien landen unter data/artifacts/_test/<task-id>/; der echte Task- und Artifact-Status bleibt unverändert.

OpenAI reference-image MIME handling

Reference images sent to the OpenAI Images Edit endpoint are uploaded with an explicit per-part MIME type (image/png, image/jpeg or image/webp). This is required because Go's multipart.CreateFormFile otherwise labels file parts as application/octet-stream, which the Images API rejects. The character anchor is always sent as image/png; task style references preserve their detected image MIME type.

Public-hosting hardening (V3.8)

Neural Hunt now starts two HTTP listeners. HTTP_ADDR (default :8080) is the public client/leaderboard API and deliberately returns 404 for /admin and /api/admin/*. ADMIN_HTTP_ADDR (default :8081) is the private control plane. Keep port 8081 behind a VPN/private reverse-proxy route; the supplied Compose file binds it to host loopback while other containers on the same Docker network can still reach app:8081.

Admin authentication uses an HttpOnly, SameSite=Strict session cookie instead of browser localStorage. The cookie is marked Secure whenever TLS is visible directly or through X-Forwarded-Proto: https. The application also emits CSP, anti-clickjacking, HSTS and related browser hardening headers. Public browser WebSockets are same-origin checked; optional extra origins can be listed in WS_ALLOWED_ORIGINS. User WebSocket bearer tokens are no longer put in the URL by the bundled web/CLI clients.

New identities can be given one-time Hashcash-style proof-of-work plus a short warm-up before guesses are eligible (sybil_pow_bits, sybil_warmup_sec in Admin → Runtime). This is deliberate Sybil friction, not proof of a real-world person; serious adversaries can still buy compute or distribute identities. Reverse-proxy request/IP controls remain recommended.

Before every OpenAI image request the worker checks rolling 1-hour/24-hour call caps and a rolling estimated 24-hour USD budget. If the breaker trips, a winner artifact is returned to pending with a diagnostic message and is retried after the hold period rather than spending more immediately. Configure openai_max_calls_1h, openai_max_calls_24h, openai_max_cost_24h_usd, and openai_budget_reserve_usd in Admin → Runtime. Successful provider usage remains the basis for the local estimate.

For public operation, JWT_SECRET must be a unique random string of at least 32 characters and ADMIN_PASSWORD must be at least 16 characters; known development defaults make startup fail. ALLOW_INSECURE_DEV_DEFAULTS=1 exists only for local throwaway development.

Distributed Worker Hosts / Service Controller (V4.3)

For larger hosted installations, Customer Service no longer has to run every worker on its own Docker host. cmd/service-controller is a private worker-host agent that owns Docker access on a remote server, registers at Customer Service, and receives the existing worker lifecycle operations from the Master.

The deployment remains backward compatible through CS_WORKER_ORCHESTRATION_MODE=direct|controller|hybrid. Use hybrid when upgrading an installation with existing local identity volumes; use controller once Customer Service should no longer receive docker.sock at all.

Build the fourth image with Dockerfile.service-controller. Configuration, VPN topology, controller emergency UI and failure behavior are documented in SERVICE_CONTROLLER.md.