Zwei Dinge, die einen ausgelieferten Client heute unbrauchbar gemacht
hätten.
Erstens: Seit die öffentliche Instanz Einladungscodes verlangt, bekam
jeder Registrierungsversuch aus dem Client 400 InvalidInviteCode, ohne
dass es ein Feld für einen Code gegeben hätte. auth_register und
create_account nehmen ihn jetzt entgegen, der LoginScreen zeigt das Feld
nur im Registrieren-Modus und leert es beim Moduswechsel — sonst würde
ein getippter Code im ausgeblendeten Feld überleben und beim nächsten
Versuch stillschweigend mitgehen.
Ein leeres Feld wird weggelassen, nicht abgelehnt: ob ein Code nötig
ist, entscheidet der Server (PDS_INVITE_REQUIRED), und eine lokale
Dev-PDS verlangt keinen. "Kein Code angegeben" und "mein Code ist der
Leerstring" sind zwei verschiedene Aussagen; nur die erste ist je wahr.
Deshalb fliegt der Schlüssel per skip_serializing_if ganz aus dem Body.
Der Server unterscheidet bei der Ablehnung bewusst nicht zwischen
fehlend, falsch, gesperrt und verbraucht — sonst wären Codes
enumerierbar. Die Meldung im Client nennt deshalb beide plausiblen
Auswege, statt einen zu raten.
Zweitens: Die Basis-URLs fielen ohne Umgebungsvariable auf
http://127.0.0.1:2583 bzw. :2584 zurück. Ein gebautes Paket hätte also
gegen nichts gesprochen. Beide zeigen jetzt auf
https://tweet.maarcade.com — dieselbe Origin für PDS und AppView, der
Proxy trennt nach Pfadpräfix. Die Variablen überschreiben weiterhin,
damit Entwicklung gegen localhost möglich bleibt; eine leer gesetzte
Variable gilt dabei als ungesetzt, weil eine leere Basis-URL sonst als
kryptischer Relative-URL-Fehler weit weg von der Ursache auftaucht.
Der Settings-View spiegelte dieselben alten Defaults und hätte falsche
Backends angezeigt — mitgezogen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013HC9HLrUU1LNwkzp8nkDLX
