Wissenschaftskommunikation auf Mastodon und Bluesky: Praktische Herausforderungen des akademischen Microbloggings

Anlässlich eine Ausschusssitzung und Livebloggings zu den Inhalten auf Microblogging-Plattformen dachte ich mir, thematisiere ich pragmatische Herausforderungen für eine “interdisziplinäre” Wissenschaftskommunikation mal kurz in einem Blogbeitrag. Denn am Beispiel dieser Sitzung zeigen sich nach wie vor die Herausforderungen und Probleme eines nicht wirklich interoperablen Microblogging-Netzwerks, das zwar eigentlich die bestmögliche aktuelle Alternative zu Big-Tech-Services ist, mit zwei leidlich kommunizierenden Angeboten aber leider praktisch echte Hürden aufweist.

Da ein großer Teil der Bibliotheksbubble und ein wesentlicher Teil der deutschsprachigen Digital-Humanities-Bubble auf Mastodon organisiert ist, hauptsächlich auf und sicherlich auch aufgrund der Instanzen von openbiblio, fedihum und hcommons, habe ich in den letzten Monaten meine Bluesky-Präsenz etwas vernachlässigt. Das ist schade, da dort ein großer Teil der IchbinHanna-Community unterwegs ist, ebenso wie Teile der weniger Biblio- und Tech-affinen Humanities und auch internationale DH-Peers. Dank engagierter Menschen und einiger Entwicklungsprojekte gibt es mehrere Optionen zur Überbrückung von Mastodon und Bluesky, die beide als offene Systeme an den Start gehen, leider aber nicht eigentlich zusammen kommunizieren:

Crossposter

Es gibt herkömmliche Crossposter, wie zum Beispiel Skymoth, die bestehende Accounts auf beiden Netzwerken über einen Service verknüpfen und abhören. Beiträge, die auf dem einen Netzwerk geposted werden, werden dann auf das andere Netzwerk gespiegelt. Der Nachteil ist natürlich, dass ein Monitoring beider Netzwerke immer noch nötig ist, um die Diskussionen und Feeds der jeweiligen Netzwerke mitzubekommen. Crossposter sind also vor allem für einseitige Kommunikation sinnvoll, wenn beide Netzwerke mit Informationen bespielt werden sollen, aber keines oder nur ein Netzwerk zur Diskussion genutzt wird.

Bridge

Es gibt mit Bridgy Fed eine Brückenarchitektur, die von einem auf dem einen Netzwekr existierenden Account ausgehend auf dem anderen Netzwerk einen Account anlegt. Posts werden so automatisch gespiegelt, ebenso werden Antworten und Reaktionen gespiegelt, solange die beteiligten Personen ebenfalls über einen gebridgten Account verfügen. Der Vorteil liegt auf der Hand: Anders als Crossposter bietet die Bridge die Möglichkeit, nicht nur einseitig zu kommunizieren, sondern die Diskussion über beide Netzwerke zu spiegeln.

Der Nachteil ist aber, dass die Voraussetzung für eine Abbildung der gesamten Kommunikation recht hoch ist: Sobald Teile der kommunizierenden Bubble nicht über eine Bridge in das andere Netzwerk verfügen, werden deren Posts nicht gespiegelt, fehlen also im jeweils anderen Netzwerk. Dadurch wird die Kommunikation lückenhaft. Neben den eh kommunizierten Ausnahmen, in denen Posts nicht gespiegelt werden, hatte ich hin und wieder den Fall, dass Posts nicht übernommen wurden, obwohl sie theoretisch hätten übertragen werden müssen. Ein weiterer Nachteil ist, dass bestehende Accounts nicht eingebunden werden können, man also in jedem Fall einen neuen Account öffnen muss.

Clients

Mit Clients wie OpenVibe können beide Netzwerke in einem Client abgebildet werden. Die Timeline wird zusammen aggregiert, Posts können in beide Netzwerke gecrossposted werden. Die Nutzung ist wie in Sammelclients üblich recht übersichtlich, wenngleich OpenVibe sicherlich noch weit weg ist von der Usability von Mastodon Clients wie Elk oder Ice Cubes.

Der Vorteil liegt auf der Hand: Keine laufenden Bridge Services, die auf Serverinfrastruktur angewiesen sind, die das Spiegeln übernimmt, alles wird direkt in beide Netzwerke gespiegelt. Das Problem ist aber, dass Accounts, die ebenfalls in beide Netzwerke posten (ob über Crossposter, Bridge oder Client) dann auch immer doppelt in der Timeline auftauchen. Das nervt tatsächlich ziemlich. Reaktionen auf solche Posts müssen dann auch immer doppelt getätigt werden, wenn man auf beiden Netzwerken reagieren möchte. Es wäre hier extrem hilfreich, wenn der Client solche Redundanzen erkennen und ebenso wie die Timeline zusammenführen würde.

Warum überhaupt?

Warum ist das so zentral? Zum einen wird man die Alternativnetzwerke kaum für die auf Xitter verbliebenen Personen attraktiver machen, wenn sich die Communities und Bubbles aufteilen, obwohl sie gemeinsame Themen haben. Die IchbinHanna, Bibliotheks- und DH-Bubbles (z.B.) sollten in meinem Fall nicht voneinander getrennt existieren, da für meine Arbeit wichtig ist, Diskurse in allen Communities verfolgen und mich in allen Communities einbringen zu können. Gerade, wenn eine Community in zwei Netzwerken existiert, macht es die akademische Kommunikation im Bereich des Microbloggings extrem schwierig und dafür ist das Format einfach zu wichtig geworden, um bestimmte Themen in und zwischen Communities auszuhandeln.

Im Falle von Ausschüssen, Konferenzen oder ähnlichen Events ist es unbedingt nötig, eine gemeinsame Diskussionsbasis zu haben. Bluesky und Mastodon bieten hier beide eine gute Grundlage. Solange beide aber nicht auch gleiche Weise miteinander kommunizieren wie Instanzen im Fediverse untereinander und eine unkomplizierte Integration jenseits von Client, Bridge oder Crossposter möglich ist, bleibt das Zusammenbringen kompliziert. Wenn jemand eine gute Idee hat, die ich hier vergessen oder übersehen habe: Gerne her damit!

Ergänzungen

Hier eine Sammlung von Ergänzungen und Reaktionen:

---

---