Notizen Fediverse-MeetUp - Tag 2 vom 39C3; 16 Uhr

Unabhängig von anderen Veranstaltungen auf dem Congress und im Zuge unseres Engagements beim Aktionsbündnis neue soziale Medien (wir sind Mitunterzeichner des Appells an die Hochschulrektorenkonferenz zur Nutzung sozialer Medien haben wir uns Entschieden, auf dem 39C3 eine offene Austauschrunde für Betreiber*innen (und solche, die es werden wollen) anzubieten. Dabei sollte es nicht nur um technische, sondern auch und vor allem um organisatorische Themen gehen. Ungefähr 15 Personen aus unterschiedlichen Kontexten diskutierten unsere vorbereiteten Fragen – wir hoffen, dass ihr aus den folgenden Mitschriften Nutzen zum Betrieb eurer eigenen Instanz ziehen könnt

Fediverse-Meet-Up: Treffen von allen, die Instanzen selber betreiben (möchten)

Was brauche ich, um eine eigene Instanz aufzusetzen und zu pflegen? Welche Fragen muss man sich stellen - am besten vorher? Was sollte man technisch, organisatorisch, aber auch rechtlich bedenken? Wie managed ihr die Moderation? Jugendschutz, NSFW, politischen Content, Werbung, Gambling, … Welche Besonderheiten gibt es bei Mastodon, Pixelfed, PeerTube, … ? Wir suchen den Austausch mit Gleichgesinnten!

• Wen möchte ich als Zielgruppe haben?
• Wer soll dann unter welchen Bedingungen Zugang zur Instanz bekommen und wie stelle ich das sicher?
• Wie geht man damit um, wenn andere user/Instanzen anderslautende Regelungen gesetzt haben, als man selbst?

• Für welche Inhaltsanbieter und mit welcher Zielsetzung betreibe ich meine Instanz?
• Gibt es auf meiner Instanz eine Thematische Eingrenzung?
• Wo ziehe ich Mediale Grenzen?

• Wie geht man mit länger inaktiven Konten um?
  • Manche server haben einen Automatismus, der nach [Dauer X] den Inhabenden anschreibt mit einer Erinnerung und Informationen zur anstehenden Löschung bzw. wie man dieser entgeht.
  • Welche Prozesse braucht es für den Umgang mit inaktiven Accounts?
  • Wie wird die Kommunikation mit den Inhabenden sichergestellt? Wer ist dafür zuständig?

• Löschfristen
  • für Assets
  • für inaktive Konten
  • Information bei der Einrichtung von Konten
• Auftragsverhältnisse klären
• Dokumentation zur Datenverarbeitung

• ggf. juristischer Körper für Haftungsfragen

• technische Anforderungen
  • Abhängig von
    • Hashtags
    • Konten
    • Medien
    • Verteilungsgrad von Nachrichten auf der eigenen Instanz
  • ab mehreren Tausend Nutzenden macht sich Hardware vs. virtualisierter Server bemerkbar
  • ZFS / COW-Dateisystem für Backups
• zeitl. Aufwand (Betrieb, nicht Setup)
  • Einzelinstanz: 30-60min je Major-Update
  • ~120 Konten: 1h / Monat - 1h / Woche
  • ~500 Konten: <10min / Woche f. Moderation; 1h je Update
  • ~10K Konten: 3h je Backup vor Update; <30min /Woche f. Moderation; 1h je Major-Upgrade
  • Anpassungen je nach Aufwand
• Voraussetzungen:
  • Server-Administration (OS, Datenbank, Webserver)
  • Domains verwalten (SPF/DKIM für Mail)
  • ggf. als Service einkaufen, dann aber weniger konfigurierbar

• Trennung von einzelnen Diensten mittels VMs / Docker / Container / Jails

• Ansible Skript zum Aufsetzen eines Servers
  • Vorlage (bisschen outdated, wird demnächst aktualisiert): https://codeberg.org/stvo/mastodon-ansible-nodocker

• Frage: Emoji in Usernamen –> 30 Zeichengrenze bei Usernamen
• generell sind viele Werte im Vanilla-Mastodon nicht konfigurierbar
• Domainnamen gut wählen - diesen nachträglich zu ändern ist nur mit Abstrichen möglich
  • wenn doch, dann müssten Nutzer*innen ihren Account umziehen
  • IDNs werden gelegentlich in der nicht-Umlaut-Version angezeigt
  • Unterschiedliche Domains für Mastodon-Instanz und Accounts sind unter https://docs.joinmastodon.org/admin/config/#web_domain kurz beschrieben. Bei Fragen meldet euch gerne bei @fabian@schle.nz.

• Instanzen blocken
  • Blocklisten
  • Infoseiten zu Blocklisten (mit Links): https://joinfediverse.wiki/FediBlock

• Zugangsbarrieren für den eigentlichen Account
• Begründungen für die Registriergung
• Zugänge für manche Mail-provider ausgeschlossen (keine @gmail.com, keine Anonymisierungs-Services)
• Mail-Verifizierung

• Moderationskonzept:
  • Welche Regeln gibt man sich? Bereitschaftsdienst (auch an Feiertagen)
  • eigene Antwortzeit/Aktionszeit definieren
• ist für öffentliche Instanzen eher ein Thema, als für einen beschränkten Nutzer*innenkreis
• wer macht die Moderation? Extra Team?
  • Welche Datenschutzbestimmungen müssen sie erfüllen?
  • Welche rechtlichen und technischen Anforderungen?
  • intern oder in Nutzer*innenkreis ausgelagert?
    • ist Datenschutzfrage, da Moderator*innen pb-Daten der Nutzenden verarbeiten
    • z.B. über Vereinsstruktur regelbar - nur Mitglieder dürfen Moderieren
  • betrifft
    • Konten
    • Inhalte
    • andere Instanzen (Deföderation)
      • einige müssen geblockt werden (rechtl. Vorgaben)
      • andere können geblockt werden (inhaltl. Diskussion)
  • Regeln dürfen gerne als Vorlage verwendet werden: https://hessen.social/about
• Prozess zum Widerspruch zum Blocking überlegen
• ist nicht unbedingt ein Problem in der prozessualen Umsetzung, sondern in der Beurteilung
  • Ausmaß der Konsequenzen ist auch vielschichtig (Löschung/Sperrung des Beitrags, temporäre Sperre des Accounts, dauerhafte Sperre des Accounts)
  • ggf. Rücksprache mit Verursacher*in
• ggf. eigene Meldepflichten bei bestimmten Inhalten
  • Infoseite vom BKA dazu: https://www.bka.de/DE/DasBKA/OrganisationAufbau/Fachabteilungen/ZentralerInformationsUndFahndungsdienst/Digitale_Eingangsstelle/FAQ/faq_dsa_node.html
  • ToDos zum Nachtragen:
    • Welche Blocklisten sollte man sich anschauen und wie kommt man dadran?
    • BKA-liste für Kinderpornografie-moderation

• Kontakte klären etc.

• Umzug testen
• recovery-Backup/testen
  • es braucht im Wesentlichen nur den Public-Folder und den Datenbank-Dump

• Anpassungen von bspw. mastodon:
  • Textbegrenzun von Posts
  • Umfragen: mehr als 3 Optionen
• Konsequenzen der Anpassungen durchdenken!

• rechtl. Anforderungen
  • „Schäden“ sind mitigierbar
  • Kommunikation mit Behörden eingehen; insb. Datenschutzbehörden helfen auch
• techn. Notwendigkeiten:
  • Community hilft
• Commitment gegenüber User*innen
  • Verfügbarkeit
  • inhaltl. Überlegungen / Community-Building