Das Fediverse wird oft als Alternative zu den großen Sozialen Netzwerken bezeichnet. Und meist, fast immer, wird in diesem Zusammenhang Mastodon mit dem Fediverse gleichgesetzt und als Ausgangspunkt für das Fediverse empfohlen…
View article
View summary
Das Fediverse wird oft als Alternative zu den großen Sozialen Netzwerken bezeichnet. Und meist, fast immer, wird in diesem Zusammenhang Mastodon mit dem Fediverse gleichgesetzt und als Ausgangspunkt für das Fediverse empfohlen.
Das ist aber eine beschränkte, im Prinzip falsche Vorstellung, dass das Fediverse eine Alternative zu anderen Sozialen Netzwerken ist.
Grund für diesen Trugschluss ist u.a., dass nicht korrekt zwischen Social Media und Social Networking unterschieden wird.
Social Media ist eigentlich nur ein Oberbegriff, unter welchen Social Networks ebenfalls fallen und meint sämtliche digitalen Plattformen, die es Nutzern ermöglichen, Inhalte zu erstellen, zu teilen und zu konsumieren. Der Kern dieser Plattformen sind eben diese Medien, welche Texte, Bilder, Videos, Audioinhalte etc. umfassen.
Zu Social Media zählen auch die Social Networks, aber ebenso Blogging-Plattformen, Foren und Nachrichtenaggregatoren. Halt alles was dazu dient Inhalte anzubieten, zu kosumieren und ggf. zu teilen.
Der Fokus liegt hier weniger auf zwischenmenschlichen Beziehungen, als vielmehr auf dem Content selbst, seiner Erstellung, Kuratierung und Verbreitung.
Social Networking ist eine Teilmenge von Social Media und bezieht sich auf Plattformen, deren Hauptzweck der Aufbau und die Pflege persönlicher und beruflicher Beziehungen ist. Hier stehen Netzwerke, Profile und direkte Interaktionen im Vordergrund.
Jedes Social Network ist Social Media, aber nicht jedes Social Media ist ein Social Network.
Das Fediverse in seiner Gesamtheit ist ein Social-Media-Netzwerkverbund, nicht aber ausschließlich ein Social-Networking-Verbund. Instanzen unterschiedlichster Ausrichtung interagieren dort mit einem gemeinsamen Kommunikationsprotokoll namens ActivityPub. Mit welcher Software die Instanzen betrieben werden, ist zunächst einmal egal, was die Einordnung als Social-Media-Network betrifft.
Interessant wird die verwendete Software erst in dem Moment, wenn es darum geht, ob ein Fediversedienst auch Social Networking ist.
Mastodon (Microblogging-Dienst) ist kein reinrassiges Social Network. Das verwundert auch nicht, weil es in gewisser Weise Twitter/X nachbilden soll. Der Schwerpunkt von X war aber nie wirklich die soziale Interaktion, sondern vielmehr das schnelle Verbreiten von Inhalten, um damit möglichst viele Nutzer zu erreichen und diese in gewisser Weise an sich zu binden. Sicher ist ein gewisses Maß an sozialer oder geschäftlicher Interaktion möglich, aber nicht wirklich einfach. Je mehr Nutzern man folgt, desto schwieriger ist es, echte Dialoge zu führen. Diese Einschränkungen hat Mastodon, weil es X möglichst nachbilden möchte, natürlich übernommen. Dadurch, dass Postings nicht als eine zusammenhängende Konversation zwischen Startpost-Ersteller und Kommentatoren verwirklicht werden, ist eine konsistente Unterhaltung auch nur eingeschränkt möglich. Und bei vielen Beteiligten an solchen Gesprächen bleiben etliche auch außen vor, sofern sie nicht explizit erwähnt werden. X, und damit auch Mastodon, sind Social Media mit eingeschränkten Social-Networking-Fähigkeiten. Ein Anhaltspunkt dafür ist, dass zwischen Gefolgten und Followern bzw. im besten Falle Mutuals unterschieden wird. Und es ist Microblogging! Die Inhalte sind also größenbeschränkt. Das muss kein Manko sein. Es gibt allerdings auch andere Microblogging-Dienste im Fediverse, die dabei auch echtes Social-Networking bieten (und nebenbei auch vieles andere besser möglich, oder überhaupt erst möglich machen, was bei Mastodon fehlt).
Echtes Social-Networking bieten außerhalb des Fediverse Dienste wie Facebook, LinkedIn und, als es noch existierte, Google+. Hier steht (stand) die soziale Interaktion und das Pflegen von Kontakten im Mittelpunkt.
Von diesen drei Diensten ist Facebook die einzige Macroblogging-Anwendung mit 63.206 Zeichen. LinkedIn erlaubt inzwischen 3.000 Zeichen, und zählt damit mit Google+, welches letztlich ca. 1.000 Zeichen zur Verfügung stellte, zu den Microblogging Diensten. Trotzdem sind sie auf wechselseitige Interaktion ausgelegt und damit echtes Social Networking.
Was lernen wir daraus?
Es ist wichtig zu wissen, was man will.
Möchte man echte Interaktion, dann muss man sich einen Dienst suchen, welcher diese auch möglichst optimal bietet. Im Fediverse sind das Friendica, Hubzilla und (streams). Kontakte sind dort bidirektional, wirken also in beide Richtungen.
Geht es um reines Social Media in dem Sinne, dass man Inhalte schnell und ohne die Notwendigkeit der Interaktion und einer echten Verbindung zu anderen Nutzern verteilt, dann kann man sehr gut mit Mastodon fahren, es gibt aber auch noch andere hervorragende Dienste dieser Art, z.B. Pleroma/Akkoma, GoToSocial, Snac2, Mitra. etc.
Eine Art "Zwischending" sind Dienste wie Misskey und die Forkeys. Mit ihnen ist auch echte soziale Interaktion einfacher möglich, als bei den reinen Social Media Diensten, die Fähigkeiten gehen aber nicht so weit, wie bei den reinrassigen Social-Networking-Diensten.
Schließlich gibt es noch Spezialfälle... z.B. Lemmy und kbin, die sich in der Funktion an Reddit orientieren und Social Media mit stärkeren Social-Networking-Fähigkeiten bieten, oder Peertube als Social-Media-Ersatz für YouTube, Pixelfed als Social-Media-Ersatz für Instagram, Loops als Social-Media-Ersatz für TikTok...
Was man dabei nicht vergessen darf: Alle diese Dienste sind Teil des Fediverse. Deshalb ist es relativ egal, für welchen Dienst man sich entscheidet, wenn es darum geht, Nutzer anderer Dienste zu erreichen. Jeder im Fediverse ist für jeden im Fediverse erreichbar, egal bei welchem Dienst derjenige ist.
Es ist egal, wenn alle Deine Freunde bei Mastodon sind. Du kannst trotzdem Friendica oder Hubzilla nutzen und mit ihnen in Kontakt bleiben. Wobei... wenn es um halbwegs "echte Freundschaft" geht, wäre es vielleicht sogar besser, wenn sie früher oder später auch zu Friendica, Hubzilla und co. wechseln (und dabei ihre Kontakte mitnehmen können), um eine echte soziale Interaktion zu genießen.
Titelbild von KNFind auf Pixabay
Wehklagen über Spam-Wellen, über unangemessene Postings, über Dauer-Repeater (Extrem-Booster) über mangelnde Berechtigungskontrolle über nicht wirklich funktionierende Inhaltswarnungen sind Teil des Fediverse. Dann auch noch das Beklagen über Zeichenbegrenzungen, unzureichende Formatierungsmöglichkeiten, eingeschränkte Umfragen, Beschränkungen mitgeschickter, oft nicht einbettbarer, sondern nur angehängter Bilder gehören auch dazu.
Mein Rat: Kommt doch ins Grid!
Mein Rat: Kommt doch ins Grid!
View article
View summary
Wehklagen über Spam-Wellen, über unangemessene Postings, über Dauer-Repeater (Extrem-Booster) über mangelnde Berechtigungskontrolle über nicht wirklich funktionierende Inhaltswarnungen sind Teil des Fediverse. Dann auch noch das Beklagen über Zeichenbegrenzungen, unzureichende Formatierungsmöglichkeiten, eingeschränkte Umfragen, Beschränkungen mitgeschickter, oft nicht einbettbarer, sondern nur angehängter Bilder gehören auch dazu.
Das Grid ist der Netzwerkverbund aller Dienste, die Zot6/Nomad als Kommunikationsprotokoll verwenden. Aktuell sind das Hubzilla, (streams) und Zap (das zwar nicht wirklich weiterentwickelt wird... es gibt aber aktuell mindestens einen Hub, der mit Zap läuft).
Innerhalb des Grid greifen nicht nur die herausragenden Möglichkeiten des Berechtigungssystems vollständig, sondern der Zugriff auf beschränkte Ressourcen wird auch noch mittels magicAuth extrem komfortabel, weil der Nutzer sich gar nicht darum kümmern muss, seine Berechtigung für den Zugriff einer Ressource nachzuweisen. Läuft automatisch.
Hinzu kommt dann aber auch noch, dass viele der Vorteile des Berechtigungssystems auch auf die Interaktion mit dem ActivityPub-Fediverse wirken, sofern man sich nicht ausschließlich auf das Grid beschränkt.
Bei Hubzilla und (streams) hat man wirklich die Möglichkeit, ganz exakt festzulegen, wie man mit anderen Nutzern im Fediverse (Kanälen) interagiert. Ich gehe hier auf die Verfahrensweise mit Hubzilla ein, die vielleicht zunächst etwas komplizierter erscheint, aber trotzdem, wenn man es verstanden hat, recht einfach ist. Ich beschränke mich deshalb, weil es ausgesprochen unwahrscheinlich ist, dass irgendwer einen (streams)-Hub findet und sich dort registriert. Hubzilla zu nutzen ist in dieser Hinsicht wesentlich einfacher.
Um seinen Stream (so nennt sich das, was bei anderen Diensten die "Timeline" heißt) sauber zu halten und Belästigungen zu vermeiden, muss man sich zunächst für eine Kanalrolle entscheiden. Foren lasse ich hier bewusst weg, denn die sind ein Spezialfall. Zur Auswahl stehen lediglich drei Varianten: Öffentlich, Persönlich und Benutzerdefiniert. Öffentlich und Persönlich sind bequem, weil einem damit einiges an Denkarbeit abgenommen wird. Allerdings beschränkt man sich damit auch in den Möglichkeiten.
Bei der Kanalrolle "Öffentlich" ist es Verbindungen (also diejenigen, die einem selbst folgen und denen man ebenfalls folg, aber auch jedem im Internet) grundsätzlich erlaubt, unsere öffentlichen Postings zu sehen (in ihrem Stream/ihrer Timeline), unser Standardprofil, unsere Verbindungen, unsere öffentlichen Dateien (Bilder, Dokumente etc.) und unsere Web- und Wikiseiten zu sehen. Außerdem dürfen Verbindungen unsere Beiträge kommentieren, liken/disliken, uns Direktnachrichten schicken, Inhalte unseres Profils liken/disliken und mit uns chatten.
Diese Rechte können wir den Verbindungen (außer wir schränken bestimmte einzelne Inhalte im Zugriff explizit ein) auch nicht verwehren.
Es fällt auf, dass wir selbst es mit diesen Berechtigungen unseren Verbindungen nicht erlauben, uns Postings zu schicken. Wir sehen damit also in unserem Stream nicht, was die Verbindung selbst öffentlich gepostet hat. Damit wäre die Verbindung also nur sowas wie ein "Follower" (wie man es von anderen Diensten kennt). Es muss also noch eine weitere Möglichkeit geben, unseren Verbindungen dieses zu erlauben, damit wir mit unserem Kanal auch ein "richtiges" Social-Network-Erlebnis haben.
Die Berechtigungen, die ich eben beschrieben habe, sind die Berechtigungen der Kanalrollen. Sie beziehen sich also auf unserem Kanal. Es gibt aber auch noch die Kontaktrolle, welche unsere Verbindungen betrifft. In dieser können zusätzliche Berechtigungen eingeräumt werden (aber keine Berechtigungen der Kanalrolle wieder entzogen werden).
Zu jeder Kanalrolle gibt es immer eine Standard-Kontaktrolle. Bei der Kanalrolle "Öffentlich" erlaubt diese Standard-Kontaktrolle unseren Verbindungen, uns ihre Beiträge in unseren Stream zu schicken. Die werden damit also auch "followed". Zusätzlich erteilt die Standard-Kontaktrolle unseren Verbindungen auch noch das Wall-to-Wall-Posting und das Spiegeln unserer Beiträge in einem anderen Kanal. Auf diese beiden Spezialfälle gehe ich jetzt hier nicht ein. Wir ignorieren sie einfach erstmal.
Ein Kanal mit der Kanalrolle "Öffentlich" verhält sich also genau so, wie man das von ganz normalen Social-Network-Accounts erwartet.
Hinweis: Alles, was wir mit einem solchen Kanal veröffentlichen, wird auch öffentlich geteilt, sofern wir dies nicht für eine einzelne Ressource explizit anders festlegen.
Bei der Kanalrolle "Persönlich" ist es grundsätzlich erlaubt, unsere öffentlichen Postings (als "Follower") und unser Standard-Profil zu sehen. Ebenso unsere öffentlich geteilten Dateien, Webseiten und Wikis. Mehr nicht!
Auch "Persönlich" hat eine spezielle Standard-Kontaktrolle. Diese erlaubt es Verbindungen zusätzlich , uns Beiträge in unseren Stream zu schicken ("Followed") und unsere Verbindungen zu sehen.
Beachte: Alles, was wir mit einem solchen Kanal veröffentlichen ist nicht öffentlich, also nur für unsere Verbindungen zu sehen, sofern wir die Ressource nicht explizit als "öffentlich" veröffentlichen. Das ist ein entscheidender Unterschied zur Kanalrolle "Öffentlich".
Das Verhalten, dass bei der Kanalrolle "Persönlich" grundsätzlich erstmal nur an Verbindungen und damit nicht-öffentlich geteilt wird, liegt nicht an der Kanalrolle und auch nicht an der Standrad-Kontaktrolle, sondern am Mechanismus der Privacy Gruppen.
Auch wenn die App "Privacy Gruppen" nicht installiert ist, verfügt jeder Kanal über eine Privacy Gruppe namens "Freunde". Alle neuen Verbindungen werden dieser Privacy Gruppe automatisch zugewiesen. Bei der Kanalrolle "Öffentlich" hat das keine direkten Auswirkungen. Sehr wohl aber bei der Kanalrolle "Persönlich". Hier ist die Privacy Gruppe "Freunde" nämlich so konfiguriert, dass alles, was wir teilen grundsätzlich nur an Mitglieder dieser Gruppe geteilt wird. Das bewirkt, dass wir nicht-öffentlich teilen, es sei denn, wir stellen das für eine einzelne Ressource explizit ein.
Die dritte Kanalrolle, "Benutzerdefiniert" ist die flexibelste und auch diejenige, die man auswählen sollte, wenn man wirklich alle Unzulänglichkeiten unterbinden möchte, die andere Fediverse-Dienste aufweisen.
"Benutzerdefiniert" bedeutet, dass man auch die Kanalrolle in allen Berechtigungen selbst einstellen kann. In der Grundeinstellung, also wenn man einen Kanal mit dieser Rolle frisch erstellt hat, entspricht die Kanalrolle des Rolle "Persönlich", erlaubt aber grundsätzlich auch, dass Dritte unsere Verbindungen sehen können. Die Standard-Verbindungsrolle entspricht 1:1 der Verbindungsrolle "Persönlich". Die Privacy-Gruppe "Freunde" ist hingegen wieder so eingestellt, dass grundsätzlich öffentlich geteilt wird.
Wer nun also von seinem Social-Network-Dienst mehr möchte, als 08/15, muss Entscheidungen treffen, also ein wenig Hirnschmalz investieren. Ohne das geht es nicht... weder bei Hubzilla, noch bei irgendeinem anderen System, denn dieses weiß ja nicht, kann ja nicht ahnen, was wir möchten. Das müssen wir schon selbst wissen oder uns klarmachen. Wer das nicht will, muss halt mit den vordefinierten Rollen leben, die auch schon vieles besser machen, als bei manchem anderen System und die -- aufgrund der vorhandenen Mechanismen -- durchaus gewisse Dinge unterbinden können.
Möchte man aber kein System "von der Stange", sind einige Vorüberlegungen und Einstellungen notwendig.
Zunächst einmal hier die einzelnen Berechtigungen, die Hubzilla zur Konfiguration anbietet:
Etliche dieser Berechtigungen erklären sich von selbst, einige sind vielleicht nicht so klar und einige wenige kann man falsch verstehen. Im Anhang gibt es eine Tabelle, in der genauer erklärt wird, was sich hinter den Berechtigungen verbirgt.
Diese Berechtigungen sind das WAS, also was andere mit Inhalten/Ressourcen unseres Kanals tun können.
Dazu gehört dann aber auch noch das WER! Damit legen wir fest, wem bestimmte Dinge erlaubt bzw. verboten sind:
Auch hier gibt es einige "Wers", die etwas näher erläutert werden müssen. Dafür gibt es ebenfalls eine kleine Tabelle im Anhang.
Die Wichtigsten Adressaten für Berechtigungen sind: "Jeder im Internet" und "Nur die, denen Du es explizit erlaubst".
Nun ist es an der Zeit, sich Gedanken darüber zu machen, was man wem denn nun erlauben möchte. Dafür arbeitet man einfach die einzelnen Berechtigungen hintereinander ab und legt die Berechtigten fest.
Im Hauptmenü (das Menü, welches sich hinter unserem Avatarbild versteckt) wählt man
Einstellungen ➔ Kanal-Einstellungen
und legt im Abschnitt Grundeinstellungen die gewünschte Kanalrolle (Channel Role) fest. Also für unsere Zwecke "Benutzerdefiniert".
![kanal-rolle.png]( "kanal-rolle.png")
Nun wechselt man zu Einstellungen ➔ Privacy-Einstellungen
![privacy-settings.png]( "privacy-settings.png")
Die Grundeinstallungen dort sind selbsterklärend und sollten nach den eigenen Wünschen festgelegt werden. Wichtig ist hier die einzige "nicht selbsterklärende" Einstellung "Enable OCAP access". Dies ermöglicht, dass Medien (Bilder etc.) auch dann in einem Thread angezeigt werden, wenn diese eigentlich im Zugriff eingeschränkt sind. Wird diese Option nicht gewählt, kann es vorkommen, dass man eingebettete Bilder in manchen Threads nicht sieht. Meine Empfehlung: Option einschalten!
Die eigentliche Einstellung der Berechtigungen, die unser Kanal einräumt, findet man unter dem Button "Benutzerdefinierte Konfiguration der Channel Role" (dies wird bei den Kanalrollen "Öffentlich" und "Persönlich" nicht angezeigt, weil man diese dort nicht ändern kann).
Es wird eine Warnung angezeigt, die zwar berechtigt ist, aber wir WISSEN ja, was wir tun wollen.
![cr-warnung.png]( "cr-warnung.png")
Deshalb klicken wir auf den Button "Risiko akzeptieren und weitermachen" und landen im Formular für die genannten Berechtigungen. Die können wir nun nach unseren Wünschen und nachdem wir uns Gedanken gemacht haben, entsprechend konfigurieren.
Dabei aber immer daran denken: Die Berechtigung, die wir hier erteilen, können wir generell nicht zurücknehmen. Wir können sie höchstens in Einzelfällen "übersteuern", indem wir Inhalte/Ressourcen über die Berechtigungs-Einstellungen bestimmten Verbindungen zugänglich machen.
Es ist also ausgesprochen sinnvoll, bei der Kanalrolle so wenig freizügige Berechtigungen zu vergeben, wie möglich und nur so viele, wie für den Zweck absolut nötig.
Bedenkt: Nur was Ihr für "Jeder im Internet" erlaubt, kann auch wirklich öffentlich gesehen werden. Die spezielleren Berechtigungen sind eher etwas für Spezialfälle. "Nur die, denen Du es explizit erlaubst" wirkt sich hingegen ausschließlich auf Verbindungen aus.
Bedeutet: Alles, was wirklich jeder im Internet sehen können soll, bekommt "Jeder im Internet" (bei einem typischen öffentlichen Social-Network-Kanal) sind das "Kann meinen Kanal-Stream und meine Beiträge sehen", "Kann mein Standardprofil sehen" und "Kann meine Datei- und Bilderordner sehen". Wer öffentlich Wiki- oder Webseiten anbietet, erlaubt auch das Anschauen dieser durch jeden im Internet.
Den Rest kann man dann ruhigen Gewissens auf "Nur die, denen Du es explizit erlaubst" setzen. Damit können sich die Berechtigungen nur auf die eigenen Verbindungen auswirken.
Euch muss an dieser Stelle bewusst sein, dass die Standard-Kontaktrolle sehr viele zusätzlich Berechtigungen vergibt:
![std-contactrole.png]( "std-contactrole.png")
Diese Kontaktrolle kann man durchaus nutzen, um ein eher "klassisches" Social-Network-Verhalten für bestimmte Verbindungen zu erhalten.
Wenn man aber wirkliche Kontrolle haben möchte, muss man sich für andere Verbindungen weitere Kontaktrollen erstellen.
Sinnvoll wäre z.B. als neuer Standard für neue Verbindungen die Rolle "Follower". Diese erstellen wir, setzen die Option "Neuen Kontakten automatisch diese Rolle zuweisen" (damit wird die Option aus der Standard-Kontaktrolle gelöscht) und geben keine weiteren Berechtigungen, außer "Darf meine Beiträge kommentieren und mögen/nicht mögen". Damit verfügen Verbindungen mit dieser Kontaktrolle nur die in der Kanalrolle vergebenen Berechtigungen plus die Möglichkeit zum Kommentieren und liken/disliken. Wenn sich jemand mit Eurem Kanal verbindet, dann verhält er sich wie ein reiner Follower. Diese Kontaktrolle ist sinnvoll, wenn Ihr es anderen gestatten möchtet, Euch zu folgen.
Wenn Ihr meint, solche "Follower" sollten auch Eure Verbindungen anschauen können, gewährt Ihr zusätzlich halt auch diese Berechtigung.
Die nächste sinnvolle Kontaktrolle könnte dann z.B. "Followed" genannt werden. Dieser Rolle räumt Ihr dann, zusätzlich zu den Berechtigungen von "Follower", noch "Kann mir die Beiträge aus seinem Kanal schicken" ein, damit Ihr auch die Beiträge der Verbindung in Eurem Stream sehen könnt. Damit es sich auch "echt" anfühlt, wären hier auch noch die Berechtigungen "Kann mir direkte Nachrichten schicken", "Kann Profile und Profilsachen mögen/nicht mögen" und "Kann mit mir chatten" praktikabel.
Diese Kontaktrolle vergebt Ihr dann, wenn Ihr selbst eine Verbindung zu einem fremden Kanal herstellt... und an Kanäle, die Euch eine Kontaktanfrage schicken und denen Ihr "zurückfolgen" möchtet.
Eine Weitere Kontaktrolle würde ich "Followed+" nennen. Die ist für Kontakte aus dem Grid, und von den owa-fähigen Deinsten Forte und Friendica. Diesen kann man die zusätzliche Berechtigung "Kann auf meiner Kanal-Seite ("wall") Beiträge veröffentlichen" erteilen (wenn man denn möchte). Das Wall-to-Wall-Posting ist eine spezielle Art, Postings zu veröffentlichen. Wen eine unserer Verbindung ein Wall-Posting auf unserem Kanal veröffentlicht, dann erscheint dieses Posting in unserem Kanalstream. Es ist also in unserem Kanal veröffentlicht.
Für gute Freunde, verwandte, Mitglieder eines Teams, Vereins etc. kann man dann, je nach Notwendigkeit noch weitere Berechtigungen vergeben und für jede erdenkliche Art von Verbindungen ganz exakt zugeschnittene Kontaktrollen erstellen.
Privacy Gruppen sind Gruppen von Verbindungen, mit denen man das Teilen von Inhalten steuern kann. Sie ähneln dem, was man bei Google+ als "Kreise" kannte und was bei Diaspora* als "Aspekte" existiert. Möchte man einen Inhalt an eine bestimmte Gruppe von Verbindungen teilen, so kann man diese Verbindungen in eine Gruppe einfügen und mit den Berechtigungs-Einstellungen festlegen, dass der Inhalt ausschließlich mit den Gruppenmitgliedern geteilt wird. Das macht eine geschlossene Gruppenkommunikation möglich.
![bereinst.png]( "bereinst.png")
Eine weitere praktische Anwendung von Privacy Gruppen ist das zuteilen von Kontaktrollen auf einen Rutsch. Wenn man eine Kontaktrolle in der App "Contact Roles" öffnet, kann man auswählen, dass diese Kontaktrolle allen Gruppenmitgliedern einer Privacy Gruppe zugewiesen wird. Beachte: Das wirkt sich nur auf Verbindungen aus, die sich zu diesem Zeitpunkt bereits in der Privacy Gruppe befanden. Auf später hinzugefügte Verbindungen wirkt es sich nicht aus. Hier muss man ggf. die Gruppen-Zuweisung wiederholen.
Es gibt Nutzer im Fediverse, die wirklich exzessiv "Boosten/Repeaten". Trotzdem mag man diesen Nutzern folgen, weil die wenigen (oder vielleicht nicht einmal wenigen) ihrer eigenen Postings insteressant sind und man sie in seinem Stream finden möchte. Aber es kommt zu viel "Rauschen" herein, weil halt auch zu viel wiederholt wird. Bei Hubzilla ist es kein Problem, diese Repeats loszuwerden, ohne die "echten" Postings zu verlieren. Man kann für jede Verbindung einen Filter einrichten, der z.B. Repeats der Verbindung nicht in den Stream importiert.
Dafür öffnet man aus der App "Verbindungen" heraus den Verbindungs-Editor (kleines Bleistift-Symbol) und trägt im Tab "Filter für den Inhalt" im Feld "Beiträge mit diesem Text nicht importieren" die Zeile
ein. Damit werden Repeats (Wiederholungen / Boosts) von dieser Verbindung nicht mehr in den eigenen Stream importiert.
![no-repeats.png]( "no-repeats.png")
Neben den eben erwähnten Kontaktfiltern gibt es auch noch Kanalfilter, die sich auf den gesamten Kanal auswirken. Auch hier könnte man z.B. die Zeile zur Repeat-Unterdrückung unterbringen. Das würde dann aber bewirken, dass gar keine Repeats mehr im Kanal erscheinen, also auch solche nicht, die vielleicht erwünscht sind.
Kanalfilter findet man unter Einstellungen ➔ Kanal-Einstellungen ➔ Beiträge mit diesem Text nicht importieren
Während bei den meisten Diensten im Fediverse der Verfasser dafür verantwortlich gemacht wird, bestimmte Inhalte hinter einer Inhaltswarnung zu verstecken, funktioniert Hubzilla genau anders herum. Hier legt der Empfänger fest, was ihn "triggern" könnte oder was ihn "nervt". Das ist eigentlich auch ausgesprochen sinnvoll, weil ich selbst am besten weiß, was ich nicht sofort in meinem Stream sehen möchte. Wenn der Absender dafür verantwortlich ist, muss er ja erahnen, was ich nicht sehen möchte... und verbirgt solche Inhalte dann zwangsweise auch vor anderen Nutzern, die davor aber gar nicht gewarnt werden möchten.
Wer sich mit Hubzilla also vor bestimmten Inhalten schützen möchte, installiert die App "NSFW". Das ist eine einfache Filter-App, in welcher man eingeben kann, bei welchen Inhalten ein Posting zunächst ausgeblendet hinter einer Schaltfläche verborgen bleibt. Es kommt also nicht darauf an, das der Absender errät, was ich nicht sehen möchte und eine Inhaltswarnung verwendet (die sich dann auch auf alle auswirkt, die seinen Beitrag anschauen), sondern darauf, dass ich als Empfänger festlege, was verborgen werden soll.
Bewege ich mich also nur im Grid und habe auch nur Verbindungen zum Grid, muss ich mich um die Befindlichkeiten anderer nicht kümmern. Sobald man aber auch Teil des Fediverse wird, hilft unseren "NSFW"-App nicht weiter, denn die meisten anderen Dienste haben diesen Mechanismus nicht. Möchten wir also rücksichtsvoll vorgehen, müssen wir doch auch für andre mitdenken und erraten, was irgendwen in der weiten Welt "triggern" könnte.
Und das Ausblenden eines solchen Eintrags verwirklichen wir dann einfach, indem wir das Zusammenfassungsfeld (Summary) im Beitragseditor z.B. mit "Inhaltswarnung" befüllen. Nun sind auch nutzer anderer Dienste "geschützt".
Nun aber ein Spezialfall:
Es ist allgemein bekannt, dass viele sich entsetzt schütteln, wenn sie in einem Posting von Dieter Bohlen angestarrt werden (mir selbst geht es nicht so... ich mag ihn... zu erklären weshalb, würde hier aber zu weit führen). Nun wollen wir ein Posting verfassen, in welchem ein Bild von D. B. eingebunden ist. Um Nutzer aus dem Grid zu schützen, müsste ich z.B. das Wort "Bohlen" im Text unterbringen, und schon wären alle "gerettet", die in "NSFW" dieses Wort als Filter haben.
Aber angenommen, wir wollen nur das Bild selbst ausblenden und ahnen, dass es Nutzer gibt, die gerne mit Holz arbeiten und deshalb das Wort "Bohlen" auch nicht als Inhaltswarnung im Filter haben. Nun, dann können wir das Bild bei Hubzilla einfach zwischen die Tags
Aber ehrlich... das soll echt nicht UNSER Problem sein. Wir können alles dafür tun, dass bestimmte Inhalte verborgen bleiben, aber nichts daran ändern, wenn andere Dienste das nicht richtig verarbeiten.
Abgesehen davon ist es möglich auch Teile eines Postings zunächst zu verbergen (BTW: beliebig viele Teile), indem man das Spoiler-Tag verwendet. Funktioniert aber zuverlässig halt nur im Grid.
Na ja, was soll man sagen?
Hubzilla packt an die 16 Millionen Zeichen. Dieser Artikel hier ist also ein Fliegenschiss mit ca. 24.000 Zeichen. ;-)
BBcode "Hubzilla-Flavour" bietet umfangreiche Textgestaltungsmöglichkeiten. Leider werden diese vom derzeitigen Beitragseditor nicht alle vereinfacht z.B. über Buttons und Dialoge angeboten. Hier müsste dringend noch nachgebessert werden (könnte mein nächstes Projekt werden). Zumindest verfügt der Editor über eine Autovervollständigung, die hilfreich ist, wenn man weiß, was die BBcode Tags bewirken.
Was Hubzilla von vielen Diensten unterscheidet ist, dass Medien wirklich in den Beitrag eingebettet werden, also an der Stelle erscheinen, wo wir sie unterbringen. Die Anzahl an Medien ist außerdem ebenfalls nicht beschränkt.
Bedenkt aber, wenn Ihr Beiträge ins Fediverse teilt, dass es Dienste gibt, die nicht nur Medien (also z.B. Bilder) hinten anhängen, sondern auch auf wenige (bei Mastodon vier) begrenzen. Es ist deshalb sinnvoll, einen Hinweis auf die tatsächliche Anzahl von Bildern hinzuweisen und dass es erforderlich sein kann, das Original-Posting auf Eurer Heimat-Instanz zu besuchen, um alle Bilder (und die auch noch korrekt eingebettet) sehen zu können. Klingt komisch, ist aber so. ;-) :-D
Kommt einfach ins Grid! Besorgt euch einen Account bei Hubzilla. Ihr könnt das ja zusätzlich zu Eurem aktuellen Fediverse-Account tun. Und importiert Eure Follower-/Following-Liste. Dafür gibt es (sofern der von Euch gewählte Hub das Addon installiert hat) inzwischen ein Addon, das die typischen Exportdateien (csv) von Mastodon und co. verarbeitet. Richtet Euren Kanal so ein, wie Ihr es euch vorstellt und nutzt es.
Es ist durchaus möglich, dass Ihr dann irgendwann immer öfter mit Hubzilla, statt mit dem ursprünglichen Dienst im Fediverse unterwegs seid. Und wenn Ihr dann auch noch Kontakte zu Nutzern im Grid habt, werdet Ihr feststellen, dass die soziale Interaktion damit noch viel komfortabler ist. Vielleicht wagt ja dann irgendwann auch die eine oder andere eurer alten Verbindungen auch den Schritt und Ihr könnt den Komfort gemeinsam genießen.
Wer?
![wer.png]( "wer.png")
Was?
![was.png]( "was.png")
Mein Rat: Kommt doch ins Grid!
Grid? Was ist das denn?
Das Grid ist der Netzwerkverbund aller Dienste, die Zot6/Nomad als Kommunikationsprotokoll verwenden. Aktuell sind das Hubzilla, (streams) und Zap (das zwar nicht wirklich weiterentwickelt wird... es gibt aber aktuell mindestens einen Hub, der mit Zap läuft).
Innerhalb des Grid greifen nicht nur die herausragenden Möglichkeiten des Berechtigungssystems vollständig, sondern der Zugriff auf beschränkte Ressourcen wird auch noch mittels magicAuth extrem komfortabel, weil der Nutzer sich gar nicht darum kümmern muss, seine Berechtigung für den Zugriff einer Ressource nachzuweisen. Läuft automatisch.
Hinzu kommt dann aber auch noch, dass viele der Vorteile des Berechtigungssystems auch auf die Interaktion mit dem ActivityPub-Fediverse wirken, sofern man sich nicht ausschließlich auf das Grid beschränkt.
Bei Hubzilla und (streams) hat man wirklich die Möglichkeit, ganz exakt festzulegen, wie man mit anderen Nutzern im Fediverse (Kanälen) interagiert. Ich gehe hier auf die Verfahrensweise mit Hubzilla ein, die vielleicht zunächst etwas komplizierter erscheint, aber trotzdem, wenn man es verstanden hat, recht einfach ist. Ich beschränke mich deshalb, weil es ausgesprochen unwahrscheinlich ist, dass irgendwer einen (streams)-Hub findet und sich dort registriert. Hubzilla zu nutzen ist in dieser Hinsicht wesentlich einfacher.
Vordefinierte Rollen oder eigene Entscheidungen
Um seinen Stream (so nennt sich das, was bei anderen Diensten die "Timeline" heißt) sauber zu halten und Belästigungen zu vermeiden, muss man sich zunächst für eine Kanalrolle entscheiden. Foren lasse ich hier bewusst weg, denn die sind ein Spezialfall. Zur Auswahl stehen lediglich drei Varianten: Öffentlich, Persönlich und Benutzerdefiniert. Öffentlich und Persönlich sind bequem, weil einem damit einiges an Denkarbeit abgenommen wird. Allerdings beschränkt man sich damit auch in den Möglichkeiten.
Bei der Kanalrolle "Öffentlich" ist es Verbindungen (also diejenigen, die einem selbst folgen und denen man ebenfalls folg, aber auch jedem im Internet) grundsätzlich erlaubt, unsere öffentlichen Postings zu sehen (in ihrem Stream/ihrer Timeline), unser Standardprofil, unsere Verbindungen, unsere öffentlichen Dateien (Bilder, Dokumente etc.) und unsere Web- und Wikiseiten zu sehen. Außerdem dürfen Verbindungen unsere Beiträge kommentieren, liken/disliken, uns Direktnachrichten schicken, Inhalte unseres Profils liken/disliken und mit uns chatten.
Diese Rechte können wir den Verbindungen (außer wir schränken bestimmte einzelne Inhalte im Zugriff explizit ein) auch nicht verwehren.
Es fällt auf, dass wir selbst es mit diesen Berechtigungen unseren Verbindungen nicht erlauben, uns Postings zu schicken. Wir sehen damit also in unserem Stream nicht, was die Verbindung selbst öffentlich gepostet hat. Damit wäre die Verbindung also nur sowas wie ein "Follower" (wie man es von anderen Diensten kennt). Es muss also noch eine weitere Möglichkeit geben, unseren Verbindungen dieses zu erlauben, damit wir mit unserem Kanal auch ein "richtiges" Social-Network-Erlebnis haben.
Die Berechtigungen, die ich eben beschrieben habe, sind die Berechtigungen der Kanalrollen. Sie beziehen sich also auf unserem Kanal. Es gibt aber auch noch die Kontaktrolle, welche unsere Verbindungen betrifft. In dieser können zusätzliche Berechtigungen eingeräumt werden (aber keine Berechtigungen der Kanalrolle wieder entzogen werden).
Zu jeder Kanalrolle gibt es immer eine Standard-Kontaktrolle. Bei der Kanalrolle "Öffentlich" erlaubt diese Standard-Kontaktrolle unseren Verbindungen, uns ihre Beiträge in unseren Stream zu schicken. Die werden damit also auch "followed". Zusätzlich erteilt die Standard-Kontaktrolle unseren Verbindungen auch noch das Wall-to-Wall-Posting und das Spiegeln unserer Beiträge in einem anderen Kanal. Auf diese beiden Spezialfälle gehe ich jetzt hier nicht ein. Wir ignorieren sie einfach erstmal.
Ein Kanal mit der Kanalrolle "Öffentlich" verhält sich also genau so, wie man das von ganz normalen Social-Network-Accounts erwartet.
Hinweis: Alles, was wir mit einem solchen Kanal veröffentlichen, wird auch öffentlich geteilt, sofern wir dies nicht für eine einzelne Ressource explizit anders festlegen.
Bei der Kanalrolle "Persönlich" ist es grundsätzlich erlaubt, unsere öffentlichen Postings (als "Follower") und unser Standard-Profil zu sehen. Ebenso unsere öffentlich geteilten Dateien, Webseiten und Wikis. Mehr nicht!
Auch "Persönlich" hat eine spezielle Standard-Kontaktrolle. Diese erlaubt es Verbindungen zusätzlich , uns Beiträge in unseren Stream zu schicken ("Followed") und unsere Verbindungen zu sehen.
Beachte: Alles, was wir mit einem solchen Kanal veröffentlichen ist nicht öffentlich, also nur für unsere Verbindungen zu sehen, sofern wir die Ressource nicht explizit als "öffentlich" veröffentlichen. Das ist ein entscheidender Unterschied zur Kanalrolle "Öffentlich".
Das Verhalten, dass bei der Kanalrolle "Persönlich" grundsätzlich erstmal nur an Verbindungen und damit nicht-öffentlich geteilt wird, liegt nicht an der Kanalrolle und auch nicht an der Standrad-Kontaktrolle, sondern am Mechanismus der Privacy Gruppen.
Auch wenn die App "Privacy Gruppen" nicht installiert ist, verfügt jeder Kanal über eine Privacy Gruppe namens "Freunde". Alle neuen Verbindungen werden dieser Privacy Gruppe automatisch zugewiesen. Bei der Kanalrolle "Öffentlich" hat das keine direkten Auswirkungen. Sehr wohl aber bei der Kanalrolle "Persönlich". Hier ist die Privacy Gruppe "Freunde" nämlich so konfiguriert, dass alles, was wir teilen grundsätzlich nur an Mitglieder dieser Gruppe geteilt wird. Das bewirkt, dass wir nicht-öffentlich teilen, es sei denn, wir stellen das für eine einzelne Ressource explizit ein.
Die dritte Kanalrolle, "Benutzerdefiniert" ist die flexibelste und auch diejenige, die man auswählen sollte, wenn man wirklich alle Unzulänglichkeiten unterbinden möchte, die andere Fediverse-Dienste aufweisen.
"Benutzerdefiniert" bedeutet, dass man auch die Kanalrolle in allen Berechtigungen selbst einstellen kann. In der Grundeinstellung, also wenn man einen Kanal mit dieser Rolle frisch erstellt hat, entspricht die Kanalrolle des Rolle "Persönlich", erlaubt aber grundsätzlich auch, dass Dritte unsere Verbindungen sehen können. Die Standard-Verbindungsrolle entspricht 1:1 der Verbindungsrolle "Persönlich". Die Privacy-Gruppe "Freunde" ist hingegen wieder so eingestellt, dass grundsätzlich öffentlich geteilt wird.
Eigene Entscheidungen
Wer nun also von seinem Social-Network-Dienst mehr möchte, als 08/15, muss Entscheidungen treffen, also ein wenig Hirnschmalz investieren. Ohne das geht es nicht... weder bei Hubzilla, noch bei irgendeinem anderen System, denn dieses weiß ja nicht, kann ja nicht ahnen, was wir möchten. Das müssen wir schon selbst wissen oder uns klarmachen. Wer das nicht will, muss halt mit den vordefinierten Rollen leben, die auch schon vieles besser machen, als bei manchem anderen System und die -- aufgrund der vorhandenen Mechanismen -- durchaus gewisse Dinge unterbinden können.
Möchte man aber kein System "von der Stange", sind einige Vorüberlegungen und Einstellungen notwendig.
Zunächst einmal hier die einzelnen Berechtigungen, die Hubzilla zur Konfiguration anbietet:
- Kann meinen Kanal-Stream und meine Beiträge sehen
- Kann mir die Beiträge aus seinem Kanal schicken
- Kann mein Standardprofil sehen
- Kann meine Verbindungen sehen
- Kann meine Datei- und Bilderordner sehen
- Kann in meine Datei- und Bilderordner hochladen/ändern
- Kann die Webseiten meines Kanals sehen
- Kann meine Wiki-Seiten sehen
- Kann Webseiten in meinem Kanal erstellen/ändern
- Kann meine Wiki-Seiten bearbeiten
- Kann auf meiner Kanal-Seite ("wall") Beiträge veröffentlichen
- Darf meine Beiträge kommentieren und mögen/nicht mögen
- Kann mir direkte Nachrichten schicken
- Kann Profile und Profilsachen mögen/nicht mögen
- Kann mit mir chatten
- Kann meine öffentlichen Beiträge in anderen Kanälen zitieren/spiegeln
- Kann meinen Kanal administrieren
Etliche dieser Berechtigungen erklären sich von selbst, einige sind vielleicht nicht so klar und einige wenige kann man falsch verstehen. Im Anhang gibt es eine Tabelle, in der genauer erklärt wird, was sich hinter den Berechtigungen verbirgt.
Diese Berechtigungen sind das WAS, also was andere mit Inhalten/Ressourcen unseres Kanals tun können.
Dazu gehört dann aber auch noch das WER! Damit legen wir fest, wem bestimmte Dinge erlaubt bzw. verboten sind:
- Jeder im Internet
- Jeder authentifizierte
- Alle Hubzilla-Mitglieder
- Jeder auf dieser Webseite
- Beliebige Verbindungen
- Angenommene Verbindungen
- Nur die, denen Du es explizit erlaubst
- Nur ich
Auch hier gibt es einige "Wers", die etwas näher erläutert werden müssen. Dafür gibt es ebenfalls eine kleine Tabelle im Anhang.
Die Wichtigsten Adressaten für Berechtigungen sind: "Jeder im Internet" und "Nur die, denen Du es explizit erlaubst".
Nun ist es an der Zeit, sich Gedanken darüber zu machen, was man wem denn nun erlauben möchte. Dafür arbeitet man einfach die einzelnen Berechtigungen hintereinander ab und legt die Berechtigten fest.
Im Hauptmenü (das Menü, welches sich hinter unserem Avatarbild versteckt) wählt man
Einstellungen ➔ Kanal-Einstellungen
und legt im Abschnitt Grundeinstellungen die gewünschte Kanalrolle (Channel Role) fest. Also für unsere Zwecke "Benutzerdefiniert".
Nun wechselt man zu Einstellungen ➔ Privacy-Einstellungen
Die Grundeinstallungen dort sind selbsterklärend und sollten nach den eigenen Wünschen festgelegt werden. Wichtig ist hier die einzige "nicht selbsterklärende" Einstellung "Enable OCAP access". Dies ermöglicht, dass Medien (Bilder etc.) auch dann in einem Thread angezeigt werden, wenn diese eigentlich im Zugriff eingeschränkt sind. Wird diese Option nicht gewählt, kann es vorkommen, dass man eingebettete Bilder in manchen Threads nicht sieht. Meine Empfehlung: Option einschalten!
Die eigentliche Einstellung der Berechtigungen, die unser Kanal einräumt, findet man unter dem Button "Benutzerdefinierte Konfiguration der Channel Role" (dies wird bei den Kanalrollen "Öffentlich" und "Persönlich" nicht angezeigt, weil man diese dort nicht ändern kann).
Es wird eine Warnung angezeigt, die zwar berechtigt ist, aber wir WISSEN ja, was wir tun wollen.
Die sorgfältig konfigurierte Kanalrolle
Deshalb klicken wir auf den Button "Risiko akzeptieren und weitermachen" und landen im Formular für die genannten Berechtigungen. Die können wir nun nach unseren Wünschen und nachdem wir uns Gedanken gemacht haben, entsprechend konfigurieren.
Dabei aber immer daran denken: Die Berechtigung, die wir hier erteilen, können wir generell nicht zurücknehmen. Wir können sie höchstens in Einzelfällen "übersteuern", indem wir Inhalte/Ressourcen über die Berechtigungs-Einstellungen bestimmten Verbindungen zugänglich machen.
Es ist also ausgesprochen sinnvoll, bei der Kanalrolle so wenig freizügige Berechtigungen zu vergeben, wie möglich und nur so viele, wie für den Zweck absolut nötig.
Bedenkt: Nur was Ihr für "Jeder im Internet" erlaubt, kann auch wirklich öffentlich gesehen werden. Die spezielleren Berechtigungen sind eher etwas für Spezialfälle. "Nur die, denen Du es explizit erlaubst" wirkt sich hingegen ausschließlich auf Verbindungen aus.
Bedeutet: Alles, was wirklich jeder im Internet sehen können soll, bekommt "Jeder im Internet" (bei einem typischen öffentlichen Social-Network-Kanal) sind das "Kann meinen Kanal-Stream und meine Beiträge sehen", "Kann mein Standardprofil sehen" und "Kann meine Datei- und Bilderordner sehen". Wer öffentlich Wiki- oder Webseiten anbietet, erlaubt auch das Anschauen dieser durch jeden im Internet.
Den Rest kann man dann ruhigen Gewissens auf "Nur die, denen Du es explizit erlaubst" setzen. Damit können sich die Berechtigungen nur auf die eigenen Verbindungen auswirken.
Die passenden Kontaktrollen
Euch muss an dieser Stelle bewusst sein, dass die Standard-Kontaktrolle sehr viele zusätzlich Berechtigungen vergibt:
Diese Kontaktrolle kann man durchaus nutzen, um ein eher "klassisches" Social-Network-Verhalten für bestimmte Verbindungen zu erhalten.
Wenn man aber wirkliche Kontrolle haben möchte, muss man sich für andere Verbindungen weitere Kontaktrollen erstellen.
"Follower"
Sinnvoll wäre z.B. als neuer Standard für neue Verbindungen die Rolle "Follower". Diese erstellen wir, setzen die Option "Neuen Kontakten automatisch diese Rolle zuweisen" (damit wird die Option aus der Standard-Kontaktrolle gelöscht) und geben keine weiteren Berechtigungen, außer "Darf meine Beiträge kommentieren und mögen/nicht mögen". Damit verfügen Verbindungen mit dieser Kontaktrolle nur die in der Kanalrolle vergebenen Berechtigungen plus die Möglichkeit zum Kommentieren und liken/disliken. Wenn sich jemand mit Eurem Kanal verbindet, dann verhält er sich wie ein reiner Follower. Diese Kontaktrolle ist sinnvoll, wenn Ihr es anderen gestatten möchtet, Euch zu folgen.
Wenn Ihr meint, solche "Follower" sollten auch Eure Verbindungen anschauen können, gewährt Ihr zusätzlich halt auch diese Berechtigung.
"Followed"
Die nächste sinnvolle Kontaktrolle könnte dann z.B. "Followed" genannt werden. Dieser Rolle räumt Ihr dann, zusätzlich zu den Berechtigungen von "Follower", noch "Kann mir die Beiträge aus seinem Kanal schicken" ein, damit Ihr auch die Beiträge der Verbindung in Eurem Stream sehen könnt. Damit es sich auch "echt" anfühlt, wären hier auch noch die Berechtigungen "Kann mir direkte Nachrichten schicken", "Kann Profile und Profilsachen mögen/nicht mögen" und "Kann mit mir chatten" praktikabel.
Diese Kontaktrolle vergebt Ihr dann, wenn Ihr selbst eine Verbindung zu einem fremden Kanal herstellt... und an Kanäle, die Euch eine Kontaktanfrage schicken und denen Ihr "zurückfolgen" möchtet.
"Followed+"
Eine Weitere Kontaktrolle würde ich "Followed+" nennen. Die ist für Kontakte aus dem Grid, und von den owa-fähigen Deinsten Forte und Friendica. Diesen kann man die zusätzliche Berechtigung "Kann auf meiner Kanal-Seite ("wall") Beiträge veröffentlichen" erteilen (wenn man denn möchte). Das Wall-to-Wall-Posting ist eine spezielle Art, Postings zu veröffentlichen. Wen eine unserer Verbindung ein Wall-Posting auf unserem Kanal veröffentlicht, dann erscheint dieses Posting in unserem Kanalstream. Es ist also in unserem Kanal veröffentlicht.
Mehr
Für gute Freunde, verwandte, Mitglieder eines Teams, Vereins etc. kann man dann, je nach Notwendigkeit noch weitere Berechtigungen vergeben und für jede erdenkliche Art von Verbindungen ganz exakt zugeschnittene Kontaktrollen erstellen.
Privacy Gruppen für genauere Steuerung
Privacy Gruppen sind Gruppen von Verbindungen, mit denen man das Teilen von Inhalten steuern kann. Sie ähneln dem, was man bei Google+ als "Kreise" kannte und was bei Diaspora* als "Aspekte" existiert. Möchte man einen Inhalt an eine bestimmte Gruppe von Verbindungen teilen, so kann man diese Verbindungen in eine Gruppe einfügen und mit den Berechtigungs-Einstellungen festlegen, dass der Inhalt ausschließlich mit den Gruppenmitgliedern geteilt wird. Das macht eine geschlossene Gruppenkommunikation möglich.
Eine weitere praktische Anwendung von Privacy Gruppen ist das zuteilen von Kontaktrollen auf einen Rutsch. Wenn man eine Kontaktrolle in der App "Contact Roles" öffnet, kann man auswählen, dass diese Kontaktrolle allen Gruppenmitgliedern einer Privacy Gruppe zugewiesen wird. Beachte: Das wirkt sich nur auf Verbindungen aus, die sich zu diesem Zeitpunkt bereits in der Privacy Gruppe befanden. Auf später hinzugefügte Verbindungen wirkt es sich nicht aus. Hier muss man ggf. die Gruppen-Zuweisung wiederholen.
Die Repeat-Hölle verlassen
Es gibt Nutzer im Fediverse, die wirklich exzessiv "Boosten/Repeaten". Trotzdem mag man diesen Nutzern folgen, weil die wenigen (oder vielleicht nicht einmal wenigen) ihrer eigenen Postings insteressant sind und man sie in seinem Stream finden möchte. Aber es kommt zu viel "Rauschen" herein, weil halt auch zu viel wiederholt wird. Bei Hubzilla ist es kein Problem, diese Repeats loszuwerden, ohne die "echten" Postings zu verlieren. Man kann für jede Verbindung einen Filter einrichten, der z.B. Repeats der Verbindung nicht in den Stream importiert.
Dafür öffnet man aus der App "Verbindungen" heraus den Verbindungs-Editor (kleines Bleistift-Symbol) und trägt im Tab "Filter für den Inhalt" im Feld "Beiträge mit diesem Text nicht importieren" die Zeile
?verb == Announceein. Damit werden Repeats (Wiederholungen / Boosts) von dieser Verbindung nicht mehr in den eigenen Stream importiert.
Kanalfilter
Neben den eben erwähnten Kontaktfiltern gibt es auch noch Kanalfilter, die sich auf den gesamten Kanal auswirken. Auch hier könnte man z.B. die Zeile zur Repeat-Unterdrückung unterbringen. Das würde dann aber bewirken, dass gar keine Repeats mehr im Kanal erscheinen, also auch solche nicht, die vielleicht erwünscht sind.
Kanalfilter findet man unter Einstellungen ➔ Kanal-Einstellungen ➔ Beiträge mit diesem Text nicht importieren
Inhaltswarnung
Während bei den meisten Diensten im Fediverse der Verfasser dafür verantwortlich gemacht wird, bestimmte Inhalte hinter einer Inhaltswarnung zu verstecken, funktioniert Hubzilla genau anders herum. Hier legt der Empfänger fest, was ihn "triggern" könnte oder was ihn "nervt". Das ist eigentlich auch ausgesprochen sinnvoll, weil ich selbst am besten weiß, was ich nicht sofort in meinem Stream sehen möchte. Wenn der Absender dafür verantwortlich ist, muss er ja erahnen, was ich nicht sehen möchte... und verbirgt solche Inhalte dann zwangsweise auch vor anderen Nutzern, die davor aber gar nicht gewarnt werden möchten.
Wer sich mit Hubzilla also vor bestimmten Inhalten schützen möchte, installiert die App "NSFW". Das ist eine einfache Filter-App, in welcher man eingeben kann, bei welchen Inhalten ein Posting zunächst ausgeblendet hinter einer Schaltfläche verborgen bleibt. Es kommt also nicht darauf an, das der Absender errät, was ich nicht sehen möchte und eine Inhaltswarnung verwendet (die sich dann auch auf alle auswirkt, die seinen Beitrag anschauen), sondern darauf, dass ich als Empfänger festlege, was verborgen werden soll.
Bewege ich mich also nur im Grid und habe auch nur Verbindungen zum Grid, muss ich mich um die Befindlichkeiten anderer nicht kümmern. Sobald man aber auch Teil des Fediverse wird, hilft unseren "NSFW"-App nicht weiter, denn die meisten anderen Dienste haben diesen Mechanismus nicht. Möchten wir also rücksichtsvoll vorgehen, müssen wir doch auch für andre mitdenken und erraten, was irgendwen in der weiten Welt "triggern" könnte.
Und das Ausblenden eines solchen Eintrags verwirklichen wir dann einfach, indem wir das Zusammenfassungsfeld (Summary) im Beitragseditor z.B. mit "Inhaltswarnung" befüllen. Nun sind auch nutzer anderer Dienste "geschützt".
Nun aber ein Spezialfall:
Es ist allgemein bekannt, dass viele sich entsetzt schütteln, wenn sie in einem Posting von Dieter Bohlen angestarrt werden (mir selbst geht es nicht so... ich mag ihn... zu erklären weshalb, würde hier aber zu weit führen). Nun wollen wir ein Posting verfassen, in welchem ein Bild von D. B. eingebunden ist. Um Nutzer aus dem Grid zu schützen, müsste ich z.B. das Wort "Bohlen" im Text unterbringen, und schon wären alle "gerettet", die in "NSFW" dieses Wort als Filter haben.
Aber angenommen, wir wollen nur das Bild selbst ausblenden und ahnen, dass es Nutzer gibt, die gerne mit Holz arbeiten und deshalb das Wort "Bohlen" auch nicht als Inhaltswarnung im Filter haben. Nun, dann können wir das Bild bei Hubzilla einfach zwischen die Tags
[spoiler][/spoiler] packen. Funktioniert prima! Nur... für Mastodon-Nutzer funktioniert das nicht. Mastodon (und viele andere Fediverse-Dienste) kennen keinen extra Spoiler. Hinzu kommt das bei vielen dieser Dienste Bilder gar nicht in ein Posting eingebunden werden, sondern als Anhang am Posting dranhängen. Selbst wenn sie das Spoiler-Tag kennen würden, würde der Empfänger das Gesicht von D. B. wieder sehen, weil es außerhalb des Postings unten dranhängt.Aber ehrlich... das soll echt nicht UNSER Problem sein. Wir können alles dafür tun, dass bestimmte Inhalte verborgen bleiben, aber nichts daran ändern, wenn andere Dienste das nicht richtig verarbeiten.
Abgesehen davon ist es möglich auch Teile eines Postings zunächst zu verbergen (BTW: beliebig viele Teile), indem man das Spoiler-Tag verwendet. Funktioniert aber zuverlässig halt nur im Grid.
Zeichenbegrenzung
Na ja, was soll man sagen?
Hubzilla packt an die 16 Millionen Zeichen. Dieser Artikel hier ist also ein Fliegenschiss mit ca. 24.000 Zeichen. ;-)
Textgestaltung
BBcode "Hubzilla-Flavour" bietet umfangreiche Textgestaltungsmöglichkeiten. Leider werden diese vom derzeitigen Beitragseditor nicht alle vereinfacht z.B. über Buttons und Dialoge angeboten. Hier müsste dringend noch nachgebessert werden (könnte mein nächstes Projekt werden). Zumindest verfügt der Editor über eine Autovervollständigung, die hilfreich ist, wenn man weiß, was die BBcode Tags bewirken.
Was Hubzilla von vielen Diensten unterscheidet ist, dass Medien wirklich in den Beitrag eingebettet werden, also an der Stelle erscheinen, wo wir sie unterbringen. Die Anzahl an Medien ist außerdem ebenfalls nicht beschränkt.
Bedenkt aber, wenn Ihr Beiträge ins Fediverse teilt, dass es Dienste gibt, die nicht nur Medien (also z.B. Bilder) hinten anhängen, sondern auch auf wenige (bei Mastodon vier) begrenzen. Es ist deshalb sinnvoll, einen Hinweis auf die tatsächliche Anzahl von Bildern hinzuweisen und dass es erforderlich sein kann, das Original-Posting auf Eurer Heimat-Instanz zu besuchen, um alle Bilder (und die auch noch korrekt eingebettet) sehen zu können. Klingt komisch, ist aber so. ;-) :-D
Fazit
Kommt einfach ins Grid! Besorgt euch einen Account bei Hubzilla. Ihr könnt das ja zusätzlich zu Eurem aktuellen Fediverse-Account tun. Und importiert Eure Follower-/Following-Liste. Dafür gibt es (sofern der von Euch gewählte Hub das Addon installiert hat) inzwischen ein Addon, das die typischen Exportdateien (csv) von Mastodon und co. verarbeitet. Richtet Euren Kanal so ein, wie Ihr es euch vorstellt und nutzt es.
Es ist durchaus möglich, dass Ihr dann irgendwann immer öfter mit Hubzilla, statt mit dem ursprünglichen Dienst im Fediverse unterwegs seid. Und wenn Ihr dann auch noch Kontakte zu Nutzern im Grid habt, werdet Ihr feststellen, dass die soziale Interaktion damit noch viel komfortabler ist. Vielleicht wagt ja dann irgendwann auch die eine oder andere eurer alten Verbindungen auch den Schritt und Ihr könnt den Komfort gemeinsam genießen.
Anhänge
Wer?
Was?
Staccato taugt nicht für jeden Zweck...
Stolz verkünden immer mehr Organisationen und Institutionen, dass sie nun im Fediverse vertreten sind... und nahezu ausschließlich betreten sie es mit Mastodon.
Dabei ist Microblogging, die Domäne von Mastodon und einigen anderen Diensten, nicht unbedingt die beste Wahl für den Zweck, der eigentlich verfolgt wird...
Stolz verkünden immer mehr Organisationen und Institutionen, dass sie nun im Fediverse vertreten sind... und nahezu ausschließlich betreten sie es mit Mastodon.
Dabei ist Microblogging, die Domäne von Mastodon und einigen anderen Diensten, nicht unbedingt die beste Wahl für den Zweck, der eigentlich verfolgt wird...
View article
View summary
Staccato taugt nicht für jeden Zweck...
Stolz verkünden immer mehr Organisationen und Institutionen, dass sie nun im Fediverse vertreten sind... und nahezu ausschließlich betreten sie es mit Mastodon.
Dabei ist Microblogging, die Domäne von Mastodon und einigen anderen Diensten, nicht unbedingt die beste Wahl für den Zweck, der eigentlich verfolgt wird.
Microblogging ist Kurzformat-Kommunikation mit meist sehr kurzen, dafür aber häufigen Postings mit Links, Bildern oder Videos. Die typische Nutzung für Microblogging sind Echtzeit-Updates, kurze Statements, Link-Teaser, Live-Kommentare, Trend‑Monitoring und Direktdialog. Microblogging-Plattformen wie Mastodon haben natürlich ihre Stärken: Sie sind schnell, aufmerksamkeitsstark und bieten eine gute Möglichkeit für eine "virale Verbreitung" innerhalb des Fediverse. Zusätzlich ist die Einstiegshürde recht gering.
Aufgrund des Konzepts gibt es aber auch Grenzen bzw. Nachteile: Begrenzte inhaltliche Tiefe und schnelle Vergänglichkeit, sowie das Risiko von Missverständnissen.
Macroblogging hingegen meint Plattformen mit längeren Beiträgen, ausgeprägtem Community-/Gruppenmanagement und Funktionen für Events und Dokumentation. Paradebeispiele dafür sind Hubzilla und Friendica.
Typische Merkmale sind umfassende Profilseiten, Gruppen, Veranstaltungen, längere Texte, Dokumentenarchivierung, feinere Moderationswerkzeuge und mehr Kontrolle über die Daten. Sie sind besonders geeignet für tiefere Informationsvermittlung, langfristige Community‑Pflege, strukturierte Diskussionen und Veranstaltungsmanagement, und bieten bessere Archivfunktion und dauerhafte Sichtbarkeit.
Also...
Für schnelle Meldungen, Live‑Updates und Trend‑Monitoring ist Microblogging sehr gut geeignet und bietet Tempo und Reichweite innerhalb relevanter Communities.
Für ausführliche Erklärungen, offizielle Statements, Dokumentation, Veranstaltungs- und Mitgliedermanagement hingegen, eignen sich Macroblogging-Dienste wesentlich besser.
Nun mag man auf die Idee kommen, dass man für viele Zwecke, die beide Bereiche beanspruchen, dann auch zwei Fediverse-Präsenzen einrichten und pflegen müsste.... und genau hier liegt ein Denkfehler: Während man bei ausgesprochenen Microblogging-Diensten, wie z.B. Mastodon, auf die Möglichkeiten dieser Sparte festgenagelt ist, bekommt man bei Macroblogging-Diensten die umfassenderen Möglichkeiten an die Hand, kann damit aber auch Microblogging betreiben, ist also gar nicht auf eine gesonderte Plattform angewiesen.
Wer sich also überlegt, das Fediverse zu bespielen, sollte sich vorher Gedanken machen, was denn erreicht werden soll. Geht es um kurze Hinweise und ggf. Verweise auf andere (ausführlichere) Quellen, dann genügt eine Microblogging-Plattform. Für mehr sollte man dann doch eher Hubzilla oder Friendica nutzen. Der Kreis der Nutzer, die damit erreicht werden können, unterscheidet sich ja nicht von dem Kreis derer, die durch Microblogging erreicht werden können.
Und wer hofft, durch Links auf umfassendere Beiträge an anderer Stelle viele Leser zu gewinnen, der wird wahrscheinlich rasch enttäuscht und vielleicht das Fediverse wieder verlassen, weil man "da ja keine Reichweite generieren" kann.
Ja... es ist wohl tatsächlich so, dass geteilten Links nicht so oft gefolgt wird. Hier kann man aber einfach zweigleisig fahren, was einem Hubzilla sehr erleichtert. Für wiederauffindbare und strukturierte Beiträge bietet sich das Format der "Artikel" an. Diese werden jedoch nicht föderiert. Es spricht aber nichts dagegen, ein und denselben Beitrag zusätzlich auch noch als normales Posting zu teilen, sodass er föderiert wird. Das dann am besten mit einer Zusammenfassung, damit solche Postings nicht "unangenehm" bei den Microblogging-Diensten auffallen, und am Ende einfach noch mit einem Link zur Artikel-Quelle auf dem eigenen Kanal. Diese Strategie werde ich ab heute einmal ausprobieren.
Wer nicht mehr will, als "Staccato", der wird mit einem Microblogging-Dienst zufrieden sein. Wer aber die Möglichkeit für eine umfassendere Kommunikation und Informationsbereitstellung wünscht, der sollte sich die Macroblogging-Dienste anschauen... und dabei im Hinterkopf behalten, dass auch Microblogging damit möglich ist, ohne sich beim Kreis der möglichen Empfänger damit zu beschränken.
Stolz verkünden immer mehr Organisationen und Institutionen, dass sie nun im Fediverse vertreten sind... und nahezu ausschließlich betreten sie es mit Mastodon.
Dabei ist Microblogging, die Domäne von Mastodon und einigen anderen Diensten, nicht unbedingt die beste Wahl für den Zweck, der eigentlich verfolgt wird.
Microblogging ist Kurzformat-Kommunikation mit meist sehr kurzen, dafür aber häufigen Postings mit Links, Bildern oder Videos. Die typische Nutzung für Microblogging sind Echtzeit-Updates, kurze Statements, Link-Teaser, Live-Kommentare, Trend‑Monitoring und Direktdialog. Microblogging-Plattformen wie Mastodon haben natürlich ihre Stärken: Sie sind schnell, aufmerksamkeitsstark und bieten eine gute Möglichkeit für eine "virale Verbreitung" innerhalb des Fediverse. Zusätzlich ist die Einstiegshürde recht gering.
Aufgrund des Konzepts gibt es aber auch Grenzen bzw. Nachteile: Begrenzte inhaltliche Tiefe und schnelle Vergänglichkeit, sowie das Risiko von Missverständnissen.
Macroblogging hingegen meint Plattformen mit längeren Beiträgen, ausgeprägtem Community-/Gruppenmanagement und Funktionen für Events und Dokumentation. Paradebeispiele dafür sind Hubzilla und Friendica.
Typische Merkmale sind umfassende Profilseiten, Gruppen, Veranstaltungen, längere Texte, Dokumentenarchivierung, feinere Moderationswerkzeuge und mehr Kontrolle über die Daten. Sie sind besonders geeignet für tiefere Informationsvermittlung, langfristige Community‑Pflege, strukturierte Diskussionen und Veranstaltungsmanagement, und bieten bessere Archivfunktion und dauerhafte Sichtbarkeit.
Also...
Für schnelle Meldungen, Live‑Updates und Trend‑Monitoring ist Microblogging sehr gut geeignet und bietet Tempo und Reichweite innerhalb relevanter Communities.
Für ausführliche Erklärungen, offizielle Statements, Dokumentation, Veranstaltungs- und Mitgliedermanagement hingegen, eignen sich Macroblogging-Dienste wesentlich besser.
Nun mag man auf die Idee kommen, dass man für viele Zwecke, die beide Bereiche beanspruchen, dann auch zwei Fediverse-Präsenzen einrichten und pflegen müsste.... und genau hier liegt ein Denkfehler: Während man bei ausgesprochenen Microblogging-Diensten, wie z.B. Mastodon, auf die Möglichkeiten dieser Sparte festgenagelt ist, bekommt man bei Macroblogging-Diensten die umfassenderen Möglichkeiten an die Hand, kann damit aber auch Microblogging betreiben, ist also gar nicht auf eine gesonderte Plattform angewiesen.
Wer sich also überlegt, das Fediverse zu bespielen, sollte sich vorher Gedanken machen, was denn erreicht werden soll. Geht es um kurze Hinweise und ggf. Verweise auf andere (ausführlichere) Quellen, dann genügt eine Microblogging-Plattform. Für mehr sollte man dann doch eher Hubzilla oder Friendica nutzen. Der Kreis der Nutzer, die damit erreicht werden können, unterscheidet sich ja nicht von dem Kreis derer, die durch Microblogging erreicht werden können.
Und wer hofft, durch Links auf umfassendere Beiträge an anderer Stelle viele Leser zu gewinnen, der wird wahrscheinlich rasch enttäuscht und vielleicht das Fediverse wieder verlassen, weil man "da ja keine Reichweite generieren" kann.
Ja... es ist wohl tatsächlich so, dass geteilten Links nicht so oft gefolgt wird. Hier kann man aber einfach zweigleisig fahren, was einem Hubzilla sehr erleichtert. Für wiederauffindbare und strukturierte Beiträge bietet sich das Format der "Artikel" an. Diese werden jedoch nicht föderiert. Es spricht aber nichts dagegen, ein und denselben Beitrag zusätzlich auch noch als normales Posting zu teilen, sodass er föderiert wird. Das dann am besten mit einer Zusammenfassung, damit solche Postings nicht "unangenehm" bei den Microblogging-Diensten auffallen, und am Ende einfach noch mit einem Link zur Artikel-Quelle auf dem eigenen Kanal. Diese Strategie werde ich ab heute einmal ausprobieren.
Wer nicht mehr will, als "Staccato", der wird mit einem Microblogging-Dienst zufrieden sein. Wer aber die Möglichkeit für eine umfassendere Kommunikation und Informationsbereitstellung wünscht, der sollte sich die Macroblogging-Dienste anschauen... und dabei im Hinterkopf behalten, dass auch Microblogging damit möglich ist, ohne sich beim Kreis der möglichen Empfänger damit zu beschränken.
Mir fallen in letzter Zeit so einige Fediverse-Instanzen auf, die in meiner Warteschlange hängenbleiben.
Also... es bleiben ja immer mal welche hängen. Zum Beispiel, wenn sie für eine gewisse Zeit nicht erreichbar sind oder irgendwas falsch konfiguriert ist.
Aber die meine ich gar nicht. Diejenigen, die ich meine sind erreichbar und anscheinend auch richtig konfiguriert. Aber sie haben sich Türsteher vor die Türe gestellt. Konkret: Anubis ...
Also... es bleiben ja immer mal welche hängen. Zum Beispiel, wenn sie für eine gewisse Zeit nicht erreichbar sind oder irgendwas falsch konfiguriert ist.
Aber die meine ich gar nicht. Diejenigen, die ich meine sind erreichbar und anscheinend auch richtig konfiguriert. Aber sie haben sich Türsteher vor die Türe gestellt. Konkret: Anubis ...
View article
View summary
Mir fallen in letzter Zeit so einige Fediverse-Instanzen auf, die in meiner Warteschlange hängenbleiben.
Also... es bleiben ja immer mal welche hängen. Zum Beispiel, wenn sie für eine gewisse Zeit nicht erreichbar sind oder irgendwas falsch konfiguriert ist.
Aber die meine ich gar nicht. Diejenigen, die ich meine sind erreichbar und anscheinend auch richtig konfiguriert. Aber sie haben sich Türsteher vor die Türe gestellt. Konkret: Anubis.
Anubis ist ein sogenanntes Web-KI-Firewall-Tool. Es dient dazu, Web-Scraper von KI-Diensten davon abzuhalten, die eigene Seite zu scrapen. Sinn und Zweck soll sein, die Seite vor massenhaften Scraping-Aktionen gleichzeitig zu schützen, die den Server dann überlasten könnten. Es wird aber kein Limit eingeführt, sondern versucht, über Challenges wirklich alle Scraper von KI-Diensten (und sicher auch anderen Diensten) komplett auszuschließen.
Eine Anfrage, welche die Challenge nicht erfüllen kann, bleibt draußen. Und das trifft offenbar auch etliche Fediverse-Dienste, wenn diese Items zustellen möchten. Das liegt daran, dass solche Instanzen oftmals keine "normalen" HTTP-Requests absenden und vor allem kein Javascript verarbeiten können. Die Challenges sind aber mit Javascript realisiert... und ohne JS schlagen sie fehl oder laufen in einen Timeout. Die Zustellung scheitert.
Wahrscheinlich sind meine Hubs und Webseiten so unwichtig, unbedeutend, unbekannt und unauffällig, dass sich die "Horden von KI-Scrapern" gar nicht zu mir verirren. Ich habe bislang jedenfalls noch keinen "Stau" durch einen Scraper-Ansturm auf meinen Servern.
Womöglich ist es aber auch eher eine abstrakte Gefahr, die auch anderen Fediverse-Diensten kaum droht... und der eigentliche Grund ist der generelle pathologische KI-Hass. Es geht also weniger um die Vermeidung von Überlastungen / Verstopfungen, als vielmehr darum, keine KI-Scraper auf der eigenen Seite zuzulassen. Eine Entscheidung, die jedem, der einen Webdienst anbietet, ja auch zusteht. Soll jeder so machen, wenn er es meint.
Problematisch wird es nur, wenn dadurch die eigentliche Funktion des Dienstes eingeschränkt oder nahezu komplett blockiert wird.
Anubis lässt sich zwar auch konfigurieren und es wäre wahrscheinlich möglich (keine Ahnung, mit wieviel Aufwand... gerade im Fediverse bekommt man ja zahlreiche Anfragen, ohne die Instanz und deren Kennung explizit vorher unbedingt zu kennen).
Es ist also anscheinend tatsächlich so, dass Fediverse-Instanzen, die sich mit Anubis "schützen", tatsächlich etliche andere Fediverse-Instanzen aussperren und damit in einer Richtung deföderieren. Vielleicht ist es den Betreibern der Instanzen ja nicht einmal bewusst. Aber sollten sie es wissen und den vermeintlichen Schutz als wichtiger bewerten, es also hinnehmen, dass ihre Instanz nicht mehr uneingeschränkt Teil des Fediverse ist, dann gehe ich entweder von Dummheit oder ideologiegetriebener Arroganz aus. Solche Instanzen landen dann künftig ganz schnell in der Liste der nicht erreichbaren Server bei meinen Hubs, damit ihre Kadaver nicht ewig in der Warteschlange vor sich hin stinken.
Lasst doch den Quatsch!
Titelbild von David Polz auf Pixabay
Ich habe mich entschlossen, den Hoster zu wechseln. Nicht, weil ich mit dem alten nicht grundsätzlich zufrieden war (immerhin habe ich acht Jahre meine Projekte dort betrieben), sondern weil ich das Gefühl hatte, dass er aus bestimmten Gründen den Service bald aufgeben würde. Und tatsächlich erhielt ich vor ein paar Tagen die Mitteilung, dass er den Dienst an einen anderen Hoster verkaufen musste.
Der neue Server läuft auch schon. YunoHost ist drauf... und erstmal nur phpMyAdmin, Webmin und snac2.
Vom Fediverse-Dienst snac bzw. snac2 hatte ich hier und da mal was aufgeschnappt, ich habe ihn mir aber nie genauer angeschaut. Bis vorgestern!
Und seit dem läuft auch meine snac2-Instanz...
Der neue Server läuft auch schon. YunoHost ist drauf... und erstmal nur phpMyAdmin, Webmin und snac2.
Vom Fediverse-Dienst snac bzw. snac2 hatte ich hier und da mal was aufgeschnappt, ich habe ihn mir aber nie genauer angeschaut. Bis vorgestern!
Und seit dem läuft auch meine snac2-Instanz...
View article
View summary
Ich habe mich entschlossen, den Hoster zu wechseln. Nicht, weil ich mit dem alten nicht grundsätzlich zufrieden war (immerhin habe ich acht Jahre meine Projekte dort betrieben), sondern weil ich das Gefühl hatte, dass er aus bestimmten Gründen den Service bald aufgeben würde. Und tatsächlich erhielt ich vor ein paar Tagen die Mitteilung, dass er den Dienst an einen anderen Hoster verkaufen musste.
Ich hab mir den dann mal angeschaut und muss sagen, dass er einen seriösen und soliden Eindruck macht. Ich werde auch bei dem bleiben, weil ich zumindest meine ungarischen Domains da weiter halten möchte.
Aber was ich sonst so am Laufen habe, das werde ich umziehen. Der Server für Hubzilla und einige wenige andere Anwendungen war inzwischen eh ziemlich am Ende der Kapazität angelangt und ich wollte ihn eigentlich schon aufstocken. Aber so, wie es aussieht, kann mir der neue Hoster nicht das bieten, was ich mir vorgestellt habe.
Durch Chris bin ich auf den Hoster Contabo aufmerksam geworden und habe ihn mit in meine Auswahlliste übernommen. Na... und nach Vergleichen und dem Einholen von Erfahrungen habe ich mich auch entschlossen, diesen Hoster künftig zu nutzen.
Der neue Server läuft auch schon. YunoHost ist drauf... und erstmal nur phpMyAdmin, Webmin und snac2.
Der Umzug des Hub Whoville steht jetzt erst am Osterwochenende an. Aber weil der neue Server deutlich "mehr PS unter der Haube hat", dachte ich mir: Du kannst ja mal wieder was ausprobieren.
Vom Fediverse-Dienst snac bzw. snac2 hatte ich hier und da mal was aufgeschnappt, ich habe ihn mir aber nie genauer angeschaut. Bis vorgestern!
Und seit dem läuft auch meine snac2-Instanz.
Was soll ich sagen? Ich finde snac2 ausgesprochen schnuffig. Er wird als "minimalistisch" bezeichnet. Tatsächlich bietet der Dienst aber eigentlich genau das, was man von einem grundlegenden ActivityPub-Dienst erwartet. Und er macht etliches wesentlich besser als die bekannten Platzhirsche.
snac2 bietet umfassende ActivityPub-Operationen, wie öffentliche und private Postings, Antworten/Kommentieren, Folgen, Liken, Boosten, Muten, Löschen und Verstecken, sowie Emoji-Reaktionen. Außerdem kann man Lesezeichen für Beiträge setzen. Dabei kommt es ohne Datenbank, ohne Javascript und ohne Cookies aus! Eine snac2-Instanz ist multiuser-fähig.
snac2 erlaubt umfassende Formatierung von Postings mittels Markdown, wodurch auch das Einbinden von Bildern innerhalb des Beitrags möglich ist.
Die enthaltene Weboberfläche ist recht minimalistisch, aber effektiv. Vor allem lässt sie sich durch Stylesheets sehr gut anpassen. meine Instanz habe ich von der schlichten Standard-Ansicht auf ein moderneres Layout gebracht. Man findet einige fertige Styles, kann aber, wenn man es vermag, halt auch eigene Styles erstellen und verwenden.
Man kann seine Identität mit einem Avatar und einem Banner-Bild verschönern, Profilinformationen hinzufügen und etliches konfigurieren.
Postings kann man mit einer Inhaltswarnung versehen, die Sichtbarkeit festlegen, die Sprache des Inhalts definieren. Attachments sind möglich, ebenso Umfragen. Eine terminierte Veröffentlichung ist ebenfalls machbar.
Man kann Hashtags folgen, bestimmte Hashtags blockieren und einen Inhaltsfilter definieren.
Als Admin wird die Konfiguration über das Kommandozeilen-Programm "snac" durchgeführt. Die Dokumentation dazu ist gut.
Die Installation mit YunoHost war völlig unproblematisch. Außerdem kann man über das Controlpanel etliche Dinge auch ohne das Kommandozeilen-Tool konfigurieren, was die Verwaltung bequemer macht.
Mein erster Eindruck war: Wow, ist das schnell!
Mein zweiter Eindruck war: Wow, ist das geschmeidig. Ich habe ja schon sehr viele Dienste ausprobiert, aber snac2 ist bisher einer der wenigen Dienste, die absolut keine Probleme bereitet, sich sofort und schnell mit anderen Kanälen zu verbinden.
Ich nutze es bis jetzt ja wirklich nur kurz, muss aber sagen, dass ich extrem positiv überrascht bin. Es macht einfach Spaß, wenn man einen schlichten und einfachen ActivityPub-Dienst haben möchte. Dabei sieht es nicht langweilig aus, wenn man den Standard-Style ersetzt.
Hinzu kommt, dass es die Mastodon-API umsetzt und damit mit allen Mastodon-Clienten genutzt werden kann. Egal ob Elk, Phanpy etc. oder z.B. die Desktop-App Tokodon von Plasma/KDE... es funktioniert prima.
Mir macht es auf jeden Fall Spaß. Und es scheint noch ordentlich weiterentwickelt zu werden... bin gespannt!
Ach ja... snac steht übrigens für: "Social Networks Are Crap". 😉😁
Sharing für Fediverse-Dienste, also ein "Share im Fediverse Button" ist kein ganz triviales Ding.
Das Problem besteht darin, dass das Fediverse dezentral ist...
Das Problem besteht darin, dass das Fediverse dezentral ist...
View article
View summary
Sharing für Fediverse-Dienste, also ein "Share im Fediverse Button" ist kein ganz triviales Ding.
Das Problem besteht darin, dass das Fediverse dezentral ist. Ein "Teile bei X", "Teile bei Facebook", etc. Button hat es leicht. Alle diese zentralisierten Dienste laufen auf einem Server bzw. sind unter einer einzigen URL erreichbar. Für "X" muss "
x.com" aufgerufen werden, für "Facebook" entsprechend "www.facebook.com" etc. Damit ist man an der richtigen (wenn man es denn so empfindet) Stelle.Es gibt aber nicht "die eine URL" für das Fediverse. Jeder, der z.B. auf eine Webseite mit einem Inhalt stößt, den er gerne im Fediverse teilen möchte, kann und wird auf einer anderen Instanz sein... und dann auch noch in der Regel bei einem anderen Fediverse-Dienst. Und jede Instanz hat eine andere URL. Der Betreiber der Webseite weiß aber nicht, welchen Dienst der Besucher verwendet. Und womöglich verwendet dieser ja sogar mehrere verschiedene Fediverse-Dienste, die natürlich unter unterschiedlichen URLs erreichbar sind. Mit welcher er den Inhalt nun teilen möchte, kann der Website-Betreiber natürlich auch nicht wissen. Dilemma!
Das ist der Grund, weshalb man fast nirgendwo einen "Teile im Fediverse Button" findet. Und es ist auch ungerecht, den Betreiber dafür zu schimpfen.
Es gibt aber eine recht gut einsetzbare Lösung dafür. Sie ist weit entfernt davon, perfekt zu sein und unterstützt derzeit auch bei weitem nicht alle Fediverse-Dienste. Aktuell werden Mastodon (inklusive Hometown, Fedibird, GlitchCafé), Misskey (inkusive Calckey/Firefish, FoundKey und Meisskey, nicht jedoch Sharkey, Iceshrimp und Iceshrimp.NET), Friendica, Hubzilla und GNU Social unterstützt. Gotosocial, Mitra, Pleroma/akkoma und die meisten anderen Dienste sind derzeit leider (noch) nicht unterstützt.
Aber immerhin, das ist schon eine ganz gute Auswahl fürs Erste.
Die Lösung heißt "Share2Fediverse" und ist unter "s2f.kytta.dev" verfügbar. Ein Button, der ein "Teile im Fediverse" mit diesem Dienst anbietet, nimmt einen kleinen Umweg diese Seite und der Besucher muss dort die URL (Webadresse) der Fediverse-Instanz angeben, bei der man über einen Account verfügt. Dieser Zwischenschritt muss sein, weil Fediverse-Dienste auf unzählige Server mit unterschiedlichen Webadressen aufgeteilt ist.
Um es nun ganz einfach zu machen... auch und gerade für Webseiten-Besitzer ohne große technische Kenntnisse, habe ich einfach einen kurzen „Schnipsel“ HTML geschrieben, den man einfach unter seinen Beitrag/Artikel etc. packen muss. Er zeigt einen Fediverse-Button an und führt zu besagter Seite, wobei Titel und Link des Beitrags übernommen werden. Hier gibt nun der Leser die Adresse seines Fediverse-Dienstes ein und kann den Beitrag teilen:
<p><a href="https://s2f.kytta.dev/" onclick= "location.href=this.href+'?text='+document.title+' '+window.location; return false;"><img src="https://pepecyb.hu/files/share_fediverse.png" alt="Teile im Fediverse" title="Teile im Fediverse"/></a></p>Das funktioniert z.B auch prima mit WordPress. Dafür erstellt man einfach einen HTML-Block mit diesem Code und speichert ihn als Vorlage. So kann man ihn mit zwei Klicks unter jeden Artikel packen.
Natürlich besteht rein technisch die Möglichkeit, dass "s2f.kytta.dev" gewisse Daten des Nutzers abgreift. Stimmt! Aber es ist eher unwahrscheinlich. Zumal der Quelltext des Dienstes in einem Git-Repository einsehbar ist: https://github.com/kytta/share2fedi.
Als weitere Alternative könnte man in Erwägung ziehen, Share2Fedi einfach auch selbst zu hosten. Das sollte sogar kostenneutral möglich sein, wenn man es mit Vercel macht... aber möchte man, dass die eigenen Leser über einen Server in den USA geleitet werden? Also ich nicht! Man kann Share2Fedi aber auch auf einem eigenen Server (mindestens VPS) installieren... doch das ist dann auch wieder etwas für Spezialisten.
Es gibt auf jeden Fall eine Möglichkeit, einen "Teile im Fediverse Button" einzusetzen, auch wenn er mit einigen wenigen Einschränkungen behaftet ist.
Mein Schnipsel ist zumindest einfach... mehr soll er auch nicht sein.
Ich habe ihn selbst verwendet, als ich meine Blogs noch mit WordPress betrieben habe.
Auf die Grafik des Buttons ist man übrigens nicht festgenagelt.
Da kann man auch die URL zur Grafik eines anderen Buttons einsetzen....was die ganze Sache nun soll?
Seit ein, zwei Tagen tauchten mehr und mehr Postings in meinem Stream auf, in welchen es um das "Forkiverse" ging.
Seit ein, zwei Tagen tauchten mehr und mehr Postings in meinem Stream auf, in welchen es um das "Forkiverse" ging.
View article
View summary
...was die ganze Sache nun soll?
Seit ein, zwei Tagen tauchten mehr und mehr Postings in meinem Stream auf, in welchen es um das "Forkiverse" ging.
Forki... Was?
Also das Fediverse kenne ich ja... und dann kenne ich noch die Forkeys, also Fediverse-Software, die als Forks oder Forks von Forks oder... na ja... Forks halt von Misskey entstanden sind (also Sharkey, Calckey - Firefish, Iceshrimp und wie sie alle heißen)... aber was ist denn das "Forkiverse" und weshalb wird darüber so viel geschrieben?
So rein vom Namen klingt es so, als würde da jemand das Fediverse "forken" wollen, also ein neues, abgeleitetes, aber dennoch anderes Fediverse schaffen.
Aber ist dem wirklich so? Und braucht es sowas? Und möchte irgendwer sowas? Und überhaupt...
Wirklich fundierte Informationen darüber, was das "Forkiverse" nun ist, findet man nicht wirklich.
Es gibt eine Mastodon-Instanz (also schonmal nix mit "Fork") mit dem Namen "Forkiverse" unter der Domain theforkiverse.com. Und da steht dann auch ein Satz:
Building a better internet with your friends from Hard Fork and Search Engine.
Also...
Gemeinsam mit Ihren Freunden von Hard Fork und Search Engine ein besseres Internet schaffen.
Wer oder was sind jetzt "Hard Fork" und "Search Engine"? Und wer sind diese Freunde, die meine Freunde sein sollen und mit mir ein "besseres Internet" aufbauen möchten?
Mehr Infos findet man unter der Domain zunächst nicht. Außer, dass es (stand 12. Januar 2026) um die 3.200 Accounts auf der Instanz gibt und die Instanz von einem gewissen Kevin Roose betrieben, adminstriert, moderiert wird.
Wer ist das denn nun schon wieder? Ein amerikanischer Journalist ist es. Kein Wunder, dass mir der Name nicht geläufig ist. Und er arbeitet irgendwie auch für die New York Times. Da zeichnet er auch für den Podcast "Rabbit Hole" verantwortlich und er ist außerdem Co-Moderator eines weiteren NYT-Podcasts mit dem Namen "Hard Fork".
Aaahhh... jetzt... "Hard Fork" ist also ein NYT-Podcast, der von Kevin Roose und einem gewissen Casey Newton moderiert wird... und in welchem es um die "Radikalisierung des Internets" geht.
Der Name Casey Newton taucht im Zusammenhang mit "Forkiverse" auch immer mal auf. Und wer ist das nun? Na auch ein amerikanischer Journalist.
Gräbt man dann in den Infos zu diesen Protagonisten und den Podcasts stößt man irgendwann auch auf "Search Engine", was ein Podcast von CBC bzw. TVOntario ist, ursprünglich moderiert von einem Jesse Brown, jetzt wohl von einem gewissen PJ Vogt, dessen Name auch im Zusammenhang mit dem "Forkiverse" immer wieder fällt.
Na ok... das mit "meinen Freunden von Hard Fork und Search Engine" war wohl nix. Hab da keine Pfroinde. Egal...
Und die wollen jetzt ein "besseres Internet" aufbauen. Stellt sich also die Frage, was denn ein "besseres" Internet auszeichnen soll.
Liest man die wenigen (habe nur zwei mit "etwas Fleesch uffe Rippen" gefunden) Artikel zum "Forkiverse", bekommt man eine grobe Vorstellung, was es damit auf sich haben soll. [1] [2]
Also... das "Forkiverse" ist ein Kind dreier Podcaster: Kevin Roose, Casey Newton und PJ Vogt. Sie wollen ein "besseres" Internet schaffen, wobei "besser" von ihnen nicht wirklich definiert wird. "Besser" halt! Und wer würde das nicht wollen, denn schließlich soll ja "die derzeitige Version des Internets" laut ihrer Ansicht die "wohl die schlechteste, die es je gab" sein.
Also... na ja, so richtig ein neues Internet trauen sie sich dann doch eher nicht zu. Ihre Vision ist ein "besseres Soziales Netzwerk". Das wollen sie aber mal machen. Und dafür nutzen sie Mastodon. Ist ja prima! Aber damit schaffen sie ja nichts Neues, denn Mastodon gibt es nun schon seit dem 16. März 2016 und das Fediverse, dessen Teil es ist, bereits seit dem 18. Mai 2008. Was sie geschaffen haben, ist eine weitere Mastodon-Instanz zu den bis dahin (Zahlen laut FediDB) 9.181 anderen Mastodon-Instanzen bzw. eine weitere Fediverse-Instanz zusätzlich zu den bis dahin 42.906 Fediverse-Instanzen.
Nun ist aber auch ihre Instanz Teil des Fediverse (und deshalb spülte es mit Postings von dieser Instanz in meinen Stream) und damit war es das dann auch schon mit dem vermeintlich "besseren" Sozialen Netzwerk nach ihren Vorstellungen. Denn sie haben ja keinen Einfluss darauf, was im gesamten Fediverse so alles passiert.
Hätte sie einen wirklichen "Reinraum" erschaffen wollen, hätten sie ihre Instanz entweder deföderieren müssen oder womöglich gleich eine andere Social-Network-Anwendung (sowas wie Oxwall, HumHub, Elgg etc.) oder eine Foren-Software nutzen können. Solange aber ihre Forkiverse-Instanz im Fediverse drinhängt, sind sie Teil dieses großen Netzwerks und nur beschränkt in der "Reinhaltung".
Der Artikel von Maho Pacheco offenbart auch, dass weder er, noch die drei Forkiversisten das Fediverse an sich verstanden haben. Man benötigt nämlich für eine Art Community, wie sie sich eine vorstellen, keine eigene Instanz. Und es ist auch nicht im Sinne der Dezentralisierung, nun möglichst viele Gleichgesinnte auf eine einzige Instanz zu locken (mit einem irgendwie gearteten Heilversprechen à la "besseres Internet").
Und, auch wenn ich viele hier vielleicht enttäuschen mag: Es ist und bleibt völlig egal, welche Instanz Ihr für Euren Account auswählt. Zumindest themenbezogen oder in Bezug auf die Region. Die Instanz-Regeln können einen Ausschlag für die Auswahl geben oder die Zuverlässigkeit (Verfügbarkeit). Aber eine "Angler-Instanz" ist auch für Nicht-Angler genauso gut zu nutzen, wie eine andere Instanz und sie bringt auch Angelbegeisterten keine wirklichen Vorteile. Lediglich die lokale öffentliche Timeline enthält dann wahrscheinlich mehr Angler. Aber wolltet Ihr nicht Algorithmen loswerden? Wolltet Ihr nicht, dass Euch nichts ungefragt in die Timeline gespült wird. Ist der lokale Stream wirklich so wichtig?
Das Fediverse macht ein klein wenig Mühe. Damit Angler als Angler gefunden werden, müssen sie diese Info halt in ihrem Profil unterbringen. Oder man sucht, auch wenn man einen Account bei einer anderen Instanz hat, einfach mal eine Angler-instanz auf und schaut sich deren lokale Zeitleiste an, um auf Angelfreunde zu stoßen. Himmel! Wenn Ihr war vorgekaut haben wollt, müsst Ihr halt bei den Walled Gardens bleiben und Euch von einem undurchsichtigen Algorithmus vor den Latz knallen lassen, was dieser meint, dass es Euch interessiert.
Und der Titel ihres Projekts ist jetzt auch nicht unbedingt sehr geschickt gewählt. "Forkiverse" klingt nämlich erstmal so, als gibge es wirklich um eine Abspaltung von Fediverse... was es aber ja eben wieder nicht ist, weil ins Fediverse eingebunden. Der Name weckt Erwartungen, die das Projekt nicht erfüllen kann. Ob das jetzt ein Versehen aus Unwissenheit war oder ob es eher eine Art Marketing-Gag sein sollte... keine Ahnung. Sympathien kann man so nicht sameln. Und eine möglichst große Instanz anzustreben widerspricht sowohl dem dezentralen Gendanken des Fediverse und macht alle Bemühungen, die Nutzer auf möglichst viele Instanzen zu verteilen, zunichte.
Für mich sieht die ganze Sache wie eine mächtige Schaumschlägerei aus... nicht mehr und nicht weniger. Und wenn der Hashtag in absehbarer Zeit nicht mehr so wild durch die Gegend geworfen wird, dann lösche ich ihn auch wieder aus meinem Filter.
[1] The Forkiverse Experiment and Why Instance Choice Matters (arch)
[2] The Fediverse Experiment (arch)
Heute Morgen habe ich den Artikel Fediverse: Wenn Admins Communities zerstören im Blog C0D1 gelesen. Und ich kann den Ärger durchaus nachvollziehen...
View article
View summary
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.
Eher zufällig bin ich auf die Fediverse-Software #Seppo! gestoßen.
Aber langsam, eins nach dem anderen...
Aber langsam, eins nach dem anderen...
View article
View summary
Eher zufällig bin ich auf die Fediverse-Software #Seppo! gestoßen.
Aber langsam, eins nach dem anderen...
Das Fediverse bietet große Freiheit, Sicherheit und Autonomie. Hauptgrund für die Autonomie ist das dezentrale Prinzip. Als Nutzer des Fediverse ist man nicht an eine einzelne Firma und nicht an einen einzelnen Server gefesselt. Das Soziale Netzwerk besteht aus einem lockeren Verbund zahlreicher, von einander unabhängiger Server (Instanzen). Der Ausfall einzelner Instanzen führt nicht zur Störung oder zum Zusammenbruch des Fediverse. Etliche Dienste erlauben auch den Export des Accounts bzw. den "Umzug" auf einen gleichen Dienst auf einem anderen Server. Hubzilla, (streams) und Forte (und bald wohl auch Mitra) bieten sogar die echte nomadische Identität mit automatisch synchronisierten klonen auf verschiedenen Servern.
Das einzige was bleibt, ist, dass man auf einen Server, also einen Serverbetreiber und Admin des jeweiligen Dienstes angewiesen ist und damit eine gewisse Abhängigkeit bestehen bleibt.
Und aus diesem Grund wird auch immer wieder einmal empfohlen bzw. als Lösung für dieses kleine Rest-Dilemma geraten, doch selbst eine Instanz zu betreiben. Womöglich als einziger nutzer. Die Anbindung an die weite Welt des Fediverse ist ja auch damit gegeben. Damit macht man sich von Dritten noch unabängiger.
Das ist auch kein schlechter Rat an sich... nur... die Installation vieler solcher Dienste ist dann doch meist nicht so simpel, wie es sein müsste, um auch von "normalen" Durchschnitts-Nutzern durchgeführt werden zu können. Hinzu kommt dann auch noch, dass man auch seine eigene kleine Instanz administrieren und auf dem neuesten Stand halten muss. Auch hier lauern immer wieder Fallstricke, die nur mit erweiterten Kenntnissen zu überwinden sind.
Der Rat ist also gut, aber nichts für jeden... und damit auch nicht einfach zu befolgen.
So... und jetzt, ja jetzt komme ich mit #Seppo! um die Ecke.
Während sich viele Fediverse-Dienste nur umständlich oder oft gar nicht auf einem normalen Web-Hosting-Dienst installieren lassen, ist dies mit #Seppo! kein Problem.
Was man benötigt ist also ein Webhosting-Dienst, wie er von sehr vielen Providern angeboten wird. Sowas ist für wirklich kleines Geld zu bekommen. Die einzige Voraussetzung ist, dass man über eine Domain oder Subdomain verfügt, und der Dienst das Ausführen von CGI erlaubt (das steht bei den Angeboten dabei bzw. muss erfragt werden). Und das war es schon.
Dann lädt man sich von der Seppo-Webseite die aktuelle Version der Datei seppo.cgi herunter, lädt diese auf den eigenen Webspace (ggf. muss man noch schauen, dass die Datei ausführbar ist) und dann ruft man diese einmalig mit <Domain_oder_Subdomain_des_eigenen_Webspaces>/seppo.cgi auf, wählt im folgenden Dialog einen Benutzer- (Fediverse-) Namen und ein Passwort... und das war es dann auch schon. Fertig! Die eigene Instanz! Und die Teilnahme am Fediverse!
Noch ist #Seppo! nicht wirklich "fertig"... und es fehlt sogar an einigen wesentlichen Funktionen. Aber man kann es schon nutzen und ausprobieren... und es taugt auch, um am Fediverse (eingeschränkt) teilzunehmen:
Man kann einige Einstellungen vornehmen und sein Profil editieren (Den angezeigten Namen ändern, Infos über das Profil eingeben, die Sprache und Zeitzone festlegen und festlegen, wie viele Postings am Stück angezeigt werden). Um ein eigenes Banner- und Avatarbild muss man diese Bilder unter den Namen "me-banner.jpg" und "me-avatar.jpg" in das Verzeichnis auf dem Webspace hochladen, wo man auch "seppo.cgi" gespeichert hat. Außerdem ist es möglich, das Passwort für den Account zu ändern.
Andere Fediverse-Nutzer können einem folgen (Subscribers) und man selbst kann anderen Fediverse-Nutzern folgen (Subscribed to). Und man kann Nutzer blocken.
Selbstverständlich kann man Postings verfassen und veröffentlichen. Und es ist möglich, eigene Postings zu editieren. Auch die Möglichkeit, Postings zu löschen, ist vorhanden.
URLs im Text eines Postings werden in anklickbare Links umgewandelt.
Ebenfalls ist es möglich, Beiträge zu "liken".
Schließlich kann man Postings "boosten" ("repeaten", "wiederholen").
Mehr geht derzeit nicht!
Was fällt auf?
Genau... Was ist denn mit "Antworten" oder "Kommentieren"? Tja, leider fehlt genau diese (essenzielle) Funktion derzeit noch. Sie steht aber offensichtlich als nächste Funktion auf dem Plan. Muss auch!
Als weiteres, bald geplantes Feature steht dann noch das Teilen von Bildern an.
Ich hoffe, dass auch Erwähnungen und ggf. Direktnachrichten in der Pipeline sind (letztere ergeben eh nur einen Sinn, wenn das Antworten möglich geworden ist).
Es ist anscheinend auch geplant, #Seppo! mit Phanpy und Tusky kompatibel zu machen. Interessant für Nutzer, die eine Webapp bzw. eine Android-App verwenden möchten.
Nicht geplant (und wahrscheinlich, um #Seppo! wirklich einfach zu halten, wird sich daran auch nichts ändern) sind Textformatierungen, der Zugriff auf eine öffentliche Zeitleiste, das dauerhafte speichern von eingehenden Postings (sie werden für 90 Tage vorgehalten), Statistiken über Likes, Bookmarks und ein Mehrbenutzer-Betrieb.
Die letztgenannten Einschränkungen mögen manchen betrüben... aber man kann damit leben. Insbesondere wenn man sich vor Augen hält, dass #Seppo! ein System für jeden ist, dass auch jeder, der über Webspace verfügt, installieren und nutzen kann, ohne Experte zu sein. Vielleicht wird es irgendwann ja auch einmal einfache Textauszeichnungen geben, wie sie derzeit auch bei Mastodon möglich sind... wer weiß? Essenziell ist das aber nicht, wenn man einfach nur Teil des Fediverse mit eigener Instanz sein möchte.
Man muss also einige Abstriche machen. Dafür gewinnt man ein großes Stück Unabhängigkeit. Übrig bleibt lediglich die Abhängigkeit vom Webspace-Provider. Sicher sollte es auch möglich sein, #Seppo! auf z.B. einem Raspi zu Hause zu betreiben. Aber dann hört es auf, einfach und für jeden nutzbar zu sein. Denn dann muss man sich mit dynamischen DNS (dDNS) und dem Installieren eines LAMP-Stacks auseinandersetzen.
Wer #Seppo! nutzen möchte, muss sich ein wenig umgewöhnen. Einige Dinge sind anders bezeichnet, als man es vielleicht bisher aus dem Fediverse kennt... und einiges findet man auf Anhieb nicht so schnell, bis man sich an das Konzept gewöhnt hat.
Deshalb hier eine Mini-Anleitung bzw. Erläuterungen zur Benutzung:
Ruft man die eigene Instanz auf, so landet man bei einer öffentlich sichtbaren Kombination aus Profilansicht und Kanal des (einzigen!) Nutzers, also der Liste der vom Nutzer geposteten Beiträge.
Im Banner des Profils sieht man einen Button "Public", der immer zu genau dieser Ansicht führt, egal ob man eingeloggt ist, oder nicht. Wenn andere Fediverse-Nutzer auf dieser Seite landen, können sie dem #Seppo!-Account leicht folgen. Dafür gibt es ein Eingabefeld, in welches sie ihr eigenes Handle ("Fediverse-Name" / "Fediverse-Adresse") eingeben können. Ein Klick auf den rechts davon befindlichen Button "Subscribe" führt dann zur eigenen Instanz und dort zum Dialog für das Hinzufügen einer Verbindung.
Ganz rechts sieht man, wenn man noch nicht eingeloggt ist, den Button "Login", mit welchem man sich bei der Instanz einloggen kann.
Nach dem Einloggen findet man sich in der "Subscribed-to-Timeline" wieder, also der Timeline, in welcher alle Postings der Nutzer auftauchen, denen man selbst folgt.
Am oberen Rand gibt es dann die Buttons "Public", "Subscribed to", "People" und "Settings".
Ein Klick auf "Public" führt wieder zu Ansicht des eigenen Profils und Kanals. Ist man eingeloggt, fehlt bei der "Public-Ansicht" das Eingabefeld, um dem eigenen Account zu folgen und wird durch den Button "Subscribed to" ersetzt.
Ein Klick auf "Subscribed to" führt zu der Timeline-Ansicht, die sich nach dem Einloggen ja bereits einmal gezeigt hat.
Klickt man auf "People", so gelangt man zur Seite der "Following-Follower-Block-Verwaltung".
Auf dieser Seite befindet sich ganz oben wieder der Button "Public", der zum eigenen Kanal führt und damit zum Verlassen der "Follow-Verwaltung" dient.
Unter dem Schriftzug "People" gibt es dann erst einmal drei Buttons: "Subscribed to", "Subscribers" und "Blocked".
Hier nicht durcheinander kommen! Der unter "People" befindliche Button "Subscribetd to" führt nicht, wie man vielleicht vermuten könnte, zur Timeline-Ansicht, sondern zur Ansicht aller Kontakte, welchen man selbst folgt.
Dort gibt es ein Suchfeld (sinnvoll, wenn man sehr viele Kontakte hat) und darunter sind alle Nutzer aufgeführt, denen man selbst folgt. Ein Klick auf das jeweilige Handle führt zur Kanal-Ansicht innerhalb von #Seppo!. Dort kann man dann auch das Folgen beenden oder den Kanal blocken. Außerdem wird angezeigt, ob einem der Nutzer selbst auch folgt. Es gibt auch noch einen Button "Message", der darauf hindeutet, dass sowas wie Erwähnungen oder Direktnachrichten demnächst geplant sind. Derzeit ist er funktionslos ausgegraut.
Der Klick auf den Button "Subscribers" unter dem Schriftzug "People" führt zur Übersicht über alle Nutzer, welche einem selbst folgen. EIn Klick auf das jeweilige Handle führt wieder zur Kanalansicht mit den eben genannten Möglichkeiten.
Der Klick auf "Blocked" führt dann natürlich zur Liste aller Nutzer, welche man selbst blockiert hat... mit wieder den selben Möglichkeiten (über die Kanalansicht kann man das Blocken dann natürlich auch wieder rückgängig machen).
Unter den nun erläuterten Buttons befindet sich eine Eingabezeile, die mit "Look up somebody:" überschrieben ist und neben der sich ein Button "View Profile" befindet. Dieses Feld kannman dafür verwenden, um neue Verbindungen zu Nutzern, deren Handles man kennt herzustellen (also diesen zu folgen). Gibt man dort ein Handle ein und klickt auf den Button, so wird die Kanalseite zu diesem Handle angezeigt, auf welcher man dann den Button findet, mit welchem man dem Nutzer folgen kann. Kennt man aber z.B. das Handle eines Nutzers, den man generell blockiern möchte, so kann man die Suche auch hierfür nutzen.
Schließlich gibt es unter dieser Eingabezeile auch noch ein größeres Textfeld, welches mit "Bulk Actor Activity" überschrieben ist und unter welchem sich drei Buttons ("Subscribe to", "Unsubscribe" und "Block") befinden. In das Feld kann man zeilenweise Handles von Kanälen eingeben und mit den Buttons dann die gewünschte Aktion für alle Kanäle durchführen. (Zumindest beim Folgen hat das bei mir bisher nicht funktioniert.)
Als letztes nun noch der Button "Settings". Dieser führt zur Seite mit den Einstellungen.
Ganz oben wieder der "Exit-Button", der mit "Subscribed to" beschriftet ist und zur Timeline-Ansicht führt.
Darunter gibt es zwei Buttons: "Edit my Profile", mit denen man die bereits zu Anfang gezeigten Profil-Einstellungen erreichen kann.
Und der Button "Change Password"... der wohl selbsterklärend genug sein dürfte.
Dann gibt es ein "Machine Room" überschriebenes Textfeld "signed http GET", dessen Sinn sich mir noch(!) nicht erschlossen hat. 😉
Am Ende der Seite findet man dann noch ein paar aktuelle statistische Informationen zu eigenen Instanz, wie zur Warteschlange, zu Jobs und zu In- und Outbox, sowie einige Referenzen und Links.
Beitrag schreiben und veröffentlichen:
In der Ansicht "Subscribed to" (Timeline) und "Public" (Kanalansicht) gibt es ein Suchfeld, welches derzeit noch ohne Funktion (ausgegraut) ist, sowie ein Textfeld "Enter text to start a post.", neben dem sich ein Button "Create Post" befindet. In dieses Feld muss man den Titel des Postings eingeben und dann auf den Button klicken. Anschließend erscheint der Beitrags-Editor.
Hier kann man seinen Beitrag nun verfassen. Unter dem Textfeld für den Beitrag befindet sich noch eine Reihe Emoticons. Klickt man auf eines dieser Symbole, so wird es in die Zwischenablage kopiert und man kann es im Textfeld einfügen.
Es gibt auch drei Buttons unter dem Editor: "Submit Post", "Cancel Create" und (inaktiv ausgegraut) "Delete Post".
Ein Klick auf "Submit Post" veröffentlicht das Posting. "Cancel Create" verwirft den Entwurf. Und "Delete Post" funktioniert hier(!) nicht (das ist für das nachträgliche Editieren gedacht).
In der Ansicht "Public" erscheint das Posting nun und es wird an diejenigen verteilt, welche einem selbst folgen (funktioniert prima... sogar mit Friendica, was ja teilweise etwas bockig mit anderen Diensten ist 😉).
Bei eigenen Postings gibt es am Ende einen Link "Edit". Damit kann man seine eigenen Postings nachträglich bearbeiten. Es öffnet sich dann wieder der Beitrags-Editor und man kann das Posting verändern. Und nun ist auch der Button "Delete Post" aktiviert (rot hinterlegt). Damit ist es möglich, das Posting wieder zu löschen.
So, das war es dann auch erst einmal...
Jetzt hier noch ein paar wichtige Links und ein erstes Fazit:
Als die eigentliche Homepage von #Seppo! sehe ich diese hier an: #Seppo!
Weitere Informationen und die Anleitung für die Installation findet man auf der Support-Seite.
Auf der Download-Seite kann man die aktuelle Version herunterladen.
Das Software-Repository ist bei Codeberg zu finden: seppo/seppo.
Hinweise zu möglichen Fehlern (und die jeweils bei Fehlermeldungen anzugebenden Fehlernummern) findet man unter Codes.
Der Entwickler (Marcus Rohrmoser) betreibt auch ein Blog zu #Seppo! Im Fediverse kann man ihm unter @Marcus Rohrmoser 🌻 folgen.
Außerdem gibt es eine Mailing-Liste und eine Support-Seite mit wichtigen Hinweisen.
Wer #Seppo! einmal ausprobieren möchte, ohne es selbst zu "installieren", kann dies bei der Demo-Instanz tun, die täglich zurückgesetzt wird.
Und nun mein erstes Zwischenfazit:
#Seppo! ist eine tolle Idee! Eine eigene Fediverse-Instanz, die auch ohne besonderes technisches Know-How einfach installiert und in Betrieb genommen werden kann. Die Software kann man als "spartanisch" bezeichnen, was ihr aber nicht gerecht wird. Sie ist schlicht auf das Notwendigste reduziert, erlaubt es aber, völlig eigenständig am Fediverse teilzunehmen. Was man unbedingt benötigt, wird zur Verfügung gestellt.
Und #Seppo! hat keine großen Ansprüche, es ist ressourcenschonend.
Fakt ist aber auch: #Seppo! ist noch nicht "fertig". Man kann es nutzen, es fehlt derzeit aber noch an einer wesentlichen Fähigkeit, nämlich dem kommentieren und der Anzeige von Kommentaren am Posting. Ausprobieren lohnt aber auf jeden Fall. Und ich schätze, dieses wichtige Feature wird band kommen. Wenn dann noch das Foto-Sharing ebenfalls kommt, hat man mit #Seppo! eine vollwertige Fediverse-instanz. Und dann gilt: JEDER kann Fediverse! Ausreden geten dann nicht mehr...
Klar... es kann die "großen" Dienste nicht ersetzen... aber das solle es ja wohl auch nicht. Der Entwickler gibt uns einfach ein Instrument an die Hand, welches uns eine große Unabhängigkeit schenkt.
Ach... und wer mir folgen möchte: @pepecyb@klacker.net
Auch wenn Hubzilla meine absolute Nummer eins ist, bin ich immer offen für andere Fediverse-Dienste und ich schaue mir viele davon an...
View article
View summary
Auch wenn Hubzilla meine absolute Nummer eins ist, bin ich immer offen für andere Fediverse-Dienste und ich schaue mir viele davon an. Teilweise installiere ich dann auch selbst Instanzen, um noch genauer hinter die Kulissen schauen zu können. Außerdem möchte ich (ist mein Spleen) mindestens eine eigene Instanz eines Dienstes, der nicht Hubzilla ist, betreiben... auch als Backup für den selbst verwalteten Fediverse-Zugang.
Neben zwei Hubzilla-Hubs habe ich (auch aus dem letzteren Grund) noch einen (streams)-Hub und einen Forte-Hub in Betrieb.
Im Herbst 2023 hatte ich dann den für mich ultimativen Alternativ-Fediversedienst gefunden: Firefish. Es bot mir einen gut föderierenden ActivityPub-Zugang und hielt etliche Features, die ich an Hubzilla schätze (Cloud, anständig formatierbare Texte, keine extreme Zeichenbeschränkung...
Nur leider ist der Fisch dann recht bald "abgesoffen". Keine Weiterentwicklung... Projekt quasi aufgegeben und deshalb verwaist.
Dann habe ich es mal mit Sharkey versucht. Das lief eher suboptimal... insbesondere die Suche (die man zwingend für das Herstellen von Verbindungen braucht) und das Föderationsverhalten waren nicht wirklich gut. Viele Kontakte konnte ich ums Verrecken nicht herstellen... und dann kam noch der Umstieg auf eine neue Redis-Version dazu, die ich aufgrund der Installation unter YunoHost (damals noch Version 11.x, die auf Debian 11 basierte) nicht mitgehen konnte. Ein weiterer Versuch mit Sharkey in Docker brachte aber auch keine Verbesserungen.
Ok... dann mal ein Test mit dem "Original", also Misskey. Auch da stieß ich auf vergleichbare Probleme. Außerdem war die bei YunoHost angebotene Version damals schon weit über ein Jahr alt. Ein weiterer Versuch mit Docker brachte aber auch keine nennenswerten Verbesserungen.
Schließlich wurde ich dann auf Iceshrimp aufmerksam, das seinerseits eine Art Fork von Firefish war. Und da lief es wieder deutlich besser. Es fühlte sich beinahe wieder wie Firefish an. Nur... auch da hing die Entwicklung etwas in den Seilen... und ich wollte nicht schon wieder auf ein totes Pferd aufsatteln.
Versuche mit Pleroma haben mich auch nicht glücklich gemacht... und so ließ die Intensität meiner Suche nach einer festen Alternative auch nach.
Dann wurde meine Aufmerksamkeit auf Mitra gelenkt. Es hieß, dass dieses System die "nomadische Identität" mit ActivityPub unterstützen solle. Allein das war schon ein Grund, es mir genauer anzuschauen. Na ja... es erschien wie ein Mastodon-Light. Trotzdem habe ich es mir eine ganze Weile angeschaut und dann auch selbst eine Instanz installiert, um mir anzuschauen, was da als Admin alles noch machbar ist.
Das Ergebnis war aber eher enttäuschend. Im Endeffekt war da nichts "hinter den Kulissen" zu entdecken, was man nicht auch "auf der Bühne" gezeigt bekommt.
Der Vorteil gegenüber Mastodon war, dass es wesentlich ressourcenschonender lief. Ok... aber eine Alternative war es für mich nicht. Eher eine Art "Studie", wie man einen Fediverse-Dienst auch realisieren kann.
Die Erinnerung an Firefish und Iceshrimp ließ mich nicht los... und Iceshrimp sollte ja seit einiger Zeit mit neuem Schwung quasi neu programmiert werden: Iceshrimp.NET.
Die Neuentwicklung eines derart komplexen Systems nimmt natürlich Zeit in Anspruch... und die Fortschritte waren nur bei genauer Verfolgung des Repos zu verfolgen. Nun aber scheint die erste Version nicht mehr weit entfernt zu sein. Es gibt schon eine Weile eine Beta-Version.
Nun gut... eine Beta selbst zu installieren, ist nicht, wenn ich nicht ganz dringend an einem Projekt hänge, keine Sache für mich. Also einmal als "Gast" ausprobieren. Allerdings war es ausgesprochen schwierig, eine Iceshrimp.NET Instanz zu finden, welche auch Registrierungen erlaubt.
Kürzlich ist es mir dann gelungen.
Und die Enttäuschung war enorm groß!
Das ist ne Beta! Probleme und Fehler inklusive. Also da habe ich mir nix vorgemacht, wobei ich keine wirklich drastischen Fehler gefunden habe. Wer Beta nutzt, sollte wissen worauf er sich einlässt. Das allerdings war auch nicht der Grund für meine maßlose Enttäuschung.
Nein... eine Beta dient dazu, bislang nicht entdeckte Fehler einer eigentlich für die endgültig zur Veröffentlichung vorgesehene Version zu finden und diese auszumerzen. Allerdings bedeutet damit Beta auch, dass die Version in Funktion und Umfang nahezu der Version zur Veröffentlichung entspricht.
Und das war halt enttäuschend.
Ich hatte die Nachbildung von Iceshrimp und damit einen Funktionsumfang erwartet, der auch dem von Firefish in etwa entspricht.
Aber nö! Auch hier sah ich eher eine "Mastodon extrem light" Version einer Fediverse-Software. Die ganzen tollen Features von Iceshrimp existieren nicht.
Man hat die bekannten Timelines (Home, Lokal, ....), man kann sich die Benachrichtigungen anschauen, die Suche funktioniert inzwischen manierlich, es gibt eine Cloud mit rudimentären Funktionen und ein Einstellungs-Menü. Das war es! Echt! Mehr ist nicht!
In den Einstellungen kann man sein Profil bearbeiten (Profilbild, Name, Bio, Geburtsdatum, Ort), man kann Wortfilter für die Timeline anlegen, einige Grundeinstellungen für den Account vornehmen und ... nüscht.
Die Einstellung des Decks ist nicht möglich... allerdings ist sie auch nicht nötig, weil es ja kaum was gibt, was man hin- und herschieben könnte. Auch keine Widgets. Nix halt.
Beim Erstellen einer Notiz steht einem als Auszeichnungssprache ein rudimentäres Markdown zur Verfügung. Unterstreichung und Überschriften funktionieren nicht. Auch nicht das Einbinden z.B. von Bildern aus dem Cloud-Speicher.
Ja... und Beta bedeutet hat, dass das der Umfang der ersten finalen Version sein soll... so ungefähr.
Das hat aber mit dem "alten" Iceshrimp (und auch mit Firefish) gar nichts zu tun. Das ist eine, (auf den ersten Blick) optisch ein wenig dem Original nachempfundene, völlig neue Fediverse-Software mit sehr eingeschränkten Möglichkeiten. Ob da in kommenden Versionen doch noch mehr vom "alten Iceshrimp"eingebaut wird, weiß ich nicht (die Öffentlichkeitsarbeit des Projekts ist... mäßig...). Und wie lange das dann ggf. dauern soll, mag ich mir gar nicht vorstellen. Einige Funktionen sind zwar in der "Roadmap", aber ich bin da nicht so zuversichtlich. So war angedacht, die "Antennen" (ein wirklich tolles Feature) 1.2025 anzugehen... aber davon ist nix zu sehen.
Ich fürchte, das "alte Iceshrimp" wird aber fallen gelassen. Damit ist diese Alternative dann auch gestorben.
Vielleicht schaue ich mir bei Gelegenheit noch einmal Misskey in einer aktuellen Version an. Die Installation des "alten Iceshrimp" lohnt mangels Zukunftsperspektiven jedenfalls wohl nicht (keine Ahnung, ob es weitergeführt werden soll oder verworfen wird).
Conversation Features
Loading...
Loading...