3 Punkte von GN⁺ 2026-03-24 | 1 Kommentare | Auf WhatsApp teilen
  • Eine Methode, bei der Einzelpersonen Inhalte zuerst auf ihrer eigenen Website veröffentlichen und dann deren Kopien oder Links auf externen Plattformen wie Social Media verbreiten
  • Der Originalbeitrag enthält eine kanonische URL und einen Permashortlink, sodass auch aus Kopien direkt auf das Original zugegriffen werden kann
  • Diese Struktur erreicht gleichzeitig Inhaberschaft am Inhalt, Suchmaschinenoptimierung und Unabhängigkeit von Ausfällen externer Dienste
  • Es gibt Beispiele für automatische oder halbautomatische POSSE-Implementierungen auf verschiedenen Plattformen wie Twitter, Facebook, Medium und Mastodon
  • Als zentrales Konzept der IndieWeb-Bewegung ist es ein wichtiger Ansatz zur Umsetzung von dezentralem Publizieren und menschenzentrierter Vernetzung

Überblick über POSSE

  • POSSE (Publish on your Own Site, Syndicate Elsewhere) ist eine Methode, bei der Einzelpersonen Inhalte zuerst auf ihrer eigenen Website veröffentlichen und dann deren Kopien oder Links auf Plattformen Dritter wie Social Media verbreiten
    • Jede Kopie enthält einen Link zum Originalbeitrag (original post link), damit Nutzer direkt mit dem Original interagieren können
    • Als zentrales Konzept der IndieWeb-Bewegung ermöglicht es Einzelpersonen, Eigentum und Zugangswege ihrer Inhalte zu kontrollieren

Zweck von POSSE

  • Es unterstützt Freunde dabei, Beiträge auf ihren bevorzugten Plattformen zu lesen, und macht Inhalte über verschiedene Social-Media-Silos (silo) wie Instagram, Tumblr, Twitter und Neocities zugänglich
  • Es stellt den Erhalt bestehender Beziehungen in den Vordergrund und betont menschenzentrierte Vernetzung stärker als technische Föderation
  • Im Gegensatz zu einem monokulturellen Ansatz zielt es nicht auf Blogging oder eine einzelne Plattform als Zentrum, sondern auf eine dezentrale Veröffentlichungsstruktur

Übliche Gründe

  • Weniger Abhängigkeit von Dritten: Da direkt auf der eigenen Website veröffentlicht wird, wirken sich Ausfälle externer Dienste nicht aus
  • Sicherung der Inhaltsinhaberschaft: Das Original befindet sich auf der eigenen Domain und unterliegt daher nicht den Nutzungsbedingungen (TOS) eines Dienstes
  • Beibehaltung einer kanonischen URL (canonical URL), während Kopien auf das Original verweisen, wodurch sich die Auffindbarkeit in Suchmaschinen verbessert
  • Über Backfeed lassen sich Reaktionen externer Dienste zurückholen; so kann man Netzwerkeffekte sozialer Netzwerke nutzen und das Original dennoch auf der eigenen Website speichern

Warum der Original-Link wichtig ist

  • Bessere Auffindbarkeit des Originalinhalts: Über den Permashortlink kann man aus der Kopie zum Original gelangen
  • Schutz vor Spam-Duplikation: Selbst wenn eine Kopie erneut veröffentlicht wird, wird der Original-Link mitkopiert, was die Sichtbarkeit des Originals erhöht
  • Besseres Suchmaschinen-Ranking: Wenn Kopien auf das Original verlinken, erkennen Suchmaschinen dies und das Ranking des Originals steigt

Implementierung

  • Die Veröffentlichungssoftware sollte Inhalte zunächst auf der eigenen Website publizieren und danach auch auf den ausgewählten Silos (silo) veröffentlichen
    • Die Kopien sollten einen Link zum Originalbeitrag (Permashortlink oder Permashortcitation) enthalten
  • Dem Originalbeitrag wird ein Abschnitt posts-elsewhere hinzugefügt, der Links zu den Kopien in den einzelnen Silos bereitstellt
  • Benutzeroberfläche

    • Eine ideale UI ist automatisch, vorhersehbar und unaufdringlich
    • Eine Vorschau (Preview) vor dem Veröffentlichen zeigt, wie der Beitrag auf jeder Plattform erscheinen wird

Beispiele für Implementierungen auf wichtigen Plattformen

  • Twitter

    • Die häufigste POSSE-Zielplattform; wenn Notizen von der eigenen Website zu Twitter per POSSE veröffentlicht werden, ist Dateneigentum gesichert
    • Veröffentlichen über die API ist möglich, aber seit November 2022 ist der Zugang zu neuen APIs eingeschränkt
    • Unterstützung für Web-Action-Endpunkte erleichtert halbautomatische Veröffentlichungen
  • Facebook

    • Manuelles Crossposting oder halbautomatisches POSSE über die Bridgy-Browser-Erweiterung ist möglich
  • Medium

    • Über die Posts API oder die Import-Post-Funktion kann der rel-canonical-Link zur Original-URL erhalten bleiben
    • Es gibt verschiedene Werkzeuge, etwa ein Medium-Plugin für WordPress oder ein Crosspost-Plugin für Jekyll
    • Mit einer Massenmigration (mass POSSE) lassen sich auch bestehende Beiträge übertragen
  • WordPress

    • Mit dem WordPress Crosspost Plugin ist POSSE von selbstgehostetem WordPress zu WordPress.com möglich
  • Ghost

    • Mit einem Open-Source-Werkzeug auf GitHub lassen sich neue Beiträge per Ghost-Webhook als JSON empfangen und mit Mastodon, Bluesky synchronisieren
  • Plain Text Notes

    • Für rein textbasierte Ziele wie SMS oder Push-Benachrichtigungen ist eine Umwandlung nötig
    • Mit dem Ansatz h-entry_to_text wird HTML in Text umgewandelt

Software rund um POSSE

  • PHP: Der POSSE-Namespace von php-helpers enthält Funktionen zur Umwandlung von HTML in Plaintext sowie zur Syndikation
  • Python:
    • SiloRider: Kommandozeilenwerkzeug mit POSSE-Unterstützung für Twitter, Mastodon usw.
    • Feed2Toot: Veröffentlicht RSS-Feeds auf ActivityPub-basierten Diensten wie Mastodon und Pleroma
  • Docker: POSSE Party ist selbsthostbare POSSE-Software

POSSE-Dienste

  • Bridgy Publish: POSSE-as-a-service mit Unterstützung für Twitter, Flickr, GitHub und Mastodon
    • Nutzbar über eine Weboberfläche oder die webmention API
  • Mugged Tweets: Ein experimenteller Dienst, der Notizen auf Tassen per POSSE veröffentlicht
  • IFTTT: Automatische Wiederveröffentlichung auf Twitter, Tumblr, Facebook usw. auf Basis von RSS/Atom-Feeds
  • EchoFeed: Ein zusätzlicher Syndikationsdienst

Veröffentlichungsablauf

  • Client → Site → Silo

    • Der Nutzer erstellt Inhalte im Client → veröffentlicht sie auf dem Server → der Server veröffentlicht Kopien in die einzelnen Silos
    • Vorteil: Nutzer müssen sich nur um ihre eigene Website kümmern, während der Server die Syndikation automatisch übernimmt
  • Client → Site & Silo

    • Der Nutzer erstellt Inhalte und veröffentlicht sie auf dem Server → der Client ruft die URL vom Server ab → der Nutzer wählt die Plattformen für die Veröffentlichung aus
    • Vorteil: Inhalt und Zeitpunkt der Kopien können direkt vom Nutzer gesteuert werden
    • Nachteil: Es ist jedes Mal ein manueller Schritt nötig, und der Client muss direkt mit jedem Silo verbunden sein

Beispiele für IndieWeb-Implementierungen

  • Tantek.com (2010)

    • POSSE auf Basis von Falcon, Echtzeit-Syndikation mit PuSH v0.4 + h-feed
    • Automatische Kopien auf Twitter und Facebook mit Permashortlink-Zitierlink
    • Über Bridgy werden Facebook-RSVPs und Likes zurückgespiegelt
  • Waterpigs.co.uk (2012)

    • Verwendet den Ablauf Client → Server → 3rd Party
    • Syndikation zu Twitter und Facebook
    • Das Taproot-System erzeugt bei Updates zusätzliche POSSE-Tweets
    • Mit Bridgy werden auch Reaktionen auf Update-Tweets zurücksynchronisiert
  • BrennanNovak.com (2012)

    • Veröffentlicht Kopien auf Twitter und Facebook
  • AaronParecki.com (2012)

    • Veröffentlicht Tweets mit Permashortlink auf Twitter
    • Alle Sammlungen können per PuSH abonniert werden
  • Sandeep.io (2012)

    • POSSE durch manuelles Anklicken von Sharing-Links für Facebook, Twitter und Google+
    • Beibehaltung eines einfachen manuellen Ansatzes, um Instabilitäten bei API-Integrationen zu vermeiden
  • Werd.io (2013)

    • POSSE über die Plugin-Struktur der idno-Plattform
    • Inhaltsartabhängige Syndikation zu Twitter, Facebook, Flickr, Foursquare usw.
  • Veganstraightedge.com (2013)

    • Manuelles POSSE auf Basis von Dark Matter
    • Einschließlich rel-syndication-Markup für Medium, WordPress, Twitter, Vine usw.
  • GlennJones.net (2014)

    • POSSE mit dem transmat.io-System
    • Derzeit werden nur Notiz-Beiträge zu Twitter syndiziert

Weitere Implementierungsbeispiele

  • Jeremy Keith

    • 2014 POSSE mit einem benutzerdefinierten CMS umgesetzt; Notizen werden zuerst auf der eigenen Website veröffentlicht und anschließend nach außen kopiert
    • Fotos werden gleichzeitig auf Twitter und Flickr veröffentlicht
  • Shane Hudson

    • 2014 POSSE zu Twitter mit Craft CMS umgesetzt
    • Reply-Kontext wird manuell behandelt; eine Automatisierung für Foto-POSSE ist geplant
  • Ravi Sagar

    • 2018 POSSE auf einem Blog auf Basis von Drupal umgesetzt
    • Beiträge mit dem Tag Share werden per RSS-Feed + Rebrandly + Zapier automatisch auf Twitter und LinkedIn geteilt
  • Ludovic Chabant

    • 2018 POSSE zu Twitter und Mastodon mit PieCrust CMS und SiloRider umgesetzt
    • Funktioniert auf Basis von Microformats-Markup und unterstützt auch Foto-Beiträge
  • Adam Dawkins

    • 2019 POSSE mit einem benutzerdefinierten CMS umgesetzt; die erste Notiz wurde auf der eigenen Website veröffentlicht und anschließend zu Twitter kopiert
  • Shaun Ewing

    • 2020 POSSE mit Jekyll und einer benutzerdefinierten API umgesetzt; derzeit in einem manuellen Synchronisationszustand
  • capjamesg

    • Synchronisiert Notizen der eigenen Website automatisch zu Twitter(brid.gy), micro.blog(feed polling) und Fediverse(fed.brid.gy)
  • Wojtek Powiertowski

    • 2026 automatische Synchronisierung von Beiträgen aus einem Ghost-Blog zu Mastodon, Bluesky
    • Nutzt einen selbstgehosteten POSSE-Client für die automatische Synchronisierung neuer Beiträge

Teilweise POSSE-Websites

  • Hupili.net

    • Implementiert ein partielles POSSE-Modell, bei dem nur ein Teil der Inhalte per POSSE veröffentlicht wird
    • Vereinheitlicht mit SNSAPI die Datenstrukturen mehrerer sozialer Netzwerke und bündelt mit SNSRouter die Timeline-Abfrage
    • Derzeit ist die Unterscheidung zwischen Original und Kopie schwierig, künftig sollen jedoch für jedes Status-Update eigene Permalink-Seiten erzeugt werden

Andere Ansätze

  • COPE (Create Once, Publish Everywhere)

    • Einmal erstellen und an mehreren Orten veröffentlichen, jedoch nicht zuerst auf der eigenen Website
    • Wegen des fehlenden Original-Permalinks verteilen sich Leser auf verschiedene Plattformen
  • POSE (Publish Once Syndicate Everywhere)

    • Ein Vorläufer von POSSE, bei dem nach einer einmaligen Veröffentlichung auf einer bestimmten sozialen Plattform (silo) auf andere Plattformen kopiert wird
  • PESOS (Post Elsewhere, Syndicate to Own Site)

    • Der entgegengesetzte Ansatz zu POSSE: zuerst auf einem externen Dienst veröffentlichen und dann auf die persönliche Website kopieren
    • Zur Unterscheidung von POSSE sollte die Kopie einen Link zum Original (permalink) enthalten
  • PESETAS

    • Ähnlich wie PESOS, aber alle Inhalte werden auf eine bestimmte Plattform kopiert
    • Tumblr unterstützt verschiedene Inhaltsformate und eignet sich daher gut als PESETAS-Ziel

Erweiterte Ideen zu POSSE (CRUD-Modell)

  • Create

    • Inhalte auf der eigenen Website erstellen und extern verbreiten
  • Read

    • Die Position der Kopien über u-syndication-Links speichern und Rücksynchronisierung (backfeed) ermöglichen
  • Update

    • Wenn externe Plattformen Bearbeitungen unterstützen, werden bei Änderungen am Original auch die Kopien aktualisiert
    • Falls Änderungen nicht möglich sind, wird der Ansatz Löschen und neu veröffentlichen (delete/repost) verwendet
  • Delete

    • Beim Löschen des Originals können auch die Kopien mit gelöscht werden
    • Wenn Kommentare oder Retweets existieren, ist eine UI zur Bestätigung der Löschung nötig
    • Grant Richmond unterstützt seit 2018 das Löschen von POSSE-Beiträgen auf Twitter

FAQ

  • Um doppelte Inhalte in Suchmaschinen zu vermeiden, müssen Kopien unbedingt einen Link zum Original enthalten und wenn möglich rel-canonical verwenden
  • POSSE ohne Backlink ist nur das letzte Mittel und kann durch die Funktion posse-post-discovery ergänzt werden
  • Die Reihenfolge von POSSE und Webmention ist: zuerst POSSE, danach Webmention

Hintergrund

  • 2010 stellte Tantek Çelik POSSE mit der Idee „auf der eigenen Website veröffentlichen und auf andere Websites verbreiten“ vor
  • 2011 wurde das Konzept auf dem IndieWebCamp erweitert, im Juni 2012 wurde der Begriff POSSE offiziell definiert
  • POSE existierte früher als POSSE, aber POSSE benennt ausdrücklich eine Struktur mit Fokus auf die eigene Website

Verwandte Artikel und Zitate

  • Zwischen 2013 und 2024 wurde das POSSE-Konzept in verschiedenen Medien vorgestellt
    • Ars Technica beschrieb POSSE als „eine Methode, von einer einzigen Quelle aus auf alle Plattformen zu verteilen“
    • Molly White und Cory Doctorow betonten POSSE als Strategie zur Wiedererlangung der Inhaltsinhaberschaft
    • Seit 2024 wird POSSE im Zusammenhang mit Bluesky, Mastodon, Fediverse und anderen dezentralen Netzwerken erneut stärker wahrgenommen

Erweiterte Anwendung von POSSE

  • POSSE für Git-Repositories: Das Konzept lässt sich als Methode erweitern, persönliche Git-Repositories nach GitHub, GitLab usw. zu spiegeln
  • Aufzeichnungen von POSSE-Sessions: In der IndieWeb-Community wurden von 2011 bis 2024 fortlaufend Sessions zu POSSE veranstaltet

Fußnoten und Lizenzinformationen

  • Quelle des Dokuments ist die IndieWeb-Wiki-Seite (https://indieweb.org/wiki/index.php?title=POSSE&oldid=107734)
  • Die Seite ist den Kategorien building-blocks und syndication zugeordnet
  • Letzte Änderung: 16. Januar 2026, 17:04
  • Der Inhalt wird unter einer CC0 Public Domain Dedication bereitgestellt
  • Als zusätzliche Links sind Privacy policy, About IndieWeb und Code of Conduct enthalten
  • Unten auf der Seite werden außerdem Links zu Creative Commons Public Domain und MediaWiki angezeigt

1 Kommentare

 
GN⁺ 2026-03-24
Hacker-News-Kommentare
  • Ich verfolge diesen Ansatz konsequent. Der Veröffentlichungsprozess ist manuell, aber die Absicht ist gut, und solange man nicht nur spamartige Blog-Werbung in verschiedene Foren kippt, funktioniert es ziemlich gut.
    Ich habe auf meinem Blog (rednafi.com) absichtlich keinen Kommentarbereich. Schreiben ist nicht meine bezahlte Arbeit, und die Moderation von Kommentaren kostet zu viel Energie.
    Früher hatte ich Disqus an meine Hugo-Seite angebunden, aber sobald die Diskussionen länger wurden, gab es ernste Skalierungsprobleme.
    Wenn ein Beitrag nützlich ist, landet er meist ohnehin auf HN oder Reddit, und ich verlinke diese Diskussionen dann zurück im Artikel. Das reicht meiner Meinung nach.

    • Ich mache es genauso. Ich verwalte zum Beispiel Linkbacks von verschiedenen Plattformen wie in diesem Beitrag.
      Social-URLs trage ich als Schlüssel im YAML-Frontmatter ein und registriere sie über standard.site auch im ATProto-Ökosystem.
      Für längere Texte hole ich mir über rogue-scholar.org eine DOI und ergänze Metadaten.
      Mein Ziel ist es, all das irgendwann in einem einzigen statischen Kommentar-Thread zusammenzuführen, aber da zwischen den Netzwerken kaum Gespräche stattfinden, sind einfache Links wie jetzt die realistischere Lösung.
    • Ich nutze HN als Kommentarplattform. Mit einem Hugo-Shortcode cache ich HN-Kommentare und lasse nur Beiträge neu laden, die jünger als 7 Tage sind.
      Das Format sieht auch ziemlich ordentlich aus; man kann es am Ende von diesem Beitrag sehen.
    • Wenn man einen Mastodon-Account hat, kann man alle Antwort-Threads zu dem Beitrag auf der eigenen Seite einbetten.
      Ein Implementierungsbeispiel gibt es in diesem Beitrag.
    • Toller Blog. Besonders der Beitrag Splintered Failure Modes ist mir aufgefallen. Einmal gelesen und sofort im Gedächtnis geblieben.
  • Ich folge diesem Ansatz, weil ich den Raum, den ich geschaffen habe, selbst besitzen möchte.
    Es funktioniert gut, aber zu automatisieren ist es schwierig, und am Ende muss man doch manuell crossposten. Da jede Community anders reagiert, ist der Traffic gering, aber als öffentlich sichtbare Arbeitsweise ist es großartig.

    • Die Automatisierung ist schwierig, weil soziale Medien es absichtlich schwer machen, automatisch zu posten.
      Facebook stuft Beiträge mit externen Links teils in der Sichtbarkeit herunter. Daher kommen Tricks wie „Link in den Kommentaren“.
    • Ich stimme nicht zu. Dienste wie micro.blog unterstützen automatisches Crossposting in mehrere soziale Netzwerke ziemlich problemlos.
      Wenn es weniger um Traffic als um Präsenz in verschiedenen Communities geht, ist das durchaus wertvoll.
    • Die Kultur und das Publikum jeder Plattform unterscheiden sich, deshalb verlaufen Diskussionen jeweils anders. Überall exakt dasselbe zu posten, kann sich ein wenig nach Spam anfühlen.
      Deshalb ist der Nutzen von Crossposting je nach Person unterschiedlich.
    • Mich würde interessieren, ob du mal einen Posting-Dienst wie Buffer.co ausprobiert hast.
  • Ich begegne POSSE auf mehreren Plattformen ziemlich oft, und manchmal wirkt dieser Ansatz auf mich unpersönlich und spamartig.
    Ich verstehe den Grund, aber es sieht eher nach einem „ship it“-Ansatz aus als nach echter Konversation. Vielleicht liegt das auch am Alter.

    • ATProto-basiertes Publishing wie standard.site entwickelt sich in eine Richtung, in der Inhalte leicht auffindbar sind, ohne sie in viele Kanäle verteilen zu müssen.
    • Mich würde interessieren, was genau unpersönlich wirkt. Ich sehe eher den Vorteil darin, Leser nicht auf eine bestimmte Plattform festzulegen.
  • Ich stelle mir ein großartiges Feature für das Small Web vor.

    1. Ich abonniere Blogs, die ich mag, per RSS
    2. Wenn ein neuer Beitrag erscheint, sehe ich im RSS-Reader gleich auch Links zu Diskussionen auf HN, Reddit, Twitter usw.
    3. Ich klicke darauf und nehme dort an der Unterhaltung teil
      Die einfache Version davon sind Links zu relevanten Diskussionen am Ende des Beitrags.
    • Stimme ich zu. Ich möchte Beiträge im RSS-Reader sehen und nicht, dass sie wahllos in Social Feeds geworfen werden.
      Ein simples „Ich habe einen neuen Beitrag veröffentlicht“ wirkt schnell wie Spam.
      Externe Diskussionen zu finden ist zwar umständlich, aber wenn man wirklich Interesse hat, reicht eine URL-Suche aus. Ein Permashortlink stört dabei eher.
    • Soweit ich weiß, wurden WebMentions ursprünglich genau für diesen Zweck entworfen.
  • Ich freue mich jedes Mal sehr, wenn solche Beiträge auftauchen. Jeder sollte seine Inhalte selbst besitzen.
    Die Philosophie der IndieWeb-Community ist etwas, das man feiern sollte.
    Wenn es möglich ist, würde ich empfehlen, einen Homebrew Website Club zu besuchen und mit anderen darüber zu sprechen, wie man seinen eigenen Platz im Web baut. Das kann die Freude an Technologie wieder spürbar machen.

    • Mit genau diesem Gedanken habe ich auch tildeweb.nl gebaut.
  • Anfangs fühlte sich dieser Beitrag für mich wie PR für Big Tech an. So nach dem Motto: „Am Ende gewinnen die großen Konzerne sowieso, also verteile es einfach überall.“
    Aber ich verstehe nicht, warum ich jemandem, der nur Facebook nutzt, unbedingt meinen Blog zeigen sollte.
    Ich möchte lieber nur mit Menschen teilen, die meine Prinzipien teilen.

    • Interessante Perspektive. Manche wollen ihre Texte möglichst vielen Menschen zeigen, andere möchten lieber still und zurückhaltend teilen.
      Je älter man wird, desto vorsichtiger wird man oft damit, Dinge online zu veröffentlichen. Vielleicht ist das auch ein Ausdruck von Selbstwahrnehmung und Reife — nicht jeder will schließlich meine Texte lesen.
  • Ich mag es, wenn ich beim Lesen eines Beitrags gleich die Links zu den wichtigsten Diskussionen dazu sehe.
    Blog-Kommentare sind meist still, und selbst wenn man einen Beitrag erst ein paar Tage später liest, kann man so den Gedanken anderer gut folgen.

    • Schon das Konzept einer „wichtigsten Diskussion“ ist traurig. Durch die Appifizierung des Internets haben wir uns daran gewöhnt, in geschlossenen Gärten zu denken.
      Der Browser selbst sollte passende verwandte Links finden und anzeigen können.
      Wenn man sich mit ActivityPub und Linked Data beschäftigt, ist es frustrierend zu sehen, wie viele Projekte letztlich doch nur geschlossene soziale Netzwerke nachahmen.
  • RSS ist ein einfacher und verlässlicher Weg, der es mir erlaubt, selbst zu kontrollieren, was ich sehen will, ohne von algorithmischer Kuratierung abhängig zu sein.

  • Ich mache es auch so. Meine Seite ist in meinem Profil verlinkt.
    Ich lasse Permashortlinks weg und behalte kurze, aussagekräftige Original-Links bei.
    Schon am Link allein kann man ungefähr erkennen, um welche Inhalte es geht, und POSSE macht es leicht, solche persönlichen Vorlieben umzusetzen.

    • Ich halte Permashortlinks ebenfalls für ein unnötiges Konzept.
      Auf indieweb.org/permashortlink werden zwar Gründe dafür aufgelistet, aber die meisten überzeugen mich nicht.
      Argumente wie höhere Stabilität in E-Mails oder bequemeres Eintippen wegen der Kürze sind aus meiner Sicht schwach.
      Stattdessen entstehen nur Verwaltungsaufwand und Probleme durch verteilte Domains. Ich würde eher einfach die bestehende URL-Struktur verbessern.
  • Ich mache es genau andersherum und nutze PESOS (Publish Elsewhere, Syndicate to Own Site).
    Dank eines Automatisierungssystems sammle ich meine Aktivitäten aus dem ganzen Web auf meiner eigenen Seite und kann sie bei Bedarf leicht nachschlagen. Sehr zu empfehlen.

    • Ich habe mir vale.rocks angesehen und fand die Seite wirklich inspirierend. Ich wünsche dir einen schönen Tag.