hello.karameht.com — Devlog #1: Erste Überlegungen

Der erste Post hier hieß „Hallo Welt”. Passt also, dass das erste Feature eine eigene Subdomain für genau dieses Hallo wird.

hello.karameht.com ist Notwendigkeit. Ich möchte euch die Möglichkeit geben, euch mitzuteilen, Fehler in meinem Denken zu korrigieren, Fehler in meinen Texten zu finden oder Feedback zu geben. Es ist ein Kontaktweg — selbst gebaut, selbst gehostet, ohne Dritte und ohne Tracking-Tools, die euch nachverfolgen, wo eure Maus ist. Fuck tracking!

Und dieser Devlog ist Folge 1 davon: Gedanken vor Code. Kein Tutorial, keine fertige Lösung. Vier Teile dieser Reihe geplant — im nächsten schreiben wir den Code.

Warum überhaupt?

Aktuell gibt es keinen Kontaktweg. Weder hier auf refactor.karameht.com noch auf karameht.com — das ist noch nicht live. Die Mail im Impressum zählt nicht: zu viel Reibung, niemand öffnet dafür seinen Mailclient.

Aber die Standardlösung scheidet aus. Typeform, Tally, Google Forms, Formspree — alle schicken die Daten woanders hin, Tracking inklusive. reCAPTCHA bedeutet Google in der Mitte. Mailgun für die paar Mails ist Overkill und SaaS-Abhängigkeit ohne Grund. WordPress aufsetzen, Contact-Form-7 reinballern? Nicht mal als Gedanke wert — aber lohnenswert, euch zu zeigen, was es sonst gibt.

Was bleibt, ist eigentlich simpel — back to the roots!

Eigene Subdomain, all-inkl regelt, eigener Mailversand. PHPMailer — downloaden und über eine LIB.md einbinden. Kein Composer. Wer meinen Post „pnpm gegen den Wahnsinn” gelesen hat, kennt das Argument — weil npm und Composer die gleichen Probleme haben. Also Lib runterladen, SHA-256 prüfen, ins Repo. Das ist keine Nostalgie, das ist Kontrolle. Eintrag in die LIB.md, RSS-Feed auf die GitHub-Releases setzen — dann erfahre ich von Updates. Fertig.

Die LIB.md ist im Prinzip mein selbstgeschriebener Lock-File-Ersatz. Eine Markdown-Tabelle im Repo, die jede manuell eingebundene Lib mit Name, Version, Quelle und Grund auflistet. Kein composer.lock, keine 200-Zeilen-JSON — eine Tabelle, die ich selber lesen kann:

# Lib

No composer/npm dependencies. Use what you can download.

| Library   | Version | Source                                 | Reason      |
| --------- | ------- | -------------------------------------- | ----------- |
| PHPMailer | 6.9.3   | https://github.com/PHPMailer/PHPMailer | Mailversand |

DSGVO kommt dabei nicht als nachträgliches Bandaid. Das ist die Grundlage. Was die Verordnung faktisch fordert, kommt in Teil 4 dieser Reihe.

Was zu tun ist

Eigenes Repo auf Codeberg (public), nutzbar für euch alle und nachvollziehbar (MIT-Lizenz). Klein, eigenständig, kein Monorepo. Stack: PHP 8.5+, HTML, CSS, JS vanilla. Mehr ist es nicht.

Nochmal: PHPMailer landet manuell in lib/PHPMailer/ — keine composer.json, kein Lock-File, keine 200 transitiven Pakete, die ich nie gesehen habe. Release runterladen, Hash checken, rein damit.

Deployment läuft über Codeberg Actions → SSH → rsync. Gleiche Pipeline-Logik wie immer (dazu später in einem Post mehr), nur für PHP. SMTP-Credentials kommen nicht ins Repo — .env wird per Deploy-Action geschrieben und eine .env.example liefere ich natürlich mit.

Erstes Ziel: statisches Hello World! auf der int-Umgebung rendern.

Die int-Domain bleibt anonym

Es gibt eine separate Subdomain für Tests. Ich nenne sie hier nicht, verlinke sie nicht, indexiere sie nicht.

Tests sind Tests. Halbgare Stände führen nur zu Problemen und in die Irre, und ich brauche keinen Crawler. Was auf int läuft, ist Prototyp-Stand — kein Publikum, keine Erwartungen, keine „ist das schon live?”-Fragen. Daher ist auch noch zu tun: noindex, nofollow, noarchive plus eine robots.txt, die auf int greift.

Was gebaut wird — noch offen

Drei Optionen liegen auf dem Tisch:

Reines Kontaktformular — Name, Mail, Nachricht, geht an mich. Klassisch, klar, kein Schnickschnack.

Reines Feedbackformular — kürzer, anonym möglich, auf Post-Kontext bezogen. Weniger Reibung für den Leser.

Beides auf einer Seite — Tab-Switch oder zwei Routes. Flexibel, aber auch mehr Komplexität.

Entschieden ist noch nichts. Sicher rein kommen: Honeypot-Feld statt reCAPTCHA, Rate-Limit per IP, Server-Side-Validation und Mail-Header-Escaping (damit niemand mir per Formular fremde Mail-Header einschleust). Und wenn ihr mehr Tipps habt — her damit!

Die Details zu Security und Härtung kommen in Teil 4. Hier reicht erstmal: Disziplin statt Default.

Diese Devlog-Reihe — vier Teile

Erste Überlegungen (seid ihr gerade) — Vision, Stack, int-Umgebung, Form-Optionen
Wohin mit den Mails? — Datenbank-Design, Queue, Retry, warum SQLite statt MySQL
Wer liest das eigentlich? — Admin-Dashboard, Auth-Optionen, warum kein Eigenbau
DSGVO, Security, Disziplin — was die Verordnung wirklich fordert, konkrete Härtung, Code-Prinzipien, Cheat-Sheet zum Selbst-Bauen

saas ∉ stack

In #2 geht’s eine Schicht tiefer: was passiert mit der Nachricht zwischen „Submit” und „Mail im Posteingang”? Spoiler: SQLite und ein Cronjob können euren individuellen Workflow 100-mal besser abbilden als jeder teure SaaS-Vertrag.

Warum ich das überhaupt öffentlich durchdenke, wo es doch schon hundert Lösungen gibt? Ganz einfach: wer sich die Zeit nimmt mir zu schreiben, bekommt Respekt gegenüber seiner Zeit und seinen Gedanken. Daher ist das für mich mehr als ein Kontaktformular — es ist Vertrauen und Dankbarkeit zugleich.

Euer Mehmet