Wehklagen über Spam-Wellen, über unangemessene Postings, über Dauer-Repeater (Extrem-Booster) über mangelnde Berechtigungskontrolle über nicht wirklich funktionierende Inhaltswarnungen sind Teil des Fediverse. Dann auch noch das Beklagen über Zeichenbegrenzungen, unzureichende Formatierungsmöglichkeiten, eingeschränkte Umfragen, Beschränkungen mitgeschickter, oft nicht einbettbarer, sondern nur angehängter Bilder gehören auch dazu.
Mein Rat: Kommt doch ins Grid!
Mein Rat: Kommt doch ins Grid!
View article
View summary
Wehklagen über Spam-Wellen, über unangemessene Postings, über Dauer-Repeater (Extrem-Booster) über mangelnde Berechtigungskontrolle über nicht wirklich funktionierende Inhaltswarnungen sind Teil des Fediverse. Dann auch noch das Beklagen über Zeichenbegrenzungen, unzureichende Formatierungsmöglichkeiten, eingeschränkte Umfragen, Beschränkungen mitgeschickter, oft nicht einbettbarer, sondern nur angehängter Bilder gehören auch dazu.
Das Grid ist der Netzwerkverbund aller Dienste, die Zot6/Nomad als Kommunikationsprotokoll verwenden. Aktuell sind das Hubzilla, (streams) und Zap (das zwar nicht wirklich weiterentwickelt wird... es gibt aber aktuell mindestens einen Hub, der mit Zap läuft).
Innerhalb des Grid greifen nicht nur die herausragenden Möglichkeiten des Berechtigungssystems vollständig, sondern der Zugriff auf beschränkte Ressourcen wird auch noch mittels magicAuth extrem komfortabel, weil der Nutzer sich gar nicht darum kümmern muss, seine Berechtigung für den Zugriff einer Ressource nachzuweisen. Läuft automatisch.
Hinzu kommt dann aber auch noch, dass viele der Vorteile des Berechtigungssystems auch auf die Interaktion mit dem ActivityPub-Fediverse wirken, sofern man sich nicht ausschließlich auf das Grid beschränkt.
Bei Hubzilla und (streams) hat man wirklich die Möglichkeit, ganz exakt festzulegen, wie man mit anderen Nutzern im Fediverse (Kanälen) interagiert. Ich gehe hier auf die Verfahrensweise mit Hubzilla ein, die vielleicht zunächst etwas komplizierter erscheint, aber trotzdem, wenn man es verstanden hat, recht einfach ist. Ich beschränke mich deshalb, weil es ausgesprochen unwahrscheinlich ist, dass irgendwer einen (streams)-Hub findet und sich dort registriert. Hubzilla zu nutzen ist in dieser Hinsicht wesentlich einfacher.
Um seinen Stream (so nennt sich das, was bei anderen Diensten die "Timeline" heißt) sauber zu halten und Belästigungen zu vermeiden, muss man sich zunächst für eine Kanalrolle entscheiden. Foren lasse ich hier bewusst weg, denn die sind ein Spezialfall. Zur Auswahl stehen lediglich drei Varianten: Öffentlich, Persönlich und Benutzerdefiniert. Öffentlich und Persönlich sind bequem, weil einem damit einiges an Denkarbeit abgenommen wird. Allerdings beschränkt man sich damit auch in den Möglichkeiten.
Bei der Kanalrolle "Öffentlich" ist es Verbindungen (also diejenigen, die einem selbst folgen und denen man ebenfalls folg, aber auch jedem im Internet) grundsätzlich erlaubt, unsere öffentlichen Postings zu sehen (in ihrem Stream/ihrer Timeline), unser Standardprofil, unsere Verbindungen, unsere öffentlichen Dateien (Bilder, Dokumente etc.) und unsere Web- und Wikiseiten zu sehen. Außerdem dürfen Verbindungen unsere Beiträge kommentieren, liken/disliken, uns Direktnachrichten schicken, Inhalte unseres Profils liken/disliken und mit uns chatten.
Diese Rechte können wir den Verbindungen (außer wir schränken bestimmte einzelne Inhalte im Zugriff explizit ein) auch nicht verwehren.
Es fällt auf, dass wir selbst es mit diesen Berechtigungen unseren Verbindungen nicht erlauben, uns Postings zu schicken. Wir sehen damit also in unserem Stream nicht, was die Verbindung selbst öffentlich gepostet hat. Damit wäre die Verbindung also nur sowas wie ein "Follower" (wie man es von anderen Diensten kennt). Es muss also noch eine weitere Möglichkeit geben, unseren Verbindungen dieses zu erlauben, damit wir mit unserem Kanal auch ein "richtiges" Social-Network-Erlebnis haben.
Die Berechtigungen, die ich eben beschrieben habe, sind die Berechtigungen der Kanalrollen. Sie beziehen sich also auf unserem Kanal. Es gibt aber auch noch die Kontaktrolle, welche unsere Verbindungen betrifft. In dieser können zusätzliche Berechtigungen eingeräumt werden (aber keine Berechtigungen der Kanalrolle wieder entzogen werden).
Zu jeder Kanalrolle gibt es immer eine Standard-Kontaktrolle. Bei der Kanalrolle "Öffentlich" erlaubt diese Standard-Kontaktrolle unseren Verbindungen, uns ihre Beiträge in unseren Stream zu schicken. Die werden damit also auch "followed". Zusätzlich erteilt die Standard-Kontaktrolle unseren Verbindungen auch noch das Wall-to-Wall-Posting und das Spiegeln unserer Beiträge in einem anderen Kanal. Auf diese beiden Spezialfälle gehe ich jetzt hier nicht ein. Wir ignorieren sie einfach erstmal.
Ein Kanal mit der Kanalrolle "Öffentlich" verhält sich also genau so, wie man das von ganz normalen Social-Network-Accounts erwartet.
Hinweis: Alles, was wir mit einem solchen Kanal veröffentlichen, wird auch öffentlich geteilt, sofern wir dies nicht für eine einzelne Ressource explizit anders festlegen.
Bei der Kanalrolle "Persönlich" ist es grundsätzlich erlaubt, unsere öffentlichen Postings (als "Follower") und unser Standard-Profil zu sehen. Ebenso unsere öffentlich geteilten Dateien, Webseiten und Wikis. Mehr nicht!
Auch "Persönlich" hat eine spezielle Standard-Kontaktrolle. Diese erlaubt es Verbindungen zusätzlich , uns Beiträge in unseren Stream zu schicken ("Followed") und unsere Verbindungen zu sehen.
Beachte: Alles, was wir mit einem solchen Kanal veröffentlichen ist nicht öffentlich, also nur für unsere Verbindungen zu sehen, sofern wir die Ressource nicht explizit als "öffentlich" veröffentlichen. Das ist ein entscheidender Unterschied zur Kanalrolle "Öffentlich".
Das Verhalten, dass bei der Kanalrolle "Persönlich" grundsätzlich erstmal nur an Verbindungen und damit nicht-öffentlich geteilt wird, liegt nicht an der Kanalrolle und auch nicht an der Standrad-Kontaktrolle, sondern am Mechanismus der Privacy Gruppen.
Auch wenn die App "Privacy Gruppen" nicht installiert ist, verfügt jeder Kanal über eine Privacy Gruppe namens "Freunde". Alle neuen Verbindungen werden dieser Privacy Gruppe automatisch zugewiesen. Bei der Kanalrolle "Öffentlich" hat das keine direkten Auswirkungen. Sehr wohl aber bei der Kanalrolle "Persönlich". Hier ist die Privacy Gruppe "Freunde" nämlich so konfiguriert, dass alles, was wir teilen grundsätzlich nur an Mitglieder dieser Gruppe geteilt wird. Das bewirkt, dass wir nicht-öffentlich teilen, es sei denn, wir stellen das für eine einzelne Ressource explizit ein.
Die dritte Kanalrolle, "Benutzerdefiniert" ist die flexibelste und auch diejenige, die man auswählen sollte, wenn man wirklich alle Unzulänglichkeiten unterbinden möchte, die andere Fediverse-Dienste aufweisen.
"Benutzerdefiniert" bedeutet, dass man auch die Kanalrolle in allen Berechtigungen selbst einstellen kann. In der Grundeinstellung, also wenn man einen Kanal mit dieser Rolle frisch erstellt hat, entspricht die Kanalrolle des Rolle "Persönlich", erlaubt aber grundsätzlich auch, dass Dritte unsere Verbindungen sehen können. Die Standard-Verbindungsrolle entspricht 1:1 der Verbindungsrolle "Persönlich". Die Privacy-Gruppe "Freunde" ist hingegen wieder so eingestellt, dass grundsätzlich öffentlich geteilt wird.
Wer nun also von seinem Social-Network-Dienst mehr möchte, als 08/15, muss Entscheidungen treffen, also ein wenig Hirnschmalz investieren. Ohne das geht es nicht... weder bei Hubzilla, noch bei irgendeinem anderen System, denn dieses weiß ja nicht, kann ja nicht ahnen, was wir möchten. Das müssen wir schon selbst wissen oder uns klarmachen. Wer das nicht will, muss halt mit den vordefinierten Rollen leben, die auch schon vieles besser machen, als bei manchem anderen System und die -- aufgrund der vorhandenen Mechanismen -- durchaus gewisse Dinge unterbinden können.
Möchte man aber kein System "von der Stange", sind einige Vorüberlegungen und Einstellungen notwendig.
Zunächst einmal hier die einzelnen Berechtigungen, die Hubzilla zur Konfiguration anbietet:
Etliche dieser Berechtigungen erklären sich von selbst, einige sind vielleicht nicht so klar und einige wenige kann man falsch verstehen. Im Anhang gibt es eine Tabelle, in der genauer erklärt wird, was sich hinter den Berechtigungen verbirgt.
Diese Berechtigungen sind das WAS, also was andere mit Inhalten/Ressourcen unseres Kanals tun können.
Dazu gehört dann aber auch noch das WER! Damit legen wir fest, wem bestimmte Dinge erlaubt bzw. verboten sind:
Auch hier gibt es einige "Wers", die etwas näher erläutert werden müssen. Dafür gibt es ebenfalls eine kleine Tabelle im Anhang.
Die Wichtigsten Adressaten für Berechtigungen sind: "Jeder im Internet" und "Nur die, denen Du es explizit erlaubst".
Nun ist es an der Zeit, sich Gedanken darüber zu machen, was man wem denn nun erlauben möchte. Dafür arbeitet man einfach die einzelnen Berechtigungen hintereinander ab und legt die Berechtigten fest.
Im Hauptmenü (das Menü, welches sich hinter unserem Avatarbild versteckt) wählt man
Einstellungen ➔ Kanal-Einstellungen
und legt im Abschnitt Grundeinstellungen die gewünschte Kanalrolle (Channel Role) fest. Also für unsere Zwecke "Benutzerdefiniert".
![kanal-rolle.png kanal-rolle.png]()
Nun wechselt man zu Einstellungen ➔ Privacy-Einstellungen
![privacy-settings.png privacy-settings.png]()
Die Grundeinstallungen dort sind selbsterklärend und sollten nach den eigenen Wünschen festgelegt werden. Wichtig ist hier die einzige "nicht selbsterklärende" Einstellung "Enable OCAP access". Dies ermöglicht, dass Medien (Bilder etc.) auch dann in einem Thread angezeigt werden, wenn diese eigentlich im Zugriff eingeschränkt sind. Wird diese Option nicht gewählt, kann es vorkommen, dass man eingebettete Bilder in manchen Threads nicht sieht. Meine Empfehlung: Option einschalten!
Die eigentliche Einstellung der Berechtigungen, die unser Kanal einräumt, findet man unter dem Button "Benutzerdefinierte Konfiguration der Channel Role" (dies wird bei den Kanalrollen "Öffentlich" und "Persönlich" nicht angezeigt, weil man diese dort nicht ändern kann).
Es wird eine Warnung angezeigt, die zwar berechtigt ist, aber wir WISSEN ja, was wir tun wollen.
![cr-warnung.png cr-warnung.png]()
Deshalb klicken wir auf den Button "Risiko akzeptieren und weitermachen" und landen im Formular für die genannten Berechtigungen. Die können wir nun nach unseren Wünschen und nachdem wir uns Gedanken gemacht haben, entsprechend konfigurieren.
Dabei aber immer daran denken: Die Berechtigung, die wir hier erteilen, können wir generell nicht zurücknehmen. Wir können sie höchstens in Einzelfällen "übersteuern", indem wir Inhalte/Ressourcen über die Berechtigungs-Einstellungen bestimmten Verbindungen zugänglich machen.
Es ist also ausgesprochen sinnvoll, bei der Kanalrolle so wenig freizügige Berechtigungen zu vergeben, wie möglich und nur so viele, wie für den Zweck absolut nötig.
Bedenkt: Nur was Ihr für "Jeder im Internet" erlaubt, kann auch wirklich öffentlich gesehen werden. Die spezielleren Berechtigungen sind eher etwas für Spezialfälle. "Nur die, denen Du es explizit erlaubst" wirkt sich hingegen ausschließlich auf Verbindungen aus.
Bedeutet: Alles, was wirklich jeder im Internet sehen können soll, bekommt "Jeder im Internet" (bei einem typischen öffentlichen Social-Network-Kanal) sind das "Kann meinen Kanal-Stream und meine Beiträge sehen", "Kann mein Standardprofil sehen" und "Kann meine Datei- und Bilderordner sehen". Wer öffentlich Wiki- oder Webseiten anbietet, erlaubt auch das Anschauen dieser durch jeden im Internet.
Den Rest kann man dann ruhigen Gewissens auf "Nur die, denen Du es explizit erlaubst" setzen. Damit können sich die Berechtigungen nur auf die eigenen Verbindungen auswirken.
Euch muss an dieser Stelle bewusst sein, dass die Standard-Kontaktrolle sehr viele zusätzlich Berechtigungen vergibt:
![std-contactrole.png std-contactrole.png]()
Diese Kontaktrolle kann man durchaus nutzen, um ein eher "klassisches" Social-Network-Verhalten für bestimmte Verbindungen zu erhalten.
Wenn man aber wirkliche Kontrolle haben möchte, muss man sich für andere Verbindungen weitere Kontaktrollen erstellen.
Sinnvoll wäre z.B. als neuer Standard für neue Verbindungen die Rolle "Follower". Diese erstellen wir, setzen die Option "Neuen Kontakten automatisch diese Rolle zuweisen" (damit wird die Option aus der Standard-Kontaktrolle gelöscht) und geben keine weiteren Berechtigungen, außer "Darf meine Beiträge kommentieren und mögen/nicht mögen". Damit verfügen Verbindungen mit dieser Kontaktrolle nur die in der Kanalrolle vergebenen Berechtigungen plus die Möglichkeit zum Kommentieren und liken/disliken. Wenn sich jemand mit Eurem Kanal verbindet, dann verhält er sich wie ein reiner Follower. Diese Kontaktrolle ist sinnvoll, wenn Ihr es anderen gestatten möchtet, Euch zu folgen.
Wenn Ihr meint, solche "Follower" sollten auch Eure Verbindungen anschauen können, gewährt Ihr zusätzlich halt auch diese Berechtigung.
Die nächste sinnvolle Kontaktrolle könnte dann z.B. "Followed" genannt werden. Dieser Rolle räumt Ihr dann, zusätzlich zu den Berechtigungen von "Follower", noch "Kann mir die Beiträge aus seinem Kanal schicken" ein, damit Ihr auch die Beiträge der Verbindung in Eurem Stream sehen könnt. Damit es sich auch "echt" anfühlt, wären hier auch noch die Berechtigungen "Kann mir direkte Nachrichten schicken", "Kann Profile und Profilsachen mögen/nicht mögen" und "Kann mit mir chatten" praktikabel.
Diese Kontaktrolle vergebt Ihr dann, wenn Ihr selbst eine Verbindung zu einem fremden Kanal herstellt... und an Kanäle, die Euch eine Kontaktanfrage schicken und denen Ihr "zurückfolgen" möchtet.
Eine Weitere Kontaktrolle würde ich "Followed+" nennen. Die ist für Kontakte aus dem Grid, und von den owa-fähigen Deinsten Forte und Friendica. Diesen kann man die zusätzliche Berechtigung "Kann auf meiner Kanal-Seite ("wall") Beiträge veröffentlichen" erteilen (wenn man denn möchte). Das Wall-to-Wall-Posting ist eine spezielle Art, Postings zu veröffentlichen. Wen eine unserer Verbindung ein Wall-Posting auf unserem Kanal veröffentlicht, dann erscheint dieses Posting in unserem Kanalstream. Es ist also in unserem Kanal veröffentlicht.
Für gute Freunde, verwandte, Mitglieder eines Teams, Vereins etc. kann man dann, je nach Notwendigkeit noch weitere Berechtigungen vergeben und für jede erdenkliche Art von Verbindungen ganz exakt zugeschnittene Kontaktrollen erstellen.
Privacy Gruppen sind Gruppen von Verbindungen, mit denen man das Teilen von Inhalten steuern kann. Sie ähneln dem, was man bei Google+ als "Kreise" kannte und was bei Diaspora* als "Aspekte" existiert. Möchte man einen Inhalt an eine bestimmte Gruppe von Verbindungen teilen, so kann man diese Verbindungen in eine Gruppe einfügen und mit den Berechtigungs-Einstellungen festlegen, dass der Inhalt ausschließlich mit den Gruppenmitgliedern geteilt wird. Das macht eine geschlossene Gruppenkommunikation möglich.
![bereinst.png bereinst.png]()
Eine weitere praktische Anwendung von Privacy Gruppen ist das zuteilen von Kontaktrollen auf einen Rutsch. Wenn man eine Kontaktrolle in der App "Contact Roles" öffnet, kann man auswählen, dass diese Kontaktrolle allen Gruppenmitgliedern einer Privacy Gruppe zugewiesen wird. Beachte: Das wirkt sich nur auf Verbindungen aus, die sich zu diesem Zeitpunkt bereits in der Privacy Gruppe befanden. Auf später hinzugefügte Verbindungen wirkt es sich nicht aus. Hier muss man ggf. die Gruppen-Zuweisung wiederholen.
Es gibt Nutzer im Fediverse, die wirklich exzessiv "Boosten/Repeaten". Trotzdem mag man diesen Nutzern folgen, weil die wenigen (oder vielleicht nicht einmal wenigen) ihrer eigenen Postings insteressant sind und man sie in seinem Stream finden möchte. Aber es kommt zu viel "Rauschen" herein, weil halt auch zu viel wiederholt wird. Bei Hubzilla ist es kein Problem, diese Repeats loszuwerden, ohne die "echten" Postings zu verlieren. Man kann für jede Verbindung einen Filter einrichten, der z.B. Repeats der Verbindung nicht in den Stream importiert.
Dafür öffnet man aus der App "Verbindungen" heraus den Verbindungs-Editor (kleines Bleistift-Symbol) und trägt im Tab "Filter für den Inhalt" im Feld "Beiträge mit diesem Text nicht importieren" die Zeile
ein. Damit werden Repeats (Wiederholungen / Boosts) von dieser Verbindung nicht mehr in den eigenen Stream importiert.
![no-repeats.png no-repeats.png]()
Neben den eben erwähnten Kontaktfiltern gibt es auch noch Kanalfilter, die sich auf den gesamten Kanal auswirken. Auch hier könnte man z.B. die Zeile zur Repeat-Unterdrückung unterbringen. Das würde dann aber bewirken, dass gar keine Repeats mehr im Kanal erscheinen, also auch solche nicht, die vielleicht erwünscht sind.
Kanalfilter findet man unter Einstellungen ➔ Kanal-Einstellungen ➔ Beiträge mit diesem Text nicht importieren
Während bei den meisten Diensten im Fediverse der Verfasser dafür verantwortlich gemacht wird, bestimmte Inhalte hinter einer Inhaltswarnung zu verstecken, funktioniert Hubzilla genau anders herum. Hier legt der Empfänger fest, was ihn "triggern" könnte oder was ihn "nervt". Das ist eigentlich auch ausgesprochen sinnvoll, weil ich selbst am besten weiß, was ich nicht sofort in meinem Stream sehen möchte. Wenn der Absender dafür verantwortlich ist, muss er ja erahnen, was ich nicht sehen möchte... und verbirgt solche Inhalte dann zwangsweise auch vor anderen Nutzern, die davor aber gar nicht gewarnt werden möchten.
Wer sich mit Hubzilla also vor bestimmten Inhalten schützen möchte, installiert die App "NSFW". Das ist eine einfache Filter-App, in welcher man eingeben kann, bei welchen Inhalten ein Posting zunächst ausgeblendet hinter einer Schaltfläche verborgen bleibt. Es kommt also nicht darauf an, das der Absender errät, was ich nicht sehen möchte und eine Inhaltswarnung verwendet (die sich dann auch auf alle auswirkt, die seinen Beitrag anschauen), sondern darauf, dass ich als Empfänger festlege, was verborgen werden soll.
Bewege ich mich also nur im Grid und habe auch nur Verbindungen zum Grid, muss ich mich um die Befindlichkeiten anderer nicht kümmern. Sobald man aber auch Teil des Fediverse wird, hilft unseren "NSFW"-App nicht weiter, denn die meisten anderen Dienste haben diesen Mechanismus nicht. Möchten wir also rücksichtsvoll vorgehen, müssen wir doch auch für andre mitdenken und erraten, was irgendwen in der weiten Welt "triggern" könnte.
Und das Ausblenden eines solchen Eintrags verwirklichen wir dann einfach, indem wir das Zusammenfassungsfeld (Summary) im Beitragseditor z.B. mit "Inhaltswarnung" befüllen. Nun sind auch nutzer anderer Dienste "geschützt".
Nun aber ein Spezialfall:
Es ist allgemein bekannt, dass viele sich entsetzt schütteln, wenn sie in einem Posting von Dieter Bohlen angestarrt werden (mir selbst geht es nicht so... ich mag ihn... zu erklären weshalb, würde hier aber zu weit führen). Nun wollen wir ein Posting verfassen, in welchem ein Bild von D. B. eingebunden ist. Um Nutzer aus dem Grid zu schützen, müsste ich z.B. das Wort "Bohlen" im Text unterbringen, und schon wären alle "gerettet", die in "NSFW" dieses Wort als Filter haben.
Aber angenommen, wir wollen nur das Bild selbst ausblenden und ahnen, dass es Nutzer gibt, die gerne mit Holz arbeiten und deshalb das Wort "Bohlen" auch nicht als Inhaltswarnung im Filter haben. Nun, dann können wir das Bild bei Hubzilla einfach zwischen die Tags
Aber ehrlich... das soll echt nicht UNSER Problem sein. Wir können alles dafür tun, dass bestimmte Inhalte verborgen bleiben, aber nichts daran ändern, wenn andere Dienste das nicht richtig verarbeiten.
Abgesehen davon ist es möglich auch Teile eines Postings zunächst zu verbergen (BTW: beliebig viele Teile), indem man das Spoiler-Tag verwendet. Funktioniert aber zuverlässig halt nur im Grid.
Na ja, was soll man sagen?
Hubzilla packt an die 16 Millionen Zeichen. Dieser Artikel hier ist also ein Fliegenschiss mit ca. 24.000 Zeichen. ;-)
BBcode "Hubzilla-Flavour" bietet umfangreiche Textgestaltungsmöglichkeiten. Leider werden diese vom derzeitigen Beitragseditor nicht alle vereinfacht z.B. über Buttons und Dialoge angeboten. Hier müsste dringend noch nachgebessert werden (könnte mein nächstes Projekt werden). Zumindest verfügt der Editor über eine Autovervollständigung, die hilfreich ist, wenn man weiß, was die BBcode Tags bewirken.
Was Hubzilla von vielen Diensten unterscheidet ist, dass Medien wirklich in den Beitrag eingebettet werden, also an der Stelle erscheinen, wo wir sie unterbringen. Die Anzahl an Medien ist außerdem ebenfalls nicht beschränkt.
Bedenkt aber, wenn Ihr Beiträge ins Fediverse teilt, dass es Dienste gibt, die nicht nur Medien (also z.B. Bilder) hinten anhängen, sondern auch auf wenige (bei Mastodon vier) begrenzen. Es ist deshalb sinnvoll, einen Hinweis auf die tatsächliche Anzahl von Bildern hinzuweisen und dass es erforderlich sein kann, das Original-Posting auf Eurer Heimat-Instanz zu besuchen, um alle Bilder (und die auch noch korrekt eingebettet) sehen zu können. Klingt komisch, ist aber so. ;-) :-D
Kommt einfach ins Grid! Besorgt euch einen Account bei Hubzilla. Ihr könnt das ja zusätzlich zu Eurem aktuellen Fediverse-Account tun. Und importiert Eure Follower-/Following-Liste. Dafür gibt es (sofern der von Euch gewählte Hub das Addon installiert hat) inzwischen ein Addon, das die typischen Exportdateien (csv) von Mastodon und co. verarbeitet. Richtet Euren Kanal so ein, wie Ihr es euch vorstellt und nutzt es.
Es ist durchaus möglich, dass Ihr dann irgendwann immer öfter mit Hubzilla, statt mit dem ursprünglichen Dienst im Fediverse unterwegs seid. Und wenn Ihr dann auch noch Kontakte zu Nutzern im Grid habt, werdet Ihr feststellen, dass die soziale Interaktion damit noch viel komfortabler ist. Vielleicht wagt ja dann irgendwann auch die eine oder andere eurer alten Verbindungen auch den Schritt und Ihr könnt den Komfort gemeinsam genießen.
Wer?
![wer.png wer.png]()
Was?
![was.png was.png]()
Mein Rat: Kommt doch ins Grid!
Grid? Was ist das denn?
Das Grid ist der Netzwerkverbund aller Dienste, die Zot6/Nomad als Kommunikationsprotokoll verwenden. Aktuell sind das Hubzilla, (streams) und Zap (das zwar nicht wirklich weiterentwickelt wird... es gibt aber aktuell mindestens einen Hub, der mit Zap läuft).
Innerhalb des Grid greifen nicht nur die herausragenden Möglichkeiten des Berechtigungssystems vollständig, sondern der Zugriff auf beschränkte Ressourcen wird auch noch mittels magicAuth extrem komfortabel, weil der Nutzer sich gar nicht darum kümmern muss, seine Berechtigung für den Zugriff einer Ressource nachzuweisen. Läuft automatisch.
Hinzu kommt dann aber auch noch, dass viele der Vorteile des Berechtigungssystems auch auf die Interaktion mit dem ActivityPub-Fediverse wirken, sofern man sich nicht ausschließlich auf das Grid beschränkt.
Bei Hubzilla und (streams) hat man wirklich die Möglichkeit, ganz exakt festzulegen, wie man mit anderen Nutzern im Fediverse (Kanälen) interagiert. Ich gehe hier auf die Verfahrensweise mit Hubzilla ein, die vielleicht zunächst etwas komplizierter erscheint, aber trotzdem, wenn man es verstanden hat, recht einfach ist. Ich beschränke mich deshalb, weil es ausgesprochen unwahrscheinlich ist, dass irgendwer einen (streams)-Hub findet und sich dort registriert. Hubzilla zu nutzen ist in dieser Hinsicht wesentlich einfacher.
Vordefinierte Rollen oder eigene Entscheidungen
Um seinen Stream (so nennt sich das, was bei anderen Diensten die "Timeline" heißt) sauber zu halten und Belästigungen zu vermeiden, muss man sich zunächst für eine Kanalrolle entscheiden. Foren lasse ich hier bewusst weg, denn die sind ein Spezialfall. Zur Auswahl stehen lediglich drei Varianten: Öffentlich, Persönlich und Benutzerdefiniert. Öffentlich und Persönlich sind bequem, weil einem damit einiges an Denkarbeit abgenommen wird. Allerdings beschränkt man sich damit auch in den Möglichkeiten.
Bei der Kanalrolle "Öffentlich" ist es Verbindungen (also diejenigen, die einem selbst folgen und denen man ebenfalls folg, aber auch jedem im Internet) grundsätzlich erlaubt, unsere öffentlichen Postings zu sehen (in ihrem Stream/ihrer Timeline), unser Standardprofil, unsere Verbindungen, unsere öffentlichen Dateien (Bilder, Dokumente etc.) und unsere Web- und Wikiseiten zu sehen. Außerdem dürfen Verbindungen unsere Beiträge kommentieren, liken/disliken, uns Direktnachrichten schicken, Inhalte unseres Profils liken/disliken und mit uns chatten.
Diese Rechte können wir den Verbindungen (außer wir schränken bestimmte einzelne Inhalte im Zugriff explizit ein) auch nicht verwehren.
Es fällt auf, dass wir selbst es mit diesen Berechtigungen unseren Verbindungen nicht erlauben, uns Postings zu schicken. Wir sehen damit also in unserem Stream nicht, was die Verbindung selbst öffentlich gepostet hat. Damit wäre die Verbindung also nur sowas wie ein "Follower" (wie man es von anderen Diensten kennt). Es muss also noch eine weitere Möglichkeit geben, unseren Verbindungen dieses zu erlauben, damit wir mit unserem Kanal auch ein "richtiges" Social-Network-Erlebnis haben.
Die Berechtigungen, die ich eben beschrieben habe, sind die Berechtigungen der Kanalrollen. Sie beziehen sich also auf unserem Kanal. Es gibt aber auch noch die Kontaktrolle, welche unsere Verbindungen betrifft. In dieser können zusätzliche Berechtigungen eingeräumt werden (aber keine Berechtigungen der Kanalrolle wieder entzogen werden).
Zu jeder Kanalrolle gibt es immer eine Standard-Kontaktrolle. Bei der Kanalrolle "Öffentlich" erlaubt diese Standard-Kontaktrolle unseren Verbindungen, uns ihre Beiträge in unseren Stream zu schicken. Die werden damit also auch "followed". Zusätzlich erteilt die Standard-Kontaktrolle unseren Verbindungen auch noch das Wall-to-Wall-Posting und das Spiegeln unserer Beiträge in einem anderen Kanal. Auf diese beiden Spezialfälle gehe ich jetzt hier nicht ein. Wir ignorieren sie einfach erstmal.
Ein Kanal mit der Kanalrolle "Öffentlich" verhält sich also genau so, wie man das von ganz normalen Social-Network-Accounts erwartet.
Hinweis: Alles, was wir mit einem solchen Kanal veröffentlichen, wird auch öffentlich geteilt, sofern wir dies nicht für eine einzelne Ressource explizit anders festlegen.
Bei der Kanalrolle "Persönlich" ist es grundsätzlich erlaubt, unsere öffentlichen Postings (als "Follower") und unser Standard-Profil zu sehen. Ebenso unsere öffentlich geteilten Dateien, Webseiten und Wikis. Mehr nicht!
Auch "Persönlich" hat eine spezielle Standard-Kontaktrolle. Diese erlaubt es Verbindungen zusätzlich , uns Beiträge in unseren Stream zu schicken ("Followed") und unsere Verbindungen zu sehen.
Beachte: Alles, was wir mit einem solchen Kanal veröffentlichen ist nicht öffentlich, also nur für unsere Verbindungen zu sehen, sofern wir die Ressource nicht explizit als "öffentlich" veröffentlichen. Das ist ein entscheidender Unterschied zur Kanalrolle "Öffentlich".
Das Verhalten, dass bei der Kanalrolle "Persönlich" grundsätzlich erstmal nur an Verbindungen und damit nicht-öffentlich geteilt wird, liegt nicht an der Kanalrolle und auch nicht an der Standrad-Kontaktrolle, sondern am Mechanismus der Privacy Gruppen.
Auch wenn die App "Privacy Gruppen" nicht installiert ist, verfügt jeder Kanal über eine Privacy Gruppe namens "Freunde". Alle neuen Verbindungen werden dieser Privacy Gruppe automatisch zugewiesen. Bei der Kanalrolle "Öffentlich" hat das keine direkten Auswirkungen. Sehr wohl aber bei der Kanalrolle "Persönlich". Hier ist die Privacy Gruppe "Freunde" nämlich so konfiguriert, dass alles, was wir teilen grundsätzlich nur an Mitglieder dieser Gruppe geteilt wird. Das bewirkt, dass wir nicht-öffentlich teilen, es sei denn, wir stellen das für eine einzelne Ressource explizit ein.
Die dritte Kanalrolle, "Benutzerdefiniert" ist die flexibelste und auch diejenige, die man auswählen sollte, wenn man wirklich alle Unzulänglichkeiten unterbinden möchte, die andere Fediverse-Dienste aufweisen.
"Benutzerdefiniert" bedeutet, dass man auch die Kanalrolle in allen Berechtigungen selbst einstellen kann. In der Grundeinstellung, also wenn man einen Kanal mit dieser Rolle frisch erstellt hat, entspricht die Kanalrolle des Rolle "Persönlich", erlaubt aber grundsätzlich auch, dass Dritte unsere Verbindungen sehen können. Die Standard-Verbindungsrolle entspricht 1:1 der Verbindungsrolle "Persönlich". Die Privacy-Gruppe "Freunde" ist hingegen wieder so eingestellt, dass grundsätzlich öffentlich geteilt wird.
Eigene Entscheidungen
Wer nun also von seinem Social-Network-Dienst mehr möchte, als 08/15, muss Entscheidungen treffen, also ein wenig Hirnschmalz investieren. Ohne das geht es nicht... weder bei Hubzilla, noch bei irgendeinem anderen System, denn dieses weiß ja nicht, kann ja nicht ahnen, was wir möchten. Das müssen wir schon selbst wissen oder uns klarmachen. Wer das nicht will, muss halt mit den vordefinierten Rollen leben, die auch schon vieles besser machen, als bei manchem anderen System und die -- aufgrund der vorhandenen Mechanismen -- durchaus gewisse Dinge unterbinden können.
Möchte man aber kein System "von der Stange", sind einige Vorüberlegungen und Einstellungen notwendig.
Zunächst einmal hier die einzelnen Berechtigungen, die Hubzilla zur Konfiguration anbietet:
- Kann meinen Kanal-Stream und meine Beiträge sehen
- Kann mir die Beiträge aus seinem Kanal schicken
- Kann mein Standardprofil sehen
- Kann meine Verbindungen sehen
- Kann meine Datei- und Bilderordner sehen
- Kann in meine Datei- und Bilderordner hochladen/ändern
- Kann die Webseiten meines Kanals sehen
- Kann meine Wiki-Seiten sehen
- Kann Webseiten in meinem Kanal erstellen/ändern
- Kann meine Wiki-Seiten bearbeiten
- Kann auf meiner Kanal-Seite ("wall") Beiträge veröffentlichen
- Darf meine Beiträge kommentieren und mögen/nicht mögen
- Kann mir direkte Nachrichten schicken
- Kann Profile und Profilsachen mögen/nicht mögen
- Kann mit mir chatten
- Kann meine öffentlichen Beiträge in anderen Kanälen zitieren/spiegeln
- Kann meinen Kanal administrieren
Etliche dieser Berechtigungen erklären sich von selbst, einige sind vielleicht nicht so klar und einige wenige kann man falsch verstehen. Im Anhang gibt es eine Tabelle, in der genauer erklärt wird, was sich hinter den Berechtigungen verbirgt.
Diese Berechtigungen sind das WAS, also was andere mit Inhalten/Ressourcen unseres Kanals tun können.
Dazu gehört dann aber auch noch das WER! Damit legen wir fest, wem bestimmte Dinge erlaubt bzw. verboten sind:
- Jeder im Internet
- Jeder authentifizierte
- Alle Hubzilla-Mitglieder
- Jeder auf dieser Webseite
- Beliebige Verbindungen
- Angenommene Verbindungen
- Nur die, denen Du es explizit erlaubst
- Nur ich
Auch hier gibt es einige "Wers", die etwas näher erläutert werden müssen. Dafür gibt es ebenfalls eine kleine Tabelle im Anhang.
Die Wichtigsten Adressaten für Berechtigungen sind: "Jeder im Internet" und "Nur die, denen Du es explizit erlaubst".
Nun ist es an der Zeit, sich Gedanken darüber zu machen, was man wem denn nun erlauben möchte. Dafür arbeitet man einfach die einzelnen Berechtigungen hintereinander ab und legt die Berechtigten fest.
Im Hauptmenü (das Menü, welches sich hinter unserem Avatarbild versteckt) wählt man
Einstellungen ➔ Kanal-Einstellungen
und legt im Abschnitt Grundeinstellungen die gewünschte Kanalrolle (Channel Role) fest. Also für unsere Zwecke "Benutzerdefiniert".

Nun wechselt man zu Einstellungen ➔ Privacy-Einstellungen

Die Grundeinstallungen dort sind selbsterklärend und sollten nach den eigenen Wünschen festgelegt werden. Wichtig ist hier die einzige "nicht selbsterklärende" Einstellung "Enable OCAP access". Dies ermöglicht, dass Medien (Bilder etc.) auch dann in einem Thread angezeigt werden, wenn diese eigentlich im Zugriff eingeschränkt sind. Wird diese Option nicht gewählt, kann es vorkommen, dass man eingebettete Bilder in manchen Threads nicht sieht. Meine Empfehlung: Option einschalten!
Die eigentliche Einstellung der Berechtigungen, die unser Kanal einräumt, findet man unter dem Button "Benutzerdefinierte Konfiguration der Channel Role" (dies wird bei den Kanalrollen "Öffentlich" und "Persönlich" nicht angezeigt, weil man diese dort nicht ändern kann).
Es wird eine Warnung angezeigt, die zwar berechtigt ist, aber wir WISSEN ja, was wir tun wollen.

Die sorgfältig konfigurierte Kanalrolle
Deshalb klicken wir auf den Button "Risiko akzeptieren und weitermachen" und landen im Formular für die genannten Berechtigungen. Die können wir nun nach unseren Wünschen und nachdem wir uns Gedanken gemacht haben, entsprechend konfigurieren.
Dabei aber immer daran denken: Die Berechtigung, die wir hier erteilen, können wir generell nicht zurücknehmen. Wir können sie höchstens in Einzelfällen "übersteuern", indem wir Inhalte/Ressourcen über die Berechtigungs-Einstellungen bestimmten Verbindungen zugänglich machen.
Es ist also ausgesprochen sinnvoll, bei der Kanalrolle so wenig freizügige Berechtigungen zu vergeben, wie möglich und nur so viele, wie für den Zweck absolut nötig.
Bedenkt: Nur was Ihr für "Jeder im Internet" erlaubt, kann auch wirklich öffentlich gesehen werden. Die spezielleren Berechtigungen sind eher etwas für Spezialfälle. "Nur die, denen Du es explizit erlaubst" wirkt sich hingegen ausschließlich auf Verbindungen aus.
Bedeutet: Alles, was wirklich jeder im Internet sehen können soll, bekommt "Jeder im Internet" (bei einem typischen öffentlichen Social-Network-Kanal) sind das "Kann meinen Kanal-Stream und meine Beiträge sehen", "Kann mein Standardprofil sehen" und "Kann meine Datei- und Bilderordner sehen". Wer öffentlich Wiki- oder Webseiten anbietet, erlaubt auch das Anschauen dieser durch jeden im Internet.
Den Rest kann man dann ruhigen Gewissens auf "Nur die, denen Du es explizit erlaubst" setzen. Damit können sich die Berechtigungen nur auf die eigenen Verbindungen auswirken.
Die passenden Kontaktrollen
Euch muss an dieser Stelle bewusst sein, dass die Standard-Kontaktrolle sehr viele zusätzlich Berechtigungen vergibt:

Diese Kontaktrolle kann man durchaus nutzen, um ein eher "klassisches" Social-Network-Verhalten für bestimmte Verbindungen zu erhalten.
Wenn man aber wirkliche Kontrolle haben möchte, muss man sich für andere Verbindungen weitere Kontaktrollen erstellen.
"Follower"
Sinnvoll wäre z.B. als neuer Standard für neue Verbindungen die Rolle "Follower". Diese erstellen wir, setzen die Option "Neuen Kontakten automatisch diese Rolle zuweisen" (damit wird die Option aus der Standard-Kontaktrolle gelöscht) und geben keine weiteren Berechtigungen, außer "Darf meine Beiträge kommentieren und mögen/nicht mögen". Damit verfügen Verbindungen mit dieser Kontaktrolle nur die in der Kanalrolle vergebenen Berechtigungen plus die Möglichkeit zum Kommentieren und liken/disliken. Wenn sich jemand mit Eurem Kanal verbindet, dann verhält er sich wie ein reiner Follower. Diese Kontaktrolle ist sinnvoll, wenn Ihr es anderen gestatten möchtet, Euch zu folgen.
Wenn Ihr meint, solche "Follower" sollten auch Eure Verbindungen anschauen können, gewährt Ihr zusätzlich halt auch diese Berechtigung.
"Followed"
Die nächste sinnvolle Kontaktrolle könnte dann z.B. "Followed" genannt werden. Dieser Rolle räumt Ihr dann, zusätzlich zu den Berechtigungen von "Follower", noch "Kann mir die Beiträge aus seinem Kanal schicken" ein, damit Ihr auch die Beiträge der Verbindung in Eurem Stream sehen könnt. Damit es sich auch "echt" anfühlt, wären hier auch noch die Berechtigungen "Kann mir direkte Nachrichten schicken", "Kann Profile und Profilsachen mögen/nicht mögen" und "Kann mit mir chatten" praktikabel.
Diese Kontaktrolle vergebt Ihr dann, wenn Ihr selbst eine Verbindung zu einem fremden Kanal herstellt... und an Kanäle, die Euch eine Kontaktanfrage schicken und denen Ihr "zurückfolgen" möchtet.
"Followed+"
Eine Weitere Kontaktrolle würde ich "Followed+" nennen. Die ist für Kontakte aus dem Grid, und von den owa-fähigen Deinsten Forte und Friendica. Diesen kann man die zusätzliche Berechtigung "Kann auf meiner Kanal-Seite ("wall") Beiträge veröffentlichen" erteilen (wenn man denn möchte). Das Wall-to-Wall-Posting ist eine spezielle Art, Postings zu veröffentlichen. Wen eine unserer Verbindung ein Wall-Posting auf unserem Kanal veröffentlicht, dann erscheint dieses Posting in unserem Kanalstream. Es ist also in unserem Kanal veröffentlicht.
Mehr
Für gute Freunde, verwandte, Mitglieder eines Teams, Vereins etc. kann man dann, je nach Notwendigkeit noch weitere Berechtigungen vergeben und für jede erdenkliche Art von Verbindungen ganz exakt zugeschnittene Kontaktrollen erstellen.
Privacy Gruppen für genauere Steuerung
Privacy Gruppen sind Gruppen von Verbindungen, mit denen man das Teilen von Inhalten steuern kann. Sie ähneln dem, was man bei Google+ als "Kreise" kannte und was bei Diaspora* als "Aspekte" existiert. Möchte man einen Inhalt an eine bestimmte Gruppe von Verbindungen teilen, so kann man diese Verbindungen in eine Gruppe einfügen und mit den Berechtigungs-Einstellungen festlegen, dass der Inhalt ausschließlich mit den Gruppenmitgliedern geteilt wird. Das macht eine geschlossene Gruppenkommunikation möglich.

Eine weitere praktische Anwendung von Privacy Gruppen ist das zuteilen von Kontaktrollen auf einen Rutsch. Wenn man eine Kontaktrolle in der App "Contact Roles" öffnet, kann man auswählen, dass diese Kontaktrolle allen Gruppenmitgliedern einer Privacy Gruppe zugewiesen wird. Beachte: Das wirkt sich nur auf Verbindungen aus, die sich zu diesem Zeitpunkt bereits in der Privacy Gruppe befanden. Auf später hinzugefügte Verbindungen wirkt es sich nicht aus. Hier muss man ggf. die Gruppen-Zuweisung wiederholen.
Die Repeat-Hölle verlassen
Es gibt Nutzer im Fediverse, die wirklich exzessiv "Boosten/Repeaten". Trotzdem mag man diesen Nutzern folgen, weil die wenigen (oder vielleicht nicht einmal wenigen) ihrer eigenen Postings insteressant sind und man sie in seinem Stream finden möchte. Aber es kommt zu viel "Rauschen" herein, weil halt auch zu viel wiederholt wird. Bei Hubzilla ist es kein Problem, diese Repeats loszuwerden, ohne die "echten" Postings zu verlieren. Man kann für jede Verbindung einen Filter einrichten, der z.B. Repeats der Verbindung nicht in den Stream importiert.
Dafür öffnet man aus der App "Verbindungen" heraus den Verbindungs-Editor (kleines Bleistift-Symbol) und trägt im Tab "Filter für den Inhalt" im Feld "Beiträge mit diesem Text nicht importieren" die Zeile
?verb == Announceein. Damit werden Repeats (Wiederholungen / Boosts) von dieser Verbindung nicht mehr in den eigenen Stream importiert.

Kanalfilter
Neben den eben erwähnten Kontaktfiltern gibt es auch noch Kanalfilter, die sich auf den gesamten Kanal auswirken. Auch hier könnte man z.B. die Zeile zur Repeat-Unterdrückung unterbringen. Das würde dann aber bewirken, dass gar keine Repeats mehr im Kanal erscheinen, also auch solche nicht, die vielleicht erwünscht sind.
Kanalfilter findet man unter Einstellungen ➔ Kanal-Einstellungen ➔ Beiträge mit diesem Text nicht importieren
Inhaltswarnung
Während bei den meisten Diensten im Fediverse der Verfasser dafür verantwortlich gemacht wird, bestimmte Inhalte hinter einer Inhaltswarnung zu verstecken, funktioniert Hubzilla genau anders herum. Hier legt der Empfänger fest, was ihn "triggern" könnte oder was ihn "nervt". Das ist eigentlich auch ausgesprochen sinnvoll, weil ich selbst am besten weiß, was ich nicht sofort in meinem Stream sehen möchte. Wenn der Absender dafür verantwortlich ist, muss er ja erahnen, was ich nicht sehen möchte... und verbirgt solche Inhalte dann zwangsweise auch vor anderen Nutzern, die davor aber gar nicht gewarnt werden möchten.
Wer sich mit Hubzilla also vor bestimmten Inhalten schützen möchte, installiert die App "NSFW". Das ist eine einfache Filter-App, in welcher man eingeben kann, bei welchen Inhalten ein Posting zunächst ausgeblendet hinter einer Schaltfläche verborgen bleibt. Es kommt also nicht darauf an, das der Absender errät, was ich nicht sehen möchte und eine Inhaltswarnung verwendet (die sich dann auch auf alle auswirkt, die seinen Beitrag anschauen), sondern darauf, dass ich als Empfänger festlege, was verborgen werden soll.
Bewege ich mich also nur im Grid und habe auch nur Verbindungen zum Grid, muss ich mich um die Befindlichkeiten anderer nicht kümmern. Sobald man aber auch Teil des Fediverse wird, hilft unseren "NSFW"-App nicht weiter, denn die meisten anderen Dienste haben diesen Mechanismus nicht. Möchten wir also rücksichtsvoll vorgehen, müssen wir doch auch für andre mitdenken und erraten, was irgendwen in der weiten Welt "triggern" könnte.
Und das Ausblenden eines solchen Eintrags verwirklichen wir dann einfach, indem wir das Zusammenfassungsfeld (Summary) im Beitragseditor z.B. mit "Inhaltswarnung" befüllen. Nun sind auch nutzer anderer Dienste "geschützt".
Nun aber ein Spezialfall:
Es ist allgemein bekannt, dass viele sich entsetzt schütteln, wenn sie in einem Posting von Dieter Bohlen angestarrt werden (mir selbst geht es nicht so... ich mag ihn... zu erklären weshalb, würde hier aber zu weit führen). Nun wollen wir ein Posting verfassen, in welchem ein Bild von D. B. eingebunden ist. Um Nutzer aus dem Grid zu schützen, müsste ich z.B. das Wort "Bohlen" im Text unterbringen, und schon wären alle "gerettet", die in "NSFW" dieses Wort als Filter haben.
Aber angenommen, wir wollen nur das Bild selbst ausblenden und ahnen, dass es Nutzer gibt, die gerne mit Holz arbeiten und deshalb das Wort "Bohlen" auch nicht als Inhaltswarnung im Filter haben. Nun, dann können wir das Bild bei Hubzilla einfach zwischen die Tags
[spoiler][/spoiler] packen. Funktioniert prima! Nur... für Mastodon-Nutzer funktioniert das nicht. Mastodon (und viele andere Fediverse-Dienste) kennen keinen extra Spoiler. Hinzu kommt das bei vielen dieser Dienste Bilder gar nicht in ein Posting eingebunden werden, sondern als Anhang am Posting dranhängen. Selbst wenn sie das Spoiler-Tag kennen würden, würde der Empfänger das Gesicht von D. B. wieder sehen, weil es außerhalb des Postings unten dranhängt.Aber ehrlich... das soll echt nicht UNSER Problem sein. Wir können alles dafür tun, dass bestimmte Inhalte verborgen bleiben, aber nichts daran ändern, wenn andere Dienste das nicht richtig verarbeiten.
Abgesehen davon ist es möglich auch Teile eines Postings zunächst zu verbergen (BTW: beliebig viele Teile), indem man das Spoiler-Tag verwendet. Funktioniert aber zuverlässig halt nur im Grid.
Zeichenbegrenzung
Na ja, was soll man sagen?
Hubzilla packt an die 16 Millionen Zeichen. Dieser Artikel hier ist also ein Fliegenschiss mit ca. 24.000 Zeichen. ;-)
Textgestaltung
BBcode "Hubzilla-Flavour" bietet umfangreiche Textgestaltungsmöglichkeiten. Leider werden diese vom derzeitigen Beitragseditor nicht alle vereinfacht z.B. über Buttons und Dialoge angeboten. Hier müsste dringend noch nachgebessert werden (könnte mein nächstes Projekt werden). Zumindest verfügt der Editor über eine Autovervollständigung, die hilfreich ist, wenn man weiß, was die BBcode Tags bewirken.
Was Hubzilla von vielen Diensten unterscheidet ist, dass Medien wirklich in den Beitrag eingebettet werden, also an der Stelle erscheinen, wo wir sie unterbringen. Die Anzahl an Medien ist außerdem ebenfalls nicht beschränkt.
Bedenkt aber, wenn Ihr Beiträge ins Fediverse teilt, dass es Dienste gibt, die nicht nur Medien (also z.B. Bilder) hinten anhängen, sondern auch auf wenige (bei Mastodon vier) begrenzen. Es ist deshalb sinnvoll, einen Hinweis auf die tatsächliche Anzahl von Bildern hinzuweisen und dass es erforderlich sein kann, das Original-Posting auf Eurer Heimat-Instanz zu besuchen, um alle Bilder (und die auch noch korrekt eingebettet) sehen zu können. Klingt komisch, ist aber so. ;-) :-D
Fazit
Kommt einfach ins Grid! Besorgt euch einen Account bei Hubzilla. Ihr könnt das ja zusätzlich zu Eurem aktuellen Fediverse-Account tun. Und importiert Eure Follower-/Following-Liste. Dafür gibt es (sofern der von Euch gewählte Hub das Addon installiert hat) inzwischen ein Addon, das die typischen Exportdateien (csv) von Mastodon und co. verarbeitet. Richtet Euren Kanal so ein, wie Ihr es euch vorstellt und nutzt es.
Es ist durchaus möglich, dass Ihr dann irgendwann immer öfter mit Hubzilla, statt mit dem ursprünglichen Dienst im Fediverse unterwegs seid. Und wenn Ihr dann auch noch Kontakte zu Nutzern im Grid habt, werdet Ihr feststellen, dass die soziale Interaktion damit noch viel komfortabler ist. Vielleicht wagt ja dann irgendwann auch die eine oder andere eurer alten Verbindungen auch den Schritt und Ihr könnt den Komfort gemeinsam genießen.
Anhänge
Wer?

Was?

Hubzilla aus einer anderen Perspektive
Es wird einmal Zeit, Hubzilla aus einer anderen Perspektive zu betrachten!
Hubzilla wird oft als reine Fediverse-Software "angepriesen". Auch ich mache das immer wieder... "aus Gründen" (dazu gleich mehr). Und tatsächlich IST Hubzilla ja auch eine Fediverse-Software, also ein Dienst, mit dem man am großen Fediverse teilnehmen kann und mit allen Fediverse-Diensten interagieren.
Doch damit wird man der Software nicht wirklich gerecht. Denn Hubzilla ist weit mehr... bzw. eine ganz andere Serveranwendung, die halt auch die Fähigkeit, am Fediverse teilzunehmen, bietet...
Es wird einmal Zeit, Hubzilla aus einer anderen Perspektive zu betrachten!
Hubzilla wird oft als reine Fediverse-Software "angepriesen". Auch ich mache das immer wieder... "aus Gründen" (dazu gleich mehr). Und tatsächlich IST Hubzilla ja auch eine Fediverse-Software, also ein Dienst, mit dem man am großen Fediverse teilnehmen kann und mit allen Fediverse-Diensten interagieren.
Doch damit wird man der Software nicht wirklich gerecht. Denn Hubzilla ist weit mehr... bzw. eine ganz andere Serveranwendung, die halt auch die Fähigkeit, am Fediverse teilzunehmen, bietet...
View article
View summary
Es wird einmal Zeit, Hubzilla aus einer anderen Perspektive zu betrachten!
Hubzilla wird oft als reine Fediverse-Software "angepriesen". Auch ich mache das immer wieder... "aus Gründen" (dazu gleich mehr). Und tatsächlich IST Hubzilla ja auch eine Fediverse-Software, also ein Dienst, mit dem man am großen Fediverse teilnehmen kann und mit allen Fediverse-Diensten interagieren.
Doch damit wird man der Software nicht wirklich gerecht. Denn Hubzilla ist weit mehr... bzw. eine ganz andere Serveranwendung, die halt auch die Fähigkeit, am Fediverse teilzunehmen, bietet.
Hubzilla wird deswegen oft auch als Social Networking Content Management System (SN-CMS) bezeichnet. Das kommt der Sache auch wesentlich näher. Ich selbst nenne Hubzilla auch gerne die "eierlegende Wollmilchsau des freien Web".
Hubzilla ging als Neuentwicklung (Fork) aus der großartigen Software Friendica hervor, die ihrerseits von Mike Macgirvin als "Ersatz" für Facebook entwickelt wurde.
Im Jahr 2012 erkannte Mike, dass das Unterfangen, einen "Facebook-Ersatz" zu etablieren, vergebliche Liebesmüh war, nicht zuletzt wegen dessen Markdominanz und Verbreitung. Und so verlagerte er den Schwerpunkt von der reinen sozialen Vernetzung hin zu Content Management, Cloud-Diensten und Groupware.
Subsequently we stopped focusing on "social networking" as a project mission. We concentrated on providing a range of privacy respecting services that were decentralised, yet highly integrated. Our focus now is more towards content management, cloud services, and groupware than social networking. You can use the same interface to share a wiki with your basketball team as you can to share private videos with your girlfriend.
Medium: Got Zot --- Mike Macgirvin on building your own apps and protocols
Für die Entwicklung von Hubzilla (anfangs unter dem Namen red, später redmatrix) unter diesen Gesichtspunkten, entwickelte er auch ein neues Kommunikationsprotokoll mit dem Namen "Zot", wobei er großen Wert auf Privatsphäre, Spamvermeidung, ausgefeilte Zugangskontrolle und elegante Authentifizierung legte.
Als weitere Kernfunktionalität ermöglichte er die sogenannte "nomadische Identität", welche eine echte Unabhängigkeit von einem einzelnen Server ermöglicht.
The second important thing we did is provide "nomadic identity", which is also built into the protocol. In 2010--2012, the free web lost hundreds of thousands of early adopters because we had no way to easily migrate from server to server; and lots of early server administrators closed down with little or no warning. This set the free web back at least five years, because you couldn't trust your account and identity and friendships and content to exist tomorrow. Most of the other free web projects decided that this problem should be solved by import/export tools (which we're still waiting for in some cases).
Medium: Got Zot --- Mike Macgirvin on building your own apps and protocols
Trotzdem hat er die Fähigkeiten zur Verbindung mit anderen Sozialen Netzwerken weiterentwickelt und macht Hubzilla damit zu einem Dienst, der die meisten Dienste dieses Bereichs unterstützt.
This is why I've gone back to providing and improving interoperability with other protocols and projects --- even if they don't work perfectly with our core features and services. Hubzilla is currently alone when it comes to being able to see most everybody in the free web family from one place. Friendica isn't far behind, and I think postActive and Pleroma might get there in the coming months. Then we might have a chance to do something useful with our crazy creations.
Medium: Got Zot --- Mike Macgirvin on building your own apps and protocols
Inzwischen ist Hubzilla erwachsen geworden und bietet eine schier unglaubliche Zahl von Möglichkeiten, sich im freien Web zu vernetzen und es sowohl für öffentliche, als auch für private bzw. geschäftliche Netzwerke zu nutzen. Nur weiß das leider keiner. Das war wohl schon immer so...
Many times I've heard things like "I'd use the free web if they had a working events system and forums". There are projects in the free web that offer these things, but many people on Mastodon and Diaspora do not know this; and so not only do those services not retain the member, but the free web services which actually have these services don't get a chance to offer their solutions. The person goes away thinking that the free web doesn't have enough basic features for general use; when in fact only specific projects may be unable to meet their needs.
Medium: Got Zot --- Mike Macgirvin on building your own apps and protocols
Um diese "frohe Kunde" unter die Leute zu bringen, muss Hubzilla an sich erst einmal überhaupt von mehr Menschen wahrgenommen werden. Große PR-Aktionen sind nicht möglich, denn dafür sind die Mittel der Hubzilla Association nicht ausreichend. In meinen Augen ist es eine gute Möglichkeit, Hubzilla durch eine wachende Anzahl von Nutzern bekannter zu machen. Natürlich wäre es klasse, wenn sich viele finden würden, die Hubzilla nicht als reine Fediverse-Anwendung nutzen wollen, sondern für die zahlreichen anderen Zwecke, die damit möglich sind. Aber hier beißt sich die Katze wieder in den Schwanz. Bleibt also nur, sie als Fediverse-Dienst, als Alternative zu den vielen anderen Diensten zu "promoten"... für die Nutzung zu werben und die Einstiegshürden für diese Zielgruppe abzusenken. Und das ist der Grund, weshalb auch ich, wie eingangs erwähnt, Hubzilla als Fediverse-Dienst "anpreise".
Wer dann erst einmal dabei ist, entdeckt dann womöglich die zahlreichen weiteren Möglichkeiten, die Hubzilla bietet. Und wenn Hubzilla dadurch etwas populärer geworden ist, werden vielleicht auch potenzielle Nutzer darauf aufmerksam, die eigentlich etwas anderes, als einen reinen Fediverse-Dienst benötigen.
Und es ist viel möglich: Webseiten, Blogs, Shops, Foren, Wikis, (Veranstaltungs-) Kalender, Adressbücher, Cloud u.v.m.
Wer z.B. eine Cloud benötigt, die nicht "x" Extrafunktionen benötigt, sondern die Kernfunktionalität inklusive Synchronisierung oder WebDAV-Zugriff und womöglich der Dokumentbearbeitung mit Collabora, der hat genau diese Funktionen schon, wenn er über einen Hubzilla-Account verfügt.
Termine im Kalender erfassen? Und den Kalender mit anderen Kalenderanwendungen, auch auf dem mobilen Gerät synchronisieren? Mit einem Hubzilla-Account hat man diese Möglichkeit.
Und obendrauf, quasi als Gimmick, "kann Hubzilla auch noch Fediverse". Und auch in dem Bereich ist weit mehr möglich, als mit vielen anderen Diensten. Selbst Video- oder Audio-Sharing ist kein Problem. Microblogging? Klar... ist im Macroblogging (ohne Zeichenbegrenzung, umfassender Textgestaltung etc.) ja mit drin, wenn man sich auf kurze Beiträge beschränkt.
Außerdem ist Hubzilla modular erweiterbar. Wenn es eine Anwendung gibt, die Hubzilla (noch) nicht bietet, kann es mittels Addons um genau diese Funktionalität ergänzt werden.
Wer das Fediverse nicht braucht, sondern eine andere Server-Anwendung, kann mit Hubzilla als Lösung durchaus auch glücklich werden. Das ist doch mal eine ganz andere Perspektive, oder?
Ausführlicher kann man sich über die Fähigkeiten von Hubzilla im Artikel Hubzilla - die mächtige ungeschminkte Königin des Fediverse (veröffentlicht bei GNU/Linux.ch) von 𝓒𝓱𝓻𝓲𝓼 informieren. Ich empfehle es wirklich jedem, den Artikel zu lesen, denn er zeigt hervorragend, was Hubzilla auszeichnet und umreißt, was es alles kann.
Was aber, wenn jemand sowohl einen Fediverse-Account, aber auch eine andere Serveranwendung benötigt und beides trennen möchte? Hmmm... wo ist da das Problem? Bei Hubzilla benötigt man nur einen einzigen Account. Unter diesem kann man dann verschiedene Kanäle für verschiedene Zwecke anlegen und jeden Kanal genau so konfigurieren, wie man es braucht. Überdies gibt es noch den Vorteil der nomadischen Identität. Besorgt man sich einen weiteren Account bei einem weiteren Hub, dann kann man seine Kanäle dorthin klonen. Fällt nun ein Hub aus oder ist für eine Zeit gestört, stehen die Dienste auf dem anderen Hub unterbrechungsfrei weiter zur Verfügung.
Die Königsdisziplin dezentraler Dienste ist natürlich das Selbsthosten eines solchen Dienstes. Und auch da kann Hubzilla punkten. Nach meiner Erfahrung (und ich habe viele Dienste im Selbsthosting ausprobiert), ist Hubzilla eines der am einfachsten zu installierenden und zu wartenden Systeme im Fediverse. Und es geht dabei auch noch ziemlich sparsam mit den Ressourcen um (ich habe da Sachen bei anderen Diensten erlebt, die waren schier unglaublich). Mit Hubzilla geht das mit einem einfachen Webhosting-Paket, daheim auf einem Raspberry Pi, einem günstigen VPS... und es gibt auch einige wenige Hoster, die ein managed Hubzilla-Hosting anbieten (meist teurer als die zuerst genannten Möglichkeiten).
Wer nun meint, Hubzilla sei wegen der Funktionsvielfalt unglaublich kompliziert, dem kann ich nur entgegnen: "Nein, denn Du musst ja die anderen Funktionen nicht nutzen!" Hubzilla ist modular aufgebaut und erweiterbar. Alles ist ein "Kann", nichts ist ein "Muss".
Wer jetzt meint, das klingt ja alles wie "Bonfire" (was ist aus dem Projekt eigentlich geworden... man hört und sieht kaum noch was davon), der hat es richtig erfasst. Nur musste das Rad gar nicht neu erfunden werden. Das alles gibt es schon seit Juli 2012, also derzeit seit fast vierzehn Jahren.
Staccato taugt nicht für jeden Zweck...
Stolz verkünden immer mehr Organisationen und Institutionen, dass sie nun im Fediverse vertreten sind... und nahezu ausschließlich betreten sie es mit Mastodon.
Dabei ist Microblogging, die Domäne von Mastodon und einigen anderen Diensten, nicht unbedingt die beste Wahl für den Zweck, der eigentlich verfolgt wird...
Stolz verkünden immer mehr Organisationen und Institutionen, dass sie nun im Fediverse vertreten sind... und nahezu ausschließlich betreten sie es mit Mastodon.
Dabei ist Microblogging, die Domäne von Mastodon und einigen anderen Diensten, nicht unbedingt die beste Wahl für den Zweck, der eigentlich verfolgt wird...
View article
View summary
Staccato taugt nicht für jeden Zweck...

Stolz verkünden immer mehr Organisationen und Institutionen, dass sie nun im Fediverse vertreten sind... und nahezu ausschließlich betreten sie es mit Mastodon.
Dabei ist Microblogging, die Domäne von Mastodon und einigen anderen Diensten, nicht unbedingt die beste Wahl für den Zweck, der eigentlich verfolgt wird.
Microblogging ist Kurzformat-Kommunikation mit meist sehr kurzen, dafür aber häufigen Postings mit Links, Bildern oder Videos. Die typische Nutzung für Microblogging sind Echtzeit-Updates, kurze Statements, Link-Teaser, Live-Kommentare, Trend‑Monitoring und Direktdialog. Microblogging-Plattformen wie Mastodon haben natürlich ihre Stärken: Sie sind schnell, aufmerksamkeitsstark und bieten eine gute Möglichkeit für eine "virale Verbreitung" innerhalb des Fediverse. Zusätzlich ist die Einstiegshürde recht gering.
Aufgrund des Konzepts gibt es aber auch Grenzen bzw. Nachteile: Begrenzte inhaltliche Tiefe und schnelle Vergänglichkeit, sowie das Risiko von Missverständnissen.
Macroblogging hingegen meint Plattformen mit längeren Beiträgen, ausgeprägtem Community-/Gruppenmanagement und Funktionen für Events und Dokumentation. Paradebeispiele dafür sind Hubzilla und Friendica.
Typische Merkmale sind umfassende Profilseiten, Gruppen, Veranstaltungen, längere Texte, Dokumentenarchivierung, feinere Moderationswerkzeuge und mehr Kontrolle über die Daten. Sie sind besonders geeignet für tiefere Informationsvermittlung, langfristige Community‑Pflege, strukturierte Diskussionen und Veranstaltungsmanagement, und bieten bessere Archivfunktion und dauerhafte Sichtbarkeit.
Also...
Für schnelle Meldungen, Live‑Updates und Trend‑Monitoring ist Microblogging sehr gut geeignet und bietet Tempo und Reichweite innerhalb relevanter Communities.
Für ausführliche Erklärungen, offizielle Statements, Dokumentation, Veranstaltungs- und Mitgliedermanagement hingegen, eignen sich Macroblogging-Dienste wesentlich besser.
Nun mag man auf die Idee kommen, dass man für viele Zwecke, die beide Bereiche beanspruchen, dann auch zwei Fediverse-Präsenzen einrichten und pflegen müsste.... und genau hier liegt ein Denkfehler: Während man bei ausgesprochenen Microblogging-Diensten, wie z.B. Mastodon, auf die Möglichkeiten dieser Sparte festgenagelt ist, bekommt man bei Macroblogging-Diensten die umfassenderen Möglichkeiten an die Hand, kann damit aber auch Microblogging betreiben, ist also gar nicht auf eine gesonderte Plattform angewiesen.
Wer sich also überlegt, das Fediverse zu bespielen, sollte sich vorher Gedanken machen, was denn erreicht werden soll. Geht es um kurze Hinweise und ggf. Verweise auf andere (ausführlichere) Quellen, dann genügt eine Microblogging-Plattform. Für mehr sollte man dann doch eher Hubzilla oder Friendica nutzen. Der Kreis der Nutzer, die damit erreicht werden können, unterscheidet sich ja nicht von dem Kreis derer, die durch Microblogging erreicht werden können.
Und wer hofft, durch Links auf umfassendere Beiträge an anderer Stelle viele Leser zu gewinnen, der wird wahrscheinlich rasch enttäuscht und vielleicht das Fediverse wieder verlassen, weil man "da ja keine Reichweite generieren" kann.
Ja... es ist wohl tatsächlich so, dass geteilten Links nicht so oft gefolgt wird. Hier kann man aber einfach zweigleisig fahren, was einem Hubzilla sehr erleichtert. Für wiederauffindbare und strukturierte Beiträge bietet sich das Format der "Artikel" an. Diese werden jedoch nicht föderiert. Es spricht aber nichts dagegen, ein und denselben Beitrag zusätzlich auch noch als normales Posting zu teilen, sodass er föderiert wird. Das dann am besten mit einer Zusammenfassung, damit solche Postings nicht "unangenehm" bei den Microblogging-Diensten auffallen, und am Ende einfach noch mit einem Link zur Artikel-Quelle auf dem eigenen Kanal. Diese Strategie werde ich ab heute einmal ausprobieren.
Wer nicht mehr will, als "Staccato", der wird mit einem Microblogging-Dienst zufrieden sein. Wer aber die Möglichkeit für eine umfassendere Kommunikation und Informationsbereitstellung wünscht, der sollte sich die Macroblogging-Dienste anschauen... und dabei im Hinterkopf behalten, dass auch Microblogging damit möglich ist, ohne sich beim Kreis der möglichen Empfänger damit zu beschränken.
Stolz verkünden immer mehr Organisationen und Institutionen, dass sie nun im Fediverse vertreten sind... und nahezu ausschließlich betreten sie es mit Mastodon.
Dabei ist Microblogging, die Domäne von Mastodon und einigen anderen Diensten, nicht unbedingt die beste Wahl für den Zweck, der eigentlich verfolgt wird.
Microblogging ist Kurzformat-Kommunikation mit meist sehr kurzen, dafür aber häufigen Postings mit Links, Bildern oder Videos. Die typische Nutzung für Microblogging sind Echtzeit-Updates, kurze Statements, Link-Teaser, Live-Kommentare, Trend‑Monitoring und Direktdialog. Microblogging-Plattformen wie Mastodon haben natürlich ihre Stärken: Sie sind schnell, aufmerksamkeitsstark und bieten eine gute Möglichkeit für eine "virale Verbreitung" innerhalb des Fediverse. Zusätzlich ist die Einstiegshürde recht gering.
Aufgrund des Konzepts gibt es aber auch Grenzen bzw. Nachteile: Begrenzte inhaltliche Tiefe und schnelle Vergänglichkeit, sowie das Risiko von Missverständnissen.
Macroblogging hingegen meint Plattformen mit längeren Beiträgen, ausgeprägtem Community-/Gruppenmanagement und Funktionen für Events und Dokumentation. Paradebeispiele dafür sind Hubzilla und Friendica.
Typische Merkmale sind umfassende Profilseiten, Gruppen, Veranstaltungen, längere Texte, Dokumentenarchivierung, feinere Moderationswerkzeuge und mehr Kontrolle über die Daten. Sie sind besonders geeignet für tiefere Informationsvermittlung, langfristige Community‑Pflege, strukturierte Diskussionen und Veranstaltungsmanagement, und bieten bessere Archivfunktion und dauerhafte Sichtbarkeit.
Also...
Für schnelle Meldungen, Live‑Updates und Trend‑Monitoring ist Microblogging sehr gut geeignet und bietet Tempo und Reichweite innerhalb relevanter Communities.
Für ausführliche Erklärungen, offizielle Statements, Dokumentation, Veranstaltungs- und Mitgliedermanagement hingegen, eignen sich Macroblogging-Dienste wesentlich besser.
Nun mag man auf die Idee kommen, dass man für viele Zwecke, die beide Bereiche beanspruchen, dann auch zwei Fediverse-Präsenzen einrichten und pflegen müsste.... und genau hier liegt ein Denkfehler: Während man bei ausgesprochenen Microblogging-Diensten, wie z.B. Mastodon, auf die Möglichkeiten dieser Sparte festgenagelt ist, bekommt man bei Macroblogging-Diensten die umfassenderen Möglichkeiten an die Hand, kann damit aber auch Microblogging betreiben, ist also gar nicht auf eine gesonderte Plattform angewiesen.
Wer sich also überlegt, das Fediverse zu bespielen, sollte sich vorher Gedanken machen, was denn erreicht werden soll. Geht es um kurze Hinweise und ggf. Verweise auf andere (ausführlichere) Quellen, dann genügt eine Microblogging-Plattform. Für mehr sollte man dann doch eher Hubzilla oder Friendica nutzen. Der Kreis der Nutzer, die damit erreicht werden können, unterscheidet sich ja nicht von dem Kreis derer, die durch Microblogging erreicht werden können.
Und wer hofft, durch Links auf umfassendere Beiträge an anderer Stelle viele Leser zu gewinnen, der wird wahrscheinlich rasch enttäuscht und vielleicht das Fediverse wieder verlassen, weil man "da ja keine Reichweite generieren" kann.
Ja... es ist wohl tatsächlich so, dass geteilten Links nicht so oft gefolgt wird. Hier kann man aber einfach zweigleisig fahren, was einem Hubzilla sehr erleichtert. Für wiederauffindbare und strukturierte Beiträge bietet sich das Format der "Artikel" an. Diese werden jedoch nicht föderiert. Es spricht aber nichts dagegen, ein und denselben Beitrag zusätzlich auch noch als normales Posting zu teilen, sodass er föderiert wird. Das dann am besten mit einer Zusammenfassung, damit solche Postings nicht "unangenehm" bei den Microblogging-Diensten auffallen, und am Ende einfach noch mit einem Link zur Artikel-Quelle auf dem eigenen Kanal. Diese Strategie werde ich ab heute einmal ausprobieren.
Wer nicht mehr will, als "Staccato", der wird mit einem Microblogging-Dienst zufrieden sein. Wer aber die Möglichkeit für eine umfassendere Kommunikation und Informationsbereitstellung wünscht, der sollte sich die Macroblogging-Dienste anschauen... und dabei im Hinterkopf behalten, dass auch Microblogging damit möglich ist, ohne sich beim Kreis der möglichen Empfänger damit zu beschränken.
Wer trägt die Verantwortung für unsere "Kinder"? Genau... es sind die Erziehungsberechtigten, also meist die Eltern. Ihre vornehmste Pflicht ist es, die Kinder vor Schaden zu bewahren. Und deshalb ist es auch ihre Pflicht, die Kinderlein vor den "Gefahren" der Sozialen Netzwerke zu bewahren, so man denn von solchen ausgeht...
View article
View summary
Wer trägt die Verantwortung für unsere "Kinder"? Genau... es sind die Erziehungsberechtigten, also meist die Eltern. Ihre vornehmste Pflicht ist es, die Kinder vor Schaden zu bewahren. Und deshalb ist es auch ihre Pflicht, die Kinderlein vor den "Gefahren" der Sozialen Netzwerke zu bewahren, so man denn von solchen ausgeht.
Und gerade in diesem Bereich haben die Eltern auch eine größere Macht, als bei anderen drohenden Gefahren. Während z.B. der Konsum von Alkohol, Tabakwaren etc. der Schutz der Kinderchen davon abhängt, dass sie auch tatsächlich nicht von Fremden (z.B. Handel, Freunde usw.) das schädliche Zeug bekommen, hängt der Konsum solcher Medien von einem Endgerät ab. Ein Endgerät, über welches die Eltern in der Regel initial die Kontrolle haben. Ohne ein solches Gerät kein Zugriff auf potentiell schädliche Inhalte. Als Minderjähriger kann man sich ein solches Gerät inklusive notwendigem Datenvolumen schlicht nicht einfach besorgen. Es sind also immer die Erziehungsberechtigten vorgeschaltet. Und damit besteht der Hebel, um Schädliches von den Kindern fernzuhalten.
Es gibt ja sogar schon heute diverse Lösungen für eine "Parentcontrol". Wo bestünde denn nun das Problem, ein Gesetz zu schaffen, welches den Erziehungsberechtigten vorschreibt, auf den Endgeräten, die ihren Kindern zugänglich sind, eine solche Schutzsoftware zu implementieren? Ich sehe keins! Und schon wäre damit das Problem eingedämmt. Ohne dass ich als alter Mann im Internet künftig überall mein Alter nachweisen muss... mit Lösungen, die gleichzeitig meine Anonymität bzw. Pseudonymität im Netz aushebeln, mich nachverfolgbar machen, meine Daten dem Missbrauch aussetzen.
Und da wären wir schon beim Kern der Sache: Es geht ja gar nicht um den Schutz der Kinderchen! Es geht um Kontrolle, um Nachverfolgung, um die Möglichkeit zur Repression, um die Einschränkung nicht nur der Meinungs-, sondern auch der Informationsfreiheit.
oder: Der Fluch des langjährigen Linux-Nutzers
Manche Dinge gewöhnt man sich so gründlich ab, dass sie ganz in Vergessenheit geraten. Diese Erkenntnis schlug gestern am späten Abend bei mir ein...
Manche Dinge gewöhnt man sich so gründlich ab, dass sie ganz in Vergessenheit geraten. Diese Erkenntnis schlug gestern am späten Abend bei mir ein...
View article
View summary
oder: Der Fluch des langjährigen Linux-Nutzers
Manche Dinge gewöhnt man sich so gründlich ab, dass sie ganz in Vergessenheit geraten. Diese Erkenntnis schlug gestern am späten Abend bei mir ein.
Aber mal von Vorne:
Anlässlich meines Hoster-Wechsels stand vor ein paar Tagen an, etliche von mir registrierte Domains auf meinen Server bei meinem neuen Provider umzustellen. Ich bin da ganz systematisch nach Liste vorgegangen, habe die Zonen-Einträge auf die neue IP geändert und wollte dann damit beginnen, die Domains nacheinander in das YunoHost-System (YH) auf meinen neuen Server einzubinden.
Das ging aber schief! Schon bei der ersten Domain. Erst meckerte YH, es könne kein Let's Encrypt Zertifikat erstellen, dann aber zeigte vor allem die notwendige Diagnose unter YH die Fehlermeldung, dass die Domain nicht von außerhalb via http zu erreichen sei.
Gnaaah!
Ok, erstmal wieder rausgeschmissen, die Domain... vielleicht habe ich bei der DNS-Verwaltung ja was falsch eingetragen... muss ich später mal gucken.
Was steht noch an? Ja! Meinen Shorturl-Dienst muss ich auf jeden Fall auf dem neuen Server wieder verfügbar machen (den habe ich in erster Linie nicht, um URLs kürzer zu machen, sondern dafür, Links auf bestimmte Seiten zu "entkoppeln"). Also habe ich eine neue Subdomain zur Hauptdomain meines Servers (die also in YH schon drin war und perfekt funktionierte... auch mit zwei weiteren Subdomains) in der Zone eingetragen. Anschließend dann in YH die Domain neu hinzufügen. Und?
Nüscht war! Let's Encrypt brach ab (dem Log war zu entnehmen, dass es sich nicht signieren ließ, weil die Domain nicht per http erreichbar sei) und in der Diagnose stand auch wieder diese verdammte Fehlermeldung, die Domain sei nicht über http erreichbar.
Tatsächlich wurde ein http-Aufruf mit "302 Moved Temporarily" quittiert und dann auf https umgeleitet, was zum Admin-Portal meines YH führte (letzteres ist soweit normal, solange die Domain noch mit keiner App verknüpft ist).
Da YH immer auch ein selbst signiertes Zertifikat für hinzugefügte Domains erstellt, habe ich einfach einmal eine My Webapp (ohne Beilage... also ohne PHP und Datenbank) unter der Domain erstellt, um die Domain mit einer App zu verknüpfen. Ich habe dann (begründet) erwartet, dass ich beim https-Aufruf der Domain und dem Übergehen der Sicherheitswarnung im Browser wegen des selbst signierten Zertifikats auf der Platzhalter-index.html von einer frischen My Webapp lande.
Pustekuchen!
Ich landete wieder beim Login des Admin-Portals meines YH. Ebenso verhielt es sich beim http-Aufruf. Auch wieder das Portal.
Mit curl konnte ich das auch bestätigen und das Fehlverhalten war zu 100 % reproduzierbar.
Nur... bei allen anderen Domains, die ich bereits früher hinzugefügt hatte, trat dieser Effekt nicht auf. Die Diagnose blieb auch unauffällig für diese und die Aufrufe landeten natürlich bei der Anwendung für die jeweilige Domain.
Es traf also nur für die neu hinzugefügte Domain zu.
Also habe ich noch einige andere Domains, die sowieso auf der eingangs erwähnten Liste standen, probeweise hinzugefügt. Und alle kackten genauso ab, wie die erste.
Ich konnte also gar keine Domain mehr erfolgreich hinzufügen. What the fuck...?
Und dann ging sie los, die Fehlersuche. Ich habe mich geschlagene drei Tage (Tag und Nacht) mit kurzen Unterbrechungen durch die nginx-Konfigurationen auf dem Server durchgewühlt. Habe verglichen (die Konfigurationen der alten, funktionierenden Domains mit der neuen, nicht funktionierenden Domain), "gedifft" irgendwann zwischendrin ein Pythonskript gebaut, das mir in einer Baumansicht rekursiv zeigt, welche Konfigurationsdateien an welcher Stelle letztlich von der Haupt-Konfiguration aus (/etc/nginx/nginx.conf) eingebunden werden.
Mit KI-Unterstützung Tests durchgeführt... gefühlt 1.000mal die Domain entfernt (mit allen schäbigen Resten, die im System bleiben und die man manuell entfernen muss) und wieder hinzugefügt, Konfigurationsdateien geändert, angepasst... und wieder zurück und dies und das.
Schließlich konnte ich ausschließen, dass es etwas mit den Konfigurationsdateien (nginx) zu tun hat. Es gab schlicht keine Unterschiede zwischen den der alten und denen der neuen Domains. Nur... die alten funktionierten, die neuen eben nicht. Das ist doch nicht normal... spukt es in meinem Server?
Und dann kam ich auf den entscheidenden Trichter. YunoHost speichert seine interne Konfiguration nicht (vollständig) in einzelnen Dateien oder Datenbankdateien, sondern in einer In-Memory-Datenbank (redis). Und genau DA muss irgendwas schiefgegangen sein.
Vermutlich(!) bei der letzten Aktion, bevor ich irgendwann wieder Domains hinzufügen wollte, muss diese Datenbank korrumpiert worden sein.
Diese Datenbank musste also irgendwie neu initialisiert werden, in der Hoffnung, dass die Fehler dann da raus sind. Und wie am besten? Na ganz einfach: Reboot!
Und was soll ich sagen? Nach dem Reboot (das spürbar länger dauerte, als ich es in Erinnerung hatte), lief alles wieder korrekt. Die nicht funktionierenden Domains waren aller in Ordnung, Let's Encrypt Zertifikate ließen sich erstellen und es erfolgte keine ungewollte Umleitung mehr.
Reboot! Der älteste aller Lösungsversuche!
Auf die Idee bin ich schlicht gar nicht gekommen. Seit Mitte der 80er Jahre bin ich von Windows weg und nur noch mit Linux unterwegs. Unter Windows musste man ständig rebooten... damit selbst die einfachsten Installationen "abgeschlossen" werden können. Und mit Linux hat man sich dieses Zwangsverhalten dann abgewöhnt. Bei Linux ist ein Reboot (und selbst das nicht immer zwingend) notwendig, wenn man tief im System etwas verändert (z.B. durch Updates). Ansonsten kann man sich das klemmen... vielleicht ist mal der Neustart eines einzelnen Dienstes erforderlich, aber die Aus-Einschalt-Orgie kennt man nicht.
Und das ist inzwischen so tief in mir verwurzelt, dass ich gar nicht auf diese simple Idee gekommen bin.
Die drei Tage Wühlen tief in YunoHost waren trotzdem nicht völlig umsonst... ich habe auf jeden Fall etliches über das System gelernt. Und den "Neustart" habe ich auch aus der hintersten Ecke meines Gedächtnisses wieder ein wenig weiter nach vorne geholt.
Mir fallen in letzter Zeit so einige Fediverse-Instanzen auf, die in meiner Warteschlange hängenbleiben.
Also... es bleiben ja immer mal welche hängen. Zum Beispiel, wenn sie für eine gewisse Zeit nicht erreichbar sind oder irgendwas falsch konfiguriert ist.
Aber die meine ich gar nicht. Diejenigen, die ich meine sind erreichbar und anscheinend auch richtig konfiguriert. Aber sie haben sich Türsteher vor die Türe gestellt. Konkret: Anubis ...
Also... es bleiben ja immer mal welche hängen. Zum Beispiel, wenn sie für eine gewisse Zeit nicht erreichbar sind oder irgendwas falsch konfiguriert ist.
Aber die meine ich gar nicht. Diejenigen, die ich meine sind erreichbar und anscheinend auch richtig konfiguriert. Aber sie haben sich Türsteher vor die Türe gestellt. Konkret: Anubis ...
View article
View summary
Mir fallen in letzter Zeit so einige Fediverse-Instanzen auf, die in meiner Warteschlange hängenbleiben.
Also... es bleiben ja immer mal welche hängen. Zum Beispiel, wenn sie für eine gewisse Zeit nicht erreichbar sind oder irgendwas falsch konfiguriert ist.
Aber die meine ich gar nicht. Diejenigen, die ich meine sind erreichbar und anscheinend auch richtig konfiguriert. Aber sie haben sich Türsteher vor die Türe gestellt. Konkret: Anubis.
Anubis ist ein sogenanntes Web-KI-Firewall-Tool. Es dient dazu, Web-Scraper von KI-Diensten davon abzuhalten, die eigene Seite zu scrapen. Sinn und Zweck soll sein, die Seite vor massenhaften Scraping-Aktionen gleichzeitig zu schützen, die den Server dann überlasten könnten. Es wird aber kein Limit eingeführt, sondern versucht, über Challenges wirklich alle Scraper von KI-Diensten (und sicher auch anderen Diensten) komplett auszuschließen.
Eine Anfrage, welche die Challenge nicht erfüllen kann, bleibt draußen. Und das trifft offenbar auch etliche Fediverse-Dienste, wenn diese Items zustellen möchten. Das liegt daran, dass solche Instanzen oftmals keine "normalen" HTTP-Requests absenden und vor allem kein Javascript verarbeiten können. Die Challenges sind aber mit Javascript realisiert... und ohne JS schlagen sie fehl oder laufen in einen Timeout. Die Zustellung scheitert.
Wahrscheinlich sind meine Hubs und Webseiten so unwichtig, unbedeutend, unbekannt und unauffällig, dass sich die "Horden von KI-Scrapern" gar nicht zu mir verirren. Ich habe bislang jedenfalls noch keinen "Stau" durch einen Scraper-Ansturm auf meinen Servern.
Womöglich ist es aber auch eher eine abstrakte Gefahr, die auch anderen Fediverse-Diensten kaum droht... und der eigentliche Grund ist der generelle pathologische KI-Hass. Es geht also weniger um die Vermeidung von Überlastungen / Verstopfungen, als vielmehr darum, keine KI-Scraper auf der eigenen Seite zuzulassen. Eine Entscheidung, die jedem, der einen Webdienst anbietet, ja auch zusteht. Soll jeder so machen, wenn er es meint.
Problematisch wird es nur, wenn dadurch die eigentliche Funktion des Dienstes eingeschränkt oder nahezu komplett blockiert wird.
Anubis lässt sich zwar auch konfigurieren und es wäre wahrscheinlich möglich (keine Ahnung, mit wieviel Aufwand... gerade im Fediverse bekommt man ja zahlreiche Anfragen, ohne die Instanz und deren Kennung explizit vorher unbedingt zu kennen).
Es ist also anscheinend tatsächlich so, dass Fediverse-Instanzen, die sich mit Anubis "schützen", tatsächlich etliche andere Fediverse-Instanzen aussperren und damit in einer Richtung deföderieren. Vielleicht ist es den Betreibern der Instanzen ja nicht einmal bewusst. Aber sollten sie es wissen und den vermeintlichen Schutz als wichtiger bewerten, es also hinnehmen, dass ihre Instanz nicht mehr uneingeschränkt Teil des Fediverse ist, dann gehe ich entweder von Dummheit oder ideologiegetriebener Arroganz aus. Solche Instanzen landen dann künftig ganz schnell in der Liste der nicht erreichbaren Server bei meinen Hubs, damit ihre Kadaver nicht ewig in der Warteschlange vor sich hin stinken.
Lasst doch den Quatsch!
Titelbild von David Polz auf Pixabay
Keine Ahnung, ob dieser Artikel nun wirklich für andere interessant ist. Ich beschreibe hier den Umzug meines Hubzilla Hub Whoville von einem Remote-Server zu einem anderen Remote-Server. Sowas ist natürlich auch immer ausgesprochen individuell und speziell, was die Voraussetzungen betrifft. Auf der anderen Seite beschreibe ich natürlich auch etliche Schritte und Überlegungen, die für vergleichbare Umzugspläne interessant sein könnten...
View article
View summary

Keine Ahnung, ob dieser Artikel nun wirklich für andere interessant ist. Ich beschreibe hier den Umzug meines Hubzilla Hub Whoville von einem Remote-Server zu einem anderen Remote-Server. Sowas ist natürlich auch immer ausgesprochen individuell und speziell, was die Voraussetzungen betrifft. Auf der anderen Seite beschreibe ich natürlich auch etliche Schritte und Überlegungen, die für vergleichbare Umzugspläne interessant sein könnten.
Nun denn... die
Voraussetzungen
bei MIR...
Ich habe meinen Hub "Whoville" auf einem VPS bei meinem ungarischen Hoster betrieben. Aus bestimmten Gründen wollte ich ihn nun aber zu einem anderen VPS bei einem anderen Hoster umziehen.
VPS 1
Beim ursprünglichen Server, ich nenne ihn hier jetzt VPS 1, lief Hubzilla unter YunoHost. Allerdings – aus Gründen – nicht als YunoHost Hubzilla-App, sondern als manuelle Installation in einer YunoHost My_Webapp (weshalb, kann man hier nachlesen). Da der Hub nun schon recht lange lief, hat sich einiges an Daten angesammelt. So belegte er im Webroot 29.5 GB, wobei der Bärenanteil natürlich auf den Ordner "store" mit insgesamt 28.4 GB ging. Die Datenbank (MySQL) kam auf 16.3 GB. Und die letzte Backup-Datei (YunoHost Backup der My_Webapp) wog 32.4 GB.
VPS 2
Der neue Server, VPS 2, war noch recht "leer", aber bereits ebenfalls mit YunoHost "bestückt".
Selbstverständlich habe ich Zugriff auf die DNS-Einträge für die Domain "hubzilla.hu".
Ein großer Vorteil von YunoHost (neben etlichen anderen) ist, dass es Backup-Funktionen für die Apps gibt. Und ein Backup einer My_Webapp umfasst den kompletten Inhalt von Webroot, einen Datenbank-Dump (sofern es eine DB gibt), sowie System-Konfigurations-Dateien (was so unter
/etc zu finden ist), die spezifisch für die Webapp sind und die geändert wurden. Damit hatte ich in dem großen tar-Archiv also eigentlich alles, was ich benötige.Der Plan
1. Die Nutzer mit Accounts per Rundmail (Hubzilla bietet mit dem Addon "Hubwall" eine einfache Möglichkeit dafür an) über die geplante Downtime (ich habe mit mindestens drei Stunden gerechnet... es wurden sogar vier) informieren.
2. Eine
index.html für eine Wartungs-Mitteilung erstellen.3. Ein frisches Backup von My_Webapp auf VPS 1 erstellen.
4. Die DNS-Einträge für
hubzilla.hu, vor allem aber für die Subdomain des Hub hub.hubzilla.hu von der IP des VPS 1 auf die IP des VPS 2 "umbiegen" und ein wenig warten.5. Sobald die neue IP publik ist, dann die Domains mit YunoHost auf VPS 2 übernehmen und dafür sorgen, dass Let's Encrypt Zertifikate erstellt werden.
6. Danach auf VPS 2 eine My_Webapp unter der Domain
hub.hubzilla.hu installieren und die index.html (mit dem Wartungshinweis) dort zunächst "servieren".7. Nun die aktuelle Backup-Datei (tar) von VPS 1 auf VPS 2 übertragen.
8. Die Backup-Datei auf VPS 2 entpacken.
9. Den Inhalt des Backups auf VPS 2 anpassen (
.htconfig.php, Nginx- und PHP-Konfigirationsdateien).10. Die noch fehlenden Pakete (gemäß der Installationsanleitung von Hubzilla) installieren.
11. Den Datenbank-Dump aus dem Backup in die neue, noch leere DB von My_Webapp auf VPS 2 importieren.
12. Den Webroot-Inhalt des entpackten Backups nun ins neue Webroot der My_Webapp auf VPS 2 verschieben.
13. Die Konfigurationsdateien für Nginx und PHP an die entsprechenden Orte unter
/etc bei VPS 2 verschieben.14. Dienste neu starten und überprüfen, ob sie ordentlich laufen (Nginx und php-fpm) und checken, ob sie fehlerfrei gestartet wurden und laufen.
15. Wichtig! Den Cronjob einrichten.
16. Eigentlich nicht notwendig, weil Dienste ja neu gestartet, aber aus Sicherheitsgründen: Reboot von VPS 2.
17. Finger überkreuzen, Stoßgebet gen Himmel, Whoville im Browser aufrufen.
Vorüberlegungen / Vorbereitung
Die Rundmail war schnell rausgeschickt. Ich hatte mir die Nacht von Ostersonntag auf Ostermontag für den Umzug vorgesehen, weil da am wenigsten Traffic und Zugriffe auf meinen Hub zu erwarten waren. Und auch die
index.html war rasch erstellt.
Für die Übertragung der doch recht großen Backup-Datei wollte ich nicht darauf zurückgreifen, sie zunächst auf meinen lokalen Rechner zu laden und anschließend von dort aus auf den neuen Server wieder hochzuladen. Das dauert auch bei guter Anbindung erstens ziemlich lange und erzeugt zusätzliche vermeidbare Fehlerquellen (Fehler bei der Datenübertragung). Klar war also, dass ich die Datei direkt von VPS 1 zu VPS 2 übertragen wollte. Da entstand natürlich die Frage, ob mit sFTP, per SSH mit scp oder der SSH mittels rsync. Welche Vor- und Nachteile ergeben sich für meinen speziellen Zweck bei den einzelnen Methoden?
Und hier nun mein Geständnis: Selbst wenn ich bei solchen Dingen schon eigene Ideen habe, frage ich gerne die "KI" (also ein LLM). In der Frage halte ich mich dann mit meinen eigenen Gedanken zurück, um sie nicht zu beeinflussen. Und damit hole ich mir quasi eine "zweite Meinung" ein. Ich habe in der Vergangenheit die Erfahrung gemacht, dass ich auf diese Weise bestimmte Ansichten zu solchen Sachen bekomme, die mir sonst nicht so präsent waren. Das kann bei der Entscheidungsfindung durchaus helfen. Bis jetzt bin ich damit immer sehr gut gefahren. Aber das "dicke Ende" kommt noch... ich habe dafür Grok verwendet... also die "KI" von dem pöhsen Pupen, dessen Namen man nicht laut aussprechen darf (alle, die das verwerflich finden, dürfen mich gerne mal dort, wo die Sonne nie scheint und anschließend an ihrer Moral ersticken 😉😁). Ich habe in der Vergangenheit einfach die besten Erfahrungen mit genau diesem Dienst gemacht.
Für eine Übertragung mit FTP hätte ich mich erstmal wieder frisch einlesen müssen... in die Nutzung auf der Kommandozeile. Im täglichen Betrieb nutze ich ja nur Filezilla (und selten Dolphin) für solche Übertragungen. Das geht remote aber nicht einfach so. Ich hätte
scp bevorzugt. Grok empfahl mir aber, mir doch einmal die Methode mit rsync via SSH anzuschauen. Und das Argument war überzeugend... während scp nämlich nicht "resumable" ist, also bei einem Verbindungsabbruch die Datenübertragung diese nicht wieder aufnehmen kann, ist das bei rsync der Fall. Hat mich überzeugt! Und mit dem Parameter "--progress" habe ich auch ein visuelles Feedback über den Fortschritt der Übertragung, ohne andere Tools dafür einsetzen zu müssen.Ich habe dann die anderen geplanten Schritte auch noch mit Grok "durchgesprochen". Insgesamt wurde mein Plan generell "abgenickt" und als erfolgversprechend gewertet.
Umzug
1. und 2. waren ja schon erledigt...
3. War auch rasch getan ("rasch" ist relativ... das Erstellen der Backup-Datei dauerte bei der Größe auch immer schon knapp 20 Minuten auf dem alten, etwas schwachbrüstigen VPS 1). Nun lag die Datei "
20260405-225032.tar" im Backupverzeichnis meines VPS 1.4. Dann habe ich ab kurz vor 01:00 Uhr nachts die DNS-Einträge vom alten auf das neue VPS umgebogen. Ab diesem Augenblick lag Whoville also im Koma (ich hatte unmittelbar zuvor die
index.php auf VPS 1, also dem alten VPS, in _index.php umbenannt, damit in der Zeit, bis die neue IP bekannt war, nicht noch irgendwelche Aktivitäten stattfinden konnten.5. Als die Sache dann erledigt war, habe ich die beiden Domains bei YunoHost auf VPS 2 übernommen. Let's Encrypt Zertifikate inklusive.
6. Das Installieren der My_Webapp (mit PHP und MySQL-Datenbank) war rasch erledigt. Während Whoville auf VPS 1 noch mit php8.2 lief, habe ich bei der My_Webapp php8.4 ausgewählt. Die
index.html hochgeladen und nun wurde der Wartungshinweis angezeigt, wenn man Whoville aufgerufen hat.7. Dann habe ich die Backup-Datei von VPS 1 nach VPS 2 übertragen. Dafür habe ich dann, aufgrund des Hinweises und der Emofehlung von Grok rsync via SSH verwendet. Schema:
rsync -av --progress /pfad/zum/backup/backup-datei.tar.gz \
deinuser@DOMAIN-BEI-VPS2:/pfad/wohin/auf/vps2/Nach der Übertragung, die knapp 40 Minuten gedauert hat, habe ich auf VPS 2 die Backup-Datei vom Eingangsverzeichnis ins Webroot der frisch installierten My_Webapp verschoben.
8. Anschließend habe ich die Backup-Datei an Ort und Stelle entpackt. Das erzeugte ein Verzeichnis "
apps" unter welchem dann die ganzen Daten strukturiert lagen.tar -xvf 20260405-225032.tarAuch dazu habe ich wieder einmal Grok konsultiert. Mir stellte sich nämlich die Frage, wie es denn mit der Eigentümer-Eigenschaft und den Rechten aussehen mag. Auch wenn es auf VPS 2 mit YunoHost die Benutzer/Gruppen "
my_webapp_1" und "www-data" gibt, so unterscheiden sich doch die Benutzer- und Gruppen-Id's wahrscheinlich. Also zumindest für "my_webapp_1". Wie könnte ich denn sichergehen, dass die korrekten Eigentümer bei den entpackten Dateien und Verzeichnissen gesetzt sind. Grok meinte, dass wahrscheinlich Probleme wegen unterschiedelicher numerischer Id's auftreten könnte und empfahl rekursiv die Eigentümer zu setzen.Es kam aber anders (angenehmer), als befürchtet. Ich nutze ja sehr gerne und quasi schon immer den Midnight Commander (
mc) für die bequeme Dateiverwaltung auf der Konsole. Das hatte ich auf VPS 2 natürlich auch installiert. Und mc zeigte mir für die entpackten Daten tatsächlich auch die ursprünglichen Besitzer an. Aber stimmen denn nun die numerischen Id's auch überein? Tatsache! Dem war so. Beim Entpacken wurden also offensichtlich die Id's (also nur die von "my_webapp_1", die Id für "www-data" war bei beiden VPS ohnehin identisch) der Dateien und Verzeichnisse auf die aktuellen Id's von VPS 2 gesetzt. Also Benutzer sind ok. Ebenso waren die Rechte sauber übernommen. Da brauchte ich nichts zu ändern.9. Nun ging es ans Anpassen der Konfiguration. BTW: Grok ist sehr gesprächig. Es hat mit immer wieder auch gesagt, was ich denn wie anpassen müsste. Ok... das habe ich dann überlesen, denn das wusste ich ohnehin.
Zunächst war die
.htconfig.php dran. Hier musste ich das Datenbank-Passwort aktualisieren. DB-Name und DB-Benutzername waren gleich geblieben, weil ich bei beiden VPS die My_Webapp als my_webapp_1 installiert hatte.Außerdem habe ich noch den Pfad zu PHP anpassen müssen, weil ich nun ja von
php8.2 auf php8.4 umgestiegen bin:// Location of PHP command line processor
App::$config['system']['php_path'] = '/usr/bin/php8.4';Ebenfalls mussten die beiden Dateien
/etc/nginx/conf.d/hub.hubzilla.hu/my_webapp.conf und /etc/nginx/conf.d/hub.hubzilla.hu/my_webapp.d/php.conf jeweils von /var/run/php/php[b]8.2[/b]-fpm-my_webapp.sock auf /var/run/php/php[b]8.4[/b]-fpm-my_webapp.sock geändert werden.10. Wie auch bei der ursprünglichen Installation von Hubzilla in eine My_Webapp mussten noch einige Pakete installiert werden, weil sie nicht in einer Standard-Installation vorhanden waren. Der
INSTALL.txt aus der Hubzilla-Distribution kann man entnehmen, was notwendig ist. Auch das habe ich rasch erledigt.11. Nun musste nur noch die Datenbank mit dem Dump aus dem Bckup "Bevölkert" werden.
pv db.sql | mysql -u my_webapp -p my_webappDank "
pv" mit Fortschrittsbalken... hat bei der Größe neun Minuten gedauert.12. Dann habe ich den Inhalt des Backup-Webroot ins Webroot der neuen My_Webapp auf VPS 2 verschoben. Aus Bequemlichkeit mit dem Midnight Commander. Und nochmal die Besitzer und Rechte überprüft... alles ok.
13. Danach die geänderten Konfigurationsdateien (Punkt 9.) an die entsprechenden Stellen verschoben.
14. Nun die Dienste (Nginx und PHP-fpm) neu gestartet
yunohost service restart nginx
yunohost service restart php8.4-fpmund ihren Status überprüft
yunohost service status nginx
yunohost service status php8.4-fpmAlles im grünen Bereich!
15. Nun mit
crontab -e den Cronjob eingerichtet:*/10 * * * * cd /var/www/my_webapp/www && /usr/bin/php8.4 Zotlabs/Daemon/Master.php Cron > /dev/null 2>&1Und überprüft:
crontab -l16. Nachdem nun alles ordentlich aussah und ich auch keine Fehler oder Störungen feststellen konnte, habe ich die
_index.php zurück in index.php umbenannt, den Ordner "apps" mit den Resten des entpackten Backups, und, um wirklich sicherzugehen, dass alles mit den aktuellen Konfigurationen läuft, VPS 2 rebootet.17. Es war inzwischen 04:30 Uhr geworden... und ich habe Whoville im Webbrowser aufgerufen...
Jawoll! Er war da! Und ich habe herumprobiert, auch ein Testposting abgesetzt und von einem anderen Dienst (Mastodon), wo es angekommen war (Zustellungsbericht war auch ok) kommentiert, was auch wieder sauber ankam.
Ich habe bis jetzt keine Probleme festgestellt. Es ist extrem geschmeidig gelaufen.
Sicherlich habe ich einiges unnötig umständlich gemacht, aber ich war halt an verschiedenen Stellen extrem vorsichtig und "mit dem Arsch an der Wand", weil mir ein gelungener Umzug mit meinem Haupt-Hub wirklich wichtig war.
Titelbild von Moondance auf Pixabay
Ich habe mich entschlossen, den Hoster zu wechseln. Nicht, weil ich mit dem alten nicht grundsätzlich zufrieden war (immerhin habe ich acht Jahre meine Projekte dort betrieben), sondern weil ich das Gefühl hatte, dass er aus bestimmten Gründen den Service bald aufgeben würde. Und tatsächlich erhielt ich vor ein paar Tagen die Mitteilung, dass er den Dienst an einen anderen Hoster verkaufen musste.
Der neue Server läuft auch schon. YunoHost ist drauf... und erstmal nur phpMyAdmin, Webmin und snac2.
Vom Fediverse-Dienst snac bzw. snac2 hatte ich hier und da mal was aufgeschnappt, ich habe ihn mir aber nie genauer angeschaut. Bis vorgestern!
Und seit dem läuft auch meine snac2-Instanz...
Der neue Server läuft auch schon. YunoHost ist drauf... und erstmal nur phpMyAdmin, Webmin und snac2.
Vom Fediverse-Dienst snac bzw. snac2 hatte ich hier und da mal was aufgeschnappt, ich habe ihn mir aber nie genauer angeschaut. Bis vorgestern!
Und seit dem läuft auch meine snac2-Instanz...
View article
View summary

Ich habe mich entschlossen, den Hoster zu wechseln. Nicht, weil ich mit dem alten nicht grundsätzlich zufrieden war (immerhin habe ich acht Jahre meine Projekte dort betrieben), sondern weil ich das Gefühl hatte, dass er aus bestimmten Gründen den Service bald aufgeben würde. Und tatsächlich erhielt ich vor ein paar Tagen die Mitteilung, dass er den Dienst an einen anderen Hoster verkaufen musste.
Ich hab mir den dann mal angeschaut und muss sagen, dass er einen seriösen und soliden Eindruck macht. Ich werde auch bei dem bleiben, weil ich zumindest meine ungarischen Domains da weiter halten möchte.
Aber was ich sonst so am Laufen habe, das werde ich umziehen. Der Server für Hubzilla und einige wenige andere Anwendungen war inzwischen eh ziemlich am Ende der Kapazität angelangt und ich wollte ihn eigentlich schon aufstocken. Aber so, wie es aussieht, kann mir der neue Hoster nicht das bieten, was ich mir vorgestellt habe.
Durch Chris bin ich auf den Hoster Contabo aufmerksam geworden und habe ihn mit in meine Auswahlliste übernommen. Na... und nach Vergleichen und dem Einholen von Erfahrungen habe ich mich auch entschlossen, diesen Hoster künftig zu nutzen.
Der neue Server läuft auch schon. YunoHost ist drauf... und erstmal nur phpMyAdmin, Webmin und snac2.
Der Umzug des Hub Whoville steht jetzt erst am Osterwochenende an. Aber weil der neue Server deutlich "mehr PS unter der Haube hat", dachte ich mir: Du kannst ja mal wieder was ausprobieren.
Vom Fediverse-Dienst snac bzw. snac2 hatte ich hier und da mal was aufgeschnappt, ich habe ihn mir aber nie genauer angeschaut. Bis vorgestern!
Und seit dem läuft auch meine snac2-Instanz.

Was soll ich sagen? Ich finde snac2 ausgesprochen schnuffig. Er wird als "minimalistisch" bezeichnet. Tatsächlich bietet der Dienst aber eigentlich genau das, was man von einem grundlegenden ActivityPub-Dienst erwartet. Und er macht etliches wesentlich besser als die bekannten Platzhirsche.
snac2 bietet umfassende ActivityPub-Operationen, wie öffentliche und private Postings, Antworten/Kommentieren, Folgen, Liken, Boosten, Muten, Löschen und Verstecken, sowie Emoji-Reaktionen. Außerdem kann man Lesezeichen für Beiträge setzen. Dabei kommt es ohne Datenbank, ohne Javascript und ohne Cookies aus! Eine snac2-Instanz ist multiuser-fähig.
snac2 erlaubt umfassende Formatierung von Postings mittels Markdown, wodurch auch das Einbinden von Bildern innerhalb des Beitrags möglich ist.
Die enthaltene Weboberfläche ist recht minimalistisch, aber effektiv. Vor allem lässt sie sich durch Stylesheets sehr gut anpassen. meine Instanz habe ich von der schlichten Standard-Ansicht auf ein moderneres Layout gebracht. Man findet einige fertige Styles, kann aber, wenn man es vermag, halt auch eigene Styles erstellen und verwenden.
Man kann seine Identität mit einem Avatar und einem Banner-Bild verschönern, Profilinformationen hinzufügen und etliches konfigurieren.
Postings kann man mit einer Inhaltswarnung versehen, die Sichtbarkeit festlegen, die Sprache des Inhalts definieren. Attachments sind möglich, ebenso Umfragen. Eine terminierte Veröffentlichung ist ebenfalls machbar.
Man kann Hashtags folgen, bestimmte Hashtags blockieren und einen Inhaltsfilter definieren.


Als Admin wird die Konfiguration über das Kommandozeilen-Programm "snac" durchgeführt. Die Dokumentation dazu ist gut.
Die Installation mit YunoHost war völlig unproblematisch. Außerdem kann man über das Controlpanel etliche Dinge auch ohne das Kommandozeilen-Tool konfigurieren, was die Verwaltung bequemer macht.
Mein erster Eindruck war: Wow, ist das schnell!
Mein zweiter Eindruck war: Wow, ist das geschmeidig. Ich habe ja schon sehr viele Dienste ausprobiert, aber snac2 ist bisher einer der wenigen Dienste, die absolut keine Probleme bereitet, sich sofort und schnell mit anderen Kanälen zu verbinden.

Ich nutze es bis jetzt ja wirklich nur kurz, muss aber sagen, dass ich extrem positiv überrascht bin. Es macht einfach Spaß, wenn man einen schlichten und einfachen ActivityPub-Dienst haben möchte. Dabei sieht es nicht langweilig aus, wenn man den Standard-Style ersetzt.
Hinzu kommt, dass es die Mastodon-API umsetzt und damit mit allen Mastodon-Clienten genutzt werden kann. Egal ob Elk, Phanpy etc. oder z.B. die Desktop-App Tokodon von Plasma/KDE... es funktioniert prima.
Mir macht es auf jeden Fall Spaß. Und es scheint noch ordentlich weiterentwickelt zu werden... bin gespannt!
Ach ja... snac steht übrigens für: "Social Networks Are Crap". 😉😁
Die Server-Verwaltung YunoHost ist eine großartige Sache. Seinen Server mit YunoHost zu verwalten erleichtert vieles. Ein E-Mail Server ist in der Grundausstattung bereits drin, ebenso wie ein Webserver. Man muss sich nicht mit der Einrichtung und Verwaltung eines Reverse-Proxy herumschlagen, Domains sind im Handumdrehen integriert und das auch gleich mit Let's Encrypt Zertifikat, welches vom System regelmäßig rechtzeitig erneuert wird. Backups? Kein Problem! ...
View article
View summary
Die Server-Verwaltung YunoHost ist eine großartige Sache. Seinen Server mit YunoHost zu verwalten erleichtert vieles. Ein E-Mail Server ist in der Grundausstattung bereits drin, ebenso wie ein Webserver. Man muss sich nicht mit der Einrichtung und Verwaltung eines Reverse-Proxy herumschlagen, Domains sind im Handumdrehen integriert und das auch gleich mit Let's Encrypt Zertifikat, welches vom System regelmäßig rechtzeitig erneuert wird. Backups? Kein Problem!
Das Beste an YunoHost ist aber die Möglichkeit, aus einem Katalog von hunderten Server-Anwendungen, seine eigenen Dienste mit wenig Aufwand zu installieren und zu verwalten.
Der App-Katalog ist inzwischen echt gigantisch und bietet alles, was das Herz begehrt.
All diese Apps werden von ehrenamtlichen Helfern betreut, die sich um die Installations-, Deinstallations- und Update-Skripte kümmern. Und sehr viele Anwendungen werden auch echt gut betreut. Updates kommen zeitnah und Fehler werden rasch beseitigt.
Ich selbst benutze YunoHost unter anderem dafür, einen meiner Hubzilla-Hubs zu betreiben. Ursprünglich habe ich ihn als YunoHost App betrieben. Im Frühjahr 2024 aber war ich es leid, dass Updates der App immer deutlich, und zu diesem Zeitpunkt sogar drastisch hinterherhinkten. Weil ich aber die Vorteile von YunoHost schätze und ich auch noch einige andere Dienste damit betreibe, wollte ich auf Hubzilla dort auch nicht verzichten. Also habe ich Hubzilla dann "zu Fuß" installiert... in der YunoHost App "My Webapp", die einen Webserver mit PHP und Datenbank zur Verfügung stellt. Das war kein großer Aufwand und ließ sich einfach erledigen. Wenn man sich an der Installationsanleitung von Hubzilla (core/install/INSTALL.txt) hält, ist es gut hinzubekommen. Lediglich die Konfiguration des Webservers (YunoHost verwendet Nginx anstelle von Apache) muss man etwas anpassen... dann passt's schon.
Der Vorteil bei der Sache: Ich kann den Komfort von YunoHost weiter nutzen... z.B. für Backups.
Zwischenzeitlich hatte sich der Update-Rhythmus der Hubzilla App bei YunoHost aber auch wieder verbessert. Eine ganze Zeit lang kamen Updates sehr zeitnah zu den Updates des eigentlichen Projektes. Ob das immer so war, weiß ich allerdings nicht, weil ich die App seit meinem Umzug zur My Webapp nicht mehr regelmäßig daraufhin angeschaut habe. Wenn ich aber mal geschaut habe, war es ganz ok. Und das, obwohl Hubzilla bei YunoHost wohl keinen echten festen Betreuer hat.
Und so habe ich dann auch die YunoHost App wieder empfohlen, wenn jemand ohne große Kenntnisse einen eigenen Hub aufsetzen wollte.
Das muss ich aber leider revidieren. Ich kann es echt nicht mehr empfehlen! Denn inzwischen hängt die App wieder extrem hinter der Original-Version. Heute, am 3. April 2026 ist die Version der YunoHost Hubzilla App 10.6.1, während die aktuelle Hubzilla-Version schon vor gut einer Woche bei 11.2 angekommen war. Die Version der App ist also über vier Monate alt. Damit fehlen einem Hub, der als App betrieben wird, auch etliche neue Features und diverse Fehlerbereinigungen sind natürlich auch noch nicht vorhanden.
Ein, zwei, drei Wochen... ja vielleicht, wenn es ein großes Update ist meinetwegen auch ein Monat... das würde ich noch als akzeptabel ansehen. Aber vier Monate sind echt zu viel, um die App noch guten Gewissens empfehlen zu können.
Schade, es scheint auch wirklich nur daran zu liegen, dass es keinen festen Betreuer für die App gibt. Pull-Requests und Testläufe sind immer sehr schnell da. Es fehlt nur derjenige, der den Hut auf hat und die App endgültig updatet. Ich wurde auch schon einmal gefragt, ob ich das übernehmen wolle. Aber ganz ehrlich... das pack ich nicht auch noch. Es ist ja nicht damit getan, irgendwie den Daumen nach oben zu recken. Man zeichnet ja dann auch für die App und deren Korrektheit verantwortlich. Ich müsste mich also erst in die ganze App-Verwalterei, die Systematik etc. bei YunoHost einarbeiten. Und das wäre jetzt echt zu viel, auch dies noch zu übernehmen. Dafür habe ich zu viele Baustellen oder Steckenpferde. Ich hänge schon bei der Hubzilla-Doku ein wenig zurück. Und dann arbeite ich mich nebenbei auch noch immer weiter in den Code von Hubzilla ein, um vielleicht irgendwann hier oder da mal mit Kleinigkeiten aushelfen zu können. Und jetzt habe ich auch noch "Addon-Blut" geleckt... und mir vorgenommen, irgendwann in diesem Jahr ein Addon zu präsentieren, mit welchem man WordPress-Artikel (samt Kommentaren) aus einer Sicherungsdatei in die Hubzilla Artikel-App zu übernehmen.
Dazu noch jeden Monat auch noch ein Hubzilla-Workshop, den irgendwie auch überwiegend ich vorbereiten muss. Dann auch noch meine eigenen "Werke für und zur Hubzilla-Dokumentation".
Jetzt aktuell steht bei mir auch noch ein geordneter Server-Umzug samt Hosterwechsel an, der sich über Wochen hinziehen wird.
Ach ja... und Frühling is'. Und Garten! Und am Haus ist auch immer was zu tun. Der Offenstall braucht dringend Reparaturen. Die Pferdkoppel braucht einen neuen Zaun. Dann unser Hunde-Altersheim... das möchte auch Zeit haben.
Also um die YunoHost App kann ich mich persönlich beim besten Willen nicht auch noch kümmern.
Aber so schlimm ist das auch nicht, denn Hubzilla geht ja prima mit YunoHost in der My Webapp. Und Hubzilla ist wirklich recht einfach zu installieren. Den grundsätzlichen Weg hab ich ja aufgeschrieben: Hubzilla mit einem YunoHost-Server betreiben / Running Hubzilla with a YunoHost server. Das sollte also jeder hinbekommen. Und für Fragen (auch dazu) bin ich jederzeit offen. Gerne auch im Kanal "Pepes Hubzilla-Sprechstunde" (hubzillasprechstunde@hub.hubzilla.hu).
Fazit: Hubzilla mit YunoHost? Ja! Aber nicht mit der Hubzilla-App, sondern mit der App "My Webapp"!
Die Server-Verwaltung YunoHost ist eine großartige Sache. Seinen Server mit YunoHost zu verwalten erleichtert vieles. Ein E-Mail Server ist in der Grundausstattung bereits drin, ebenso wie ein Webserver. Man muss sich nicht mit der Einrichtung und Verwaltung eines Reverse-Proxy herumschlagen, Domains sind im Handumdrehen integriert und das auch gleich mit Let's Encrypt Zertifikat, welches vom System regelmäßig rechtzeitig erneuert wird. Backups? Kein Problem! ...
View article
View summary
Die Server-Verwaltung YunoHost ist eine großartige Sache. Seinen Server mit YunoHost zu verwalten erleichtert vieles. Ein E-Mail Server ist in der Grundausstattung bereits drin, ebenso wie ein Webserver. Man muss sich nicht mit der Einrichtung und Verwaltung eines Reverse-Proxy herumschlagen, Domains sind im Handumdrehen integriert und das auch gleich mit Let's Encrypt Zertifikat, welches vom System regelmäßig rechtzeitig erneuert wird. Backups? Kein Problem!
Das Beste an YunoHost ist aber die Möglichkeit, aus einem Katalog von hunderten Server-Anwendungen, seine eigenen Dienste mit wenig Aufwand zu installieren und zu verwalten.
Der App-Katalog ist inzwischen echt gigantisch und bietet alles, was das Herz begehrt.
All diese Apps werden von ehrenamtlichen Helfern betreut, die sich um die Installations-, Deinstallations- und Update-Skripte kümmern. Und sehr viele Anwendungen werden auch echt gut betreut. Updates kommen zeitnah und Fehler werden rasch beseitigt.
Ich selbst benutze YunoHost unter anderem dafür, einen meiner Hubzilla-Hubs zu betreiben. Ursprünglich habe ich ihn als YunoHost App betrieben. Im Frühjahr 2024 aber war ich es leid, dass Updates der App immer deutlich, und zu diesem Zeitpunkt sogar drastisch hinterherhinkten. Weil ich aber die Vorteile von YunoHost schätze und ich auch noch einige andere Dienste damit betreibe, wollte ich auf Hubzilla dort auch nicht verzichten. Also habe ich Hubzilla dann "zu Fuß" installiert... in der YunoHost App "My Webapp", die einen Webserver mit PHP und Datenbank zur Verfügung stellt. Das war kein großer Aufwand und ließ sich einfach erledigen. Wenn man sich an der Installationsanleitung von Hubzilla (core/install/INSTALL.txt) hält, ist es gut hinzubekommen. Lediglich die Konfiguration des Webservers (YunoHost verwendet Nginx anstelle von Apache) muss man etwas anpassen... dann passt's schon.
Der Vorteil bei der Sache: Ich kann den Komfort von YunoHost weiter nutzen... z.B. für Backups.
Zwischenzeitlich hatte sich der Update-Rhythmus der Hubzilla App bei YunoHost aber auch wieder verbessert. Eine ganze Zeit lang kamen Updates sehr zeitnah zu den Updates des eigentlichen Projektes. Ob das immer so war, weiß ich allerdings nicht, weil ich die App seit meinem Umzug zur My Webapp nicht mehr regelmäßig daraufhin angeschaut habe. Wenn ich aber mal geschaut habe, war es ganz ok. Und das, obwohl Hubzilla bei YunoHost wohl keinen echten festen Betreuer hat.
Und so habe ich dann auch die YunoHost App wieder empfohlen, wenn jemand ohne große Kenntnisse einen eigenen Hub aufsetzen wollte.
Das muss ich aber leider revidieren. Ich kann es echt nicht mehr empfehlen! Denn inzwischen hängt die App wieder extrem hinter der Original-Version. Heute, am 3. April 2026 ist die Version der YunoHost Hubzilla App 10.6.1, während die aktuelle Hubzilla-Version schon vor gut einer Woche bei 11.2 angekommen war. Die Version der App ist also über vier Monate alt. Damit fehlen einem Hub, der als App betrieben wird, auch etliche neue Features und diverse Fehlerbereinigungen sind natürlich auch noch nicht vorhanden.
Ein, zwei, drei Wochen... ja vielleicht, wenn es ein großes Update ist meinetwegen auch ein Monat... das würde ich noch als akzeptabel ansehen. Aber vier Monate sind echt zu viel, um die App noch guten Gewissens empfehlen zu können.
Schade, es scheint auch wirklich nur daran zu liegen, dass es keinen festen Betreuer für die App gibt. Pull-Requests und Testläufe sind immer sehr schnell da. Es fehlt nur derjenige, der den Hut auf hat und die App endgültig updatet. Ich wurde auch schon einmal gefragt, ob ich das übernehmen wolle. Aber ganz ehrlich... das pack ich nicht auch noch. Es ist ja nicht damit getan, irgendwie den Daumen nach oben zu recken. Man zeichnet ja dann auch für die App und deren Korrektheit verantwortlich. Ich müsste mich also erst in die ganze App-Verwalterei, die Systematik etc. bei YunoHost einarbeiten. Und das wäre jetzt echt zu viel, auch dies noch zu übernehmen. Dafür habe ich zu viele Baustellen oder Steckenpferde. Ich hänge schon bei der Hubzilla-Doku ein wenig zurück. Und dann arbeite ich mich nebenbei auch noch immer weiter in den Code von Hubzilla ein, um vielleicht irgendwann hier oder da mal mit Kleinigkeiten aushelfen zu können. Und jetzt habe ich auch noch "Addon-Blut" geleckt... und mir vorgenommen, irgendwann in diesem Jahr ein Addon zu präsentieren, mit welchem man WordPress-Artikel (samt Kommentaren) aus einer Sicherungsdatei in die Hubzilla Artikel-App zu übernehmen.
Dazu noch jeden Monat auch noch ein Hubzilla-Workshop, den irgendwie auch überwiegend ich vorbereiten muss. Dann auch noch meine eigenen "Werke für und zur Hubzilla-Dokumentation".
Jetzt aktuell steht bei mir auch noch ein geordneter Server-Umzug samt Hosterwechsel an, der sich über Wochen hinziehen wird.
Ach ja... und Frühling is'. Und Garten! Und am Haus ist auch immer was zu tun. Der Offenstall braucht dringend Reparaturen. Die Pferdkoppel braucht einen neuen Zaun. Dann unser Hunde-Altersheim... das möchte auch Zeit haben.
Also um die YunoHost App kann ich mich persönlich beim besten Willen nicht auch noch kümmern.
Aber so schlimm ist das auch nicht, denn Hubzilla geht ja prima mit YunoHost in der My Webapp. Und Hubzilla ist wirklich recht einfach zu installieren. Den grundsätzlichen Weg hab ich ja aufgeschrieben: Hubzilla mit einem YunoHost-Server betreiben / Running Hubzilla with a YunoHost server. Das sollte also jeder hinbekommen. Und für Fragen (auch dazu) bin ich jederzeit offen. Gerne auch im Kanal "Pepes Hubzilla-Sprechstunde" (hubzillasprechstunde@hub.hubzilla.hu).
Fazit: Hubzilla mit YunoHost? Ja! Aber nicht mit der Hubzilla-App, sondern mit der App "My Webapp"!
Conversation Features
Loading...
Loading...
Login
PepeCyBs Welt
pcw@hub.hubzilla.hu
Mein Blog PepeCyB's Welt - Pepes Gedanken, das Fediverse und mehr…
Categories
Archives

