>>151475Die IPs werden gespeichert, aber IPs ändern sich auch ständig, in der Regel täglich. Als Motte bzw. Admin hat man hier natürlich die Möglichkeit, nach ganzen IP-Adressbereichen zu suchen, das ist schon hilfreich, aber das ist offensichtlich nichts, was man für die Allgemeinheit freigeben kann.
Wenn es wirklich gewünscht ist und die Anonymitätsimplikationen jemanden nicht jucken, dann wäre es am einfachsten, für den jeweiligen Nutzer (als Opt-In) eine zufällige ID zu generieren und diese an jeden seiner Beiträge anzuhängen (natürlich nicht sichtbar). Dann könnte derjenige (und nur derjenige) seine Beiträge leicht wieder auffinden. Aber die Zuordnung ist dann halt für immer auf dem Servierer gespeichert und man könnte ein Profil über denjenigen erstellen (geht bis zu einem gewissen Grad mit IP-Adressen natürlich auch, ist aber ungenauer).
Über die Kekslösung habe ich in den letzten Tagen auch noch mal nachgedacht, aber bin zu keiner vernünftigen Lösung gekommen. Ein Problem ist auch, dass, abgesehen von der Effizienzproblematik, alle Kekse für eine Domäne zusammen (einschließlich der Schlüssel) nur maximal 4 KiB groß sein dürfen. Also wenn man es jetzt ganz naiv umsetzen würde und einfach eine Liste von Pfosten-IDs im Keks speichern würde (jeweils ein Int, also 4 Bytes), dann könnte man damit theoretisch maximal 1000 Beiträge speichern. Das ist aber nur ein theoretischer Wert, denn das ganze muss vorher noch Base64-kodiert werden, weil Kekse keine Binärdaten vertragen, und dann kommt noch der Overhead durch die Schlüssel und weitere Kekse hinzu (wie z.B. den Dunkelmodus, die Sitzung für Mods/Admins, Bypässe usw.), was man abziehen müsste. Und für alles andere wäre kein Platz mehr. Und für jeden einzelnen Request (jede Seite, jedes Bild, jeder Download) sendet dein Brausierer dann 4 KiB an den Diätkanal-Servierer.
Ich hatte zum Spaß trotzdem mal überlegt, ob man da irgendwas cleveres machen kann, z.B. die Beitragsnummern deltakomprimieren (also statt die ganze Nummer zu speichern nur die Differenz zum Vorgänger) und das dann irgendwie zu komprimieren, z.B. mit Huffman-Kompression. Über Bitmasken habe ich auch nachgedacht, weil man damit unter gewissen Umständen auch ziemlich effizient speichern könnte, welcher Pfosten einem gehört (1000 Bits reichen theoretisch für bis zu 1000 Beiträge und belegen nur 125 Bytes – weniger als ein Tweet). Das Problem ist nur, dass das nicht funktioniert, wenn jemand nur selten pfostiert (oder z.B. einen sehr alten Pfosten mit einer niedrigen ID in seinem Verlauf hat), und gerade dort wäre der Nutzen einer Historie ja eigentlich am Größten. Sogar über Bloom-Filter habe ich nachgedacht, weil die auch oft ziemlich effizient sind, wenn man mit einer geringen Falschpositivrate leben kann, aber das war hier auch nicht wirklich machbar, dafür ist der im Keks vorhandene Speicherplatz einfach zu gering. [0] Hatte noch verschiedene Abwandlungen von all diesen Dingen durchgedacht.