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...

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.tar

Auch 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_webapp

Dank "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-fpm

und ihren Status überprüft

yunohost service status nginx
yunohost service status php8.4-fpm

Alles 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>&1

Und überprüft: crontab -l

16. 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

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! ...

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"!

Heute trinke ich mir zur Feier des Tages mal einen Pálinka (was selten vorkommt)...

Auf den Tag genau zehn Jahre ist es nun her (28. Februar 2016), dass ich meine ersten Schritte mit Hubzilla gemacht habe...

Heute trinke ich mir zur Feier des Tages mal einen Pálinka (was selten vorkommt)...

Auf den Tag genau zehn Jahre ist es nun her (28. Februar 2016), dass ich meine ersten Schritte mit Hubzilla gemacht habe. Fragt mich bitte nicht nach der genauen Version... muss irgendwas um die 1 herum gewesen sein. Damals war das Hubzilla-Universum nur das Grid, denn ActivityPub war noch nicht implementiert. Ich hatte mir dann einen Hub ausgesucht und wollte mich registrieren, aber das hat nicht wirklich geklappt, weshalb ich einen eigenen Hub auf Uberspace installierte, was aufgrund einer im Netz vorhandenen Anleitung sehr einfach war. So war ich von Anfang an also auch Hubzilla-Admin.

Am 13. März 2016 veröffentlichte ich dann auch einen ersten Artikel zu Hubzilla: Schon wieder was neues? Hubzilla.

Denn ich war begeistert von den Möglichkeiten dieses Netzwerks und der Software. Und ich bin seit dem auch nie wieder wirklich von Hubzilla weggekommen. Zwar habe ich etliche Dienste als "Gast" auf fremden Instanzen, aber sehr oft auch auf selbst gehosteten Instanzen ausprobiert, aber es hat mich immer wieder zu Hubzilla zurückgezogen... und ich hatte auch immer(!) einen eigenen Hub am Laufen.

Anfangs hatte ich viele Kontakte zu Diaspora-Nutzern (weil Hubzilla die Verbindung durch ein Addon erlaubte) und zu etlichen Hubzilla-Kanälen. Die große Welt des Fediverse erschloss sich dann im Sommer 2017, als Hubzilla –zusätzlich zum Protokoll Zot – auch noch ActivityPub implementierte, was es möglich machte, sich mit den (damals noch wenigen) Diensten zu verbinden, die auch schon ActivityPub verwendeten (Pleroma war das wohl und an Herbst 2017 kam dann Mastodon hinzu, auf welches viele GNU Social Nutzer umgestiegen waren). Von da an ging die Post ab.

Aktuell habe ich mit meinem Hauptkanal Der Pepe (Hubzilla) ⁂ 114 Zot6/Nomad-Verbindungen, zwei RSS-Verbindungen und 212 ActivityPub-Verbindungen. Diaspora-Kontakte habe ich keine mehr.

Über die Jahre habe ich mir einiges an Wissen zu Hubzilla angeeignet und versuche, dieses Wissen auch weiterzugeben und auch für Einsteiger möglichst verständlich aufzubereiten.

Im Sommer 2024 habe ich dann begonnen, die hubzilla-interne Hilfe, also die eingebaute Dokumentation grundlegend zu überarbeiten (sie war wirklich sehr veraltet) und neu aufzubauen. Nebenbei pflege ich auch noch meine Hubzilla KnowledgeDB, die Informationen noch einmal anders aufbereitet und auch Themen behandelt, die im Manual nicht oder nur in beschränktem Umfang vorkommen. Und für die Nutzung von Hubzilla als Content Management System habe ich auch eine Online-Dokumentation begonnen, die hoffentlich helfen kann, auch andere Dinge, als nur Social Media mit Hubzilla zu machen.

Und obwohl ich nun schon so lange "mit Hubzilla rummache", entdecke ich trotzdem immer wieder Möglichkeiten und Funktionen, die ich bislang nicht kannte. Das geht übrigens nicht nur mir so, sondern sogar die Entwickler stolpern ab und an über Dinge, die ihnen vorher unbekannt waren. Gerade kürzlich entdeckte Harald Eilertsen (einer der Entwickler) einen "Experten-Modus" für die Warteschlangenverwaltung (was natürlich sofort in der KnowledgeDB landete und auch ins Manual kommt), was Jupiter Rowland zu einem Kommentar veranlasste, der jetzt auf meiner Kanalseite prangt:

Hubzilla is when even the main devs keep discovering hidden features they knew nothing about.
Quelle: Jupiter Rowland auf Hubzilla

Ende 2024 wurde ich dann Mitlied der Hubzilla Association, der Organisation, welche die Entwicklung, Förderung und Verbreitung von Hubzilla unterstützt und bei der Pflege der Dokumentation und der Website hilft. Sie betreibt auch die Projekt-Webseite hubzilla.org und verschiedene Support-Kanäle, wie z.B. das "berühmte" (und absolut empfehlenswerte) Hubzilla Support Forum.



Auch wenn Hubzilla heute immer noch "unter dem Radar" fliegt, ist es das System meiner Wahl. Ich schätze es wegen der kontinuierlichen und unaufgeregten Weiterentwicklung. Gerade hat z.B. ein echtes Hammer-Feature Einzug gehalten: die Integration von Collabora über das neue WOPI-Addon. Damit ist die Bearbeitung von Cloud-Inhalten extrem komfortabel geworden und eine Zusammenarbeit wesentlich einfacher, als über den Umweg z.B. über die Wiki-Funktion. Fehler werden schnell ausgemerzt und der Support ist in der wundervollen Gemeinschaft rund um Hubzilla einfach hervorragend.

Im Rückblick waren es zehn aufregende Jahre, Jahre die Spaß gemacht haben und Jahre, die Lust auf weitere zehn Jahre mit Hubzilla machen.

Und falls jetzt jemand neugierig geworden ist: Probiert es einfach einmal aus... Join Hubzilla

Heute bin ich über einen Artikel bei wordpress.org (genauer bei Make WordPress Core … das WordPress Developer Blog) gestolpert [...]

Heute bin ich über einen Artikel bei wordpress.org (genauer bei Make WordPress Core … das WordPress Developer Blog) gestolpert:

AI as a WordPress Fundamental (arch)

Ist das deren Ernst? WordPress soll also in absehbarer Zeit komplett KI-durchseucht werden?

Ok… aber ohne mich!

Ich habe zu dem, was alle Welt „KI“ nennt, eine ausgesprochen ambivalente Einstellung. Generell finde ich das eine wahnsinnig spannende Entwicklung, die man auch – das eigene Hirn eingeschaltet gelassen – durchaus nutzbringend einsetzen kann. Die immer mehr um sich greifende Faulheit aber, führt dazu, dass irgendwie die Tendenz besteht, sich das Denken nahezu völlig abnehmen zu lassen. Und überall bekommt man diese „KI“ inzwischen aufgedrückt. Immer mehr nehmen das auch an und verlassen sich auf Algorithmen, die eine Intelligenz vortäuschen und gerne auch mal enttäuschen. Das gehe ich nicht mit!

Ich selbst nutze das, was „KI“ genannt wird, auch. Aber als bewusste Entscheidung und als Unterstützung meiner eigentlichen Arbeit (nicht, um mir die Arbeit abnehmen zu lassen). Wenn ich Artikel (insbesondere in der Dampfdruck-Presse) schreibe, zu denen ich recherchieren muss, dann frage ich anfangs auch häufig ein LLM. Einfach, um Anhaltspunkte zu bekommen. Manches LLM nennt mir sogar weiterführende Links, wenn ich gezielt danach frage. Das ist schon eine nette Ausgangsposition. Solche Links verfolge ich dann auch und lese mir das, was hinter den Links steckt, aber selbst durch. Und trotz dieser recht neuen Einstiegs-Routine gehe ich dann letztlich doch wieder so vor, wie ich es schon immer gemacht habe. Ich bemühe echte Suchmaschinen, die ich mit möglichst geeigneten Suchbegriffen meist dazu bewegen kann, mir wirklich passende Ergebnisse (als Links… auf Zusammenfassungen kann ich echt verzichten) aufzuzählen. Und die verfolge ich dann. Ich nutze mein Hirn, denn der Artikel, den ich später aus den Informationen füttere, trägt ja auch meinen Namen (als Verfasser).

Bei Artikelbildern bin ich da sogar etwas freizügiger. Ich benutze, weil ich persönlich der Meinung bin, in meinem Blog sollten Artikel immer ein Titelbild haben (sieht in der Übersicht allein schon einfach stimmiger aus… mein Blog, mein persönlicher Geschmack), in letzter Zeit öfter einmal KI-Bildgeneratoren. Die meisten Artikelbilder haben aber sowieso rein „dekorativen“ Zweck. Sie sollen einen Bezug zum Inhalt des Artikels haben, sie sind aber nicht erforderlicher Teil des Artikels. Jeder Artikel „funktioniert“ auch ohne das Bild.

Es ist bei mir so, dass ich meist schon eine konkrete Idee habe, wie das Titelbild aussehen soll. In Ermangelung der künstlerischen Fähigkeiten habe ich früher lange nach freien Bildern und Grafiken gesucht und diese sehr oft auch mit meinen (besseren) Fähigkeiten mit Gimp nachbearbeitet oder kombiniert. Ich schaue auch heute noch, ob ich etwas finde oder ich versuche, mich selbst doch irgendwie künstlerisch zu betätigen und selbst etwas zu zaubern. Aber wenn ich nichts finde, weil die Idee in meinem Kopf zu speziell ist, dann lasse ich die KI ran und schaue, ob mich das Ergebnis überzeugt. Allerdings gebe ich mir bei der Erstellung des Prompts auch wirklich Mühe und versuche das gewünschte Ergebnis möglichst detailliert zu beschreiben. Bekomme ich dann womöglich das, was ich mir vorgestellt habe, bearbeite ich es aber nicht selten selbst noch nach.

Ich setze also KI in Maßen ein, um mir einige Arbeiten zu erleichtern oder um vielleicht noch besseres Futter für meine Artikel zu bekommen. Das mache ich aber 1. außerhalb von WordPress (im Fall der Dampfdruck-Presse) und 2. nur wenn ich es für angebracht oder erforderlich halte.

Ohnehin arbeite ich die meiste Zeit für meine Artikel außerhalb von WordPress. Ich schreibe inzwischen so ziemlich alles in Markdown… also nicht nur Artikel, sondern wirklich das Meiste, was ich so schreibe. Dafür nutze ich Typora (für das ich schon vor etlichen Jahren eine Lizenz erworben habe, die sich inzwischen mehr als gelohnt hat). Und so verfasse ich meine Artikel (so wie diesen hier) mit Typora in Markdown.



Bildbearbeitung inklusive Skalierung: Gimp!



Zeichnungen: Inkscape oder LibreOffice Draw.




Und dann lese ich oben stehenden Artikel und muss da Passagen ertragen, wie etwas diese:

Stellen Sie sich vor, jeder einzelne Entwickler würde mit KI-Fähigkeiten ausgestattet, ohne sich mit den Komplexitäten der KI-Integration auseinandersetzen zu müssen. Was wäre, wenn der Entwickler einfach etwas wie Folgendes tun würde

$$image = Ai_Client::prompt( ‚Erstelle ein Bild, das den Inhalt dieses Beitrags schön widerspiegelt‘ )
->with_text($post_content)
->generate_image();

So einfach ist das. Mehr ist nicht erforderlich, um mit der KI zu interagieren. Man könnte alles erstellen, von einfachen interaktiven Tools bis hin zu leistungsstarken Agenten. Wenn KI für WordPress von grundlegender Bedeutung ist und im Ökosystem eingesetzt wird, gibt es einfach keinen Konkurrenten, der mithalten kann. (Anmerkung: Dieser Code ist nicht nur eine Idee, sondern Realität! Es handelt sich um den WP AI Client, der für WordPress 7.0 vorgeschlagen wird!

Gruselig! Horror! Da fehlt nur noch ein Prompt, der einen Artikel (also den für die Bilderzeugung erforderlichen Inhalt) auch ohne Zutun zu einem vorgegebenen Thema erstellt. Am besten noch vollautomatisch anhand einer Themenliste… und die kann man sich womöglich auch noch zu einem Kernthema von der KI erstellen lassen… unter Einbeziehung der ermittelten Trends.

Dann braucht es echt kein Blog mehr, denn ein Blog ist immer auch ein persönliches „Tagebuch“ oder eine persönliche „Kladde“. Doch wenn immer mehr Dinge von einer vermeintlichen maschinellen „Intelligenz“ ohne das Zutun des Betreibers erledigt wird, dann ist da nichts „persönliches“ mehr dran. Dann ist es ein Produkt ohne menschliche Note. Fehlen nur noch die rein automatischen virtuellen Leser, die KI-generierte Kommentare abgeben… und schon gibt es ein echtes Paralleluniversum.

Nun, wer da hinein möchte… nur zu… Reisende soll man nicht aufhalten.

Aber diese Reise findet ohne mich statt!

Und wenn WordPress in absehbarer Zeit zu einem KI-Monster mutiert (auch wenn ich diese Features ja vielleicht nicht nutzen müsste), dann wird es seinen Weg auch ohne mich gehen müssen. Allein schon deshalb, weil ich nicht möchte, dass irgendwer denkt, ich lasse mir meine Inhalte nun von einer KI schreiben.

Und womit werde ich das dann tun? Na klar: mit Hubzilla!

Schließlich habe ich ja kürzlich angefangen, ein Online-Buch zu dem Thema zu schreiben (kann auch schon gelesen werden: Hubzilla – das Social Network CMS) und außerdem hatte ich ja schon einmal begonnen, die Dampfdruck-Presse damit umzusetzen (Hubzilla-DDP) und pflege inzwischen alle neuen Artikel dort ein.

Wenn ich den Schritt gehe, dann wird das ein echter Kraftakt mit enormem Zeitaufwand. 1.074 Artikel und etliche Seiten müssten dann konvertiert werden… inklusive der 2.475 Kommentare. Wie ich das realisiere, weiß ich noch nicht. Aber wenn es erforderlich wird, weil WordPress diesen Schritt geht, dann tu ich das.

Dann halt nur noch Hubzilla auch als CMS!

Denn das hier

AI is an industry shift, quickly becoming a cornerstone of the next generation of technology. For WordPress to grow into the next phase it’s critical that AI become a fundamental part of WordPress itself, and for this to succeed everyone has a role to fulfill.

können die sich dorthin stecken, wo die Sonne nie hinscheint!

Henning Uhle hat sich auch damit befasst: WordPress-KI? Habt ihr Lack gesoffen?


Titelbild: Bearbeitung des Bildes von Seanbatty auf Pixabay

Im Zusammenhang mit Hubzilla liest man immer wieder vom "Grid".

Was ist damit denn gemeint? ...

Im Zusammenhang mit Hubzilla liest man immer wieder vom "Grid".

Was ist damit denn gemeint?

Ganz einfach: Als Grid wird das gesamte Netzwerk von Servern bezeichnet, welche untereinander mit dem Kommunikationsprotokoll Nomad/Zot6 kommunizieren. Das ist vergleichbar mit der Bezeichnung "Fediverse", welches für das Netzwerk aller Server steht, die mit dem Kommunikationsprotokoll ActivityPub kommunizieren.

Erzeugt man also einen Kanal auf einem Hubzilla-Hub, so ist man in diesem Moment Teil des Grid. Die Kommunikation und vor allem die Interaktionsmöglichkeiten im Grid sind groß und umfassender, als die im Fediverse. Erst wenn man in seinem Hubzilla-Kanal das ActiviyPub Protokoll aktiviert, ist der Kanal auch Teil des Fediverse. Während die Urfassung von Hubzilla, damals noch unter dem Namen red bzw. Redmatrix, mit dem Protokoll Zot im Juli 2012 veröffentlicht wurde, hielt das Protokoll ActivityPub erst am 18.07.2017 Einzug in Hubzilla (am 03.09.2017 zog Mastodon, welches am 16.03.2026 released wurde, mit ActivityPub nach).

Dass Hubzilla so lange ohne und derzeit noch ohne generell aktiviertes ActivityPub daherkommt, hat historische Gründe und liegt im Zweck der Software begründet.

Es wurde und wird als

Hubzilla – Community-Server

bezeichnet und wurde ursprünglich mit

Groupware neu gedacht und neu erfunden. Verbinden und verknüpfen Sie dezentrale Web-Communities.

beschrieben.

Und weiter...

Was sind Hubz?
Hubz sind unabhängige, universell einsetzbare Websites, die nicht nur mit ihren Mitgliedern und Besuchern verbunden sind, sondern auch untereinander, um persönliche Nachrichten und andere Informationen auszutauschen.
Dadurch können Hub-Mitglieder auf jedem Hub alles sicher und privat mit jedem auf jedem Hub – überall – teilen oder, wenn gewünscht, Inhalte öffentlich mit jedem im Internet teilen.
Hubzilla ist die Server-Software, die dies ermöglicht. Es handelt sich um eine ausgeklügelte und einzigartige Kombination aus einem Open-Source-Content-Management-System und einem dezentralen Identitäts-, Kommunikations- und Berechtigungs-Framework sowie einer Protokollsuite, die unter Verwendung gängiger Webserver-Technologie (PHP/MySQL/Apache und beliebte Varianten) erstellt wurde. Das Endergebnis ist ein Maß an Systemintegration, Datenschutzkontrolle und Kommunikationsfunktionen, das Sie weder in einem Content-Management-System noch in einem dezentralen Kommunikationsnetzwerk für möglich gehalten hätten. Es bringt auch ein neues Maß an Zusammenarbeit und Datenschutz ins Web und führt das Konzept des persönlichen „Single Sign-On” für Webdienste im gesamten Internet ein.

Schließlich noch...

Hubzilla-Hubs sind

• dezentralisiert
• von Natur aus sozial
• optional mit anderen Hubs vernetzt
• datenschutzfähig (Datenschutzausnahmen gelten im gesamten Internet für jede registrierte Identität auf jedem kompatiblen Hub)

Mögliche Website-Anwendungen sind

• dezentrale Social-Networking-Knoten
• persönlicher Cloud-Speicher
• Datei-Dropboxen
• Verwaltung der Kommunikation und Aktivitäten von Organisationen
• Zusammenarbeit und gemeinschaftliche Entscheidungsfindung
• Websites für kleine Unternehmen
• Öffentliche und private Medien-/Dateibibliotheken
• Blogs
• Veranstaltungswerbung
• Feed-Aggregation und -Wiederveröffentlichung
• Foren
• Dating-Websites
• So ziemlich alles, was Sie auf einem traditionellen Blog oder einer Community-Website tun können, aber besser tun könnten, wenn Sie es einfach mit anderen Websites verbinden oder Dinge privat über Website-Grenzen hinweg teilen könnten.

Quelle: hubzilla-1.12

Sehr viel Zitat – sorry... aber damit erklärt sich, als was Hubzilla ursprünglich gedacht war und auch immer noch gedacht ist. Es handelt sich letztlich um eine Content Management Software (CMS), die auch Social Networkig (Macro- und Microblogging inklusive) erlaubt. Bis zum Einzug von ActivityPub war die Föderation auf das Grid (also alle Hubzilla-Hubs) und auf alle Server, welche das Diaspora Federation Protokoll sprachen (also alle Diaspora-Pods), beschränkt. Als sich dann ActivityPub als das verbindende Protokoll aller anderen Dienste herauskristallisierte, wurde Hubzilla um eben diese Protkoll erweitert. Es kann aber auch, wenn man AP nicht benötigt, weiterhin nur mit Nomad/Zot6 genutzt werden.

Ich bewerbe Hubzilla ja meistens als Fediverse-Software mit ganz besonderen Eigenschaften. Und das hat auch einen Grund. Oder mindestens zwei. Einmal ist Hubzilla wirklich hervorragend für die Teilnahme am Fediverse geeignet und wartet mit vielen Features auf, die andere Dienste nicht bieten. Und zweitens kann Hubzilla nur erfolgreich werden, wenn es von mehr und mehr Nutzern verwendet wird. Ja, und das sind erstmal Menschen, die ins Fediverse wollen oder mehr im Fediverse machen wollen.

Die andere und eigentliche Zielgruppe, nämlich diejenigen, die ein CMS benötigen, sind nicht so leicht zu erreichen und für Hubzilla zu begeistern. Man kann es durchaus auch anstatt WordPress oder Ghost verwenden und hat dabei noch den Vorteil, dass die Hubs im Grid schon miteinander verbunden sind und interagieren können (was bei WordPress- und Ghost-Servern untereinander nicht möglich ist). Die Anbindung an das Fediverse kann dann aber (wie es ja bei WordPress und Ghost auch der Fall ist) zugeschaltet werden. Damit wird aus Hubzilla ein echtes Fediverse CMS, also ein Social-Networking CMS.

Es ist an der Zeit, Hubzilla als CMS bekannter zu machen und Ein- bzw. Umsteigern die Nutzung zu erklären und zu erleichtern.

Fortsetzung zu Individuelle Anpassungen mit dem PDL-Editor (Einsteiger)

Eine Digitaluhr im simplen Text-Format in die Seitenleiste schieben und umständlich ein Hubzilla-Menü zu bauen... das ist jetzt nicht die "Hohe Schule" der Hubzilla-Gestaltung. Und auch nicht besonders schick und modern...

Fortsetzung zu Individuelle Anpassungen mit dem PDL-Editor (Einsteiger)

Eine Digitaluhr im simplen Text-Format in die Seitenleiste schieben und umständlich ein Hubzilla-Menü zu bauen... das ist jetzt nicht die "Hohe Schule" der Hubzilla-Gestaltung. Und auch nicht besonders schick und modern. Die Beispiele aus dem Artikel sollten nur dem grundlegenden Verständnis der Seitengestaltung bei Hubzilla dienen.

Das Thema ist auch kaum vollumfassend abzuhandeln. In diese Artikel hier gehe ich auch nur beispielhaft auf die Möglichkeiten ein und ich kann vielleicht Anstöße zu neuen Ideen geben, wie sich Nutzer ihr eigenes Hubzilla zusammenbauen können, ohne mit Admin-Rechten irgendetwas zu installieren.

Im ersten Teil habe ich ja gezeigt, wie man mit der App "Webseiten" ein Menü erstellt und dieses im PDL-Editor in die Seitenleiste packen kann... etwas umständlich und so eigentlich auch nicht vorgesehen.

Die Optik eines solchen Menüs ist ohnehin nicht sonderlich ansprechend und tut damit auch nichts gegen den Vorwurf, Hubzilla würde mit seinem Standard-Theme "Redbasic" doch recht altbacken aussehen.

Sinnvoller und auch so vorgesehen ist die Gestaltung mit selbst erstellten Blöcken. Nutzt man ein moderneres Theme, so passt sich die Optik auch halbwegs an das Theme an. So richtig schick wird es aber erst, wenn man auf ein modernes Framework zurückgreift.

Voraussetzungen

Voraussetzung für all die Dinge, die ich hier einmal vorführen möchte, sind die installierten Apps "PDL-Editor" und "Webseiten" und die Freigabe für Code für den Kanal, den man aufpeppen möchte.

Sofern man nicht selbst der Administrator ist, muss man für den letzten Punkt den Hub-Administrator kontaktieren und ihn bitten, Code für den eigenen Kanal zuzulassen. Für den Admin ist das nur ein einfacher Klick. Am besten schreibt man dem Admin bei der Bitte um Freischaltung auch gleich, wofür man das benötigt.

Sind diese Voraussetzungen geschaffen, die Apps also installiert und der Code erlaubt, kann es auch gleich losgehen.

Bootstrap und/oder W3.CSS

Die meisten Themes für Hubzilla bieten entweder ein Subset oder teilweise zumindest das Basis-Stylesheet von Bootstrap. Möchte man aber die Fähigkeiten von Bootstrap umfassend für die Gestaltung nutzen, ist es sinnvoll, das Framework auch original einzubinden.

Das funktioniert mit dem Inhaltstyp "HTML" auch völlig problemlos. Man muss nur führend im Block (gilt natürlich auch für Webseiten, wenn man sie so erstellen möchte) Bootstrap einbinden:

<link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css"   rel="stylesheet">`

<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/js/bootstrap.bundle.min.js"></script>

Damit bringt man dann allerdings eine Fremdquelle mit ein. Nun ist Bootstrap nicht extrem groß (aktuell 8,3 MB), weshalb es sich anbietet, es einfach in der eigenen Hubzilla-Cloud vorzuhalten. Dazu legt man sich am besten im Wurzelverzeichnis der eigenen Cloud ein Verzeichnis bootstrap an, in welches man dann den Inhalt der Bootstrap-Distribution hochlädt.

Eingebunden wird es dann mit

<link href="https://<URL_des_Hub>/cloud/<Kanal>/bootstrap/css/bootstrap.min.css"   rel="stylesheet">`

<script src="https://<URL_des_Hub>/cloud/<Kanal>/bootstrap/js/bootstrap.bundle.min.js"></script>

Ich persönlich nutze aber auch sehr gerne das W3.CSS Framework, weil es ohne Javascript-Bibliothek auskommt und wesentlich kompakter ist (24,2 KB).

Auch dieses Framework muss man am Beginn eines Blocks einbinden:

<link rel="stylesheet" href="https://www.w3schools.com/w3css/5/w3.css">

Oder man lädt w3.css herunter, packt es z.B. in ein Verzeichnis css in der eigenen Cloud und bindet es mit

<link rel="stylesheet" href="https://<URL_des_Hub>/cloud/<Kanal>/css/w3.css">

ein.

Blöcke

Blöcke werden von der App "Webseiten" zur Verfügung gestellt. Sie dienen dazu, wiederholt benutzbare Inhalte aufzunehmen, welche man dann über den Blocknamen in Webseiten, Webseiten-Layouts oder aber auch in die Seitenlayouts von Hubzilla einbinden kann.

Der Vorteil ist, dass selbst erstellte Blöcke im ITEM-Bereich des PDL-Editors zur Verfügung stehen und per Drag-and-Drop an die passende Stelle geschoben werden können.

Ein Block kann so ziemlich "alles" beinhalten. Und man kann ihn mit verschiedenen Inhaltstypen erstellen.

Es stehen die Inhaltstypen

• bbCode
• HTML
• Markdown
• Text (plain Text)
• Comanche-Layout
• PHP

zur Auswahl.

bbCode erlaubt zwar keine Einbindung eines Web-Frameworks, dafür bietet es spezielle Auszeichnungen für hubzilla-spezifische Dinge.

HTML ist der universellste Inhaltstyp, sofern man sich mit HTML auskennt. Mit einem HTML-Block kann man auch die erwähnten Frameworks nutzen und tolle Effekte und Funktionen einsetzen.

Markdown eignet sich für formatierte Texte, ist also eher etwas für Beitrags-Inhalte und weniger für Blöcke, die man z.B. in die Seitenleiste einer Ansicht packt. Verwenden kann man es aber schon dafür.

(Plain) Text, also reiner, unformatierter Text, ist die einfachste Variante, gibt aber für unsere Zwecke nichts her.

Die Comanche-Layout Auszeichnungssprache ist für den Einsatz für die Dinge, welche hier behandelt werden auch nicht sinnvoll.

PHP hingegen kann man durchaus nutzen, wenn man dynamische Inhalte erzeugen möchte. Setzt allerdings das Verständnis und die Fähigkeit zum Programmieren voraus.

Ich werde jetzt hier fast ausschließlich Blöcke im HTML-Format einsetzen, weil damit die größte Flexibilität gegeben ist.

Beispiel 1: Navigationsleiste für die Kanalseite

Und jetzt fange ich einmal mit einem konkreten Beispiel an: Eine Navigationsleiste, die ich ganz oben im Inhaltsbereich der Kanalansicht einbauen möchte. Ich möchte damit Besuchern meiner Kanalseite eine einfache Navigation zu wesentlichen Bereichen meines Kanals ermöglichen. So sollen sie mit einem Klick, ohne länger zu suchen, auf meine Artikelseite, zu meinen Karten, zu meinem Wiki, meiner Galerie und zu meinem öffentlichen Kalender gelangen können. Damit es auch noch wirklich schick aussieht, gibt es als ersten Navigationspunkt eine Logo-Grafik des Hubs, die bei Anklicken zur Hub-Beschreibung führt.



Zunächst habe ich mir für den "Home-Button" eine passende Grafik gebaut, die transparenten Hintergrund hat und zur Schriftgröße der weiteren Buttons passt (100 x 24 Pixel):



Die Navigationsleiste realisiere ich in diesem Fall mit W3.CSS. Außerdem mach ich es noch ein wenig bunt, indem ich die Hover-Farbe für die Buttons auf verschiedene Standard-Farben des Frameworks festlege.

Den Block erstelle ich mit dem Block-Editor der App "Webseiten". Als Namen habe ich "wnavbar" festgelegt. Als Inhaltstyp

<link rel="stylesheet" href="https://klacker.org/cloud/pepecyb/css/w3.css">

<div class="w3-bar w3-border w3-light-grey">
  <a href="https://klacker.org/page/pepecyb/about" class="w3-bar-item w3-button"><img src="https://klacker.org/cloud/pepecyb/whoville/whoville-logo.png" alt=""></a>
  <a href="https://klacker.org/articles/pepecyb" class="w3-bar-item w3-button w3-hover-green">Artikel</a>
  <a href="https://klacker.org/cards/pepecyb" class="w3-bar-item w3-button w3-hover-blue">Karten</a>
  <a href="https://klacker.org/wiki/pepecyb" class="w3-bar-item w3-button w3-hover-teal">Wikis</a>
  <a href="https://klacker.org/gallery/pepecyb" class="w3-bar-item w3-button w3-hover-purple">Galerie</a>
  <a href="https://klacker.org/cal/pepecyb" class="w3-bar-item w3-button w3-hover-red">Kalender</a>
</div>

Anschließend muss der Block im PDL-Editor noch an die oberste Stelle des Inhaltsbereichs im MODUL "channel" geschoben und die Änderungen mit Klick auf den Button "APPLY" übernommen werden.



Nicht schlecht für den Anfang, oder?

Beispiel 2: Nochmal das Menü aus dem ersten Teil - aber besser

Im ersten Einführungsteil hatte ich ja ein Menü zu Artikeln von mir als Beispiel gebastelt. Allerdings nicht als Block, sondern als Hubzilla-Menü, welches man nur umständlich mit dem PDL-Editor einbauen kann:



Im Endeffekt ist ein natives Hubzilla-Menü nichts anderes als eine Liste von Links. Und eine Link-Liste kann man auch ohne die Menü-Funktion erstellen.

Für diese Beispiel jetzt, erstelle ich wiederum ein Menü zu einigen (drei) Artikeln meines Kanals. Allerdings als Link-Liste.

Der HTML-Code für den entsprechenden Block sieht dann z.B. so aus:

<a href="https://klacker.org/articles/pepecyb/hhowama">Hubzilla-Häppchen: Hubzilla-Magie - OpenWebAuth / MagicAuth</a><br>
<a href="https://klacker.org/articles/pepecyb/folhsh2">Hubzilla: Hashtags folgen - Variante 2</a><br>
<a href="https://klacker.org/articles/pepecyb/irrungenwirrungen">Irrungen und Wirrungen - Hubzilla-Accounts, -Kanäle, -Profile</a>

Hier einfach als einzelne Links untereinander mit dem <br>-Tag (nicht schön und elegant).

Sieht so aus:



Oder vielleicht besser als unsortierte Liste?

<ul><li><a href="https://klacker.org/articles/pepecyb/hhowama">Hubzilla-Häppchen: Hubzilla-Magie - OpenWebAuth / MagicAuth</a></li>
<li><a href="https://klacker.org/articles/pepecyb/folhsh2">Hubzilla: Hashtags folgen - Variante 2</a></li>
<li><a href="https://klacker.org/articles/pepecyb/irrungenwirrungen">Irrungen und Wirrungen - Hubzilla-Accounts, -Kanäle, -Profile</a></li></ul>

Sieht schon etwas besser aus:



In die Kanalseite eingebaut (und mit einem Titel versehen):



Nett! Aber... Nett ist die kleine Schwester von Scheiße! 😉😂

Also packen wir mal ein wenig Schnick und Schnack vom W3.CSS Framework dazu:

<link rel="stylesheet" href="https://klacker.org/cloud/pepecyb/css/w3.css">

<ul class="w3-ul w3-card-4 w3-pale-green" style="width:100%">
<li><a href="https://klacker.org/articles/pepecyb/hhowama">Hubzilla-Häppchen: Hubzilla-Magie - OpenWebAuth / MagicAuth</a></li>
<li><a href="https://klacker.org/articles/pepecyb/folhsh2">Hubzilla: Hashtags folgen - Variante 2</a></li>
<li><a href="https://klacker.org/articles/pepecyb/irrungenwirrungen">Irrungen und Wirrungen - Hubzilla-Accounts, -Kanäle, -Profile</a></li>
</ul>

Und schon sieht es fetziger aus, oder?

Beispiel 3: Kontakt-Widget

Nun möchte ich noch in der Seitenleiste ein Element haben, welches die Kontaktmöglichkeit mittels Delta Chat anzeigt. Dafür möchte ich den QR-Code meines Delta Chat Accounts verwenden.

Nun könnte man einfach ein Bild, nämlich den QR-Code dort hinpacken. Und das sogar mit bbCode, weil's einfacher ist.



Dann sieht das halt so aus:



Nicht sehr ansprechend... und es frisst Platz, weshalb das Artikelmenü (oder andere Inhalte, falls man noch weitere in die Seitenleiste geschoben hat) nach unten rutscht und man erst scrollen muss, um es zu erreichen.

Besser wäre es, wenn dort ein Button "Kontakt" zu sehen wäre, welche bei Klick den QR-Code einblendet... und den man mit einem weiteren Klick wieder ausblenden kann. Dafür bietet sich das "Accordeon" von W3.CSS an.

Und damit es nicht so langweilig aussieht, peppe ich es noch mit einer Karte als Inhalt und einer kleinen Animation auf. Ach... und der Button wird schwarz und hat ganz leich abgerundete Ecken.

Der Code dafür:

<link rel="stylesheet" href="https://klacker.org/cloud/pepecyb/css/w3.css">

<button onclick="myFunction('contact1')" class="w3-button w3-block w3-black w3-left-align w3-round w3-margin-bottom">Kontakt</button>
<div id="contact1" class="w3-hide w3-container w3-animate-zoom">
<div class="w3-container">
  <div class="w3-card-4 w3-center" style="width:100%;max-width:400px">
  <h2>Delta Chat</h2>
    <img src="https://klacker.org/cloud/pepecyb/Pepes%20pic/delta.png" alt="" style="width:100%">
    <div class="w3-container w3-center">
      <p>derpepe@morpork.email</p>
    </div>
  </div>
</div>
</div>

<script>
function myFunction(id) {
  var x = document.getElementById(id);
  if (x.className.indexOf("w3-show") == -1) {
    x.className += " w3-show";
  } else {
    x.className = x.className.replace(" w3-show", "");
  }
}
</script>

Schnell noch in die Seitenleiste geschoben... und schon ist die Delta Chat Karte da!

Beispiel 4: Sinnfreier PHP-Block

Einfach, um zu zeigen, dass man auch was mit PHP machen kann, hier ein Block, der anzeigt, wann die aktuelle Seite aufgerufen wurde. Mir ist einfach nichts Nützliches eingefallen...

Dazu legt man einen Block mit dem Inhaltstyp "PHP" an. Ich nenne ihn hier einfach mal "aufrufzeit".

Der Code ist extrem simpel!

date_default_timezone_set('Europe/Budapest');
echo 'Seite aufgerufen am: ' . date('d.m.Y - H:i:s');

Beachte hier: Es darf kein <?php davor und kein ?> am Ende stehen!

Das Ding packe ich in die Profilansicht ganz ans Ende, damit jeder weiß, wann er sich das Profil angeschaut hat:

Soviel dazu...

Damit lasse ich es jetzt einfach bewenden. Ich wollte hier einfach nur zeigen, was über die einfachen Dinge aus dem ersten Teil mit Hubzilla alles möglich ist.

Man ist extrem frei, die Oberfläche für sich selbst, aber auch für Besucher attraktiver und praktischer zu gestalten.

Und man ist nicht auf die Fähigkeiten vorhandener Widgets und Styles vorhandener Themes beschränkt. Mit aktuellen Frameworks kann man sehr viel gestalten, was frisch und modern aussieht.

Und da geht manches, was man vielleicht gar nicht für möglich hält. So habe ich einfach einmal was ausprobiert (in einem Test-Kanal... weil ich es eigentlich nicht nutzen würde)...

Zum einfachen Verfassen von bbCode-Beiträgen nutze ich gerne den SCEditor. Den habe ich mir lokal in eine HTML-Datei abgelegt und als Lesezeichen in die Lesezeichen-Symbolleiste meines Browsers gepackt. Ein Klick und er öffnet sich... und ich kann losschreiben.

Und da dachte ich mir einfach mal: Ob man das auch in eine Hubzilla-Ansicht packen kann?

Und tatsächlich ist es ohne große Anstrengung dort umsetzbar. Sah dann so aus:



Ihr seht also... es ist echt viel möglich. Einfach einmal ausprobieren.

Um Euch in die Frameworks einzuarbeiten oder den Einstieg in PHP zu schaffen, empfehle ich persönlich die Tutorials von w3 schools:

• Bootstrap 5 Tutorial
• W3.CSS Tutorial
• PHP Tutorial

Viel Spaß beim Experimentieren und bei der Gestaltung Eures Hubzilla-Kanals!

---

Artikel in der Hubzilla KnowledgeDB

Immer wieder "prahle" ich, wie feingranular denn das Berechtigungssystem von Hubzilla ist und wie genau man festlegen kann, wer was sehen und wer was womit machen kann...

Immer wieder "prahle" ich, wie feingranular denn das Berechtigungssystem von Hubzilla ist und wie genau man festlegen kann, wer was sehen und wer was womit machen kann.

Nutzt man die Kanalrollen "Persönlich" oder "Öffentlich", so ist auch schon sehr viel möglich. Viel mehr als bei den meisten Fediverse-Diensten. Aber trotzdem bleiben es noch "Berechtigungen mit Hammer und Meißel". Wer aber mit dem spitzen Bleistift feine Berechtigungsmuster zeichnen möchte, der muss etwas tiefer in das Berechtigungssystem von Hubzilla eintauchen und – das ergibt sich aus dem Wunsch – ein wenig mehr Aufwand betreiben.

Ausgangspunkt für einen solchen Kanal ist die Kanalrolle. Und hier müssen wir nun "Benutzerdefiniert" auswählen, weil die vorgegebenen Rollen zu viele Rechte einräumen.

Die benutzerdefinierte Kanalrolle entspricht nach Kanalerstellung der Rolle "Persönlich". Wir können aber, im Gegensatz zu den vorkonfigurierten Rollen, jegliche Berechtigung selbst festlegen. Dies geschieht über Einstellungen ➔ Privacy-Einstellungen ➔ Benutzerdefinierte Konfiguration der Channel Role.



Wählt man diesen Punkt, wird man zunächst gewarnt, dass man sich damit seinen Kanal durchaus "kaputt konfigurieren" kann. Na ja... dauerhaft kaputt macht man ihn sich damit auch nicht, weil man ja alles "zurückdrehen" kann. Es kann nur passieren, dass gewisse Dinge womöglich nicht mehr funktionieren, sofern man bei bestimmten Berechtigungen die falsche Einstellung wählt.



"Feintunig extrem" heißt dieser Beitrag... und "extrem" ist hier ziemlich wörtlich gemeint.

Grundsätzlich möchte man ja trotzdem, wenn man ein Soziales Netzwerk nutzt, mit anderen Nutzern in Interaktion treten. Das sollte man im Hinterkopf behalten, insbesondere bevor man bei einer Berechtigung die Auswahl "Nur ich" anwendet.

Für mein Beispiel setze ich jede(!) Berechtigung auf "Nur die, denen Du es explizit erlaubst". Damit ist der erste Schritt getan. Ab sofort muss ich alles, was ich anderen zugestehen möchte, explizit für jeden auch erlauben.

Nun kommen die Kontaktrollen ins Spiel. Es gibt immer die Rolle "Standard", welche allen Verbindungen das erlaubt, was auch mit der Kanalrolle "Persönlich" erlaubt ist. Und jede neue Verbindung erhält zunächst die Kontaktrolle "Standard". Damit wäre also erstmal kaum etwas gewonnen. An dieser Stelle ist es also erforderlich (bei einem neuen Kanal am besten, bevor man die erste Verbindung überhaupt eingeht), weitere Kontaktrollen zu erstellen. Das geschieht mit der App "Contact Roles" (findet Ihr die nicht im App-Menü, müsst ihr in der App-Verwaltung das "Sternchen" erst noch aktivieren).

Dort sieht man in einer Liste die bisher einzige vorhandene Kontaktrolle "Standard" und ein leeres Formular zur Erstellung einer neuen Rolle. Die ist nun im vorliegenden Fall im Bereich der Berechtigungen ohne auch nur ein einziges abgehaktes Kästchen und es gibt auch keine positiven Berechtigungen, die von der Kanalrolle geerbt wurden. Und genau diese Rolle nehmen wir jetzt auch mit sämtlich leeren Kästchen als eine neue Kontaktrolle. Das ist die Rolle, die auch Verbindungen nichts erlaubt. So mal rein gar nichts.



Sie muss einen Namen bekommen. Ich habe meine "nüscht" genannt. Wichtig (nicht zwingend, dazu später mehr) für unser Vorhaben ist die Option "Neuen Kontakten automatisch diese Rolle zuweisen". Die sollte aktiviert werden. Das sorgt dafür, dass jede neu eingegangene Verbindung grundsätzlich erst einmal diese Rolle bekommt... und letztlich "nüscht" darf. Die Verbindung bekommt nicht einmal von uns geteilte Inhalte auch nur zu sehen. Und wir selbst sehen von dieser Verbindung damit auch erstmal genau "nüscht".

Das ist nun aber eher sinnfrei. Die Rolle und die Festlegung, jedem Kontakt dieser Rolle zuzuweisen, sofern man keine andere auswählt, dient nur der Sicherheit, dass neue Verbindungen unbeabsichtigt Berechtigungen bekommen, die wir ihnen eigentlich nicht zugestehen wollen.

So, und nun können wir ans Feintuning gehen. Wir legen uns weitere Kontaktrollen an, die ganz genau auf unsere Bedürfnisse abgestimmt sind.

Die vorhandene (und nicht bearbeitbare) Standard-Rolle können wir natürlich auch für Verbindungen nutzen. Nämlich für genau diejenigen, mit denen wir wie in einem Sozialen Netzwerk ganz normal interagieren möchten.

Nun mag es vielleicht sein, dass wir das typische Social-Network-Verhalten nur für eine bestimmte Zahl unserer Verbindungen haben wollen, die meisten aber sollen die Funktionen nur etwas eingeschränkt nutzen können. Angenommen, die normalen Kontakte sollen unsere Postings sehen können, wir selbst wollen deren Postings auch sehen, sie sollen auch unsere Dateien und Bilder sehen können, ebenso unsere Webseiten und Wikiseiten. Überdies sollen sie liken und disliken können und unsere Beiträge kommentieren... ach und Direktnachrichten sollen sie uns auch schicken können. Die Rolle, ich nenne sie einfach mal "normal" würde dann so aussehen:



Nun mag es sein, dass wir Kontaktanfragen bekommen, wir dem Antragsteller auch durchaus erlauben wollen, unsere Beiträge zu verfolgen, wir selbst wollen aber seine Beiträge nicht sehen und er soll auch keine Reaktionen oder Kommentare machen können... er wäre also das, was bei anderen Diensten der "Follower" ist, dem wir selbst aber nicht folgen, dann können wir eine weitere Rolle anlegen (und z.B. "Follower" nennen). Die sähe dann so aus:



Wir erlauben dem "Follower" also, alles zu sehen, aber selbst nicht in unserem Stream in Erscheinung zu treten.
Und nach diesem Schema können wir uns beliebig viele Kontaktrollen für jede denkbare Verbindung erstellen und dann bestimmten Verbindungen zuweisen.

Das Zuweisen erfolgt entweder, wenn wir selbst eine Verbindung eingehen im dann erscheinenden Verbindungs-Editor. Hier können wir im Auswahlmenü "Wählen Sie eine Rolle für diesen Kontakt" die gewünschte Kontaktrolle auswählen.



Bereits bestehenden Verbindungen können wir auch andere Kontaktrollen zuordenen, indem wir den Verbindungs-Editor in der App "Verbindungen" nutzen.



Bekommen wir eine Verbindungs-Anfrage, landen wir auch wieder im Verbindungs-Editor und legen dort auch gleich die Rolle fest.



Bei einer übersichtlichen Zahl von Verbindungen funktioniert das. Werden es wesentlich mehr Verbindungen, dann kann man sich auch mit der Privacy Gruppen das Leben etwas einfacher machen (auch wenn man die Berechtigungen später einmal umfassend für seine Verbindungen umstrukturieren möchte).

Die App "Privacy Gruppen"muss, sofern noch nicht geschehen, erst einmal installiert werden (obwohl ihre Grundfunktionalität ohnehin schon vorhanden ist... man kann halt ohne die App nicht dran rumschrauben).

Legt man sich für verschiedene Berechtigungs-Rollen nun verschiedene Privacy Gruppen an und schiebt seine Kontakte in diese Gruppen, so kann man in der App "Contact Roles" bei jeder Rolle festlegen, dass diese allen Mitgliedern einer bestimmten Privacy Gruppe zugewiesen werden.

Achtung, Fußangel: Ordnet Ihr einzelne Verbindungen gleichzeitig mehreren Privacy Gruppen zu, so gilt für diese Verbindungen natürlich die Kontaktrolle, die Ihr zuletzt einer Gruppe zugewiesen habt.

Ist also Kontakt A gleichzeitig in den Gruppen B und C und Ihr weist die Kontaktrolle D allen Mitgliedern der Gruppe B zu und danach allen Mitgliedern der Gruppe C die Rolle E, dann verfügt Kontakt A über die Berechtigungen der Rolle D, weil ihm zuletzt als Gruppenmitglied der Gruppe C die Rolle E zugewiesen hat.

Aaaargh... wenn Ihr jetzt einen Knoten im Gehirn habt, Beschwerden bitte nach /dev/null verschieben. 😉😂 War jetzt suboptimal, das Beispiel...
Also kurz: Die zuletzt einer Privacy Gruppe zugewiesene Kontaktrolle gilt dann für alle Gruppenmitglieder, die sich zu dem Zeitpunkt in dieser Gruppe befunden haben. Andere Kontaktrollen, die sie vorher hatten, werden überschrieben.

Soviel zum Berechtigungs-Feintuning. Mit Hubzilla ist echt sehr viel möglich. Und das, was ich hier beschrieben habe, ist tatsächlich, wenn man es auf die Spitze treibt, etwas für Berechtigungsverteilungsfanatiker (nicht nur die Ungarn können lange Wörter). Man muss die richtige Balance finden.
Das Beispiel, das ich mit den paar Rollen hier beschrieben habe, ist aber durchaus alltagstauglich und kann helfen, den Stream hygienisch zu halten.
Die Rolle "nüscht" könnt Ihr Euch auch klemmen, wenn Ihr wollt (vor allem die automatische Zuweisung für neue Kontakte). Ihr müsst dann halt nur darauf achten, beim Eingehen einer Verbindung auch wirklich die korrekte Kontaktrolle zuzuweisen. Ist quasi nur ein zusätzliches Sicherungsseil. Dann wäre es aber sinnvoll, neuen Kontakten als Standard die Rolle "Normal" zuzuweisen.

---

Titelbild von Kevin Wuhrmann auf Pixabay

Heute war der große Tag... Das Update von Hubzilla auf Version 10.4 wurde veröffentlicht.

Der Hauptentwickler Mario Vavti verkündete dies mit den Worten: "Fasten your seatbelts!"

Und er übertreibt nicht...

Heute war der große Tag... Das Update von Hubzilla auf Version 10.4 wurde veröffentlicht.

Der Hauptentwickler Mario Vavti verkündete dies mit den Worten: "Fasten your seatbelts!"

Und er übertreibt nicht. Es hat sich einiges getan. Am offensichtlichsten, und ein großer Schub für den Komfort, die Schonung von Ressourcen und für die bessere Übersichtlichkeit ist die neue Darstellung von Threads, also Konversationen.

Mit der neuen Version werden immer das Ausgangsposting, sowie die letzten drei Kommentare geladen. Das sorgt für Beschleunigung beim Aufbau des Streams. Gibt es nun aber mehr als drei Kommentare, so erscheint unter dem Startbeitrag eine Schaltfläche "–––". Klickt man auf diese, so werden die vorhergehenden Kommentare (dann erst) geladen und angezeigt.





Nun kann man als Nutzer einen Kommentar nicht nur zum Startbeitrag verfassen, sondern auch Kommentare selbst kommentieren. Auch diese "Kommentar-Kommentare" werden zunächst nicht geladen. Ihr Vorhandensein wird über ein Sprechblasensymbol mit einer kleinen Zahl daneben (hier wird die Anzahl der Subkommentare angegeben) angezeigt. Ein Klick auf diese Sprechblase führt dazu, dass die Subkommentare geladen und angezeigt werden.



Um Unterkommentare und ihren Bezug sichtbar und erkennbar zu machen, werden die zusammenhängenden Kommentare an der linken Seite durch eine farbige Linie markiert. Man sieht so, was zusammengehört. Ein erneuter Klick auf die Sprechblase führt schließlich dazu, dass die Kommentare hierarchisch leicht eingerückt werden, um die Hierarchie und den Zusammenhang noch deutlicher zu machen.





Auch Reaktionen werden erst nach Klick auf das Symbol geladen und dargestellt.

Ein weiteres Schmankerl ist, dass man in Kommentaren nun auch Medien aus der eigenen Cloud einbinden kann, ohne sich "verrenken" zu müssen.

Bisher bot der Kommentar-Editor per Schnellzugriff (also über ein Icon am unteren Rand) lediglich an, Medien in einen Kommentar einzubinden, indem man diese neu hochgeladen hat (Büroklammer-Icon). Die Datei – meist sind es ja Bilder – wurde dann in die Cloud (in ein automatisch dafür erstelltes Unterverzeichnis) hochgeladen und die Datei in den Kommentar eingebettet. Wenn nun z.B. eine Grafik ohnehin schon in der eigenen Cloud vorhanden war, entstand so eine Dublette. Nicht sehr praktisch, nicht sehr schön. Bei also schon vorhandenen Bildern hatte man nun entweder die Möglichkeit, sich die URL des Mediums zu kopieren und das Bild "zu Fuß" mittels bbCode einzubinden, oder man rief in einem separaten Tab den Hub noch einmal auf uns öffnete den Beitragseditor (entweder durch Aufruf der App "Beitrag schreiben" oder durch Klick auf das Feld "Teilen" ganz oben über dem Stream),wo das Icon zum Einfügen von Medien vorhanden ist. Den davon erzeugten bbCode hat man dann kopiert und in den Kommentar-Editor eingefügt.

Kann man machen, ist aber Sch... ... aääh... nicht sehr komfortabel und erst recht nicht intuitiv.

Nun gibt es auch im Kommentareditor das Icon mit dem Bildsymbol und man kann, wie im Beitragseditor auch in Kommentaren Bilder aus der Cloud ohne Umweg einfügen.

Apropos Kommentare/Kommentar-Editor...

War es bisher so, dass unter jedem Beitrag und jedem Kommentar, der eine Kommentierung erlaubt, ein Eingabefeld zu sehen war, in welches man den Kommentar eingeben konnte, ist nun der Kommentar-Editor konsequent "modal". Das bedeutet: Das Eingabefeld ist verschwunden... man kann nicht einfach drauf losschreiben, sondern man klickt auf das Symbol , worauf sich der Kommentar-Editor öffnet. Daran gewöhnt man sich aber sehr schnell... und die Threads werden dadurch auch ansehnlicher  und übersichtlicher.

Ich habe schon sehr lange gequengelt, dass diese Funktion endlich eingebaut wird.

Eine weitere Quengelei wurde auch noch erhört: Das "überflüssige" führende "@"!

Im Dialogfeld für das Herstellen von Verbindungen musste man bisher immer zwingend ein führendes "@" vor dem Kanalhandle weglassen... egal bei welchem Fediversedienst der Kanal beheimatet war. Also aus @quatschkopf@ganzsicher.sozial musste man quatschkopf@ganzsicher.sozial machen. Hat man das "@" davor gelassen, wurde der Kanal nicht gefunden (und keine Verbindung hergestellt) und man bekam den Hinweis, dass der Kanal durchaus ja "verborgen" sein könnte.

Das war unpraktisch und auch eine echte Fehlerquelle. Wer sich dessen nicht bewusst war, hat keine Kontakte zu vielen anderen Diensten herstellen können. Einsteiger konnten dadruch sogar auf den Gedanken kommen, dass Hubzilla ja doch nicht mit "dem Fediverse" könne... also zumindest nicht mit Mastodon und so. Weil: Hubzilla findet ja die Benutzer nicht.

Und der Fehler konnte (auch wieder gerade bei Neulingen) ganz leicht vorkommen. Zum Beispiel, wenn ein Neu-Hubzillianer sich das Handle eines anderen Nutzers per Copy & Paste direkt vom Originalprofil in das Verbindungsfeld brachte... natürlich mit dem "@" davor.

Mit 10.4 ist das vorbei. Ein führende "@" wird schlicht ignoriert. Es klappt dann also auch, wenn man @quatschkopf@ganzsicher.sozial ins Feld eingibt.

Es gibt außerdem Verbesserungen bim Foto-Handling, was dazu führt, dass mehr Kanäle mit dem korrekten Avatarbild erscheinen, anstatt mit dem Default-Bild.

Die Inhaltsfiler erlauben jetzt auch Bedingungen und zeitbasierte Filterung (fraaagt mich nicht, wie die Syntax lautet... da muss ich auch erstmal noch nachfragen... landet dann in der Hilfe und in der KnowledgeDB).

Und auch wegen den nun möglichen benutzerdefinierten Emojis muss ich nachfragen...

Der Fotocache wurde verbessert, das Superblock-Addon ebenfalls und um die Möglichkeit eines seitenweiten Blocks erweitert. Das Flashcard-Addon wurde stark überarbeitet und ermöglicht jetzt auch Teilen, gemeinsames Bearbeiten und hubübergreifende Synchronisierung.

Geo-URLs können nun in [url]-Tags gefasst werden und werden korrekt zu einem anklickbaren Link gerendert.

Auch unter der Haube wurde etliches optimiert und verbessert... und Codeleichen wurden entsorgt.

Die überarbeitete Hilfe ist nun Bestandteil der Distribution (Englisch und Deutsch), die norwegischen Übersetzungen wurden überarbeitet, erweitert und verbessert.

Es gibt eine Menge Fehlerbeseitigungen und etliche Addons wurden verbessert oder fehlerbereinigt.

Alle Infos zum Update gibt es hier: Hubzilla 10.4 Released!

...und im Changelog.

Insgesamt ein echter Meilenstein, die Version 10.4.!



Das Update ist, wie immer, unproblematisch. Allerdings müssen Admins, die Hubzilla mit MySQL (MariaDB) betreiben, die Datenbankstruktur ein wenig anpassen. Auch das ist wirklich kein großes Problem.

After recently writing a ‘Hubzilla-Häppchen’ on the topic of ‘channel calming,’ I thought I would share my personal configuration here, along with some explanations... and perhaps show what a great tool Hubzilla is for participating in the Fediverse in a relaxed manner...

After recently writing a ‘Hubzilla-Häppchen’ on the topic of ‘channel calming,’ I thought I would share my personal configuration here, along with some explanations... and perhaps show what a great tool Hubzilla is for participating in the Fediverse in a relaxed manner.

The channel roles ‘Public’ and ‘Personal’ are a good choice for getting started and correspond to what you would expect from the Fediverse and social networks in general. However, these settings do not protect you from being annoyed by spam or receiving ‘inappropriate’ comments from strangers (i.e. participants without a connection).

To achieve this, you need to dip into Hubzilla's bag of tricks. With its sophisticated permission system, Hubzilla offers all the tools you need for an enjoyable Fediverse experience.

To do this, you need to select the ‘Custom’ setting for the channel role.

This is done via Settings (in the main menu... the one with your profile picture... at the top of the navigation bar) ➔ Channel Settings. There, select ‘Custom’ from the ‘Channel Role’ drop-down menu.

Then, set the permissions precisely under Settings ➔ Privacy Settings. This is done by clicking on the ‘Custom configuration of channel role’ button to switch to the role editor. You will first see a warning: ‘Proceed with caution - Changing advanced configuration settings can impact your, and your contacts channels functionality and security.’ If you confirm that you want to take the ‘risk’, you will be taken to the configuration editor for the channel role.

First, you should think about what you want to allow whom on the Internet, in the Fediverse and in the Grid (the network of all Hubzilla hubs)... in other words, what rights you want to grant to others.

Below, I present my personal preferences. If you have other ideas, you must specify them for yourself and ultimately implement them in the channel role rules. This is therefore a highly individual decision... and everyone is entitled to their own opinion. There is no right or wrong here.

My idea for participating with my main channel is as follows: I want everyone on the internet – whether they have a Fediverse account or not – to be able to see my posts. This should be the case on other instances and also in my channel stream. In addition, everyone on the internet should be able to see my standard profile. However, my contacts (i.e. my connections) are nobody else's business. Only my connections should be able to see them. Everyone should also be able to see my media and images, as well as my websites and wikis.

However, I don't want to receive posts directly from strangers in my stream. And I don't want everyone to be able to edit my web and wiki pages or create new ones. I would much rather decide who is allowed to do that. I also only want to allow connections to post on my ‘wall’, i.e. directly in my channel stream. Strangers should not be able to like/dislike or comment on my posts. This should also be reserved for my contacts. The same applies to chatting and repeating or sharing my posts. The administration of my channel is my business... and perhaps that of one or a few trusted individuals... in case I am unavailable for a longer period of time.

At this point, it is important to remember that Hubzilla's permissions are based on the whitelist principle. The basis for this is the channel role. Everything that is permitted in this is generally permitted for the selected groups and cannot be removed elsewhere. With the contact roles, you can then grant further permissions (for all points for which you have set the permission ‘Only those you explicitly allow’ in the channel role). However, you can create as many contact roles as you like with different additional permissions and assign them to different connections.

It is therefore advisable to be quite restrictive with the channel roles and to set most items to ‘Only those you explicitly allow’.

Now I will go through the individual items in the channel role and show how I have set them...

1. Can view my channel stream and my posts -> Anybody on the Internet

This makes all my posts public so that everyone can see them.

2. Can send me their channel stream and posts -> Only those you explicitly allow

I will allow all my connections to do this for now via my own standard contact role, which I will create later.

3. Can view my default profile -> Anybody on the Internet

I also want everyone on the Internet to be able to see my default profile.

4. Can view my connections -> Only those you explicitly allow

I also grant this (my personal decision/setting) to all my connections via my own standard contact role.

5. Can view my file storage and photos -> Anybody on the internet

Here, permission must be granted to everyone, because media and images are sometimes (mostly) shared in posts that everyone should be able to see.

6. Can upload/modify my file storage and photos -> Only me

Only I am allowed to mess around with my files and folders. Period. End of story.

7. Can view my channel webpages -> Anybody on the Internet

8. Can view my wiki pages -> Anybody on the Internet

In both cases, this is public content... visible to everyone.

9. Can create/edit my channel webpages -> Only me

My websites are my websites. Anyone who wants to create their own must register and create their own channel.

10. Can write to my wiki pages -> Only those you explicitly allow

I only allow certain connections to edit and create entries in my wikis. To do this, I have to create a separate contact role.

11. Can post on my channel (wall) page -> Only those you explicitly allow

I initially allow all my connections to do this via my own standard contact role.

12. Can comment on or like my posts -> Only those you explicitly allow

This is also only allowed for all my connections via my own standard contact role. This prevents comments from strangers.

13. Can send me direct messages -> Only those you explicitly allow

14. Can like/dislike profiles and profile things -> Only those you explicitly allow

15. Can chat with me -> Only those you explicitly allow

These three permissions are also only for my contacts (my own default contact list).

16. Can source/mirror my public posts in derived channels -> Only those you explicitly allow

I also only allow repeating and sharing (quote posting) via my own default contact role to all my connections.

17. Can administer my channel -> Only those you explicitly allow

If necessary, I will create an extra contact role for this purpose in order to grant certain, particularly trustworthy contacts this ‘sacred task’ if necessary.

Now a few words about the general privacy settings:

‘Automatically approve new contacts’ should remain disabled, because otherwise strangers could secure rights by “following” your channel that I explicitly only grant to those with whom I establish a connection (i.e., mutual “following”).

I also leave ‘Accept all messages which mention you’ turned off because I don't want posts from strangers in my stream just because they mention my channel handle.

‘Enable OCAP access’, on the other hand, should be turned on. This allows you to see media in (Hubzilla) posts (especially in forum channels) even if the author/owner has restricted their visibility.

You should think carefully about whether to enable ‘Accept unsolicited comments for moderation’. If you do not enable this, strangers will not be able to comment on your posts. Comments will be discarded. If you enable it, accounts/channels that you are not connected to can also comment on your posts. However, these will not be published immediately. You can decide (moderate) whether the comment should be accepted.
I have only very rarely received inappropriate comments or spam comments, so I have enabled this option. The reason? It is entirely possible (and has happened to me on several occasions) that a stranger has posted a ‘successful/appropriate/special’ comment on one of my posts... and I may have added them to my connections because of this. If I had left the option disabled, such ‘encounters’ would not have been possible.
If inappropriate comments start to take over at some point, I can always turn the option off again. That's my personal opinion... that's why I do it this way. Everyone has to decide for themselves.

Important... after you have made your custom settings and selected your options, be sure to click on the ‘Submit’ button, otherwise all your work will be for nothing. 😉

I have now laid the foundation for my relaxed channel. All I have to do now is create a few contact roles to grant my connections the desired permissions. With this channel role, interaction with connections is initially as restricted as it is for strangers (‘Everyone on the Internet’).

You can manage contact roles via the ‘Contact Roles’ app.

The default contact role ‘Standard’ is the system contact role and cannot be changed. I'll put that on hold for now by disabling the option ‘Automatically assign this role to new contacts’.

I create my own default contact role. I have named it ‘Default’. For this role, I now enable ‘Automatically assign this role to new contacts’ so that all contacts I add from now on will be assigned this role.

To grant my connections the rights discussed above, I have configured the contact role as follows:

Can view my channel stream and posts	X
Can send me their channel stream and posts	X
Can view my default channel profile	X
Can view my connections	X
Can view my file storage and photos	X
Can upload/modify my file storage and photos
Can view my channel webpages	X
Can view my wiki pages	X
Can create/edit my channel webpages
Can write to my wiki pages
Can post on my channel (wall) page	X
Can comment on or like my posts	X
Can send me direct messages	X
Can like/dislike profiles and profile things	X
Can chat with me	X
Can source/mirror my public posts in derived channels	X
Can administer my channel

To ensure that this contact role now applies to all my connections, I select the privacy group ‘Friends’ (which, unless changed, is the default group for all contacts) in the input field ‘Assign this role to the following privacy group’ and click on the ‘Submit’ button.

I have also created a contact role called ‘Minimal’, in which I do not grant any additional permissions. This allows me to perfectly simulate a pure ‘follow’ role, because the contact to whom I assign this role has the same rights as ‘Everyone on the Internet’, with the difference that they can see my posts in their timeline.



For those connections that should also be able to contribute to my wikis, I create a contact role called ‘Wiki collaboration’, which has the same permissions as the ‘Default’ contact role, but also allows ‘Can edit my wiki pages’.

And a role called ‘Channel admin’, which also corresponds to the ‘Default’ role, but additionally has the permission ‘Can administer my channel’.

And now my channel feels exactly the way I want it to. I am spared spam and annoyances.

The only thing that can happen now is that one of my connections repeats a post that I don't want to see in my stream or that comes from a user who has no business being in my stream. This post will then end up in my stream. In this case, I use the ‘Superblock’ app to add the original author to the block list and delete the post from my stream. This means that no more posts from this unknown user will appear in my stream in future, and they will no longer be able to do anything more than ‘Everyone on the Internet’... i.e. they cannot give likes/dislikes, repeat my posts or even comment on them.

---
Cover image by SerenityArt on Pixabay.

Nachdem ich kürzlich ein "Hubzilla-Häppchen" zum Thema "Kanalberuhigung" geschrieben hatte, dachte ich, dass ich mal meine persönliche Konfiguration - mit entsprechenden Erläuterungen - hier vorstelle... und damit vielleicht zeige, welch tolles Werkzeug Hubzilla ist, um entspannt am Fediverse teilzunehmen...

Nachdem ich kürzlich ein "Hubzilla-Häppchen" zum Thema "Kanalberuhigung" geschrieben hatte, dachte ich, dass ich mal meine persönliche Konfiguration - mit entsprechenden Erläuterungen - hier vorstelle... und damit vielleicht zeige, welch tolles Werkzeug Hubzilla ist, um entspannt am Fediverse teilzunehmen.

Die Kanalrollen "Öffentlich" und "Persönlich" sind eine gute Wahl für den Einstieg und entsprechen dem, was man vom Fediverse und Sozialen Netzwerken im Allgemeinen erwartet. Nur ist man mit diesen Schemata nicht geschützt davor, mit Spam genervt zu werden oder "unpassende" Kommentare von Fremden (also Teilnehmern ohne eine Verbindung) zu bekommen.

Um das zu erreichen, muss man in die Trickkiste von Hubzilla greifen. Hubzilla bietet nämlich mit seinem ausgefeilten Berechtigungssystem alle Werkzeuge für ein angenehmes Fediverse-Erlebnis an.

Dafür muss man für die Kanalrolle die Einstellung "Benutzerdefiniert" auswählen.

Dies geschieht mittels Einstellungen (im Hauptmenü... das mit dem eigenen Profilbild... oben in der Navigationsleiste) ➔ Kanal-Einstellungen. Dort wählt man im Auswahlfeld "Channel Role" den Eintrag "Benutzerdefiniert".

Anschließend stellt man die Berechtigungen unter Einstellungen ➔ Privacy-Einstellungen ganz genau ein. Dies geschieht, indem man über den Button "Benutzerdefinierte Konfiguration der Channel Role" in den Rollen-Editor wechselt. Zunächst wird man noch gewarnt: "Mit Vorsicht vorgehen - Das Ändern von erweiterten Konfigurationseinstellungen kann sich auf die Funktionalität und Sicherheit Ihrer Kanäle und der Ihrer Kontakte auswirken." Bestätigt man, dass man das "Risiko" eingehen möchte, so landet man im Konfigurationseditor für die Kanalrolle.

Vorneweg sollte man sich Gedanken machen, was man wem im Internet, im Fediverse und im Grid (das Netzwerk aller Hubzilla-Hubs) erlauben möchte... welche Rechte man Anderen also einräumen will.

Im Folgenden stelle ich meine persönlichen Präferenzen vor. Wer andere Vorstellungen hat, muss diese entsprechend für sich konkretisieren und letztlich in den Regeln der Kanalrolle umsetzen. Das ist also eine ausgesprochen individuelle Entscheidung... und jeder hat für sich selbst erst einmal recht. Es gibt hier kein Richtig oder Falsch.

Meine Vorstellung für die Teilnahme mit meinem Haupt-Kanal ist folgende: Ich möchte, dass jeder im Internet - ob er einen Fediverse-Account besitzt, oder nicht - meine Beiträge sehen kann. Das soll auf anderen Instanzen oder auch in meinem Kanal-Stream so sein. Außerdem soll jeder im Internet mein Standard-Profil sehen können. Meine Kontakte (also meine Verbindungen) gehen hingegen nicht jeden etwas an. Das sollen nur meine Verbindungen sehen können. Meine Medien und Bilder soll ebenfalls jeder sehen können, ebenso meine Webseiten und meine Wikis.

Ich möchte allerdings keine Beiträge direkt von Fremden in meinen Stream bekommen. Und ich möchte auch nicht, dass jeder meine Web- und Wikiseiten bearbeiten oder neue erstellen kann. Ich möchte vielmehr selbst festlegen, wer das darf. Auch das Posten auf meine "Wall", also direkt in meinen Kanalstream möchte ich nur Verbindungen erlauben. Fremde sollen auch keine Likes/Dislikes oder Kommentare zu meinen Beiträgen setzen/verfassen können. Das soll ebenfalls meinen Kontakten vorbehalten bleiben. Ebenso das Chatten und das Wiederholen oder Teilen meine Beiträge. Die Administration meines Kanals ist meine Sache... und vielleicht die einer oder einiger weniger echter Vertrauenspersonen... für den Fall, dass ich einmal länger verhindert bin.

Und an dieser Stelle muss man sich nun noch einmal vergegenwärtigen, dass Hubzilla bei seinen Berechtigungen nach dem Whiltelist-Prinzip arbeitet. Die Basis ist dabei die Kanalrolle. Alles, was man in dieser erlaubt, ist generell für die gewählten Kreise erlaubt und kann nicht an anderer Stelle weggenommen werden. Mit den Kontaktrollen kann man dann weitere Berechtigungen erteilen (für alle Punkte, denen man in der Kanalrolle die Berechtigung "Nur die, denen Du es explizit erlaubst" eingestellt hat). Man kann allerdings beliebig viele Kontaktrollen mit unterschiedlichen zusätzlichen Berechtigungen erstellen und verschiedenen Verbindungen zuordnen.

Es empfiehlt sich also, bei den Kanalrollen recht restriktiv zu sein und bei den meisten Punkten "Nur die, denen Du es explizit erlaubst" einzustellen.

Jetzt gehe ich einmal die einzelnen Punkte der Kanalrolle durch und zeige, wie ich sie eingestellt habe...

1. Kann meinen Kanal-Stream und meine Beiträge sehen -> Jeder im Internet

Damit mache ich alle meine Beiträge grundsätzlich öffentlich, sodass sie jeder sehen kann.

2. Kann mir die Beiträge aus seinem Kanal schicken -> Nur die, denen Du es explizit erlaubst

Über die später zu erstellende eigene Standard-Kontaktrolle erlaube ich dies erst einmal allen meinen Verbindungen.

3. Kann mein Standardprofil sehen -> Jeder im Internet

Auch mein Standard-Profil soll jeder, der im Internet unterwegs ist, sehen können.

4. Kann meine Verbindungen sehen -> Nur die, denen Du es explizit erlaubst

Das gewähre ich ebenfalls (meine persönliche Entscheidung/Einstellung) all meinen Verbindungen über die eigene Standard-Kontaktrolle.

5. Kann meine Datei- und Bilderordner sehen -> Jeder im Internet

Hier muss die Berechtigung an jeden vergeben werden, weil Medien und Bilder ja teilweise (größtenteils) in Beiträgen geteilt werden, die auch jeder sehen können soll.

6. Kann in meine Datei- und Bilderordner hochladen/ändern -> Nur ich

An meinen Dateien und Ordnern darf nur ich herumpfuschen. Punkt. Aus. Ende.

7. Kann die Webseiten meines Kanals sehen -> Jeder im Internet

8. Kann meine Wiki-Seiten sehen -> Jeder im Internet

In beiden Fällen sind das erst einmal öffentliche Inhate... also für jeden sichtbar.

9. Kann Webseiten in meinem Kanal erstellen/ändern -> Nur ich

Meine Webseiten sind meine Webseiten. Wer selbst welche erstellen möchte, registriert sich und erstellt einen eigenen Kanal dafür.

10. Kann meine Wiki-Seiten bearbeiten -> Nur die, denen Du es explizit erlaubst

Das Ändern und Erstellen von Einträgen in meinen Wikis erlaube ich nur bestimmten Verbindungen. Dafür muss ich eine eigene Kontaktrolle erstellen.

11. Kann auf meiner Kanal-Seite ("wall") Beiträge veröffentlichen -> Nur die, denen Du es explizit erlaubst

Dies wiederum erlaube ich zunächst allen meinen Verbindungen über die eigene Standard-Kontaktrolle.

12. Darf meine Beiträge kommentieren und mögen/nicht mögen -> Nur die, denen Du es explizit erlaubst

Ebenfalls grundsätzlich nur all meinen Verbindungen über die eigene Standard-Kontaktrolle erlaubt. Damit verhindere ich Kommentare von Fremden.

13. Kann mir direkte Nachrichten schicken -> Nur die, denen Du es explizit erlaubst

14. Kann Profile und Profilsachen mögen/nicht mögen -> Nur die, denen Du es explizit erlaubst

15. Kann mit mir chatten -> Nur die, denen Du es explizit erlaubst

Auch diese drei Berechtigungen nur für meine Kontakte (eigene Standard-Kontaktrolle).

16. Kann meine öffentlichen Beiträge in anderen Kanälen zitieren/spiegeln -> Nur die, denen Du es explizit erlaubst

Das Wiederholen und Teilen (Zitat-Posting) erlaube ich ebenfalls über die eigene Standard-Kontaktrolle grundsätzlich nur all meinen Verbindungen.

17. Kann meinen Kanal administrieren -> Nur die, denen Du es explizit erlaubst

Hierfür erstelle ich bei Bedarf auch wieder eine extra Kontaktrolle, um bestimmten, besonders vertrauenswürdigen Kontakten diese "heilige Aufgabe" ggf. einzuräumen.

Nun noch ein paar Worte zu den allgemeinen Privacy-Einstellungen:

"Neue Kontakte automatisch genehmigen" sollte ausgeschaltet bleiben, weil sich ansonsten Fremde durch das "Folgen" des eigenen Kanals die Rechte sichern könnten, die ich ja explizit nur denen einräume, mit denen ich eine Verbindung eingehe (also wechselseitiges "Folgen").

"Accept all messages which mention you" lasse ich ebenfalls ausgeschaltet, weil ich nicht über eine schlichte Erwähnung über mein Kanal-Handle Beiträge von Fremden in meinem Stream haben möchte.

"Enable OCAP access" sollte man hingegen einschalten. Damit kann man Medien in (Hubzilla-) Postings (insbesondere in Foren-Kanälen) sehen, selbst wenn der Verfasser/Eigentümer sie in der Sichtbarkeit eingeschränkt hat.

Ob man "Accept unsolicited comments for moderation" einschaltet, sollte man sich genau überlegen. Schaltet man es nicht ein, so haben Fremde nicht die Möglichkeit, einen Beitrag zu kommentieren. Kommentare werden verworfen. Schaltet man es ein, so können auch Accounts/Kanäle, zu denen man keine Verbindung hat, einen Kommentar zu einem eigenen Beitrag verfassen. Diese werden aber nicht sofort veröffentlicht. Man selbst kann entscheiden (moderieren), ob der Kommentar angenommen werden soll.
Ich habe bislang nur sehr selten unangemessene Kommentare oder Spam-Kommentare erhalten, sodass ich diese Option eingeschaltet habe. Der Grund? Es ist ja durchaus möglich (und es ist bei mir auch schon öfter vorgekommen), dass ein Fremder einen "gelungenen/passenden/besonderen" Kommentar zu einem meiner Beiträge abgegeben hat... und ich ihn womöglich deshalb zu meinen Verbindungen zugefügt habe. Wenn ich die Option ausgeschaltet gelassen hätte, wären solche "Begegnungen" nicht möglich gewesen.
Sollten irgendwann unpassende Kommentare überhandnehmen, dann kann ich die Option ja wieder ausschalten. Meine persönliche Meinung... drum mache ich das so. Das muss halt jeder für sich selbst entscheiden.

Wichtig... nach den benutzerdefinierten Einstellungen und der Wahl der Optionen unbedingt auf den Button "Absenden" klicken, sonst war die ganze Arbeit für die Katz. 😉

Damit habe ich die Basis für meinen entspannten Kanal geschaffen. Jetzt muss ich nur noch ein paar Kontaktrollen erstellen, um meinen Verbindungen die gewünschten Berechtigungen einzuräumen. Denn mit dieser Kanalrolle ist die Interaktion auch mit den Verbindungen zunächst so eingeschränkt, wie sie es auch für Fremde ("Jeder im Internet") ist.

Die Verwaltung der Kontaktrollen erreicht man über die App "Contact Roles".

Die Standard-Kontaktrolle "Standard" ist die System-Kontaktrolle und kann nicht verändert werden. Die schiebe ich erst einmal aufs Abstellgleis, indem ich die Option "Neuen Kontakten automatisch diese Rolle zuweisen" ausschalte.

Ich baue mir eine eigene Standard-Kontaktrolle. Ich habe sie "Default" genannt. Bei dieser Rolle schalte ich nun "Neuen Kontakten automatisch diese Rolle zuweisen" ein, damit alle Kontakte, die ich ab jetzt hinzufüge, diese Rolle erhalten.

Um meinen Verbindungen nun die oben besprochenen Rechte einzuräumen, habe ich die Kontaktrolle wie folgt konfiguriert:

Kann meinen Kanal-Stream und meine Beiträge sehen	X
Kann mir die Beiträge aus seinem Kanal schicken	X
Kann mein Standardprofil sehen	X
Kann meine Verbindungen sehen	X
Kann meine Datei- und Bilderordner sehen	X
Kann in meine Datei- und Bilderordner hochladen/ändern
Kann die Webseiten meines Kanals sehen	X
Kann meine Wiki-Seiten sehen	X
Kann Webseiten in meinem Kanal erstellen/ändern
Kann meine Wiki-Seiten bearbeiten
Kann auf meiner Kanal-Seite ("wall") Beiträge veröffentlichen	X
Darf meine Beiträge kommentieren und mögen/nicht mögen	X
Kann mir direkte Nachrichten schicken	X
Kann Profile und Profilsachen mögen/nicht mögen	X
Kann mit mir chatten	X
Kann meine öffentlichen Beiträge in anderen Kanälen zitieren/spiegeln	X
Kann meinen Kanal administrieren

Damit diese Kontaktrolle nun für alle meine Verbindungen greift, wähle ich im Eingabefeld "Weisen Sie diese Rolle folgender Privacy Gruppe zu" die Privacy Gruppe "Freunde" (welcher als Standard, sofern man nichts verändert hat, alle Kontakte angehören) aus und klicke auf den Button "Absenden".

Und ich habe außerdem eine Kontaktrolle "Minimal" erstellt, in welcher ich gar keine zusätzlichen Berechtigungen erteile. Damit kann ich ein reines "gefolgt werden" perfekt simulieren, denn damit verfügt der Kontakt, welchem ich ausschließlich diese Rolle zuordne, die gleichen Rechte, wie "Jeder im Internet" mit dem Unterschied, dass er meine Beiträge in seine Timeline gespült bekommt.



Für diejenigen Verbindungen, die auch an meinen Wikis mitarbeiten können sollen, erstelle ich eine Kontaktrolle "Wiki-Zusammenarbeit", welche dieselben Berechtigungen wie die Kontaktrolle "Default" besitzt, zusätzlich aber auch "Kann meine Wiki-Seiten bearbeiten" erlaubt.

Und eine Rolle "Kanal-Admin", die ebenfalls der Rolle "Default" entspricht, aber zusätzlich noch über die Berechtigung "Kann meinen Kanal administrieren" verfügt.

Und damit fühlt sich mein Kanal genau so an, wie ich es möchte. Ich bleibe von Spam und Nerverei verschont.

Es kann jetzt nur noch vorkommen, dass eine meine Verbindungen einen Beitrag, den ich in meinem Stream nicht sehen möchte, oder welcher von einem Nutzer stammt, der in meinem Stream nichts zu suchen hat, wiederholt. Dieser Beitrag landet dann in meinem Stream. In diesem Fall setze ich den ursprünglichen Verfasser mit der App "Superblock" auf die Blockliste und lösche den Beitrag aus meinem Stream. Damit kommen künftig auch keine Beiträge mehr von diesem fremden Nutzer mehr in meinen Stream und er kann ohnehin nicht mehr, als "Jeder im Internet"... also auch keine Likes/Dislikes verteilen, meine Beiträge nicht wiederholen oder gar kommentieren.

---
Titelbild von SerenityArt auf Pixabay.