Kategorien
Artikel

Mastodon – Fedihum – autodone #DHd2024

In ein paar Tagen beginnt die diesjährige Konferenz der deutschsprachigen Sektion des Digital Humanities Verbandes, kurz DHd2024 und ich bin zum ersten Mal bei einem Workshop dabei. Genauer gehöre ich neben Mareike König, Philip Schildkamp, Vivian Wolter, Ulrike Wuttke und seit kurzem auch Henrik Schönmann zum Team, das den Praxisworkshop “Microblogging mit Mastodon: Fediverse, Fedihum und Co. in den Digital Humanities” anbietet. Mit Philip werde ich für den zweiten Teil des Workshops zuständig sein, in dem wir den von der Community lang erwarteten Autoscheduling-Service autodone zum ersten Mal öffentlich vorstellen und praktisch anwenden werden. Dieser Blogpost gibt vorab schon einmal einen Einblick, was die Teilnehmer:innen erwartet. Wenn jemand Blut leckt und sich am Montag nachmittag bereits in Passau angekommen sein sollte, findet sich bestimmt noch ein Plätzchen. Genauere Infos zu Zeit und Ort gibt es auf der Konferenzwebseite.

Im ersten Teil des Workshops werden erste und zweite Schritte in Mastodon, auch in einer Hands-on-Session, vorgenommen. Außerdem wird das Konzept von Fedihum, dem Mastodon-Server für die DH-Community vorgestellt und diskutiert. Im zweiten Teil dürfen dann Philip und ich die Idee und Entwicklung von autodone skizzieren, die natürlich mit autoChirp und autoPost eine Vorgeschichte hat.

Dritte Ausfahrt autodone

Auch autodone ist ein Service zur automatisierten zeitgesteuerten Veröffentlichung von Content, dieses Mal aber nicht für Twitter (wie es autoChirp war) oder Facebook (das übernahm autoPost), sondern eben für Mastodon. Im Gegensatz zu seinen beiden Geschwistern dürfte autodone allerdings davor gewappnet sein, irgendwann suspendiert zu werden, weil es im verteilten Microblogging-Dienst keine zentrale Instanz gibt, die eine solche Suspendierung aussprechen kann. Zu den Hintergründen: Facebook bzw. Meta war irgendwann der Meinung, automatisierte Veröffentlichung mir autoPost würde gegen die ToS verstoßen. Twitter stellte schränkte neuer Führung den freien API-Zugang, den wir auch für autoChirp nutzten, massiv ein, so dass unser Service nicht mehr als 50 Tweets pro Tag veröffentlichen durfte. Bei einer zweistelligen Zahl von Nutzer:innen rissen wir diese Schranke naturgemäß mehrfach, so dass der Service in seiner Gesamtheit suspendiert wurde. Immerhin lief er über 7 Jahre lang (2016-2023) und womöglich hätten wir mit mittelgroßem Einsatz ein paar der Projekte retten können, die auf Twitter veröffentlicht wurden. Wir nahmen aber davon Abstand, diesen Aufwand zu betreiben und damit dieser Plattform und ihren Betreibern weiterhin kostenfrei Material zu liefern. Irgendwann ist’s dann auch mal gut.

Die Anfragen aus der DH-Community, ob wir denn nicht mal Vergleichbares für Mastodon entwickeln wollten, wurden indes häufiger und auch drängender. Tatsächlich hatten wir uns ja die meisten Gedanken zu benötigten Funktionalitäten und deren programmatischer Umsetzung schon gemacht und müssten das einfach auf eine andere Plattform anpassen. Auf der anderen Seite gibt es signifikante Unterschiede zwischen den Plattformen, die eine spezifische Behandlung erfordern. Und wenn man Code aus früheren Jahren anschaut, sieht man immer, wie und wo man was schmaler, schneller, sicherer, kurz: Einfach besser machen kann – bzw. Philip kann das einfach nicht vermeiden. 🙂 Die verteilte Struktur von Mastodon zwingt einem außerdem eine Reihe von Konzepten auf, die man für den zentralen Dienst Twitter nicht benötigte, etwa ein Handling verschiedener Server, die angesprochen werden müssen. Bei Twitter war es außerdem möglich, Bilder direkt per Link durchzustecken, ohne diese zwischenspeichern zu müssen, was bei Mastodon nicht geht. Das verursacht eine Menge Mehraufwand, weil man sich etwa um Bildgrößen kümmern muss und um Rate-Limits (und ja, da haben wir auch noch keine allseits anwendbare Lösung für).

Abb. 1: Irgendwann zwischendrin hat man so komische Bilder an der Tafel.

Auch wenn mir die Konzepte eines Webservices im Einzelnen klar sind, bin ich weit davon entfernt, einen solchen eigenverantwortlich zu programmieren, aufzusetzen und auch zu betreiben. Ich bin daher unendlich froh, Philip quasi zurückgewonnen zu haben (er hat damals schon autoChirp mitentwickelt). Als Ulrike und Mareike mich auf der #DHd2023 in Trier ansprachen, ob wir nicht zusammen einen Mastodon-Workshop anbieten wollen, bei dem auch die automatisierte Veröffentlichung thematisiert werden sollte, hatten wir dann auch eine Deadline zur Fertigstellung eines Prototyps. Und das hilft ja immer ungemein bei der Entwicklung. Und tadaa: Den Service könnt ihr ab sofort hier ausprobieren. Und den Code findet ihr selbstverständlich auch, nämlich hier.

autodone – Stand der Dinge

Zentral für autodone ist die Möglichkeit, Daten für mehrere (ggfs. auch sehr viele) Posts in Tabellen zu sammeln und diese in einer Aktion hochzuladen. Diese Posts werden dann in autodone als Gruppe verwaltet. Ist die Gruppe scharf geschaltet (per enable) kümmert sich der Service dann um die zeitgesteuerte Veröffentlichung. Egal, wann diese stattfinden soll. Ein besonderes Feature ist, dass man die Gruppe auch threaden kann. Damit wird jeder Post der Gruppe zu einer Antwort auf den zuvor veröffentlichten. Als autoChirp noch lief, war es der einzige uns bekannte Service weltweit, mit dem man automatisiert und zeitgesteuert Threads veröffentlichen konnte. Ob dies für Mastodon/autodone auch gilt, vermögen wir gerade nicht zu sagen, wir freuen uns aber über Hinweise!

Abb. 2: Screenshot einer hochgeladenen Gruppe in autodone, die enabled und threaded ist. Das dem Upload zugrundeliegende Spreadsheet kann man hier einsehen.

Das Design ist bewusst einfach gehalten, das Logo LLM-generiert und die Funktionalitäten eingeschränkter als die von autoChirp (es fehlt z.B. noch ein automatisches Re-Scheduling von Gruppen, etwa auf das nächste Jahr). Wir wollen erst einmal abwarten, ob und wie der Service überhaupt genutzt wird und was uns die Nutzer:innen rückmelden. Wir denken, erst einmal eine gute Basis gelegt zu haben und freuen uns, dass wir diese am Montag direkt mit einem Teil der DH-Community erproben können. Alle, die nicht dabei sein werden, aber Teil der Community auf Fedihum sind, können sich demnächst über Projekte wie Tiwoli und die Humboldt-Chronik auf Mastodon freuen. Beide werden zeitnah starten.

Und wenn ihr Interesse an der Nutzung von autodone habt, probiert den Service gerne aus! Schreibt uns aber auch jederzeit gerne an – per Mail, per Mastodon (oder direkt beim @autodone-Account), per BlueSky oder auch über einen Kommentar hier!



Diesen Blogbeitrag zitieren
Jürgen Hermes (2024, 23. Februar). Mastodon – Fedihum – autodone #DHd2024. TEXperimenTales. Abgerufen am 27. Mai 2024, von https://doi.org/10.58079/vw98

Von Jürgen Hermes

Arbeitet als Wissenschaftler und Geschäftsführer am Institut für Digital Humanities an der Universität zu Köln.

3 Antworten auf „Mastodon – Fedihum – autodone #DHd2024“

Das ist ganz grandios! Auch dass du direkt eine Beispieltabelle bereitstellst. Ich hoffe, die kommt auch noch auf die autodone-Seite? Freu mich schon auf meine ersten Versuche. Und wünsch euch einen phänomenal guten Workshop 🙂

@Flusskiesel – Wenn man seine Daten in einer Tabelle speichert, kann man dort die Daten erst einmal weglassen. autodone legt Status allerdings nur an, wenn mindestens Datum, Uhrzeit und Text gefüllt sind.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

Suche in OpenEdition Search

Sie werden weitergeleitet zur OpenEdition Search