Föderation ist eines dieser Worte, die Nextcloud seit Jahren in jeder Keynote fallen lässt, gefolgt von einem großen „Aber“. Die Idee klingt verführerisch: Statt in jedem Silo aufs Neue zu registrieren, wachsen die einzelnen Instanzen zu einem gemeinsamen Netzwerk zusammen. Wer bei einer Cloud angemeldet ist, soll auch mit jemandem auf einer anderen Instanz Dateien teilen oder eine Videokonferenz anstoßen können. Die Praxis war lange Zeit holprig. Ein Gedanke macht immer wieder die Runde: „Wie soll mich jemand finden, wenn er meine Instanz nicht kennt?“ Genau dafür gibt es den Lookup Server – und den Connector.
Dieser Artikel nimmt den Nextcloud Lookup Server Connector unter die Lupe. Was das Bauteil wirklich leistet, wo es den Selbstbetreiber vor Rätsel stellt und wie sich die Einrichtung sauber über die Bühne bringen lässt, steht auf den folgenden Zeilen. Manches davon mag sich nach einem Ausflug in die Details anhören, aber bei der Föderation steckt der Teufel im Detail.
Ein Anschluss für das föderierte Telefonbuch
Stellen Sie sich vor: Zwei Unternehmen, beide nutzen Nextcloud, beschließen, ihre Abteilungen für ein gemeinsames Projekt zu verbinden. Der Administrator von Unternehmen A richtet eine sogenannte Federated Share ein, sucht nach einem Kollegen der Firma B … und findet nichts. Er müsste die exakte Cloud-ID des Gegenübers kennen, also eine Kombination aus Benutzername und Instanzadresse, die wie eine E-Mail-Adresse aussieht: benutzer@cloud-firma-b.de. Diese ID kann man per E-Mail austauschen oder im Adressbuch eintragen. Aber wer sich über den Anzeigenamen oder die E-Mail-Adresse des Nutzers finden will, braucht eine zusätzliche Instanz, die genau diese Zuordnung kennt – den Lookup Server.
Der Nextcloud Lookup Server Connector ist die Softwarekomponente, die eine Nextcloud-Instanz mit diesem Verzeichnis verbindet. Er ist also der „Telefonanschluss“: Er trägt die Benutzerkonten der lokalen Instanz in die verteilte Datenbank des Lookup-Servers ein und hält sie dort aktuell. Ohne diesen Connector wäre der zentrale Lookup-Server kaum mehr als eine leere Registratur, nützlich für niemanden. Mit ihm wird aus der statischen Nextcloud eine föderierte Kommunikationsbasis. In der Praxis spielt der Connector dabei die Rolle eines stillen Dienstes: Er arbeitet im Hintergrund und meldet sich nur dann zu Wort, wenn sich ein Datensatz ändert oder ein Benutzer gelöscht wird.
Man darf sich das nicht als konkretes Programm vorstellen, das man etwa als Daemon betreibt. Der Connector ist eher ein loses Modul – in neueren Versionen direkt in die Nextcloud-App zur Föderation integriert, in manchen Ausbaustufen als eigenständige Zusatz-App verfügbar, die sich in den Einstellungen wiederfindet. Diese App verwaltet Einträge des eigenen Nutzers, nicht etwa des gesamten Servers. Das ist ein wichtiger Punkt: Im Gegensatz zu einem Active Directory oder einem LDAP-Verzeichnis werden hier keine kompletten Benutzerlisten abgeglichen. Sondern es werden nur Datensätze von Anwendern verarbeitet, die selbst einwilligen.
Was genau liegt auf dem Lookup Server?
Der Lookup Server selbst ist eine Art Register, das ausschließlich öffentlich relevante Informationen aufbewahrt. Dazu zählen an erster Stelle die föderierte Cloud ID, optional die E-Mail-Adresse, eventuell ein Klarname oder der öffentliche Teil eines Signaturschlüssels. Wenn ein Nutzer in seiner Nextcloud in der Suche „max.mustermann@example.org“ eingibt, dann schickt der Client eine Anfrage an den Lookup Server. Der liefert passende Einträge zurück, und die lokale Instanz kann eine Verbindung zu dieser fremden ID aufbauen. Erst in diesem Moment beginnt der eigentliche Dateitransfer.
Technisch gesehen ist der Ablauf ein einfaches HTTP-REST-Ding. Der Connector reicht eine registrierte Kombination aus E-Mail, Benutzername und Instanzadresse ein. Das Higher-Level-Protokoll ist bewusst schlank gehalten, um mit vielen verschiedenen Implementierungen zusammenzuarbeiten. Wer sich für die Details interessiert, findet in der offiziellen Dokumentation einige REST-Endpunkte, die für die Verwaltung der Datensätze zuständig sind. Für die Mehrheit der Adminstratoren reicht jedoch die Vorstellung: Der Connector sendet einen Datensatz, verschlüsselt mit einem lokalen Token, und der Lookup Server bestätigt oder lehnt ab.
Diese Schlichtheit hat ihren Preis: Der Server erfüllt keine autorisierende Rolle, sondern lediglich eine Hinweis-Funktion. Er gibt an, wo ein Nutzer zu Hause ist – ob er tatsächlich existiert und das Recht an der Datenhoheit besitzt, verifiziert er nicht. Um dennoch ein Mindestmaß an Missbrauchsschutz zu bieten, wird bei der Anmeldung in vielen Konfigurationen eine Prüfung per E-Mail verschickt. Der Anwender muss sie bestätigen, bevor der Eintrag öffentlich sichtbar wird. Ansonsten könnte jemand fremde E-Mail-Adressen anmelden und damit ungebeten Kontaktanfragen auslösen.
Rolle in der Federation: Übersetzer, nicht Vermittler
Der Nextcloud Lookup Server Connector übernimmt keine Vermittlung von Dateien oder Zugriffsrechten. Er ist nicht mit einem Identity Provider zu verwechseln, der Passwörter prüft oder Authentifizierungs-Tokens ausstellt. Diese Abgrenzung ist vielen Administratoren nicht sofort klar, und deshalb ein häufiges Missverständnis. Ein Benutzer, der über den Lookup Server gefunden wird, ist damit noch lange nicht berechtigt, auf irgendetwas zuzugreifen. Er ist nur sichtbar, quasi die Anschrift auf einem Umschlag. Der Brief selbst wird erst geöffnet, wenn die föderierte Instanz die Berechtigungen prüft.
Architektonisch gesprochen sitzt der Connector also nicht im Datenpfad, sondern an der Eingangstür des Verzeichnisdienstes. Das macht ihn aus Sicht der Sicherheit angenehm unkritisch: Selbst wenn der Lookup Server kompromittiert würde, hätte ein Angreifer allenfalls die Kontrolle über die Sichtbarkeit von Kontaktdaten, nicht über die Daten selbst. Was ein moderateres Problem ist, als es im ersten Moment klingt – denn die Sichtbarkeit von Metadaten ist gerade in föderalen Umgebungen keineswegs harmlos.
Nicht zuletzt ist da die Frage der Eindeutigkeit. Wenn zwei Instanzen denselben Benutzer erfassen wollen, braucht es eine gemeinsame Basis. Der Lookup Server kann dafür sorgen, dass eine E-Mail-Adresse nur einmal vergeben ist. Das klingt gut, erzeugt im Alltag aber bisweilen die berühmten Löcher: Ein ehemaliger Mitarbeiter zieht sich aus der Instanz zurück, sein Konto wird gelöscht, doch die E-Mail-Adresse bleibt noch für Wochen im Verzeichnis des Lookup Servers hängen. Für die verbleibenden Kollegen bedeutet das tote Einträge, die beim Teilen wie gespenstische Prospekte aussehen.
Wie der Connector mit dem Server spricht
Der Datenaustausch zwischen dem Connector und dem Lookup Server läuft über eine schlanke REST-Schnittstelle. Es ist kein Echtzeitprotokoll; der Connector sendet einmalig Daten, wenn sich etwas ändert. Um zu verhindern, dass sich jemand von außen als Benutzer ausgeben kann, verwendet der Connector einen signierten Nachrichtenbestandteil. Der Lookup Server prüft die Signatur anhand des öffentlichen Schlüssels, den die Nextcloud-Instanz zuvor registriert hat. Damit ist die Zuordnung eines Benutzers zur Domäne gesichert, ohne dass ein zentraler Session-Cookie nötig wäre.
In der Praxis sieht das Ganze weniger spektakulär aus, als es klingt. Ein HTTP-Client schickt die E-Mail-Adresse und die ID an den Server, gefolgt von einem Zeitstempel und einer Prüfsumme. Der Server antwortet mit einer Art Acknowledgement, das die Registrierung bestätigt. Dass dabei kein OAuth verwendet wird, hat einen einfachen Grund: Der Connector ist kein Teil des Browser-Workflow, sondern ein serverseitiger Dienst. Er benötigt kein interaktives Login, sondern ein festes Betriebsgeheimnis. Das ist je nach Betriebsmodell eines der kritischen Elemente, denn der Schlüssel muss in der Nextcloud-Config sicher verwahrt werden.
Interessant ist ferner, dass sich die Suche über den Lookup Server nicht nur auf einen einzelnen Treffer beschränkt. Der Server kann mehrere Datensätze liefern, wenn die Suchanfrage mit einem Wildcard-Charakter formuliert wird. In der Oberfläche von Nextcloud wird das in der Regel als Vorschlagsliste dargestellt. Der Administrator kann diese Suche begrenzen, um zu verhindern, dass die lokale Instanz ganze Bereiche des öffentlichen Registers abfragt. Diese Einstellung hängt eng mit dem Datenschutz zusammen, weil dadurch bereits Metadaten über Abfrageverhalten anfallen.
Installation und Konfiguration: Eine Anleitung in Prosa
Wie ist der Connector nun einzurichten? Die meisten Installationen brauchen keine separate Datei, weil die Nextcloud inzwischen eine Vorauswahl an Apps mitliefert. Man öffnet in der Administration die „Apps“, sucht nach „Föderation“ oder „Lookup“ und aktiviert das entsprechende Modul. Fertig ist der Grundbaustein. Ob das schon die ganze Magie war? Nein, denn standardmäßig zeigt der Connector auf den öffentlichen Dienst lookup.nextcloud.com. Wer das ändern will, muss einen Parameter setzen.
In der Datei config.php findet sich nach der Aktivierung ein Eintrag, der anfangs unscheinbar wirkt:
'lookup_server' => 'https://lookup.nextcloud.com',
'lookup_server_access' => 'read_only'Der zweite Wert ist spannend. Mit read_only schaltet man den Connector so, dass die Instanz den Datensatz des eigenen Servers nicht zurückschreibt. Das kann sinnvoll sein, wenn man eine zentrale Verwaltung durch externe Betreiber vermeiden möchte – oder wenn man den Testbetrieb einfach nicht selbst mit Daten füttern will. Mit write erlaubt man die Registrierung von Benutzerdaten. In den Einstellungen eines angemeldeten Anwenders taucht dann eine Sektion mit der eigenen Federated Cloud ID und dem optionalen Häkchen zur Veröffentlichung auf.
Der nächste Schritt ist die Überprüfung der Datenschutz-Einstellungen. Denn die Zustimmung des Anwenders muss nicht pauschal beim Serverstart erfolgen, sondern wird im Benutzerinterface abgefragt. Es hat sich eingebürgert, dass dem Anwender der Zweck der Veröffentlichung transparent angezeigt wird. Andernfalls bekommt der Admin irgendwann bitterböse Mails, falls der Lookup Server fremden Instanzen die Mail-Adressen der eigenen Belegschaft verrät. Das ist der unbequemste Teil der Konfiguration – nicht technisch, sondern organisatorisch.
Wartung und Updates: Der Connector im Produktlebenszyklus
Wie alle Nextcloud-Apps entwickelt sich auch der Connector weiter. Wer die App regelmäßig aktualisiert, stellt fest, dass sich das Verhalten im Hintergrund ändern kann. Mal wird das Format der Signatur angepasst, mal kommen neue Optionen für die Veröffentlichung hinzu. Bevor man ein Update im laufenden Betrieb einspielt, lohnt sich ein Blick in die Release Notes des Moduls. Selten, aber möglich ist es, dass alte Datensätze durch ein Update auf dem Lookup Server nicht mehr anerkannt werden. Dann hilft es, den Eintrag des Benutzers zu deaktivieren und nach der Aktualisierung wieder zu aktivieren.
Ein häufiger Fehler ist, dass der Connector nach einem Server-Umzug nicht mehr kommuniziert. Die Kette aus Federated Cloud ID, Instanz-Domain und Lookup Server muss zusammenpassen. Wenn die Domain wechselt, müssen die Nutzer ihre Cloud-ID aktualisieren, was der Connector beim nächsten Anmelden übernimmt. Allerdings bleibt die alte ID unter Umständen noch im Lookup Server stehen. Das erzeugt wieder die oben erwähnten toten Einträge. Ein routinierter Administrator gleicht daher regelmäßig die Datenbank des Lookup Servers mit der lokalen Benutzerliste ab – sofern das eigene Server-Setup das erlaubt.
Dazu ein kleiner Rat: Legen Sie sich eine Liste der registrierten Nutzer an, bevor Sie mit Experimenten beginnen. So können Sie nachvollziehen, welche Benutzer über den Connector veröffentlicht werden und welche nicht. Wenn ein Konto gelöscht wird, sollte der Löschvorgang im Nextcloud-Interface der App durchgeführt werden, anstatt den Benutzer einfach in der Datenbank zu entfernen. Andernfalls bleibt der öffentliche Eintrag bestehen, bis er manuell in der Administration des Lookup Servers bereinigt wird.
Der öffentliche Dienst: Bequemlichkeit und Misstrauen
Nextcloud betreibt seit vielen Jahren einen eigenen Lookup Server für alle, die keine eigene Infrastruktur aufsetzen wollen. Das ist bequem, spart Ressourcen und funktioniert in der Regel zuverlässig. Zugleich wirft es eine Frage auf, die in der Community unterschiedlich beantwortet wird: Soll man seine Nutzer überhaupt an eine zentrale Stelle melden, die man nicht in der Hand hat? Das Argument „Ist doch nur die E-Mail-Adresse“ zieht nicht immer, weil die Kombination aus E-Mail, Name und Cloud-ID bereits ein Profil bilden kann. Ein Ermittler – oder ein Werbenetzwerk – könnte über diese Daten Verbindungen zwischen ansonsten unabhängigen Instanzen knüpfen.
Die Verantwortlichen von Nextcloud haben auf diesen Einwand reagiert, unter anderem mit der Unterstützung selbst gehosteter Lookup-Server. Wer will, kann den Server als eigene Instanz aufsetzen und den Connector per URL umbiegen. Wie so oft steckt der Teufel im Detail: Die Suche über mehrere Server hinweg funktioniert dann nicht, es sei denn, man betreibt einen eigenen Föderationsknoten, der wiederum mit anderen Servern verbunden ist. Ein Wildwuchs, der die Dezentralität etwas zurückholt – aber der zentrale Dienst bleibt bei den meisten Installationen die erste Wahl.
Aus journalistischer Perspektive ist es bemerkenswert, wie selten die Grundsatzfrage auf den Konferenzen gestellt wird. Da ist einerseits das Marketing, das mit „Deine Daten, deine Regeln“ wirbt; andererseits der Komfort, der die eigene Addresse eben doch lieber in eine zentrale Liste einträgt. Es wäre unfair, das als Heuchelei abzutun. Viele Betreiber machen es einfach aus Pragmatismus, weil ein eigener Lookup Server für eine Zwanzig-Mann-Firma nicht die erste Priorität ist.
Selbst gehosteter Lookup Server: Für wen sich das lohnt
Der Betrieb eines eigenen Lookup Server ist keine Hexerei, aber er verlangt mehr, als ein PHP-Paket hinzuwerfen. Das Projekt ist auf GitHub verfügbar, nutzt eine Datenbank im Hintergrund und benötigt einige Cron-Jobs. Wer bereit ist, sich einzuarbeiten, kann so eine vollständige Kontrolle über die Datensätze erreichen. Besonders für Bildungseinrichtungen oder Behörden, die interne Föderationen ohne Umweg über zentrale Cloud-Dienste aufbauen wollen, ist das eine denkbare Lösung.
Interessant ist, dass der selbst gehostete Lookup Server nicht zwingend als globale Instanz sichtbar sein muss. Er kann als interner Verzeichnisdienst eingesetzt werden, der nur für die eigenen Standorte erreichbar ist. In so einem Szenario ähnelt er einem DNS-Server, den man nur für ein bestimmtes Netzwerk betreibt. Die Nextcloud-App erlaubt es, einen solchen Server als „Lookup Server“ zu benennen und im selben Subnetz zu verwenden. Voraussetzung ist eine saubere TLS-Verschlüsselung, da sonst die übertragenen Daten im Klartext durch das Rechenzentrum laufen.
Dennoch: Ein eigener Server bedeutet auch eigene Wartung. Updates, Backup, Ausfallzeiten. Der Aufwand ist nicht gigantisch, aber er gehört zu den Dingen, die in kleinen Teams gerne untergehen. Bevor man sich für diesen Weg entscheidet, sollte man den eigenen Bedarf ehrlich veranschlagen: Dient der Lookup Server nur als internes Adressbuch? Dann kann man stattdessen auch mit nextcloud-eigenen Kontakten im Adressbuch arbeiten und spart sich das Problem. Soll er tatsächlich ein global zugängliches Verzeichnis sein? Dann ist die Administration eines eigenen Servers eine dauerhafte Hausaufgabe.
Datenschutz in der praktischen Auseinandersetzung
Ein Thema, das oft in den FAQs auftaucht: Wie werden Einträge vom Lookup Server wieder entfernt? Der Connector hat dafür eine Funktion, die im Benutzerkontext verfügbar ist. Wenn ein Nutzer seine Veröffentlichung zurückzieht oder sein Konto in der Nextcloud gelöscht wird, wird der Datensatz beim Server abgemeldet. In der Praxis verläuft das nicht immer synchron. Der Lookup Server kann Einträge aus Redundanzgründen länger vorhalten. Das deutsche Bundesdatenschutzgesetz verlangt klar Löschfristen, aber wer betreibt schon die Gegenstelle? Der Betreiber muss darauf achten, dass die eingesetzte Software die Löschung auch tatsächlich umsetzt.
Der Umgang mit dem öffentlichen Schlüssel ist ein anderer Aspekt. Wer Ende-zu-Ende-Verschlüsselung in Nextcloud nutzen möchte, muss dem Gegenüber vertrauen können. Über den Lookup Server hinterlegte Schlüssel sind eine Möglichkeit, diese Vertrauensbeziehung herzustellen. Doch genau hier zeigt sich die Krux: Der Server ist nicht unabhängig – er könnte einen gefälschten Schlüssel liefern, zusteuern oder anderweitig manipulieren. Wer absolute Sicherheit braucht, wird deshalb um einen gegenseitigen Schlüsselaustausch auf anderen Wegen nicht herumkommen. Der Lookup Server ist da eher das Sahnehäubchen, nicht das Sicherheitsfundament.
Immerhin: Ein Blick auf die API zeigt, dass die Kommunikation zwischen Connector und Server über HTTPS läuft, was die übertragenen Daten im Transit schützt. Aber letzte Gewissheit gibt es nicht. Eine Prüfung der Serverzertifikate durch die Nextcloud-Instanz ist auf Wunsch möglich. Die Standardinstallation verlässt sich auf die Zertifikate des Systems. Das ist ein Zustand, der an das alltägliche Vertrauen in öffentliche Zertifikatstellen erinnert – funktioniert, bis es eben nicht mehr funktioniert.
Stolpersteine aus der Praxis
Womit kämpfen Administratoren am häufigsten, wenn der Connector eingerichtet ist? Nach unseren Beobachtungen sind es drei Dinge. Erstens: Der Eintrag wird nicht in den Einstellungen der Nutzer angezeigt. Das liegt gelegentlich daran, dass der Haken bei „Veröffentlichung“ nicht gesetzt ist oder der Eintrag erst nach einem Cron-Lauf aktualisiert wird. Manche lösen das, indem sie die Inaktivität des Connectors durch einen Klick auf „Aktualisieren“ provozieren.
Zweitens: Der Lookup Server gibt einen Eintrag zurück, der nicht mehr existiert. Das ist der schon erwähnte tote Eintrag, verursacht durch fehlende Synchronisierung oder eine nicht abgeschlossene Löschung. Wer den Eintrag in der eigenen Config manuell entfernt hat, muss den Löschbefehl ebenso manuell an den Server senden. Daran scheitert der eine oder andere.
Drittens: Der falsche Vertrauensrahmen. Dass der Connector ein fremdes Verzeichnis befüllt, ist manchen Mitgliedern des eigenen Teams nicht geheuer. Sie wollen nicht, dass ihre Dienst-Mail-Adresse in einer öffentlichen Datenbank auftaucht. Dann hilft es, die Option zu installieren, nur die anonymisierte Cloud-ID zu übertragen, ohne weitere Metadaten. Auch das erfordert eine Konfigurationseinstellung, die man nicht in den ersten zehn Minuten findet.
Dazu kommt die übliche, fast schon historische Fehlerquelle: Namensräume. Wer von einer alten ownCloud-Migration kommt, hat vielleicht noch mit falsch geschriebenen föderierten IDs zu kämpfen. Ein @ im Benutzernamen oder eine Domain mit portgeschriebenem Schema führt zu undurchsichtigen Suchläufen. Der Lookup Server ist da pedantisch – er schaut auf die exakte Zeichenkette. Eine kleine Aufforderung an alle Admins: Testet die Suche nicht nur mit der gemütlichen Abkürzung, sondern mit der voll ausgeschriebenen ID. Die Zahl der vermeintlichen Fehlermeldungen sinkt erheblich.
Ausblick: Open Cloud Mesh und die Zukunft der Verzeichnisse
Der Lookup Server Connector ist nicht das Ende der Entwicklung. In der Föderation von Cloud-Diensten gibt es das Projekt Open Cloud Mesh (OCM), das darauf zielt, unterschiedliche Systeme über einen gemeinsamen Standard miteinander zu verbinden. Dabei geht es nicht nur um Nextcloud, sondern auch um andere Anbieter, die Datenaustausch über eine föderierte API realisieren wollen. Der Connector könnte dabei in eine zentrale Rolle rücken, weil er ja bereits eine Art Verzeichnisdienst bereitstellt. Andererseits zeigen erste Implementierungen von OCM, dass der Suchraum nicht unbedingt global sein muss. Es lassen sich Vertrauenskreise definieren, die ähnlich funktionieren wie bei sozialen Netzwerken: Man tauscht bestimmte Schlüssel aus, und nur diese könne miteinander kommunizieren.
Parallel dazu gibt es Ansätze, Lookup-Funktionen in die Instanz hineinzuverlagern. Ein verteilter Verzeichnisdienst, der über die eigenen Benutzerdaten hinausgeht, wäre der logische nächste Schritt. Die Idee eines verteilten „Telefonbuchs“ ist nicht neu, aber sie gewinnt durch die neue Generation von Datenschutzverordnungen an Reiz. Statt eines zentralen Servers würde jeder Knoten nur eine Liste derjenigen Daten bereithalten, die er tatsächlich benötigt. Der Connector wäre dann nur noch der Übergabepunkt zwischen den Knoten, kein Telefonbuch mehr. Dass ein solcher Ansatz für Nextcloud auch ein Risiko darstellt, steht auf einem anderen Blatt – das Produkt lebt schließlich von der Interoperabilität zwischen unabhängigen Instanzen. Eine radikale Dezentralisierung könnte die Suche nach Nutzern wieder enorm erschweren, weil sich keine gemeinsame Basis mehr suchen lässt.
Fazit: Ein stiller, aber wichtiger Begleiter
Der Nextcloud Lookup Server Connector ist kein Baustein, der auf der Bühne glänzt. Er erinnert eher an den Postboten, der dafür sorgt, dass der Briefkasten den richtigen Absender aufweist. Ohne ihn funktioniert die Föderation nicht richtig, weil ein zentrales Verzeichnis fehlt. Mit ihm offenbart sich aber auch der Zielkonflikt zwischen Bequemlichkeit und Datenhoheit. Administratoren, die sich der Aufgabe stellen, sollten nicht nur die technische Installation beherrschen, sondern auch die rechtlichen und organisatorischen Fragen im Blick behalten.
Am Ende bleibt eine Ansicht, die man nicht jedem Vortrag entnehmen kann: Der Lookup Server Connector ist ein Paradebeispiel dafür, wie wichtig unscheinbare Infrastrukturkomponenten in zunehmend vernetzten Cloud-Landschaften sind. Er ist klein, er arbeitet leise – aber wenn er fehlt, merkt es jeder. Und wenn er falsch konfiguriert ist, ebenfalls. Dass er sich in der Praxis meist gut schlägt, spricht für eine durchdachte Integration in die vorhandenen Systeme. Denken Sie daran, wenn Sie das nächste Mal einen Nutzer auf einer anderen Instanz über die Suche finden: Vor dieser Suche steht die Arbeit eines Connectors, der sich selten in den Feierabend-Nachrichten findet.