Fediverse mit eigenem Namen: GoToSocial mit Adresse auf der Hauptdomain

Im Fediverse gehört die eigene Adresse niemandem außer Ihnen, wenn der Server Ihnen gehört. Statt @name@mastodon.social heißt es dann @name@ihre-domain.de, und die Domain bleibt Ihre, auch wenn Sie später die Software wechseln. Mastodon selbst ist für einen Einzelnutzer schwergewichtig: mehrere Dienste, PostgreSQL, Redis. GoToSocial ist ein einzelnes Programm mit SQLite und spricht dieselbe Sprache, ActivityPub. Diese Anleitung richtet es so ein, dass die Adresse auf der Hauptdomain liegt, der Server aber unter einer Subdomain läuft, und prüft die Verbindung zu Mastodon und anderen Servern in beide Richtungen.

Dies ist Teil 13 der Reihe „Server im Netz“. Als Beispiel dient ein netcup-VPS mit Ubuntu und Docker, auf dem Caddy die Domain sedv-lab.de ausliefert. Die Website aus Teil 5 liegt dort hinter Anubis aus Teil 6.

Voraussetzungen

• Der VPS aus Teil 4 mit Caddy im Host-Netz und Docker
• Eine Subdomain für den Server, im Beispiel social.sedv-lab.de
• Die Möglichkeit, unter der Hauptdomain drei Pfade weiterzuleiten
• Eine App, die die Mastodon-Schnittstelle spricht, für den Alltag

Host und Account-Domain

Andere Server finden ein Konto über WebFinger: Sie fragen bei der Domain aus der Adresse nach /.well-known/webfinger. GoToSocial trennt deshalb zwei Namen. GTS_HOST ist der Name, unter dem der Server läuft. GTS_ACCOUNT_DOMAIN ist die Domain in den Adressen. Laut Doku legen Sie beide vor dem ersten Start fest. Nach der ersten Föderation lassen sie sich nur noch ändern, wenn Sie die Datenbank neu anlegen.

Schritt 1: GoToSocial starten

services:
  gotosocial:
    image: superseriousbusiness/gotosocial:0.22.3
    container_name: gotosocial
    restart: unless-stopped
    network_mode: host
    environment:
      GTS_HOST: "social.sedv-lab.de"
      GTS_ACCOUNT_DOMAIN: "sedv-lab.de"
      GTS_PROTOCOL: "https"
      GTS_BIND_ADDRESS: "127.0.0.1"
      GTS_PORT: "8095"
      GTS_DB_TYPE: "sqlite"
      GTS_DB_ADDRESS: "/gotosocial/storage/sqlite.db"
      GTS_LETSENCRYPT_ENABLED: "false"
      GTS_TRUSTED_PROXIES: "127.0.0.1/32,::1/128"
      GTS_ACCOUNTS_REGISTRATION_OPEN: "false"
      TZ: "Europe/Berlin"
    volumes:
      - ./data:/gotosocial/storage

Der Container läuft als Benutzer 1000, der Datenordner muss ihm gehören. Zertifikate holt Caddy, deshalb ist das eingebaute Let's Encrypt aus. GTS_TRUSTED_PROXIES sorgt dafür, dass GoToSocial die echte Adresse der Besucher aus den Headern von Caddy liest. Fremde Registrierungen sind abgeschaltet.

mkdir -p data && chown 1000:1000 data
docker compose up -d
docker logs gotosocial 2>&1 | grep listening

Verifizieren: Das Log meldet listening on 127.0.0.1:8095.

Schritt 2: Caddy und die Weiterleitungen

Der Block für den Server selbst:

social.sedv-lab.de {
	import sicher
	reverse_proxy 127.0.0.1:8095
}

Im Block der Hauptdomain leiten drei Pfade auf den Server weiter, damit andere Server und Apps das Konto unter @lab@sedv-lab.de finden:

sedv-lab.de {
	...
	@fedi path /.well-known/webfinger /.well-known/host-meta* /.well-known/nodeinfo
	redir @fedi https://social.sedv-lab.de{uri} 301
	...
}

{uri} nimmt die Abfrage mit, etwa ?resource=acct:lab@sedv-lab.de. Caddy bearbeitet redir vor reverse_proxy, die Anfragen erreichen Anubis also nicht.

Verifizieren: curl -sL "https://sedv-lab.de/.well-known/nodeinfo" liefert JSON mit Verweisen auf https://social.sedv-lab.de/nodeinfo/2.0.

Schritt 3: Das Konto anlegen

Konten legt die Kommandozeile im Container an. Danach bestätigen und zum Administrator machen, dann einmal neu starten:

docker exec gotosocial /gotosocial/gotosocial admin account create \
  --username lab --email admin@sedv-lab.de --password 'LANGES-PASSWORT'
docker exec gotosocial /gotosocial/gotosocial admin account confirm --username lab
docker exec gotosocial /gotosocial/gotosocial admin account promote --username lab
docker restart gotosocial

Ein zweiter Aufruf von account create mit demselben Namen brach im Test mit einem Programmfehler ab. Legen Sie das Konto also nur einmal an.

curl -sL "https://sedv-lab.de/.well-known/webfinger?resource=acct:lab@sedv-lab.de"

Verifizieren: Die Antwort beginnt mit {"subject":"acct:lab@sedv-lab.de" und verweist auf https://social.sedv-lab.de/users/lab.

GoToSocial hat keine Oberfläche zum Schreiben von Beiträgen. Die Weboberfläche dient für Profil und Einstellungen, geschrieben wird mit Apps, die die Mastodon-Schnittstelle sprechen. Für den Test haben wir uns einmal angemeldet und mit OAuth ein Token für die Schnittstelle geholt.

Schritt 4: Föderation in beide Richtungen

Mit dem Token haben wir zwei fremde Konten gesucht, eines auf mastodon.social und eines auf dem GoToSocial-Server des Projekts:

curl -s -H "Authorization: Bearer TOKEN" \
  "https://social.sedv-lab.de/api/v2/search?q=%40Gargron%40mastodon.social&resolve=true&type=accounts"

Beide Konten fand der Server, nach 3,71 und 2,97 Sekunden. Die Zahlen für Beiträge und Folgende standen danach auf null: GoToSocial lädt beim Auflösen nur das Profil, keine älteren Beiträge. Spannend war das Log des eigenen Servers: In den Sekunden danach fragten Mastodon und GoToSocial bei uns nach dem Profil, dem Schlüssel unter /users/lab/main-key, der Outbox und den Listen der Folgenden, alles mit Status 200. Mit dem Schlüssel prüften sie die Signatur unserer Anfragen. Damit funktionierten Abrufe in beide Richtungen.

Ein Abruf des Profils ohne Signatur, etwa mit curl und Accept: application/activity+json, endet mit 401 und http request wasn't signed or http signature was invalid. GoToSocial gibt Profile über ActivityPub nur an Server heraus, die sich ausweisen. Im Browser bleibt die öffentliche Profilseite sichtbar.

Verifizieren: docker logs gotosocial 2>&1 | grep "Mastodon/" zeigt nach einer Suche Abrufe fremder Server auf /users/NAME.

Was der Server braucht

Nach dem Auflösen der beiden Konten belegte GoToSocial 213 MiB Arbeitsspeicher, die Daten 4,1 MB. Mit jedem Konto, dem Sie folgen, wachsen Datenbank und Medien-Zwischenspeicher. Kurz nach dem Start tauchten im Log auch die ersten Scanner auf.

Typische Fehler

Meldung oder Beobachtung	Ursache und Lösung
Konto unter der Hauptdomain nicht auffindbar	Weiterleitung für /.well-known/webfinger fehlt oder Anubis beantwortet die Anfrage. Weiterleitung im Block der Hauptdomain prüfen.
http request wasn't signed or http signature was invalid	Kein Fehler, GoToSocial verlangt signierte Abrufe. Mit einer App oder einem anderen Server testen.
Programmfehler bei admin account create	Konto mit dem Namen gibt es schon. Mit admin account und den Befehlen confirm oder password weiterarbeiten.
Fremde Konten zeigen null Beiträge	GoToSocial lädt keine älteren Beiträge nach. Laut Doku kommen nach dem Folgen nur neue Beiträge an.

Häufige Fragen

Welche App nehme ich?

Jede, die mit Mastodon-Servern arbeitet und Anmeldung per OAuth kann. Die Liste der getesteten Apps steht in der Doku von GoToSocial.

Kann ich später zu Mastodon wechseln?

Die Domain bleibt Ihre, aber beim Wechsel der Software unter derselben Adresse gehen Beiträge und Folgende verloren. Die Kontomigration im Fediverse zieht nur die Folgenden auf ein neues Konto um, keine Beiträge.

Wie viele Konten verträgt das?

GoToSocial ist für Einzelnutzer und kleine Gruppen gedacht. Für eine große offene Gemeinschaft ist Mastodon die bessere Wahl.

Fazit

GoToSocial macht aus der eigenen Domain eine Adresse im Fediverse, mit einem Container und drei Weiterleitungen. Der Test zeigte, dass Abrufe zwischen dem eigenen Server, Mastodon und anderen Servern sofort funktionierten. Wer die Trennung von Host und Account-Domain vor dem ersten Start festlegt, hat eine Adresse, die auch einen späteren Wechsel der Software übersteht.

Weiterführende Anleitungen und Quellen

• Teil 14: Eigener Matrix-Server
• Teil 4: Caddy als Eingangstür
• Teil 6: Anubis vor der Website
• Docker und Docker Compose auf Linux installieren
• Docker Compose absichern
• GoToSocial: Dokumentation
• GoToSocial: Host und Account-Domain
• GoToSocial auf Codeberg
• W3C: ActivityPub