Was ich da rauslesen und was ich mir auch schon gedacht habe: eine Pull-Lösung wäre wohl die bessere :-/

Verstehe den Ansatz da grad vielleicht nicht ganz aber:

• Die Daten sollen möglichst dupliziert überall vorliegen um Zensur oder Single-Point-Of-Failures zu vermeiden. Ist aktuell so.
• Mit push hast du sehr schnell die Daten übertragen, da sofort nach dem Event die Daten weitergegeben werden. Das ist gut.
• Bei einem fehlerhaften push muss halt eine Retry-Strategie bestehen um sicherzustellen, dass die Daten irgendwann ankommen.
• Man könnte auch noch als Fallnetz eine Pull-Ideologie einführen, die einfach periodisch bei Pods anklopft und nachfragt, ob es nicht in der Zwischenzeit etwas gab, was vergessen wurde zu übertragen.

Aber grundsätzlich ist Event-Basiert IMMER dem periodischen Anfragen vorzuziehen, weil es weniger Last verursacht. Dass die Daten sowieso gespiegelt werden, sollte klar sein und sowieso nicht zur Debatte stehen.

Wäre auch eine Kombination aus beidem denkbar? Zumindest bei Tagsuchen würde ja pull z.B. Sinn machen. Alle Pods, die mein eigener Pod kennt, werden angewiesen mir Beiträge zu schicken, die das Tag #tag haben und jünger als 2 Jahre sind. Oder ist das bei der Tagsuche schon der Fall? Ich denke, nicht.

Tags werden nur lokal gesucht. Ich vermute man kann das bestehende Push-Verhalten durch Pull-Elemente erweitern, sicherlich. Damit triggerst du ja quasi nur einen Push. Details weiß ich da aber auch nicht, ich glaube du kannst dich da gut mal einlesen, wie die Federation in 0.5 geplant ist, da wird es meines Wissens nach einige Verbesserungen / Änderungen geben.

Was ich auch schon mal gedacht hatte: Man könnte einen periodischen Task machen, der die Existenz von Accounts auf ihren Ursprungspods prüft und im Fall, dass ein Account gelöscht wurde, die Löschung auch auf dem eigenen Pod durchführt (falls die Löschung nicht gut genug federiert wurde).