Hubzilla verfügt über die beiden Apps "Artikel" und "Karten". Sie sind eng miteinander verwandt und ermöglichen das Erstellen von Beiträgen im Artikelformat. Sie eignen sich für eine Artikelsammlung im eigenen Kanal oder können z.B. für eine echte Blog-Funktionalität genutzt werden. Weder die Artikel-, noch die Karten-App verfügt über eine eigene Suchfunktion. Aus diesem Grund habe ich ein Addon entwickelt, welches diese Funktionalität zur Verfügung stellt...

Hubzilla verfügt über die beiden Apps "Artikel" und "Karten". Sie sind eng miteinander verwandt und ermöglichen das Erstellen von Beiträgen im Artikelformat. Sie eignen sich für eine Artikelsammlung im eigenen Kanal oder können z.B. für eine echte Blog-Funktionalität genutzt werden.

Im Unterschied zu Postings, die in Grid (Verbund aller Zot6/Nomad-Hubs) und, sofern ActivityPub aktiviert ist, im Fediverse an Verbindungen verteilt (föderiert) werden, sind Artikel und Karten an den Kanal gebunden und werden nicht föderiert. Man kann sie aber in Grid und Fediverse bekannt machen, indem man den Link zu den Artikeln oder Karten in einem Posting teilt.

Die Suchfunktion von Hubzilla findet Inhalte des eigenen Kanals, aber keine Inhalte von Artikeln und Karten. Selbst wenn sie mit der Funktion zu finden wären, würden sie in der Regel in der Masse der Treffer untergehen. Weder die Artikel-, noch die Karten-App verfügt über eine eigene Suchfunktion.

Aus diesem Grund habe ich ein Addon entwickelt, welches diese Funktionalität zur Verfügung stellt. Dabei wird die Datenbank nicht jedes Mal durchsucht, es wird vielmehr ein eigener Index erstellt, der für die Suche verwendet wird. Beim Indizieren eines Artikels oder einer Karte wird eine deutsch- und englischsprachige Stoppwortliste berücksichtigt, um den Index in der Größe nicht zu groß werden zu lassen. Für die initiale Indizierung startet man die zu installierende App "AC Index" und führt eine Indizierung durch Klick auf den Button "Create / update Index" durch. Hier besteht auch die Auswahlmöglichkeit, ausschließlich Artikel, ausschließlich Karten oder sowohl Artikel als auch Karten in den Index einzubeziehen.



Auf dieser Verwaltungsseite, die nur dem Kanalinhaber zur Verfügung steht, befindet sich außerdem ein Link zur eigentlichen Suchseite, die auch von Besuchern genutzt werden kann ("Public search"). Der Link führt zur Seite acindex/search.



Werden neue Artikel oder Karten hinzugefügt, werden diese automatisch dem Index hinzugefügt, ohne die explizite Indexerstellung erneut aufzurufen.

Außerdem umfasst Das Addon ein Such-Widget ("acsearch"), welches z.B. auf die Artikel- oder Karten-Seite (App) mit dem PDL-Editor hinzugefügt werden kann. Damit steht die Suchfunktion komfortabel für jeden zur Verfügung.



Die Suche listet nach Klick auf den Button "Search" die gefundenen Artikel und/oder Karten auf. Ein Klick auf den Titel eines Suchergebnisses öffnet den Artikel bzw. die Karte in einem neuen Browser-Tab.

Um das Addon auf dem eigenen Hub zur Verfügung zu stellen, muss der Administrator mein Addon-Repo hinzufügen

util/add_addon_repo https://codeberg.org/derpepe/pepes-addons.git pepes-addons

und das Addon in der Adminoberfläche aktivieren.

Beachte: Der Index wird nicht föderiert und auch nicht zwischen Kanalklonen synchronisiert. Möchte man die Suche auch bei einem Kanalklon zur Verfügung stellen, muss man auch bei diesem die Indizierung explizit ausführen.

Mit Hubzilla kann man auch statische Webseiten anbieten, ohne das hubzilla-interne Webseiten-System zu nutzen... das geht mit der Cloud!

Hier drei Beispiele: mdBook, Hugo, Publii

Mit Hubzilla kann man auch statische Webseiten anbieten, ohne das hubzilla-interne Webseiten-System zu nutzen... das geht mit der Cloud!

Beispiel: mdBook-Seiten

Meine Dokumentationen erstelle ich alle mit dem Seitengenerator mdBook erstellt. Ich nutze dieses System gerne und habe den Workflow inzwischen verinnerlicht. Den gesamten Inhalt erstellt man damit mit Marksown-Dateien, die dann in einer weiteren Markdown-Datei (SUMMARY.md) in eine unsortierte Liste verlinkt werden. mdBook kann die Seite mit einem eigenen kleinen Webserver lokal so anzeigen, wie sie letztlich auch auf dem Server ausgeliefert wird. Änderungen an den Quell-Dateien werden dabei ständig sofort übernommen, sodass man jederzeit sieht, wie sich diese auf das Gesamtwerk auswirken.

Mit einem anderen Befehl erzeugt mdBook dann die komplette Struktur der statischen Webseite in einem eigenen Verzeichnis. Diesen Inhalt muss man nur auf den Server hochladen und die Seite ist online.

Ich habe versuchsweise die mdBook-Webseite “Nostr KnowledgeDB”, die ich normalerweise unter https://ninfo.tnevlos.xyz/ öffentlich anbiete, in das Verzeichnis “nostr_kdb” meines Kanals “thesmokinggnu@klacker.org” hochgeladen. Ruft man nun die Datei https://klacker.org/cloud/thesmokinggnu/nostr_kdb/index.html auf, wird die mdBook-Seite ganz normal dargestellt und man kann innerhalb der Seite mit sämtlichen Features, die mdBook bietet, surfen.

Beispiel: Hugo-Seiten

Ein sehr bekanntes System zur Erzeugung statischer Webpräsenzen ist Hugo. Auch Hugo-Webseiten kann man benutzbar in der Hubzilla-Cloud anbieten. Man muss dafür in der Datei hugo.toml bei baseURL
die URL des Hubzilla Cloud-Verzeichnisses eintragen und (wichtig) einen weiteren Eintrag uglyURLs = true anfügen (dieser sorgt dafür, dass Verweise innerhalb der Seitenstruktur immer als vollständige Dateinamen referenziert werden).

Als Beispiel habe ich das “berühmte” Quickstart-Beispiel aus der Hugo-Dokumentation verwendet und die erzeugte Seitenstruktur in das Verzeichnis “gohugoqs” hochgeladen. Ruft man nun https://klacker.org/cloud/pepecyb/gohugoqs/index.html auf, wird die Hugo-Webseite vollständig nutzbar dargestellt.

Beispiel: Publii

Ein weiteres, sehr komfortables System zur Erstellung statischer Webseiten mit dem Komfort eines modernen CMS ist die Software Publii. Ich habe hier zur Demonstration ein Mini-Blog mit dem Standard-Theme "Simple" (es gibt noch etliche andere Themes: Marketplace - Themes) und zwei Demo-Artikeln erstellt. Das hat keine fünf Minuten gedauert.



Wie auch bei Hugo ist es erforderlich, dass Verlinkungen innerhalb der Seitenstruktur das jeweilige Dokument vollständig referenzieren. Um das zu erreichen wählt man auf der Seite "Seiteneinstellungen" ➔ "Erweiterte Optionen" die Option "Immer index.html zu URL's hinzufügen" aus.



Für das Erstellen wählt man für den "Server" und dort "Relative URL's verwenden" und für den Ausgabetyp "Unkomprimierter Katalog". Den Inhalt des damit erzeugten Verzeichnisses muss man einfach nur in die Cloud hochladen und die statische Seite ist dann in der Cloud an entsorechnder Stelle über index.html erreichbar:



Das Beispiel-Blog ist hier erreichbar: https://klacker.org/cloud/tutorial01/publiidemo/index.html.

With its nomadic identity and sophisticated permission system, Hubzilla is a little different from the other well-known Fediverse services...

With its nomadic identity and sophisticated permission system, Hubzilla is a little different from the other well-known Fediverse services.

For example, when you create an account (a user account) on Mastodon with a specific instance (a Mastodon server), you immediately receive your identity with a ‘Fediverse name’ (handle/channel). The channel is permanently linked to the server. If you want to use a different Mastodon instance (perhaps because one is down for a long time), you have to create another account on the other server, but this also gives you a new identity that is completely independent of the other identity.

The user's profile information is also permanently linked to the account and channel. They can provide further information about themselves or their channel in their public profile. Of course, they only have a single profile, just as they only have a single channel.

With Hubzilla, you have to free yourself from this principle.

Creating an account on Hubzilla means nothing more or less than creating an account (a user account) on a Hubzilla instance (hub). This account is linked to the respective hub. However, a simple account alone does not allow you to do much on the hub except log in. It does not give you a Fediverse identity (a handle/channel).

What you can do with a user account, i.e. an account on a Hubzilla server, is create such a channel as soon as you are logged in. If you do this (which is usually offered immediately after creating an account, because it is practically the only thing you can do with a ‘bare’ account on Hubzilla), you finally have an identity in the Fediverse, a channel, and thus also a ‘Fediverse name’ (a handle).

When creating a channel on Hubzilla, you will be asked for the ‘channel name’. Here you enter a ‘descriptive’ name, i.e. the name that will appear in the grid (the network of Hubzilla servers) and in the Fediverse. It will be displayed when you or a visitor visits the channel page or profile page. You also need to enter a ‘short identifier’ (a short name) for the channel. This is the actual name of the channel and the part that appears in the handle before the ‘@’. It represents your actual identity.



Each channel has its own default profile. This is similar to the profile information found on other services. The standard profile is created automatically and is visible to everyone (in the default setting). Initially, it only contains the ‘channel name’ that you entered when creating the channel (this name is not actually part of the channel, but part of the profile, whereby the standard profile is linked to the channel).

A special feature of Hubzilla is that you can create as many channels as you want with just one user account. These are independent of each other and each have at least one standard profile. This means you don't have to create a new account on a server for each additional identity in the Fediverse.

Another special feature of Hubzilla is that each channel can have as many profiles as you want. The different profiles are linked to the channel. They are essentially different ‘business cards’ for the channel for different recipients. With multiple profiles, you can effectively print different ‘business cards’ that contain different information for the person you give the card to. This allows you to create a profile that contains more personal information that you don't want everyone to see, but only selected contacts. You can then assign the data to these contacts. When they visit the channel or profile page, they will see the ‘business card for special friends’ instead of the ‘standard business card’. Strangers, on the other hand, will only see the ‘standard profile business card’.





However, you cannot generally appear under any profile, but always appear as a channel. This means that you cannot ‘switch’ profiles and act with one profile. You act with the channel, and contacts or visitors see the contents of the respective profile as information about the channel. By default, this is the content of the standard profile.

Everything we do with our channel on Hubzilla (e.g. uploading files to the cloud or creating calendars, etc.) is done with our channel and not with our profile. The profiles are just different views of our channel for others.

There are reasons and advantages for separating accounts and channels on Hubzilla. The main reason for the separation is nomadic identity. The identity, i.e. the channel, is not permanently linked to an account and therefore not permanently linked to a specific server (hub), but is independent of it. The channel is the identity, but not the channel in connection with the hub.

I can take my identity, i.e. my channel, with me. But I can also export it and carry the files that represent it (including all keys) around with me on a USB stick, for example, if I want to.
However, in order to be ‘addressed’ in the Fediverse (and in the Grid), you need a handle. This consists of the channel name (i.e. the identity) and the domain of the hub. My channel must be located on some hub. And others must be able to find this out in order to interact with me.

Now, however, I can create another account on a different hub and clone my channel from the original hub to this second hub. The actual identity (represented by the short name) remains the same, only the domain of the hub, i.e. what comes after the ‘@’ in the handle, changes. Once I have a clone, everything I do with my original channel and all interactions with my original channel are automatically synchronised. They are in the same state.

Once I have created at least one clone of a channel, I need to specify which of the channels is the primary channel. The primary channel determines which handle I appear with in the Fediverse. The primary channel is always the channel on the hub where it was first created. However, I can specify that a channel on another hub is the primary channel via Settings -> Manage clone addresses. This is recommended, for example, if the original hub is unavailable for some reason for a period of time.

Thanks to the automatic synchronisation of the clones, I always have the option of working with my channel and appearing with it in the Fediverse.
For example, if someone sends a direct message to the handle of my primary channel, the clones also receive this message. I can also reply from a clone. The reply (i.e. the comment on the post) is then also available on the primary channel.

If someone sends a direct message to the handle of one of my channel clones, the message is delivered there, but also to the primary channel.

The various profiles are also synchronised.

As for identity portability, as mentioned above, you can export your channel. In addition, it is also possible to export the channel's data (content, wikis, websites, calendars and chat rooms) as downloadable files.
Hubzilla distinguishes between accounts, channels and profiles, whereby the profile is only the calling card of a channel and the channel is independent of the account. What you do as a Fediverse user, you do with your channel... and only with that channel. Different profiles are just ‘business cards’ with different information about the same channel. You can run your channels simultaneously under different accounts on different hubs, with the clones being automatically synchronised.

Now to the topic at hand: ‘What exactly is associated with the channel?’

Short answer: All settings, data and content, as well as the profiles!

To understand how this works, you just need to ignore the fact that Hubzilla allows multiple channels under one account. Just imagine that the channel you are currently using is like an account with another Fediverse service. All files you upload, all settings you make, all wiki pages, websites, calendars and calendar entries, all address book entries, all connections, all profiles, ..., ..., that you create belong to the channel.

Changing channels is like logging in to another Fediverse service with a different account. However, you don't need a different account with Hubzilla. Once you have changed channels, the settings from the channel you just came from will no longer apply. All settings, files, data, content, etc. are now different, namely those of the current channel. Channels are completely independent of each other. They only ‘share’ an account (although... if I clone one of them on another hub, then... never mind...).

Hubzilla ist mit seiner nomadischen Identität und dem ausgefeilten Berechtigungssystem ein wenig anders, als die sonst bekannten Fediverse-Dienste...

Hubzilla ist mit seiner nomadischen Identität und dem ausgefeilten Berechtigungssystem ein wenig anders, als die sonst bekannten Fediverse-Dienste.

Wenn man z.B. bei Mastodon einen Account (ein Benutzerkonto) bei einer Bestimmten Instanz (einem Mastodon-Server) erstellt, erhält man damit auch sofort seine Identität mit einem "Fediverse-Namen" (Handle / Kanal). Der Kanal ist fest mit dem Server verbunden. Möchte man eine andere Mastodon-Instanz nutzen (vielleicht weil die eine für eine längere Zeit ausfällt), so muss man sich auf dem anderen Server wieder einen Account erstellen, erhält damit aber auch eine neue Identität, welche völlig unabhängig von der anderen Identität ist.

Ebenfalls fix verbunden mit dem Account und dem Kanal sind die Profilinformationen des Nutzers. Er kann im öffentlichen Profil weitere Informationen zu sich oder zu seinem Kanal angeben. Er verfügt natürlich auch nur über ein einziges Profil, wie er ja auch nur über einen einzigen Kanal verfügt.

Bei Hubzilla muss man sich von dem Gedanken an dieses Prinzip frei machen.

Einen Account zu erstellen, bedeutet bei Hubzilla nicht mehr oder weniger, als sich einen Account (ein Benutzerkonto) auf einer Hubzilla-Instanz (Hub) zu erstellen. Dieser Account ist an den jeweiligen Hub gebunden. Mit einem reinen Account allein kann man auf dem Hub aber nicht viel anfangen, außer sich bei diesem einzuloggen. Man verfügt damit noch nicht über eine Fediverse-Identität (ein Handle / einen Kanal).

Was man aber mit einem Benutzerkonto, also einem Account bei einem Hubzilla-Server machen kann ist, dass man sich, sobald man eingeloggt ist, einen solchen Kanal erstellen kann. Tut man dies (was in der Regel nach der Account-Erstellung sofort angeboten wird, weil es praktisch das einzige ist, was man mit einem "nackten" Account bei Hubzilla anstellen kann), so hat man dann endlich auch eine Identität im Fediverse, einen Kanal, und damit auch einen "Fediverse-Namen" (ein Handle).

Beim Erstellen eines Kanal bei Hubzilla wird man nach dem "Namen des Kanals" gefragt. Hier gibt man einen "sprechenden" Namen ein, nämlich denjenigen, mit welchem man im Grid (das Netzwerk der Hubzilla-Server) und im Fediverse erscheint. Er wird angezeigt, wenn man selbst oder ein Besucher die Kanalseite oder die Profilseite aufruft. Außerdem muss man eine "kurze Kennung" (einen Kurznamen) für den Kanal eingeben. Das ist eigentliche Name des Kanals und der Teil, welcher im Handle vor dem "@" steht. Er stellt unsere eigentliche Identität dar.



Jeder Kanal verfügt über ein eigenes Standard-Profil. Dies entspricht quasi den Profilangaben, die es auch bei anderen Diensten gibt. Das Standard-Profil wird automatisch erstellt und ist für jeden sichtbar (bei Grundeinstellung). Es enthält zunächst nur den "Namen des Kanals", den man bei Kanalerstellung eingegeben hat (dieser Name ist also eigentlich nicht eigentlicher Bestandteil des Kanals, sondern Bestandteil des Profils, wobei das Standard-Profil an den Kanal gebunden ist).

Eine Besonderheit von Hubzilla ist, dass man sich beliebig viele Kanäle mit nur einem Benutzerkonto (Account) erstellen kann. Diese sind voneinander unabhängig und verfügen jeder auch mindestens über ein eigenes Standard-Profil. Man muss also nicht für jede weitere Identität im Fediverse einen neuen Account bei einem Server erstellen.

Eine weitere Besonderheit von Hubzilla ist, dass jeder Kanal beliebig viel Profile haben kann. Die verschiedenen Profile sind an den Kanal gebunden. Sie sind quasi sowas, wie verschiedene "Visitenkarten" des Kanals für verschiedene Adressaten. Mit mehreren Profilen kann man sich praktisch verschiedene "Visitenkarten" drucken, die jeweils unterschiedliche Informationen für denjenigen, welchem wir die Karte geben, aufweisen. So kann man ein Profil erstellen, das persönlichere Informationen enthält, die nicht jeder kennen soll, sondern nur ausgewählte Kontakte. Diesen Kontakte kann man dann das Protokoll zuweisen. Besuchen diese die Kanal- oder Profilseite, so wird ihnen die "Visitenkarte für spezielle Freunde" anstatt der "Standard-Visitenkarte" gezeigt. Fremde hingegen bekommen nur die "Visitenkarte Standard-Profil" zu sehen.





Man kann aber nicht allgemein unter einem beliebigen Profil auftreten, sondern man tritt immer als Kanal auf. Man kann also das Profil nicht "wechseln" und mit einem Profil agieren. Man agiert mit dem Kanal und Kontakte bzw. Besucher bekommen als Information zum Kanal die Inhalte des jeweiligen Profils zu sehen. Als Standard die Inhalte des Standard-Profils.

Alles, was wir mit unserem Kanal mit Hubzilla machen (z.B. die Cloud mit Dateien bestücken oder Kalender erstellen etc.), tun wir mit unserem Kanal und nicht mit unserem Profil. Die Profile sind nur verschiedene Ansichten unseres Kanals für andere.

Die Trennung von Account und Kanal bei Hubzilla hat Gründe und Vorteile. Der Hauptgrund für die Trennung ist die nomadische Identität. Die Identität, also der Kanal ist nömlich dadurch nicht fest mit einem Account und damit auch nicht fest mit einem bestimmten Server (Hub) verbunden, sondern unabhängig von diesem. Der Kanal ist die Identität, nicht aber der Kanal in Verbindung mit dem Hub.

Ich kann meine Identität, also meinen Kanal mitnehmen. Ich kann ihn aber auch exportieren und die Dateien, welche ihn repräsentieren (inklusive aller Schlüssel) z.B. auf einem USB-Stick mit mir herumtragen, wenn ich das möchte.

Damit man im Fediverse (und im Grid) "angesprochen werden kann", braucht man aber ein Handle. Dieses besteht aus dem Kanalnamen (also der Identität) und der Domain des Hubs. Auf irgendeinem Hub muss mein Kanal ja liegen. Und andere müssen das erfahren können, um mit mir zu interagieren.

Nun kann ich mir aber auf einem anderen Hub einen weiteren Account anlegen und meinen Kanal vom ursprünglichen Hub aus auf diesen zweiten Hub klonen. Die eigentliche Identität (repräsentiert vom Kurznamen) bleibt dabei gleich, nur die Domain des Hub, also was im Handle hinter dem "@" steht verändert sich. Habe ich nun einen Klon, so wird alles, was ich mit meinem ursprünglichen Kanal mache und alle Interaktionen mit meinem ursprünglichen Kanal automatisch synchronisiert. Sie haben den gleichen Stand.

Sobald ich mindestens einen Klon eines Kanals erstellt habe, muss festgelegt werden, welcher der Kanäle der primäre Kanal ist. Der primäre Kanal legt fest, mit welchem Handle ich im Fediverse erscheine. Als primärer Kanal ist zunächst immer der Kanal auf dem Hub, auf welchem er erstmalig erstellt wurde. Ich kann aber über Einstellungen -> Klon-Adressen verwalten festlegen, dass ein Kanal auf einem anderen Hub der primäre Kanal ist. Das empfiehlt sich z.B. wenn der ursprüngliche Hub aus irgendwelchen Gründen für einige Zeit nicht erreichbar ist.

Durch die automatische Synchronisation der Klone habe ich aber auf jedem Fall immer die Möglichkeit, mit meinem Kanal zu arbeiten und mit ihm im Fediverse aufzutreten.

Schickt z.B. jemand eine Direktnachricht an das Handle meines primären Kanals, so erhalten auch die Klone diese Nachricht. Ich kann auch von einem Klon aus antworten. Die abgesendete Antwort (also der Kommentar auf das Posting) ist dann auch beim primären Kanal verfügbar.

Schickt jemand eine Direktnachricht an das Handle eines meiner Kanalklone, so wird die Nachricht dort, aber auch beim primären Kanal zugestellt.

Auch die verschiedenen Profile werden synchronisiert.

Was die Portabilität der Identität betrifft: Man kann den Kanal, wie gesagt, exportieren. Darüber hinaus ist es auch noch möglich, die Daten des Kanals (Inhalte, Wikis, Webseiten, Kalender und Chaträume) als herunterladbare Dateien exportieren.

Bei Hubzilla werden also Account, Kanal und Profil unterschieden, wobei das Profil nur das Aushängeschild eines Kanals ist, und der Kanal unabhängig vom Account. Was man als Fediverse-Nutzer  macht, macht man mit seinem Kanal... und nur mit diesem. Verschiedene Profile sind nur "Visitenkarten" mit verschiedenen Informationen ein und desselben Kanals. Man kann seine Kanäle gleichzeitig unter verschiedenen Account bei verschiedenen Hubs betreiben, wobei die Klone automatisch synchron gehalten werden.

Nun noch zum Thema: "Was hängt am Kanal eigentlich so alles dran?"

Kurze Antwort: Alle Einstellungen, Daten und Inhalte, sowie die Profile!

Um zu verstehen, wie sich das mit diesen Dingen verhält, muss man nur einmal kurz beiseite schieben, dass mit Hubzilla unter einem Account mehrere Kanäle möglich sind. Einfach vorstellen, der aktuell genutzte Kanal ist sowas wie ein Account bei einem anderen Fediverse-Dienst. Alle Dateien, die man hoch lädt, alle Einstellungen, die man vornimmt, alle Wiki-Seiten, Webseiten, Kalender und Kalendereinträge, alle Adressbucheinträge, alle Verbindungen, alle Profile, ..., ..., die man erstellt, gehören zum Kanal.

Wechselt man den Kanal, dann ist das so, als würde man sich bei einem anderen Fediverse-Dienst mit einem anderen Account anmelden. Nur ist ein anderer Account bei Hubzilla nicht erforderlich. Hat man den Kanal gewechselt, so gelten dort natürlich nicht die Einstellungen des Kanals, von dem aus wir gerade gekommen sind. Alle Einstellungen, Dateien, Daten, Inhalte etc. sind nun andere, nämlich die des nunmehr aktuellen Kanals. Kanäle sind völlig unabhängig voneinander. Sie "teilen" sich lediglich einen Account (wobei... wenn ich einen davon auf einem anderen Hub klone, dann... egal...).

In the article ‘Follow hashtags’, I described a way to follow hashtags using a Hubzilla channel. It is even simpler and more comprehensive (complete) to do this with the relay service from FediBuzz...

In the article ‘Follow hashtags’, I described a way to follow hashtags using a Hubzilla channel.

To do this, you had to find a (preferably popular) Mastodon instance and add its RSS feed for a specific hashtag as an RSS connection.

It is even simpler and more comprehensive (complete) to do this with the relay service from FediBuzz.

To do this, open the ‘Connections’ app, click on the ‘+ Add’ button at the top and enter the following in the input field:

https://relay.fedi.buzz/tag/<HASHTAG>







You can also generate the link on the page https://relay.fedi.buzz/ by entering the hashtag at the bottom left under ‘Follow posts by #tag’. The address will then be displayed below the input field, ready to be copied.

After clicking on the ‘+’ button, the connection editor opens, where you can set word filters for content import, for example...



...or you can simply close the editor. You will then be connected to the relay and future posts with the selected hashtag will appear in the stream.



Advantage over the RSS version: The posts are actually ‘boosted’ into the stream, meaning they are genuine posts and can be commented on, liked/disliked, boosted again, quoted, etc.

Im Artikel "Hashtags folgen" hatte ich eine Möglichkeit beschrieben, um mit einem Hubzilla-Kanal Hashtags zu folgen. Noch simpler und umfassender (vollständiger) ist es mit dem Relay-Service von FediBuzz zu realisieren...

Im Artikel "Hashtags folgen" hatte ich eine Möglichkeit beschrieben, um mit einem Hubzilla-Kanal Hashtags zu folgen.

Dafür musste man sich eine (möglichst populäre) Mastodon-Instanz suchen und deren RSS-Feed für einen bestimmten Hashtag als RSS-Verbindung hinzufügen.

Noch simpler und umfassender (vollständiger) ist es mit dem Relay-Service von FediBuzz zu realisieren.

Dafür öffnet man die App "Verbindungen", klickt auf den Button "+ Add" ganz oben und gibt in das Eingabefeld folgendes ein:

https://relay.fedi.buzz/tag/<HASHTAG>







Den Link kann man sich auch auf der Seite https://relay.fedi.buzz/ erzeugen lassen, indem man unten links bei "Follow posts by #tag" den Hashtag eingibt. Unter dem Eingabefeld wird die Adresse dann "kopierfertig" angezeigt.

Nach dem Klick auf den "+" Button öffnet sich noch der Verbindungs-Editor, mit dem man z.B. Wortfilter für den Inhalts-Import festlegen kann...



...oder man klickt den Editor einfach so weg. Danach hat man eine Verbindung zu dem Relais und künftig erscheinen Beiträge mit dem gewählten Hashtag im Stream.



Vorteil gegenüber der Variante mit RSS: Die Beiträge werden tatsächlich in den Stream "geboostet", sind also als echte Beiträge vorhanden und können kommentiert, geliked/disliked, erneut geboostet oder zitiert etc. werden.

Hubzilla und die anderen Dienste der Hubzilla-Familie bieten die Möglichkeit, bestimmte Inhalte nur Nutzern zur Verfügung zu stellen, welchen die Berechtigung dafür gewährt wurde. Ob jemand berechtigt ist, wird anhand einer Authentifizierung erkannt...

Hubzilla und die anderen Dienste der Hubzilla-Familie [1] bieten die Möglichkeit, bestimmte Inhalte nur Nutzern zur Verfügung zu stellen, welchen die Berechtigung dafür gewährt wurde. Ob jemand berechtigt ist, wird anhand einer Authentifizierung erkannt.

OpenWebAuth

Dafür gibt es einen Mechanismus, welcher die Authentifizierung auf fremden Instanzen ermöglicht: OpenWebAuth (OWA; FEP-61cf).

Ganz simpel gesagt: Ihr meldet Euch bei Eurem Hub an und bleibt dort eingeloggt. Bei einem anderen, fremden Hub könnt Ihr Euch nun mit Eurem Kanalnamen authentifizieren.

Ihr seid bei dem fremden Hub eingeloggt und könnt dort nun alles tun, was Euch als authentifizierter Besucher eingeräumt wird. Und falls ein Kanal dieses Hubs bestimmte Inhalte nur für authentifizierte Nutzer oder gar speziell für Euch mit Eurem Kanal freigegeben hat, könnt ihr diese auch sehen oder damit interagieren.

Die "entfernte Authentifizierung" kann man durchführen, indem man in der Login-Maske auf den Button "Entfernte Authentifizierung" klickt. Nun erscheint ein Formular, in welches man die eigene Kanaladresse eingeben muss.







Beachte: Du musst im Browser auf dem Hub, wo Dein Kanal liegt, eingeloggt sein.

Ein Klick auf "Authentifizieren", und Du bist angemeldet. Erkennen kann man das, weil der Benutzer-Avatar im Hauptmenü nun das Avatarbild des Kanals zeigt, mit welchem Du Dich authentifiziert hast.





Über eben dieses Hauptmenü kannst Du Dich auch wieder bei dem fremden Hub abmelden – "Logge mich von dieser Seite aus" – oder mit einem Klick zu Deinem eigenen Kanal zurückkehren – "Bringe mich nach Hause (eigener Kanal)". Letzteres hat eine besondere Bedeutung, auf welche ich gleich in Bezug auf MagicAuth eingehe.

MagicAuth

Die Dienste im Grid (dem Verbund von Hubs der Hubzilla-Familie) bieten auch noch eine magische (automatische) Authentifizierung. Verlinkt man Inhalte mit den Tags [zrl][/zrl] bzw. [zmg][/zmg] (für Bilder) statt [url][/url] bzw. [img][/img], so wird über ein Authentifizierungs-Token die entfernte Authentifizierung automatisch durchgeführt. Das extra Anmelden kann entfallen.

Angenommen, der Nutzer mit dem Kanal "KanAl" auf dem Hub "A" hat in seiner Cloud eine Datei, welche er für den Nutzer mit dem Kanal "KanBl" auf dem Hub "B" freigeben möchte. Andere Nutzer sollen keinen Zugriff auf die Datei haben. "KanBl" sendet nun "KanAl" eine Direktnachricht mit dem Inhalt
[zrl=https://hub.b/cloud/kanbl/datei.txt]Datei für Dich[/zrl]
"KanAl" erhält die Nachricht und klickt auf den Link... und... zack, wird die Datei angezeigt. Er wurde "automagisch" beim Hub "B" authentifiziert (auch wieder sichtbar am Avatarbild im Hauptmenü).

Will er nun zurückkehren, so empfiehlt es sich, dies über den Menüpunkt "Bringe mich nach Hause (eigener Kanal)" im Hauptmenü zu tun. Damit kehrt man zum eigenen Hub zurück und loggt sich nicht erst beim fremden Hub ab, um anschließend "zu Fuß" zu seinem eigenen Hub zurückzukehren.

All diese Mechanismen gibt es derzeit leider nicht bei allen, nicht einmal bei sehr vielen Fediverse-Diensten, obwohl OpenWebAuth vernünftig spezifiziert ist. In der Hubzilla-Familie (Hubzilla, Zap – ja, es gibt tatsächlich noch mindestens einen Zap Hub –, (streams) und Forte) funktioniert es aber sehr gut. Vielleicht überwindet sich ja das eine oder andere Entwickler-Team anderer Fediverse-Dienst doch irgendwann noch, OpenWebAuth zu implementieren. Friendica hat die Funktion vor längerer Zeit eingebaut. Wie gut sie funktioniert, kann ich selbst nicht beurteilen, es gibt aber "Erfolgsmeldungen": Friendica nun mit funktionierendem OWA

---

[1] Hubzilla Timeline and History

Karten sind, neben dem vermutlich selten genutzten ursprünglichen Verwendungszweck "persönliche Planungskarten", ein wirklich gute und sinnvolle Möglichkeiten, Informationen, Links, Bookmarks, Notizen und viele andere Sachen kategorisiert zu erfassen...

Sofern der Admin das Addon "Cards" aktiviert hat, kann man als Nutzer die App "Karten" installieren und im App-Menü und/oder der Navigationsleiste verfügbar machen.

Aber was sind nun Karten? Wofür taugen sie?

Die Beschreibung des Addons gibt wirklich nicht viel her:

Persönliche Planungskarten erstellen

Aha...

In der Hilfe findet man, wenn man Informationen zu den Addons sucht, auch nicht wirklich viel:

Karten stellen einen dauerhaften Bereich für die Zusammenarbeit dar, der vom Social Stream getrennt ist. Sie sind etwas leichter als Webseiten und Wikis zur schnellen Organisation von Informationen und haben den Vorteil, dass sie Zusammenarbeit und Kommentare ermöglichen. Sie eignen sich gut für die Organisation komplexer Aufgaben, bei denen es häufig zu Aktualisierungen und Feedback kommt.

Und in einem alten (im Netz nicht mehr verfügbaren) Artikel von Andrew Manning heißt es:

Dein Team plant eine Veranstaltung und du musst die verschiedenen Aufgaben detailliert beschreiben, die du durchführen musst, um dies zu erreichen. Du möchtest über die Kommentare von Teammitgliedern aktuelle Konversationen führen, während ihr zusammenarbeitet, um die einzelnen Aufgaben zu definieren und durchzuarbeiten. Wenn du sie kategorisierst, kannst du die Aufgaben flüssig in Gruppen organisieren, die für deine Ziele sinnvoll sind.

Fein. Also damit kann man irgendwie einzelne Aufgaben von Projekten organsisieren, anderen ermöglichen, sich daran zu beteiligen... und sie werden nicht föderiert, verbleiben also auf dem eigenen Hub.

Brauch ich sowas?

Ich selbst hatte bisher keine Verwendung dafür. Bisher... denn Karten sind durchaus vielseitiger nutzbar (nicht unbedingt im ursprünglichen Sinn).
Anlässlich einer Frage im Hubzilla Support Forum, bei welcher es darum gibt, ob es bei Hubzilla auch sowas wie "Bookmarks" gibt, wurden die Karten mit einer diesbezüglichen Verwendung von hosh ins Spiel gebracht. Die Frage nach Bookmarks zielte nicht auf die Bookmarks / Lesezeichen von Hubzilla an, weil es dabei um tatsächliche URL geht, die man sichern kann, sondern um ein Feature, welches bei anderen Fediverse-Diensten als "Bookmark" oder "Lesezeichen" bezeichnet wird: Das Ablegen von Postings in einer Link-Sammlung... am besten auch noch kategorisiert.
Dafür bietet Hubzilla das Speichern in Ordnern. Das mach genau das, was vom Fragesteller im Grundsatz erwartet wurde.

Hosh antwortete in dem Thread, dass er seine Beitrags-Bookmarks mittels Karten organisiert. Er verlinkte auch auf seine Karten-Sammlung. Tatsächlich ist das Organisieren von Inhalten, welche man sich merken möchte, mit Karten eine wirklich tolle Sache. Karten können nämlich mit Kategorien versehen werden, die dann in der App "Karten" in der linken Seitenleiste aufgeführt werden. Es handelt sich bei Karten um Beiträge, welche, wie gesagt, nicht föderiert werden, nicht so aufwendig sind, wie Artikel und anders organisiert sowie schlanker als Wikiseiten oder Webseiten.
Im Endeffekt kann man Karten auch sehr gut als quasi kategorisierten Notizzettel-Kasten verwenden (abgesehen von der ursprünglichen Idee der Verwendung). Damit ist es, neben der Nutzung z.B. für eine kategorisierte Bookmark-Sammlung, auch als ein adäquater Ersatz für die App "Notizen" geeignet (letztere ist derzeit ja ein einziger großer "Notizzettel... und nicht mehr").

Und wie nutzt man sie nun? Das ist keine Wissenschaft.

Man ruft die App "Karten" auf.

Bei der ersten Benutzung ist sie noch leer.



Um eine neue Karte anzulegen, klicken wir nun in das Feld "Karte hinzufügen" und landet im Karten-Editor.



Er entspricht dem Editor für "Artikel", weist also ein Feld für den Titel, für eine Zusammenfassung, für Kategorien und ein Feld für den "Link zur Seite", sowie ein Eingabefeld für den Inhalt auf. Es sind Formatierungsmöglichkeiten wie auch bei anderen Beiträgen vorhanden und man kann mittels Berechtigungs-Einstellungen festlegen, wer die Karte überhaupt sehen darf.

Der Titel ist zwar optional, aber durchaus sinnvoll, sodass man sich das Ausfüllen des Feldes durchaus angewöhnen sollte.

Eine Zusammenfassung (Summary) bietet sich eigentlich nur bei größeren Inhalten an und ist eigentlich eher etwas für Artikel. Allerdings kann man mit der Zusammenfassung eine Art Inhaltswarnung verwirklichen. Dafür kann es taugen, wenn auch andere Nutzer auf unsere Karten zugreifen möchten (und dürfen).

Wirklich sinnvoll ist die Angabe mindestens einer Kategorie, denn diese werden in der linke Seitenleiste aufgeführt. Damit kann man seine Karten kategorisieren und sortieren. Klickt man später links auf eine Kategorie, werden nur die Karten angezeigt, welche mit der entsprechenden Kategorie markiert wurden.

Der "Link zur Seite" wird von Hubzilla automatisch befüllt und kann dafür genutzt werden, die Karte anderen per Link zugänglich zu machen. Der Link zu einer Karte hat dann folgendes Format:

<HUB>/cards/<KANALHANDLE>/<LINK ZUR SEITE>

Hubzilla erzeugt aber ziemlich "kryptische" Links, weshalb es sinnvoll ist, hier selbst einen "sprechenden", also verständlichen, Verweis einzugeben.
Beispiel für einen automatisch erzeugten Link gefällig? Bitte:



...ergibt:



Als Beispiel legen wir jetzt einfach einmal eine Karte mit einem externen Linkverweis an... z.B. auf die Hubzilla KnowledgeDB.



Nach dem Speichern erscheinen nun in der vorher leeren App sowohl die gerade eingegebene Karte, als auch zwei Kategorien in der Seitenleiste.



Die Kategorie "Alles" wird automatisch erzeugt, sobald die erste Karte angelegt wird. In ihr werden sämtliche (für den Nutzer sichtbaren) Karten angezeigt. Es ist auch die Kategorie, wie nach Aufruf der App "Karten" angezeigt wird.

Ein Klick auf die Kategorie "Links" ändert derzeit noch nichts, weil wir eh nur eine Karte haben, die zu dieser Kategorie gehört.
Wenn wir mehrere Karten angelegt haben, füllt sich die Kategorie "Alles", bis es unübersichtlich wird.



Nun können wir uns die Karten durch die Kategorie gefiltert anzeigen lassen. So bringt in meinem Beispiel ein Kick auf die Kategorie "Hubzilla" nur die beiden Karten zu diesem Thema auf den Screen.



Karten sind also, neben dem vermutlich selten genutzten ursprünglichen Verwendungszweck "persönliche Planungskarten", ein wirklich gute und sinnvolle Möglichkeiten, Informationen, Links, Bookmarks, Notizen und viele andere Sachen kategorisiert zu erfassen.

Wer das Wiki nach meiner Beschreibung für gemeinsame Arbeit an Dokumenten nutzt, möchte sich vielleicht nicht immer durch das App-Menü und die Wiki-Übersicht hangeln, um das Dokumenten-Wiki zu erreichen...

Wer das Wiki nach meiner Beschreibung für gemeinsame Arbeit an Dokumenten nutzt, möchte sich vielleicht nicht immer durch das App-Menü und die Wiki-Übersicht hangeln, um das Dokumenten-Wiki zu erreichen.

Na ja, dann "bauen" wir uns halt eine "App", die wir dann anpinnen, um mit nur einem Klick zu den gemeinsamen Dateien zu gelangen.

Dafür rufen wir im App-Menü die App-Verwaltung ("+ Apps") auf.

Bei den "Installierten Apps" finden wir oben rechts einen Button "Apps verwalten", auf den wir klicken.



In der App-Verwaltung ist nun, wieder oben rechts ein Button "Erstelle eine eigene App" zu sehen, den wir auch wieder anklicken.



Nun erscheint ein Formular zur App-Erstellung.

In diesem Formular geben wir der App einen Namen... also für unsere Zwecke nennen wir sie

gemeinsame Dateien.

In das Feld Ort (URL) der App geben wir nun die URL des Wikis ein... also

https://<hub>/wiki/<kanalname>/gemeinsame(20)Dokumente/Home

Dann fehlt nur noch ein passendes Icon. Ich habe im entsprechenden Feld

icon:file-text

eingegeben.

Hubzilla nutzt die Bootstrap-Icons. Um passende Icons für alle möglichen Zwecke zu finden, kann man unter https://icons.getbootstrap.com/ ein passendes Icon heraussuchen (die Filter-Funktion erleichtert das Finden) und erhält so den Namen des Icons. Den kann man dann mittels

icon:<name-des-icons>

adressieren.



Nun nur noch auf "Absenden" klicken... und die App "gemeinsame Dateien" ist erstellt.
Diese kann man dann einfach anpinnen und hat sie entweder in der Navigationsleiste (redbasic oder neuhub-tab) oder in der Seitenleiste (adminlte) samt Icon für den schnellen Zugriff auf das Wiki zur Verfügung.