Promotler
JPGesponserte Posts haben ein Vertrauensproblem. Die Marke gibt einen Text frei, der Creator postet etwas leicht anderes, löscht es nach zwei Tagen, und plötzlich streiten beide mit Screenshots. Was fehlt, ist ein Beleg, auf den beide zeigen können und den keiner heimlich ändern kann.
Entwickler haben dafür seit Jahrzehnten ein Werkzeug: Versionskontrolle.
Git auf einen Deal abbilden
| Git | In Promotler | Was Nutzer sehen |
|---|---|---|
| Commit | unveränderlicher Snapshot aus Text und Konditionen | „Version v3 · a1b2c3d“ |
| Branch + Pull Request | Änderungsvorschlag auf einer Basisversion | „Vorgeschlagene Änderungen“ |
| Merge | Fast-Forward oder Drei-Wege-Merge | „Änderungen annehmen“ |
| Merge-Konflikt | beide änderten dieselbe Passage | „Überschneidung auflösen“ |
| signierter Tag | beide unterschreiben einen Hash | „Finale Version freigeben“ |
Marketer sehen nie das Wort „Rebase“. Die Oberfläche spricht ihre Sprache, und darunter gelten die Garantien von Git.
Konditionen gehören in den Snapshot
Die wichtigste Designentscheidung war, Preis, Veröffentlichungsfenster, Laufzeit und automatisches Löschen mit in den Commit zu nehmen, neben den Post-Text. Eine Preisänderung ist einfach ein weiterer Änderungsvorschlag, geprüft und angenommen wie eine Tippfehlerkorrektur. Ein Hash deckt also alles ab, und diesen Hash zu unterschreiben ist die Vereinbarung.
type Snapshot = {
v: 1;
content: string; // NFC-normalisiert, \n als Zeilenende
terms: { priceCents: number; minLiveDays: 7 | 14 | 30 /* … */ };
};Der Hash an genau einer Stelle
Der Snapshot-Hash wird an genau einer Stelle berechnet, von einem Insert-Trigger in Postgres:
sha256('pp-snapshot-v1\n' || content || '\x00' || terms::jsonb::text)jsonb normalisiert die Reihenfolge der Schlüssel, der Hash ist also deterministisch. Clients können ihn nicht mitschicken, und es gibt bewusst keine TypeScript-Implementierung, die vom SQL abweichen könnte. Die Oberfläche zeigt die ersten sieben Hex-Zeichen, wie Git.
Die Datenbank ist der Schiedsrichter
Wenn der Hash der Vertrag ist, darf die Datenbank niemanden die Regeln biegen lassen, auch keine fehlerhafte Oberfläche:
- Row-Level-Security auf jeder Tabelle und keine direkten Schreibzugriffe: Jede Änderung ist eine auditierte RPC-Funktion.
- Versionen, Reviews, Freigaben und das Audit-Log sind nur erweiterbar.
- Eine Freigabe ist an einen Versions-Fingerabdruck gebunden. Jede spätere Änderung macht sie ungültig.
pgTAP-Tests prüfen Rechte, RLS und Workflow-Invarianten gegen einen schriftlichen Katalog von Logikfehlern und stellen sicher, dass die Datenbank zu jedem davon Nein sagt.
Was es bringt
Geht ein Post raus, veröffentlicht die Plattform genau den unterschriebenen Text über die LinkedIn-API und prüft danach weiter, dass er online und unverändert bleibt. Auszahlungen erfolgen bei bestätigten Meilensteinen. Fragt je jemand „Ist das, was wir vereinbart haben?“, vergleicht man zwei Hashes.