Bei allen Überlegungen, wie ich es denn letztlich realisieren möchte, läuft es in fast allen Fällen darauf hinaus, dass ich die Inhalte des WordPress Blogs exportieren muss...

Bei allen Überlegungen, wie ich es denn letztlich realisieren möchte, läuft es in fast allen Fällen darauf hinaus, dass ich die Inhalte des WordPress Blogs exportieren muss. Auf welche Weise ich diese dann verarbeite, hängt vom gewählten Weg ab.

Die Export-Funktion von WordPress ist ganz einfach zu benutzen. Man findet sie in der Seitenleiste unter dem Menüpunkt "Werkzeuge".



Man kann dort alle möglichen Inhalte exportieren, ja sogar alle auf ein Mal. Nun, alle brauche ich nicht. Ich brauche tatsächlich nur die Beiträge (inklusive der Kommentare). Und weil in der DDP so viele Beiträge existieren und die Sicherungsdatei extrem groß werden würde, habe ich mich entschieden, je einen Export für jeweils ein Jahr zu erzeugen.





Und dann habe ich eine Export-Datei (die Sicherungsdateien werden von WordPress als WXR-Dateien – für WordPress eXtended RSS - bezeichnet) im XML-Format.



Diese Dateien sind für Publii und dessen Import-Funktion direkt nutzbar. Allerdings werden nur die Artikel selbst importiert. Die Kommentare bleiben unberücksichtigt.

Ansonsten sind die WXR-Dateien aber nicht wirklich für die direkte Nutzung geeignet. Um sie z.B. für die Artikel-App von Hubzilla zu verwenden, muss man die eigentlichen Artikel extrahieren und ins BBcode-Format umwandeln. Und die Kommentare müssen auch (am besten separat) extrahiert werden.

Per Hand ein riesiger Aufwand. Dafür müssen Helfer-Skripte her... aber dazu später mehr (sind schon in Arbeit).

Lediglich für die Variante mit einem externen statischen Archiv werden die Exportdateien nicht benötigt (schadet aber auch nicht, welche als Backup zu haben). Ich würde dafür Simply Static nutzen, mit dem ich schon gute Erfahrungen gemacht habe.

Ich bin mir inzwischen sicher, bzw. ich bin fest entschlossen, mein Blog "Die Dampfdruck-Presse" (aktuell noch mit WordPress) in Zukunft nur noch mit Hubzilla als CMS anzubieten...

Ich bin mir inzwischen sicher, bzw. ich bin fest entschlossen, mein Blog "Die Dampfdruck-Presse" (aktuell noch mit WordPress) in Zukunft nur noch mit Hubzilla als CMS anzubieten.

Die Gründe dafür sind die irrsinnigen KI-Ideen der WordPress-Entwickler und auch ein Stück weit Glaubwürdigkeit (immerhin predige ich ja schon lange, dass Hubzilla auch als vollwertiges CMS gut nutzbar ist).

Die Basis existiert ja auch schon eine ganze Weile: Dampfdruck-Presse bei Hubzilla. Ich pflege dieses Parallel-Blog seit dem Start mit den neuen Artikeln, die ich in der WordPress-Version veröffentliche. Und ein paar ältere Artikel habe ich auch schon konvertiert... zu Fuß.

Und genau da liegen die Probleme! Das wirklich per Hand einzeln zu machen, ist ein enormer Aufwand. Immerhin gibt es ja (aktueller Stand) 1.075 Artikel. Wenn ich die alle einzeln konvertieren möchte und vielleicht am Tag durchschnittlich drei bis vier Artikel hinbekäme, dann wäre ich locker bis zu einem Jahr damit beschäftigt.

Schöne Scheiße!

Nun gibt es mehrere Möglichkeiten.

Die einfachste wäre, das WordPress Blog als Archiv bestehen zu lassen und künftig nur noch im Hubzilla-Blog zu veröffentlichen. Allerdings müsste ich dann die Updates dafür abschalten oder es in ein statisches Blog umwandeln (das funktioniert ganz manierlich).

Der Vorteil: Die Kommentare blieben sauber bestehen. Es würde nichts verloren gehen.

Der Nachteil: Die DDP wäre in zwei Teile aufgeteilt, also quasi zerrissen.

Hier überwiegt der Nachteil! Ich könnte die statische Version (denn so würde ich es machen, um WordPress auch wirklich loszuwerden) unter dampfdruck-presse.de laufen lassen und das aktuelle Blog (also das mit Hubzilla) unter dampfdruck-presse.hu laufen lassen. Es gefällt mir so aber nicht!

Eine weitere Möglichkeit wäre, das WordPress Blog per Import als Publii-Blog zu konvertieren. Das funktioniert auch sehr gut. Dieses statische Blog könnte ich dann auch mit Hubzilla anbieten. Das wäre dann das "Archiv". Das aktuelle Blog würde mit Hubzilla und der App "Artikel" fortgeführt. Es gäbe dann halt einen Link zum Archiv, der zum Publii-Archiv in der Hubzilla-Cloud führen würde.

Der Vorteil: Alles wäre an einem Ort und unter einer Domain zu erreichen.

Der Nachteil: Die Kommentare müsste ich per Hand einpflegen, denn die werden von der Import-Funktion nicht erfasst.

Und schließlich könnte ich tatsächlich das ganze Blog komplett als Hubzilla-Artikel konvertieren.

Der Vorteil: Alles wäre aus einem Guss.

Der Nachteil: Wie schon erwähnt, wäre das eine Mords-Arbeit bei so vielen Artikeln. Da müsste ich mir Helfer-Skripte basteln.

Nun, ich werde jetzt nach und nach an allen Varianten herumtüfteln, schauen, was sich automatisieren und vereinfachen lässt und es sicher irgendwann irgendwie schaffe, die DDP komplett zu Hubzilla umzuziehen.

Und ich nehme Euch gerne mit auf diese Reise, indem ich die einzelnen Schritte und Experimente hier dokumentiere und erläutere. Es kommen also jetzt nach und nach etliche weitere Artikel zu dem Thema "Von WordPress zu 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://hub.hubzilla.hu/cloud/pepecyb/css/w3.css">

<div class="w3-bar w3-border w3-light-grey">
  <a href="https://hub.hubzilla.hu/page/pepecyb/about" class="w3-bar-item w3-button"><img src="https://hub.hubzilla.hu/cloud/pepecyb/whoville/whoville-logo.png" alt=""></a>
  <a href="https://hub.hubzilla.hu/articles/pepecyb" class="w3-bar-item w3-button w3-hover-green">Artikel</a>
  <a href="https://hub.hubzilla.hu/cards/pepecyb" class="w3-bar-item w3-button w3-hover-blue">Karten</a>
  <a href="https://hub.hubzilla.hu/wiki/pepecyb" class="w3-bar-item w3-button w3-hover-teal">Wikis</a>
  <a href="https://hub.hubzilla.hu/gallery/pepecyb" class="w3-bar-item w3-button w3-hover-purple">Galerie</a>
  <a href="https://hub.hubzilla.hu/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://hub.hubzilla.hu/articles/pepecyb/hhowama">Hubzilla-Häppchen: Hubzilla-Magie - OpenWebAuth / MagicAuth</a><br>
<a href="https://hub.hubzilla.hu/articles/pepecyb/folhsh2">Hubzilla: Hashtags folgen - Variante 2</a><br>
<a href="https://hub.hubzilla.hu/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://hub.hubzilla.hu/articles/pepecyb/hhowama">Hubzilla-Häppchen: Hubzilla-Magie - OpenWebAuth / MagicAuth</a></li>
<li><a href="https://hub.hubzilla.hu/articles/pepecyb/folhsh2">Hubzilla: Hashtags folgen - Variante 2</a></li>
<li><a href="https://hub.hubzilla.hu/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://hub.hubzilla.hu/cloud/pepecyb/css/w3.css">

<ul class="w3-ul w3-card-4 w3-pale-green" style="width:100%">
<li><a href="https://hub.hubzilla.hu/articles/pepecyb/hhowama">Hubzilla-Häppchen: Hubzilla-Magie - OpenWebAuth / MagicAuth</a></li>
<li><a href="https://hub.hubzilla.hu/articles/pepecyb/folhsh2">Hubzilla: Hashtags folgen - Variante 2</a></li>
<li><a href="https://hub.hubzilla.hu/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://hub.hubzilla.hu/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://hub.hubzilla.hu/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

Nachdem wir ja im ersten Halbjahr einige unserer Schützlinge endgültig gehen lassen mussten, war wieder Kapazität in unserem Hunde-Altersruhesitz...

Nachdem wir ja im ersten Halbjahr einige unserer Schützlinge endgültig gehen lassen mussten, war wieder Kapazität in unserem Hunde-Altersruhesitz.

Und so hat Bájoska, eine nette ältere Dame (ca. 9 Jahre), Neufundländer-Mix wie auch unser Magic, bei uns ihr endgültiges Zuhause gefunden. Sie war wieder einmal der klassische Fall eines Hundes, der das Tierheim ansonsten nie mehr verlassen hätte: etwas größer, schwarz, "alt"... und überdies mit Herzwurmvorgeschichte (ist schon therapiert). Sowas will keiner haben.

Jedenfalls sprach meine Frau vor ein paar Tagen mit der Leiterin des örtlichen Tierheims hier und berichtete vom Stand unseres Hundealtersruhesitzes. Den Saša, den wir vor Jahren über sie aufgenommen hatten, mussten wir ja vor einiger Zeit erlösen. Na jedenfalls erwähnte meine Frau, dass wir nun wieder einmal Platz für Unvermittelbare hätten.

Und... natürlich gab es da die unvermittelbare Bájoska. Die sei voll lieb (auf den Fotos ständig am Lächeln... das sprach dafür), aber niemand würde sie haben wollen. Verträglich mit Hund und Katz und Spatz. Wir sollten sie uns doch mal am Sonntag anschauen kommen.

Gestern waren wir also da... und was soll ich sagen... so einen aufgeschlossenen, lieben Hund hab ich selten erlebt. Sie kam sofort auf uns zu, als würden wir uns schon ewig kennen und nun endlich nach längerer Zeit wiedersehen. Wir haben ja schon sehr lange Erfahrung mit Hunden aus dem Tierschutz, und wissen wie lange es dauern kann, bis so ein Engel Vertrauen gefasst hat und "angekommen" ist. So z.B. der Magic, dem sie ja so ähnlich sieht. Grundvertrauen hatte er schon nach ein paar Monaten, aber erst seit ein paar Wochen, also nach über einem Jahr bei uns, ist er so richtig endgültig angekommen... Kuscheln einfordern und sowas halt.

Na jedenfalls hat sie uns 😉😂 sofort adoptiert und wir haben sie auch sofort mitgenommen (das Tierheim ist eh völlig überfüllt).



Hier angekommen wollte ich sie dann mit der üblichen Strategie ans Rudel (acht gerettete Hunde) heranführen... also: Rudel im Haus, Neuzugang in den Garten und dann einen nach dem anderen, vom aufgeschlossensten bin zum skeptischsten Schützling in den Garten lassen. Magic war der erste, der durfte. Und dann hat unser Toni von innen selbst die Tür geöffnet und der Rest war ungeplant auf einen Schlag draußen.

Null Probleme! Geschaut, beschnuppert, akzeptiert!

Ob sie wohl mit ins Haus kommt? Klar kommt sie. Nun muss sie nur noch die Hundeklappe (ne große, wo sie alle durchpassen) lernen, das kennt sie noch nicht. Ich schätze, das geht auch in ein paar Tagen.

Auf jeden Fall verhält sie sich hier, als wäre sie schon immer bei uns gewesen. Ich habe noch nie einen Hund erlebt, der (sie kennt uns ja noch nicht einmal 24 Stunden) so in uns hineinkriecht, wie Bájoska. Ines hat sich gestern dann mit ihr auf den Boden gesetzt und wollte probieren, ob sie sich kämmen lässt (war dringend notwendig). Na klar... nach ein paar Stunden lag neben ihr ein "zweiter Hundefell-Hund". Und Bájoska hatte sich während des Bürstens auf ihre Schenkel gelegt. Unglaublich!

Die erste Nacht war völlig ohne Vorkommnisse. Vermutlich wird wohl der Rudi neben ihr gelegen haben... der war nämlich sofort "schockverliebt".



Und so hat sie ein neues Zuhause und darf bei uns bleiben... logisch...

Heute Morgen habe ich den Artikel Fediverse: Wenn Admins Communities zerstören im Blog C0D1 gelesen. Und ich kann den Ärger durchaus nachvollziehen...

Heute Morgen habe ich den Artikel Fediverse: Wenn Admins Communities zerstören im Blog C0D1 gelesen.

Und ich kann den Ärger durchaus nachvollziehen. Ich persönlich halte grundsätzlich vom Blocken kompletter Instanzen nicht sehr viel, bin auf der anderen Seite aber auch froh, dass es einen solchen Mechanismus gibt. Der ist nämlich durchaus sinnvoll, um wirklich echten Dreck von der eigenen Instanz fernzuhalten.

Fediverse-Server krimineller Vereinigungen, Instanzen die vom Ansatz her ausschließlich auf Spam-Verteilung ausgerichtet sind, welche Inhalte anderer Instanzen abgrasen, um sie selbst anzubieten oder die schon vom Namen her ganz klar zeigen, wofür sie stehen (ein altes, aber prominentes Beispiel ist hub.natehiggers.org), die blockiere auch ich instanzweit auf meinen Hubs.

Damit sperre ich aber nicht wirklich "normale" Nutzer dieser Instanzen aus, weil diese speziellen Instanzen gar keine "Normalen" Nutzer haben.

Nun ist es leider so, dass auch normale Fediverse-Instanzen (oft nur temporär bis der jeweilige Admin dem einen Riegel vorschiebt) von Nutzern missbraucht werden, um z.B. massenweise Spam zu verteilen. Die überwiegende Mehrheit der Nutzer gehört aber zu den "anständigen Fediversisten". Und die würde ich mit einem Instanz-Block einerseits von allen Kontakten, welche sie zu Nutzern meiner Hubs haben, als auch die Nutzer meiner Hubs von allen Kontakten, die einen Account auf der blockierten Instanz haben, komplett abschneiden. So, wie es Norbert halt auch widerfahren ist. Und deshalb blockiere ich solche Instanzen grundsätzlich erst einmal nicht. Grundsätzlich bedeutet aber, dass es Ausnahmen gibt. Wenn es eine Spam-Schwemme gibt, die von einer bestimmten Instanz ausgeht und diese von sehr vielen Spam-Accounts missbraucht wird, dann hat das Auswirkungen auf meine Nutzer (und ggf. sogar auf die Kontakte meiner Nutzer). Nun können Admins betroffener Instanzen oftmals nicht in kürzester Zeit etwas dagegen unternehmen. Deshalb besteht durchaus die Möglichkeit, dass ich solche Instanzen temporär, also für die Zeit, während welcher das Problem besteht, blockiere. Der Block wird dann wieder entfernt, sobald die Probleme beseitigt sind. Das ist aber nur die ultima Ratio. Solange es sich trotzdem um eine überschaubare Anzahl von missbräuchlich genutzten Accounts handelt und ich deren Handle dann auch kenne, landen nur die Accounts (Kanäle, wie es bei Hubzilla heißt) auf der instanzweiten Blockliste. Der Rest der Ausgangs-Instanz bleibt davon unberührt.

So... das ist mein Umgang in Bezug auf das Blockieren. Ach ja... von Blocklisten halte ich mal so gar nichts. Ungeprüft irgendwem blind zu vertrauen, dass er die Weisheit gepachtet hat, alleine alle blockierungswürdigen Instanzen zu kennen, kommt für mich nicht infrage. Bevor ich eine Instanz blockiere, schaue ich sie mir selbst genau an und entscheide dann für mich und meine eigenen Instanzen.

Aber das löst natürlich nicht die Probleme, die Norbert beschrieben hat. Denn es muss ja keiner so handhaben, wie ich. Und es kann letztlich jeder Instanzbetreiber (Admin) für seine eigene Instanz entscheiden, andere Instanzen einfach zu blockieren. Aus welchen Gründen auch immer. Und dann bliebe, wenn sich nichts daran ändern lässt, das, was er in seinem Artikel beschreibt:

Ich habe einen Account auf einer anderen Instanz und damit kann ich die mir wichtigen Menschen kontaktieren und darauf aufmerksam machen.

Aber weder kann ich von anderen erwarten, dass sie ihre Instanz wechseln, noch werde ich wechseln. Zumal diese Funktion ja auch nicht ganz so reibungslos funktioniert und Teile der Kontakte im Nirwana hängen bleiben.

Ja, das ist halt das Problem. Ein Zweit-Account hilft nicht viel. Man müsste den ja schon recht früh erstellen, dann auch dort alle Verbindungen eingehen, die man auf seinem Haupt-Account hat, hoffen, dass die "Follower" einem dann auch dort folgen, selbst wenn man dort nichts schreibt und letztlich dann, im konkreten Fall auf den Zweit-Account umsteigen. Nicht praktikabel! Umständlich! Aufwendig!

Das sind Probleme, die ich sehe, die mich aber selbst nicht betreffen. Denn ich nutze ein Fediverse-System, welches in dieser Hinsicht wesentlich "zensurresistenter" ist, als die Mehrheit der Fediverse-Dienste: Hubzilla.

Durch die nomadische Identität wäre es kein Problem, wenn eine fremde Instanz, bei welcher ich Kontakte habe, meinen Hub komplett blockiert. Ich habe ja Klone von meinem Kanal auf anderen Hubs (eigenen und fremden). Und für diese Klone brauche ich mich um fast nichts zu kümmern. Die Verbindungen, die ich mit dem Haupt-Kanal eingehe, die bestehen auch bei den Klonen. Was ich poste, wird ebenfalls bei den Klonen – ohne dass ich einen Finger krumm machen muss – synchronisiert. Es geht also nichts verloren. Da meine Identität (also mein Kanal) unabhängig von einem bestimmten Server ist, kann ich also jederzeit mit einem dieser Klone als genau der, den man im Fediverse kennt (also meine Identität), mit einem anderen Hub weitermachen. Wäre ich von einem umfassenden (also viele meiner Verbindungen betreffenden) Block betroffen, würde ich dann überlegen, ob ich nicht den Klon auf einem nicht blockierten Hub zu meinem primären Kanal (quasi Haupt-Kanal) machen sollte.

Ein kleines Manko sollte man dabei aber nicht verschweigen. Viele Dienste, die nur ActivityPub verwenden, kommen mit der nomadischen Identität nicht richtig klar. Ist man auf seinem Klon-Kanal, erkennt man diese daran, dass im Verbindungsverzeichnis neben dem Kontakt "An diesem Ort nicht verbunden" steht. Aber es gibt dort dann auch einen (meist grünen) Button "+Verbinden", welcher mit einem Klick die Verbindung auch beim Klon-Kanal erstellt.

So, das hilft jetzt dem Protagonisten aus dem eingangs erwähnten Artikel jetzt aktuell auch nicht weiter. Aber ich denke, die Möglichkeiten sind ein gutes Argument, Hubzilla als Zugangssoftware für das Fediverse zu nutzen. Wenn man denn ein- oder umsteigen möchte. Und das Onboarding ist jetzt auch keine schwarze Magie mehr. Abgesehen von sehr wenigen Einstellungen, ist ein frisch erstellter Hubzilla-Kanal sofort und ohne extreme Umstellung sofort für das Agieren im Fediverse geeignet. Die ganzen "Spezialitäten" von Hubzilla, welche für den Ruf sorgen, es sei ein unglaublich kompliziertes System, muss man ja gar nicht nutzen. Einiges ist etwas anders, das begreift man aber sehr schnell. So wie man z.B. auch ganz schnell die Spezialitäten eines Mastodon-Klienten begreift, wenn man von App "A" auf App "B" umsteigt.

Für Nutzer wie Norbert, der 2.300 Follower hat und der selbst 240 Kanäle, denen er folgt, gibt es leider keine einfache Lösung, um einfach mal so umzusteigen. Wer solche umfangreichen Kanäle hat, muss selbst entscheiden, ob er sich die Mühe macht, in die Freiheit umzusteigen, oder ob er sich weiterhin der Gefahr aussetzen möchte, durch pauschale Instanz-Blocks einen (womöglich nicht gerade kleinen) Teil seiner Kontakte komplett zu verlieren.

Z.B. bei Mastodon, kann man die Handles der Kanäle, welchen man folgt, als CSV-Datei exportieren. Leider gibt es keine Import-Funktion für solche Dateien in Hubzilla. Das liegt nicht zuletzt daran, dass Kontakte bei Hubzilla anders funktionieren. Grundsätzlich ist eine Verbindung bei Hubzilla genau das, was das Wort selbst sagt: eine Verbindung. Es geht also um einen wechselseitigen Kontakt. Es ist zwar möglich, dass fremde Nutzer dem eigenen Kanal nur folgen, man ihnen selbst aber nicht. Das ist jedoch die Ausnahme und kann von Hubzilla aus auch verhindert werden.

Dementsprechend muss man sich einmal die Arbeit machen und die exportierten "gefolgten Kanäle" z.B. aus der Exportdatei per Copy & Paste dem Hubzilla-Kanal hinzufügen.

Fremde Kanäle, die einem folgen, denen man selbst jedoch nicht folgt ("Follower") lassen sich nicht exportieren. Hier muss man also direkt z.B. bei der Mastodon-Instanz die Liste der Follower direkt aufrufen und sie ggf. als Verbindungen bei Hubzilla zufügen. Allerdings macht dieses Vorgehen einen selbst dann auch zum "Follower", was womöglich nicht gewünscht ist. Einfache wäre es, das Posten bei der fremden Instanz zu beenden und eine (am besten angepinnte) Nachricht zu veröffentlichen, dass man nun eine andere Instanz verwendet und dort auch gleich das Handle des Hubzilla-Kanals angeben. Dadurch gehen sicher einige Follower verloren, aber mit diesem Schwund muss man wohl leben. Karteileichen falen so raus... und solche Follower, die womöglich gar kein echtes Interesse an den Inhalten haben ebenfalls, denn wer die "Mühe" scheut einen neuen Kontakt einzugehen, der hat vermutlich gar kein so großes Interesse an dem Kanal und den Inhalten.

Wer mehr Sicherheit und Schutz davor haben möchte, Opfer von Instanzblocking zu werden, sollte in Erwägung ziehen, Hubzilla als Fediverse-Zugang zu nutzen. Selbst wenn man schon eine Reihe Kontakte hat, lässt sich solch ein Umstieg gut verwirklichen. Ja... und wer noch unabhängiger werden möchte: Die Installation eines eigenen Hubs ist wesentlich einfacher, als das Aufsetzen einer Instanz der meisten anderen Fediverse-Dienste.

Wie bereits erwähnt, ist der "Benutzername" in Nostr der öffentliche Schlüssel "npub". Das ist jetzt nicht besonders benutzerfreundlich und auch nicht zu merken. Schöner wäre es, wenn man ein Handle wie bei den typischen Sozialen Netzwerken und dem Fediverse haben könnte...

Wie bereits erwähnt, ist der "Benutzername" in Nostr der öffentliche Schlüssel "npub". Für meine Idetität "PepeCyB" lautet dieser

npub1h8ypsr7lw8l5r9pr9tm44xfkdm32welavahzmeez2t0flp5cs8qq04wc3j.

Das ist jetzt nicht besonders benutzerfreundlich und auch nicht zu merken. Schöner wäre es, wenn man ein Handle wie bei den typischen Sozialen Netzwerken und dem Fediverse haben könnte.

So nach dem Schema benutzername@irgendwashintendran.tld.

Und das ist mit Nostr ebenfalls möglich.

Es gibt für Nostr die sogenannten NIPs. Die Abkürzung NIP steht für Nostr Implementation Possibilities, welche beschreiben, auf welche Art und Weise bestimmte Funktionalitäten für Nostr von den Clients umgesetzt werden müssen.

Und da gibt es die NIP-05 mit der Bezeichnung Mapping Nostr keys to DNS-based internet identifiers (Zuordnung von Nostr-Schlüsseln zu DNS-basierten Internet-Identifikatoren).

Und genau dieses Dokument beschreibt, wie eine solche Zuordnung umzusetzen ist. Allerdings ist das Dokument nun wirklich nicht für den normalen Endbenutzer oder gar den Einsteiger geeignet. Deshalb hier jetzt eine Anleitung, wie man an ein "Nostr-Handle" gelangen kann. Ist gar nicht so kompliziert.

NIP-05 dient dazu, den Nostr-Schlüssel einer e-mail-ähnlichen Adresse zuzuordnen. Tatsächlich funktioniert es sehr ähnlich wie eine Webfinger-Adresse im Fediverse: Ein Client überprüft den Teil /.well-known/ eines Domainnamens auf ein nostr.json-Dokument. Also z.B.

GET https://tnevlos.xyz/.well-known/nostr.json?name=PepeCyB

Der Client erhält eine JSON-Antwort, in der der Name mit einer hexadezimal formatierten Version des dazugehörigen öffentlichen Schlüssels verbunden wird:

{

      "names": {
            "PepeCyB": "b9c8180fdf71ff4194232af75a99366ee2a767fd676e2de72252de9f869881c0"
      }

}

Die Nostr-Identität verweist also auf den NIP-05-Wert auf dem Server, der mit dem Namen übereinstimmt, welcher seinerseits auf die Nostr-Identität (öffentlicher Schlüssel) verweist.

Nun gibt es verschiedene Möglichkeiten, ein solches Handle zu erhalten. Es gibt Drittanbieter-Dienste, die Identitäten anbieten, oder man verfügt selbst über einen Server mit einem Domainnamen, auf welchem man die benötigte Datei ablegt.

Verschiedene Clients bieten solche Dienste an, wobei die Nutzung in der Regel kostenpflichtig ist. Ein einfacher Weg ist es, eine Adresse mit dem Dienst Alby zu erzeugen. Das erledigt man dort via Dashboard ➔ Settings ➔ Nostr Address. Hier muss man nur seinen öffentlichen Schlüssel angeben und es wird ein Handle erzeugt. Ist aber nicht jedermanns Sache (meine auch nicht), weil Alby ein Bitcoin-Dienst ist.

Verfügt man z.B. über eine Wordpress-Installation, so gibt es z.B. das Plugin Nostr Verify. Das muss man unter Wordpress installieren und dann kann man dort einen Namen (der Teil vor dem "@") und den eigenen öffentlichen Schlüssel (im Hex-Format – hiermit kann man den npub ins Hex-Format konvertieren: damus Key Converter) ein. Nun verfügt man über eine NIP-05-Adresse, wobei der Teil hinter dem "@" dem Domainnamen der WordPress-Installation entspricht.

Ein wenig technischer, aber die höchste Form der Unabhängigkeit ist es, die NIP-05-Adresse manuell einzurichten. Voraussetzung ist ein eigener oder gemieteter Server (oder auch Webspace), sowie eine eigene Domain.

Im Wurzelverzeichnis der Domain muss ein Unterverzeichnis .well-known vorhanden sein. Ggf. muss man es selbst anlegen. Wichtig ist, dass es öffentlich lesbar ist. In dieses Verzeichnis lädt man dann eine Datei mit dem Namen nostr.json hoch, welche folgenden Inhalt hat:

{

      "names": {
            "<BENUTZERNAME>": "HEX-SCHLÜSSEL"
      }

}

Auch hier benötigt man wieder die Hex-Version des öffentlichen Schlüssels.

Man kann auch mehrere Benutzernamen mit der Datei anlegen, um für mehrere Identitäten ein Handle festzulegen.

Wichtig ist nur, dass die Datei öffentlich erreichbar ist. Also nach dem Schema <URL_DES_EIGENEN_SERVERS>/.well-known/nostr.json. Ruft man diese Adresse im Browser auf, so muss die JSON-Datei angezeigt werden.

Nun muss diese Verknüpfung nur noch bekannt gemacht werden.

Das kann man mit seiner bevorzugten Nostr-App erledigen (die meisten bieten das an). Mit Iris z.B. gibt man einfach unter Settings ➔ Profile im Feld "User @ domain name verification (NIP-05)" das komplette Handle ein und klickt anschließend auf "Save".



Eine weitere Möglichkeit ist die Nutzung von nostr.app, wo man die NIP-05-Adresse im entsprechenden Feld einträgt und anschließend ganz unten auf den Button "SaveProfile" klickt.



Nun verfügt man über ein Nostr-Handle, unter welchem man von anderen Nutzern leichter gefunden werden kann und welches sich auch einfacher weitergeben lässt.

Schaut man auf die Webseite nostr apps, werden derzeit (Stand: 03.09.2025) 71 Apps angezeigt...

Schaut man auf die Webseite nostr apps, werden derzeit (Stand: 03.09.2025) 71 Apps angezeigt. Das kann einen schon erschlagen. Wieso gibt es eigentlich so viele verschiedene Apps? Nun, das liegt einerseits daran, dass man mit Nostr wesentlich mehr veranstalten kann, als nur Microblogging à la X, und andererseits daran, dass die Apps der eigentliche Motor von Nostr sind (die Relays sind eher der Treibstofftank). Während bei den üblichen Sozialen Netzwerken der Server (auf dem man sich registrieren muss) die Funktionalität und die Benutzeroberfläche anbietet, welche dann von Webbrowsern oder dummen Clients auf dem Endgerät dargestellt wird, ist es bei Nostr genau umgekehrt. Die eigentlichen FUnktionen und die Benutzeroberfläche werden von den Apps zur Verfügung gestellt, während der Server (Relay) lediglich die Daten verwaltet.

Und das sind die Gründe, weshalb es nicht die eine Nostr-App gibt, sondern sehr viele verschiedene. Jeder App-Entwickler hat eigene Vorstellungen, wie sein App funktionieren und wie sie sich dem Anwender darstellen soll. Und es gibt Allrounder-Apps, die viele verschiedene Funktionen von Nostr anbieten, aber auch sehr spezialisierte Apps, die vielleicht nur eine oder zwei Funktionalitäten zur Verfügung stellen.

So kann man mit Nostr auch (verschlüsselte) private Nachrichten versenden. Und so gibt es Apps, die genau nur das bieten. Oder Chat-Apps (auch Gruppenchat), Foto- oder Streaming-Apps, Blogging-Apps und viele mehr.