Like Us
Support Hubzilla
Nur meine Meinung / Einstellung
In den vergangenen Monaten habe ich viel mit verschiedenen Diensten im Fediverse experimentiert. Manches gefiel mir, manches gefiel mir nicht. Manches funktionierte, manches funktionierte nicht. Bei einigen Diensten fehlten mir wesentliche Features, bei anderen hakte es hier und da. Mastodon… funktioniert. Ist mir aber wirklich zu eingeschränkt. Und für eine eigene Instanz echt zu speicherhungrig. Meine Test-Installationen (regulär und Glitch) haben Plattenplatz gefressen… da konnte man bei zugucken. Bei einer Single-User-Instanz. ...
View article
View summary
Dieser Artikel wurde am 2. März 2024 erstmals veröffentlicht.
In den vergangenen Monaten habe ich viel mit verschiedenen Diensten im Fediverse experimentiert.
Manches gefiel mir, manches gefiel mir nicht. Manches funktionierte, manches funktionierte nicht.
Bei einigen Diensten fehlten mir wesentliche Features, bei anderen hakte es hier und da.
Mastodon… funktioniert. Ist mir aber wirklich zu eingeschränkt. Und für eine eigene Instanz echt zu speicherhungrig. Meine Test-Installationen (regulär und Glitch) haben Plattenplatz gefressen… da konnte man bei zugucken. Bei einer Single-User-Instanz.
Firefish war echt prima, habe ich aber aus (hier im Blog) geschilderten Gründen aufgegeben… Miss- und Sharkey waren mir nicht kommunikativ genug, was die Föderation betrifft. Mit Iceshrimp hatte ich dann einen adäquaten Ersatz für Firefish gefunden… nur leider ist mir meine Instanz ganz plötzlich, wie aus heiterem Himmel, abgekackt (irgendwas mit yarn/npm). Leider konnte mir auch niemand helfen, das noch zu reparieren. Also dann halt nicht.
Ich hatte dann auch mal mit Epicyon herumgemacht. Vom Konzept her gefällt es mir ausgezeichnet (zumal ich mit Python auch vertraut genug bin). Leider klappte es mit der Föderation auch nicht wirklich. Aber mal so gar nicht. Schade… das hätte mir gefallen können.
Und so betreibe ich jetzt nur noch zwei Fediverse-Instanzen… auf Dauer angelegt: Hubzilla und streams.
Hubzilla gibt es seit 2015 (na ja… eigentlich schon seit 2012) und ich habe in der gesamten Zeit, in der ich Instanzen betrieben habe, keine wirklich dramatischen Probleme erlebt. 2015 erschien Version 1.0 und jetzt steht Version 9 vor der Tür. Es wird kontinuierlich entwickelt und gepflegt. Es geht relativ sparsam mit dem Plattenplatz um und frisst auch nicht unnötig Prozessor-Ressourcen. Also: Es funktioniert einfach!
(streams) scheint in die gleiche Kerbe zu hauen.
Vor allem habe ich mit beiden Plattformen die wenigsten (also so ziemlich keine) Probleme, mit anderen Plattformen zu interagieren. Vor allem aber bieten sie mir die größtmögliche Kontrolle über meinen Account bzw. Kanal.
Die Zeit mit Experimenten (also dem Betrieb eigener Instanzen) ist jetzt erstmal vorbei. Vielleicht wage ich bei Gelegenheit mal einen Versuch mit Bonfire… aus Neugier… aber ansonsten genügen mir Hubzilla und (streams) vollauf. Den Rest? Muss ich nicht haben! Meine Meinung, meine Einstellung… 😉
In den vergangenen Monaten habe ich viel mit verschiedenen Diensten im Fediverse experimentiert.
Manches gefiel mir, manches gefiel mir nicht. Manches funktionierte, manches funktionierte nicht.
Bei einigen Diensten fehlten mir wesentliche Features, bei anderen hakte es hier und da.
Mastodon… funktioniert. Ist mir aber wirklich zu eingeschränkt. Und für eine eigene Instanz echt zu speicherhungrig. Meine Test-Installationen (regulär und Glitch) haben Plattenplatz gefressen… da konnte man bei zugucken. Bei einer Single-User-Instanz.
Firefish war echt prima, habe ich aber aus (hier im Blog) geschilderten Gründen aufgegeben… Miss- und Sharkey waren mir nicht kommunikativ genug, was die Föderation betrifft. Mit Iceshrimp hatte ich dann einen adäquaten Ersatz für Firefish gefunden… nur leider ist mir meine Instanz ganz plötzlich, wie aus heiterem Himmel, abgekackt (irgendwas mit yarn/npm). Leider konnte mir auch niemand helfen, das noch zu reparieren. Also dann halt nicht.
Ich hatte dann auch mal mit Epicyon herumgemacht. Vom Konzept her gefällt es mir ausgezeichnet (zumal ich mit Python auch vertraut genug bin). Leider klappte es mit der Föderation auch nicht wirklich. Aber mal so gar nicht. Schade… das hätte mir gefallen können.
Und so betreibe ich jetzt nur noch zwei Fediverse-Instanzen… auf Dauer angelegt: Hubzilla und streams.
Hubzilla gibt es seit 2015 (na ja… eigentlich schon seit 2012) und ich habe in der gesamten Zeit, in der ich Instanzen betrieben habe, keine wirklich dramatischen Probleme erlebt. 2015 erschien Version 1.0 und jetzt steht Version 9 vor der Tür. Es wird kontinuierlich entwickelt und gepflegt. Es geht relativ sparsam mit dem Plattenplatz um und frisst auch nicht unnötig Prozessor-Ressourcen. Also: Es funktioniert einfach!
(streams) scheint in die gleiche Kerbe zu hauen.
Vor allem habe ich mit beiden Plattformen die wenigsten (also so ziemlich keine) Probleme, mit anderen Plattformen zu interagieren. Vor allem aber bieten sie mir die größtmögliche Kontrolle über meinen Account bzw. Kanal.
Die Zeit mit Experimenten (also dem Betrieb eigener Instanzen) ist jetzt erstmal vorbei. Vielleicht wage ich bei Gelegenheit mal einen Versuch mit Bonfire… aus Neugier… aber ansonsten genügen mir Hubzilla und (streams) vollauf. Den Rest? Muss ich nicht haben! Meine Meinung, meine Einstellung… 😉
Brücke? Ohne mich!
Hab mich bei der Diskussion wegen der Bluesky-Brücke von bridgy.fed ja erstmal echt bedeckt gehalten. Es gab ausreichend Trubel… Pros und Contras… und die Ankündigung, die Verbindung nun doch opt-in statt opt-out zu machen. ...
View article
View summary
Dieser Artikel wurde am 22. Februar 2024 erstmals veröffentlicht.
Hab mich bei der Diskussion wegen der Bluesky-Brücke von bridgy.fed ja erstmal echt bedeckt gehalten. Es gab ausreichend Trubel… Pros und Contras… und die Ankündigung, die Verbindung nun doch opt-in statt opt-out zu machen.
Grundsätzlich ist Interoperabilität ja auch ne gute Idee. Allerdings hängt es trotzdem davon ab, mit wem man denn nun föderiert. Und wie sich das auswirkt.
Aufgrund der Architektur der Fediversedienste besteht nicht die Gefahr, dass mir ungewollte Inhalte in die Timeline gedrückt werden. Den Inhalt meiner Timeline bestimme ich halt selbst. Wenn ich mich entscheide, mich mit einem Bluesky-Nutzer oder einem Threads-Nutzer zu verbinden, dann entscheide ich mich dafür, dass seine Inhalte und von ihm geteilte Inhalte in meinem Stream landen. Teilt er was von einem anderen Nutzer seines Dienstes und es gefällt mir nicht, dann kann ich es aus meiner Timeline löschen und, wenn ich denn meine, kann ich auch den unerwünschten fremden Nutzer muten oder blockieren. Das ist bei Kontakten aus dem freien Fediverse ja auch nicht anders. Und es klappt.
Ggf. muss der Admin oder ein Moderator bestimmte Inhalte auch moderieren… auch das kann ebenfalls bei Beiträgen aus dem freien Fediverse geschehen.
Die Frage, die sich mir stellt, ist aber: Wie sieht es auf der anderen Seite aus?
Was passiert mit meinen Inhalten, wenn mir ein Nutzer von Threads oder Bluesky (via Bridge) folgt? Der landet dann doch vermutlich in de Timeline des Nutzers. Nun sind die Streams auf diesen beiden Plattformen aber algorithmisch gesteuert. Der Nutzer hat keinen oder nur wenig Einfluss darauf, was ihm in welcher Reihenfolge gezeigt wird. Mein Inhalt wird also bei Threads oder Bluesky nach deren Gutdünken verwurstet… Das wäre ja noch kein so großer Beinbruch… aber wenn ich nun etwas von einem anderen Fediverse-Nutzer teile, dann müsste es doch auch bei dem T-/B-Nutzer in der Timeline landen… und damit auch in der Wurstmaschine von Meta oder Dorsey-World. Und der Fediverse-Nutzer, dessen Beitrag ich geteilt habe, hat gar keinen Einfluss darauf, dass es da verwurstet wird… dass es durch den Algorithmus genuddelt wird und womöglich (keine Ahnung, ob es so ist) auch in der Timeline von anderen T-/B-Nutzern landet.
Nun… mit Threads hab ich eh meine Probleme, weil es halt ein Meta-Produkt ist… und davon halte ich mich so weit weg, wie nur möglich. Ich möchte einfach nicht, dass meine Inhalte, Inhalte der Nutzer meiner Instanz oder Inhalte von Nutzern, die mir oder einem Nutzer meiner Instanz folgen, in den Klauen von Meta landen (die Inhalte sind zwar öffentlich und damit nicht geschützt, aber ich werde sie Meta nicht freiwillig in den Allerwertesten pumpen). Deshalb ist bei den von mir betriebenen Fediverse-Servern (Iceshrimp, Hubzilla, (Streams)) „threads.net“ auch blockiert.
Zu Bluesky musste ich mir erst noch eine Meinung bilden. Die Herkunft bzw. Geschichte ist halt eng mit RaiderHeißtJetztTwixMitX verbunden, was nicht gerade für einen Vertrauensvorschuss sorgt. Eine der Ideen von Bluesky war es, ein föderiertes, also dezentrales Netzwerk aufzubauen. Man hat sich dafür für ein eigenes Protokoll (AT) entschieden, anstatt auf das bewährte und standardisierte, sowie weit verbreitete ActivityPub zu bauen. Nein… man wollte das Rad neu erfinden und das beste Rad aller Zeiten designen. Ok… wenn’s denn sein muss. Muss man nicht unbedingt verstehen. Aber egal.
Heute nun habe ich das Blogpost vom Bluesky-Team zum Start der Föderation gelesen… und bin zu dem Schluss gekommen, dass ich auch nix mit Bluesky zu tun haben möchte. Weder in die eine, noch in die andere Richtung. Der Beitrag offenbart eine große Unkenntnis über Struktur und Funktion des Fediverse (oder sie lügen dreist, um besser dazustehen). Meine Fresse… wenn man keine Ahnung hat, einfach mal die Fresse halten! Und auf diesen Fehlinformationen und dem gefährlichen Halbwissen bauen sie dann ihre Argumentation pro Bluesky/AT auf.
Na, wenn das Fediverse so beschissen ist, dann werde ich Bluesky davor schützen, durch mich (also die von mir betriebenen Instanzen) damit in Berührung zu kommen, indem ich „bsky.brid.gy“ auch auf die Blockliste setze. Bitteschön! Gern geschehen! Über diese „Brücke“ gehe ich nicht… 😉
Hab mich bei der Diskussion wegen der Bluesky-Brücke von bridgy.fed ja erstmal echt bedeckt gehalten. Es gab ausreichend Trubel… Pros und Contras… und die Ankündigung, die Verbindung nun doch opt-in statt opt-out zu machen.
Grundsätzlich ist Interoperabilität ja auch ne gute Idee. Allerdings hängt es trotzdem davon ab, mit wem man denn nun föderiert. Und wie sich das auswirkt.
Aufgrund der Architektur der Fediversedienste besteht nicht die Gefahr, dass mir ungewollte Inhalte in die Timeline gedrückt werden. Den Inhalt meiner Timeline bestimme ich halt selbst. Wenn ich mich entscheide, mich mit einem Bluesky-Nutzer oder einem Threads-Nutzer zu verbinden, dann entscheide ich mich dafür, dass seine Inhalte und von ihm geteilte Inhalte in meinem Stream landen. Teilt er was von einem anderen Nutzer seines Dienstes und es gefällt mir nicht, dann kann ich es aus meiner Timeline löschen und, wenn ich denn meine, kann ich auch den unerwünschten fremden Nutzer muten oder blockieren. Das ist bei Kontakten aus dem freien Fediverse ja auch nicht anders. Und es klappt.
Ggf. muss der Admin oder ein Moderator bestimmte Inhalte auch moderieren… auch das kann ebenfalls bei Beiträgen aus dem freien Fediverse geschehen.
Die Frage, die sich mir stellt, ist aber: Wie sieht es auf der anderen Seite aus?
Was passiert mit meinen Inhalten, wenn mir ein Nutzer von Threads oder Bluesky (via Bridge) folgt? Der landet dann doch vermutlich in de Timeline des Nutzers. Nun sind die Streams auf diesen beiden Plattformen aber algorithmisch gesteuert. Der Nutzer hat keinen oder nur wenig Einfluss darauf, was ihm in welcher Reihenfolge gezeigt wird. Mein Inhalt wird also bei Threads oder Bluesky nach deren Gutdünken verwurstet… Das wäre ja noch kein so großer Beinbruch… aber wenn ich nun etwas von einem anderen Fediverse-Nutzer teile, dann müsste es doch auch bei dem T-/B-Nutzer in der Timeline landen… und damit auch in der Wurstmaschine von Meta oder Dorsey-World. Und der Fediverse-Nutzer, dessen Beitrag ich geteilt habe, hat gar keinen Einfluss darauf, dass es da verwurstet wird… dass es durch den Algorithmus genuddelt wird und womöglich (keine Ahnung, ob es so ist) auch in der Timeline von anderen T-/B-Nutzern landet.
Nun… mit Threads hab ich eh meine Probleme, weil es halt ein Meta-Produkt ist… und davon halte ich mich so weit weg, wie nur möglich. Ich möchte einfach nicht, dass meine Inhalte, Inhalte der Nutzer meiner Instanz oder Inhalte von Nutzern, die mir oder einem Nutzer meiner Instanz folgen, in den Klauen von Meta landen (die Inhalte sind zwar öffentlich und damit nicht geschützt, aber ich werde sie Meta nicht freiwillig in den Allerwertesten pumpen). Deshalb ist bei den von mir betriebenen Fediverse-Servern (Iceshrimp, Hubzilla, (Streams)) „threads.net“ auch blockiert.
Zu Bluesky musste ich mir erst noch eine Meinung bilden. Die Herkunft bzw. Geschichte ist halt eng mit RaiderHeißtJetztTwixMitX verbunden, was nicht gerade für einen Vertrauensvorschuss sorgt. Eine der Ideen von Bluesky war es, ein föderiertes, also dezentrales Netzwerk aufzubauen. Man hat sich dafür für ein eigenes Protokoll (AT) entschieden, anstatt auf das bewährte und standardisierte, sowie weit verbreitete ActivityPub zu bauen. Nein… man wollte das Rad neu erfinden und das beste Rad aller Zeiten designen. Ok… wenn’s denn sein muss. Muss man nicht unbedingt verstehen. Aber egal.
Heute nun habe ich das Blogpost vom Bluesky-Team zum Start der Föderation gelesen… und bin zu dem Schluss gekommen, dass ich auch nix mit Bluesky zu tun haben möchte. Weder in die eine, noch in die andere Richtung. Der Beitrag offenbart eine große Unkenntnis über Struktur und Funktion des Fediverse (oder sie lügen dreist, um besser dazustehen). Meine Fresse… wenn man keine Ahnung hat, einfach mal die Fresse halten! Und auf diesen Fehlinformationen und dem gefährlichen Halbwissen bauen sie dann ihre Argumentation pro Bluesky/AT auf.
Na, wenn das Fediverse so beschissen ist, dann werde ich Bluesky davor schützen, durch mich (also die von mir betriebenen Instanzen) damit in Berührung zu kommen, indem ich „bsky.brid.gy“ auch auf die Blockliste setze. Bitteschön! Gern geschehen! Über diese „Brücke“ gehe ich nicht… 😉
Das Fediverse ist weit mehr…
…als Mastodon. Und Mastodon ist auch nicht der allein gültige Maßstab. ...
View article
View summary
Dieser Artikel wurde am 14. Februar 2024 erstmals veröffentlicht.
![Image/photo]()
…als Mastodon. Und Mastodon ist auch nicht der allein gültige Maßstab.
Anlässlich eines Postings von Jupiter Rowland, einem wirklichen Kenner des Fediverse, in seinem Hubzilla-Kanal, möchte ich hier in Zusammenfassung auch ein paar Hinweise für die deutschsprachigen Nutzer geben. Er hat da etliche Aspekte angebracht, die vielen Nutzern des Fediverse womöglich nicht so präsent sind.
Seinen Text in Form eines „Theads“ hatte er in „Päckchen“ zu 500 Zeichen gepostet, um Mastodon-Nutzer nicht zu überfordern.
Schwerpunkt seines Postings waren Inhaltswarnungen (contentwarning, CW, cw), aber auch die Unterschiede der verschiedenen Fediverse-Projekte, von denen die meisten deutlich älter sind als Mastodon.
Einer der Gründe, weshalb viele Nutzer des Fediverse „überrascht“ sind, wenn sie auf Postings stoßen, die nicht von einem Mastodon-Account stammen, ist, dass weit mehr erlaubt ist, als bei Mastodon selbst. Aufgrund der Reduzierung des Fediverse auf Mastodon durch Presse und Medien, wissen viele schlicht nicht, was das Fediverse in Wahrheit ist, nämlich ein offenes Netzwerk verschiedenster Zugänge, die sich auf ein gemeinsames Kommunikationsprotokoll geeinigt haben.
Tauchen dann plötzlich Postings mit teilweise wesentlich mehr als 500 Zeichen auf, so erscheint das dem Fediverse-Nutzer, der nur und ausschließlich Mastodon kennt, wie „schwarze Magie“.
Ist es aber nicht! Die Zeichenbeschränkung von Mastodon ist eine selbst auferlegte Beschränkung aus „Design-Gründen“. Es handelt sich dabei um keine Beschränkung des Fediverse und des genutzten Protokolls ActivityPub (AP). Die meisten anderen Dienste im Fediverse haben eine wesentlich großzügigere bzw. gar keine Beschränkung bezüglich der Textlänge.
Das gilt auch für Textformatierungen. Der Verzicht darauf ist eine Entscheidung der Macher von Mastodon. Andere Dienste erlauben hier weit mehr.
Ein wichtiger Punkt, der zu Missverständnissen und teilweise echten Ärger führt, sind die Inhaltswarnungen.
Postings mit „sensiblen Inhalten“ sollen mit einer Inhaltswarnung versehen werden. Das führt dazu, dass diese Postings in der Timeline „eingeklappt“, also nicht direkt lesbar, erscheinen. Um den Inhalt zu sehen, muss man sie anklicken. Die Inhaltswarnung selbst sollte einen Hinweis auf den Inhalt geben. So soll jeder dann entscheiden können, ob er sich den Inhalt anschauen möchte oder ob er es, um des lieben Seelenfriedens, sein lässt.
Sehr viele Dienste neben Mastdon bieten das aber gar nicht an, bzw. es ist nicht offensichtlich, wie man es machen kann und unterliegt verschiedenen Beschränkungen.
Das bedeutet aber nicht, dass Nutzer dieser Dienste nun jeglichem Inhalt „ungeschützt“ ausgesetzt sind. Nein, vergleichbare Mechanismen gibt es auch bei Hubzilla, Friendica , (streams) etc. Nur liegt hier die Verantwortung bei demjenigen, der geschützt werden will.
Das klingt vielleicht zunächst nach einer zusätzlichen Belastung, ist aber im Endeffekt ausgesprochen sinnvoll. Denn hier hat der Betroffene das Ausblenden in der eigenen Hand… derjenige, der wohl am besten weiß, ob und was ihn womöglich „triggert“.
Ein CW durch den Verfasser eines Postings ist hingegen eher ungeeignet. Und vor allem, wo soll die Sache denn ansetzten, wo soll sie beginnen? Woher soll ich als Verfasser denn wissen, ob es nicht einige wenige im Netz gibt, denen mein Inhalt an den Nerven sägt?
Diese Unmöglichkeit der Vorhersage führt zu einem teilweise inflationären Einsatz von CW. Lieber ein CW setzen… nicht dass man irgendwem auf die Füße tritt und man ausgeschimpft wird. Es gibt Mastodon-Instanzen mit teilweise irre anmutenden Nutzungsbedingungen, was Triggerwarnungen anbelangt. Politik? Bloß verstecken! Essen? Ja denkt Ihr denn nicht an die Menschen mit einer Essstörung oder diejenigen, welche gerade eine Diät machen? Auf jeden Fall verstecken! Bilder von Katastrophen? Verstecken! Dies und das? Verstecken!
Am besten, man würde alles verstecken… so fühlt sich das an.
Ich kann doch den anderen Nutzern das Denken nicht abnehmen und mich vor allem nicht in ihren psychischen Zustand hineinversetzen.
Das Prinzip wie es Hubzilla (und verwandte Dienste… ich schreibe jetzt zur Vereinfachung nur noch von Hubzilla, die verwandten Dienste sind aber „mitgemeint“ 😉 😀 ) macht, ist wesentlich sinnvoller. Hierzu kommt die App „NSFW“ zum Einsatz. Der Nutzer, der sich vor bestimmten Inhalten schützen möchte, „füttert“ NSFW mit entsprechenden Mustern (Wörter, Hashtags, regulären Ausdrücken) und fortan werden Postings mit entsprechenden Inhalten „aufklickbar“ verborgen. Derjenige, der gerade eine Diät macht z.B. gestaltet seinen Filter entsprechend und bleibt künftig von Essens-Fotos, Rezepten, Berichten von Restaurantbesuchen etc. verschont.
Die einzige Voraussetzung ist, dass Postende ihre Inhalte mit sinnvollen und passenden Tags versehen. Das aber ist nun kein Problem, wir aber leider gerade von den Nutzern von CW-Diensten leider zu sehr vernachlässigt… z.T. weil die Software diese Möglichkeit gar nicht explizit vorsieht.
Hubzilla bietet trotzdem eine Art CW… also einen Mechanismus, mit dem man sowas realisieren kann: die Zusammenfassung.
Bei einem Posting kann man eine Zusammenfassung angeben, die eigentlich dafür gedacht ist, den Inhalt längerer Postings zusammenzufassen. In der Timeline wird dann nur die Zusammenfassung angezeigt und man muss darauf klicken, um sich den gesamten Text anzeigen zu lassen. Das macht die Timeline übersichtlicher.
Will man nun z.B. ein Rezept für ein lecker Essen mit einer Art CW versehen, um Fastende nicht zu verschrecken, kann man „Essen, Rezept“ in die Zusammenfassung schreiben. Dann wird dem Besucher nur „Essen, Rezept“ angezeigt… und wenn es für ihn „unschädlich“ ist, klickt er drauf und kann das Rezept sehen.
Nur… das funktioniert nicht bei allen hubzillaartigen Diensten gleich einfach. Es gibt Dienste, die das Zusammenfassungsfeld nicht anzeigen. Hier kann man das aber trotzdem mittels BBcode eingeben und das Ergebnis ist das selbe.
Was aber nicht funktioniert: Kommentare zu einem solchen Posting werden nicht versteckt. Zusammenfassungen für Kommentare sind schlicht nicht vorgesehen. Kommentiert also jemand mit einem modifizierten Rezept, so schlägt dies unserem Faster ungefiltert ins Gesicht.
Da wäre auch wieder das Prinzip der NSFW-Filter optimal. Er packt einfach die entsprechenden Begriffe in seinen Filter und sieht dann auch solche Kommentare nicht.
Das Fediverse ist vielfältig. Und viele Dienste, die es schon weit vor Mastodon gab, gehen mit bestimmten Dingen anders um. Das sollten insbesondere Mastodon-Nutzer im Hinterkopf behalten, bevor sie einen anderen Nutzer wegen fehlendem CW ausschimpfen oder melden. Es gibt nicht wenig Dienste, die genau diese Form der Inhaltswarnung, wie sie bei Mastodon stattfindet, nicht anbieten, sondern eigene Mechanismen dafür haben.
Ich persönlich finde den „Hubzilla-Weg“ wesentlich besser, weil es jeder selbst in der Hand hat, was er sehen möchte und was nicht. Die umgekehrte Methode, der „Mastodon-Weg“ läuft auf „betreutes Denken“ hinaus und ist ja fast schon sowas wie ein fremder Algorithmus, der in meine Timeline eingreift.
An alle Mastodon-Nutzer, für die das Fediverse neu ist: Das Fediverse ist nicht Mastodon und Mastodon ist nicht das Fediverse. Das Fediverse ist ein riesiges Netzwerk verschiedener Dienste. Einen ersten Eindruck darüber, was noch zum Fediverse gehört findet man z.B. hier: Was sind Fediverse-Projekte?
…als Mastodon. Und Mastodon ist auch nicht der allein gültige Maßstab.
Anlässlich eines Postings von Jupiter Rowland, einem wirklichen Kenner des Fediverse, in seinem Hubzilla-Kanal, möchte ich hier in Zusammenfassung auch ein paar Hinweise für die deutschsprachigen Nutzer geben. Er hat da etliche Aspekte angebracht, die vielen Nutzern des Fediverse womöglich nicht so präsent sind.
Seinen Text in Form eines „Theads“ hatte er in „Päckchen“ zu 500 Zeichen gepostet, um Mastodon-Nutzer nicht zu überfordern.
Schwerpunkt seines Postings waren Inhaltswarnungen (contentwarning, CW, cw), aber auch die Unterschiede der verschiedenen Fediverse-Projekte, von denen die meisten deutlich älter sind als Mastodon.
Einer der Gründe, weshalb viele Nutzer des Fediverse „überrascht“ sind, wenn sie auf Postings stoßen, die nicht von einem Mastodon-Account stammen, ist, dass weit mehr erlaubt ist, als bei Mastodon selbst. Aufgrund der Reduzierung des Fediverse auf Mastodon durch Presse und Medien, wissen viele schlicht nicht, was das Fediverse in Wahrheit ist, nämlich ein offenes Netzwerk verschiedenster Zugänge, die sich auf ein gemeinsames Kommunikationsprotokoll geeinigt haben.
Tauchen dann plötzlich Postings mit teilweise wesentlich mehr als 500 Zeichen auf, so erscheint das dem Fediverse-Nutzer, der nur und ausschließlich Mastodon kennt, wie „schwarze Magie“.
Ist es aber nicht! Die Zeichenbeschränkung von Mastodon ist eine selbst auferlegte Beschränkung aus „Design-Gründen“. Es handelt sich dabei um keine Beschränkung des Fediverse und des genutzten Protokolls ActivityPub (AP). Die meisten anderen Dienste im Fediverse haben eine wesentlich großzügigere bzw. gar keine Beschränkung bezüglich der Textlänge.
Das gilt auch für Textformatierungen. Der Verzicht darauf ist eine Entscheidung der Macher von Mastodon. Andere Dienste erlauben hier weit mehr.
Ein wichtiger Punkt, der zu Missverständnissen und teilweise echten Ärger führt, sind die Inhaltswarnungen.
Postings mit „sensiblen Inhalten“ sollen mit einer Inhaltswarnung versehen werden. Das führt dazu, dass diese Postings in der Timeline „eingeklappt“, also nicht direkt lesbar, erscheinen. Um den Inhalt zu sehen, muss man sie anklicken. Die Inhaltswarnung selbst sollte einen Hinweis auf den Inhalt geben. So soll jeder dann entscheiden können, ob er sich den Inhalt anschauen möchte oder ob er es, um des lieben Seelenfriedens, sein lässt.
Sehr viele Dienste neben Mastdon bieten das aber gar nicht an, bzw. es ist nicht offensichtlich, wie man es machen kann und unterliegt verschiedenen Beschränkungen.
Das bedeutet aber nicht, dass Nutzer dieser Dienste nun jeglichem Inhalt „ungeschützt“ ausgesetzt sind. Nein, vergleichbare Mechanismen gibt es auch bei Hubzilla, Friendica , (streams) etc. Nur liegt hier die Verantwortung bei demjenigen, der geschützt werden will.
Das klingt vielleicht zunächst nach einer zusätzlichen Belastung, ist aber im Endeffekt ausgesprochen sinnvoll. Denn hier hat der Betroffene das Ausblenden in der eigenen Hand… derjenige, der wohl am besten weiß, ob und was ihn womöglich „triggert“.
Ein CW durch den Verfasser eines Postings ist hingegen eher ungeeignet. Und vor allem, wo soll die Sache denn ansetzten, wo soll sie beginnen? Woher soll ich als Verfasser denn wissen, ob es nicht einige wenige im Netz gibt, denen mein Inhalt an den Nerven sägt?
Diese Unmöglichkeit der Vorhersage führt zu einem teilweise inflationären Einsatz von CW. Lieber ein CW setzen… nicht dass man irgendwem auf die Füße tritt und man ausgeschimpft wird. Es gibt Mastodon-Instanzen mit teilweise irre anmutenden Nutzungsbedingungen, was Triggerwarnungen anbelangt. Politik? Bloß verstecken! Essen? Ja denkt Ihr denn nicht an die Menschen mit einer Essstörung oder diejenigen, welche gerade eine Diät machen? Auf jeden Fall verstecken! Bilder von Katastrophen? Verstecken! Dies und das? Verstecken!
Am besten, man würde alles verstecken… so fühlt sich das an.
Ich kann doch den anderen Nutzern das Denken nicht abnehmen und mich vor allem nicht in ihren psychischen Zustand hineinversetzen.
Das Prinzip wie es Hubzilla (und verwandte Dienste… ich schreibe jetzt zur Vereinfachung nur noch von Hubzilla, die verwandten Dienste sind aber „mitgemeint“ 😉 😀 ) macht, ist wesentlich sinnvoller. Hierzu kommt die App „NSFW“ zum Einsatz. Der Nutzer, der sich vor bestimmten Inhalten schützen möchte, „füttert“ NSFW mit entsprechenden Mustern (Wörter, Hashtags, regulären Ausdrücken) und fortan werden Postings mit entsprechenden Inhalten „aufklickbar“ verborgen. Derjenige, der gerade eine Diät macht z.B. gestaltet seinen Filter entsprechend und bleibt künftig von Essens-Fotos, Rezepten, Berichten von Restaurantbesuchen etc. verschont.
Die einzige Voraussetzung ist, dass Postende ihre Inhalte mit sinnvollen und passenden Tags versehen. Das aber ist nun kein Problem, wir aber leider gerade von den Nutzern von CW-Diensten leider zu sehr vernachlässigt… z.T. weil die Software diese Möglichkeit gar nicht explizit vorsieht.
Hubzilla bietet trotzdem eine Art CW… also einen Mechanismus, mit dem man sowas realisieren kann: die Zusammenfassung.
Bei einem Posting kann man eine Zusammenfassung angeben, die eigentlich dafür gedacht ist, den Inhalt längerer Postings zusammenzufassen. In der Timeline wird dann nur die Zusammenfassung angezeigt und man muss darauf klicken, um sich den gesamten Text anzeigen zu lassen. Das macht die Timeline übersichtlicher.
Will man nun z.B. ein Rezept für ein lecker Essen mit einer Art CW versehen, um Fastende nicht zu verschrecken, kann man „Essen, Rezept“ in die Zusammenfassung schreiben. Dann wird dem Besucher nur „Essen, Rezept“ angezeigt… und wenn es für ihn „unschädlich“ ist, klickt er drauf und kann das Rezept sehen.
Nur… das funktioniert nicht bei allen hubzillaartigen Diensten gleich einfach. Es gibt Dienste, die das Zusammenfassungsfeld nicht anzeigen. Hier kann man das aber trotzdem mittels BBcode eingeben und das Ergebnis ist das selbe.
[abstract][/abstract]Was aber nicht funktioniert: Kommentare zu einem solchen Posting werden nicht versteckt. Zusammenfassungen für Kommentare sind schlicht nicht vorgesehen. Kommentiert also jemand mit einem modifizierten Rezept, so schlägt dies unserem Faster ungefiltert ins Gesicht.
Da wäre auch wieder das Prinzip der NSFW-Filter optimal. Er packt einfach die entsprechenden Begriffe in seinen Filter und sieht dann auch solche Kommentare nicht.
Das Fediverse ist vielfältig. Und viele Dienste, die es schon weit vor Mastodon gab, gehen mit bestimmten Dingen anders um. Das sollten insbesondere Mastodon-Nutzer im Hinterkopf behalten, bevor sie einen anderen Nutzer wegen fehlendem CW ausschimpfen oder melden. Es gibt nicht wenig Dienste, die genau diese Form der Inhaltswarnung, wie sie bei Mastodon stattfindet, nicht anbieten, sondern eigene Mechanismen dafür haben.
Ich persönlich finde den „Hubzilla-Weg“ wesentlich besser, weil es jeder selbst in der Hand hat, was er sehen möchte und was nicht. Die umgekehrte Methode, der „Mastodon-Weg“ läuft auf „betreutes Denken“ hinaus und ist ja fast schon sowas wie ein fremder Algorithmus, der in meine Timeline eingreift.
An alle Mastodon-Nutzer, für die das Fediverse neu ist: Das Fediverse ist nicht Mastodon und Mastodon ist nicht das Fediverse. Das Fediverse ist ein riesiges Netzwerk verschiedener Dienste. Einen ersten Eindruck darüber, was noch zum Fediverse gehört findet man z.B. hier: Was sind Fediverse-Projekte?
WAS? Was ist jetzt so schwierig am Registrieren im Fediverse?
Und man liest und hört es noch immer: Sich einen Account im Fediverse zu besorgen, sie ja so kompliziert, so „uneinladend“, so verwirrend… bei den großen Käfigen sei das alles einfacher und viel simpler. Das könne jeder… fürs Fediverse muss man eher ein Nerd sein. ...
View article
View summary
Dieser Artikel wurde am 9. Februar 2024 erstmals veröffentlicht.
Und man liest und hört es noch immer: Sich einen Account im Fediverse zu besorgen, sie ja so kompliziert, so „uneinladend“, so verwirrend… bei den großen Käfigen sei das alles einfacher und viel simpler. Das könne jeder… fürs Fediverse muss man eher ein Nerd sein.
Bei Bluesky hatte ich ja mal reingeschaut (nach wochenlangem Warten auf einen Einladungscode) und das Konto nach wenigen Wochen wieder geschlossen… nicht nur, weil ich den Account weder brauchte, noch haben wollte… sondern auch weil es da an Nutz- und Belanglosigkeit donnerte. Überflüssig.
Nun, da man sich auch ohne Einladung dort registrieren kann, hab ich nur für diesen Artikel noch einmal die Prozedur durchlaufen und als ein(!) Beispiel für das Fediverse, mich bei einer Mastodon-Instanz registriert (der Account ist auch schon wieder gelöscht… ich will keinen Instanzbetreiber mit unnötigen Account-Kadavern belasten).
Die beiden Registrierungsprozesse habe ich dann mal hier gegenübergestellt.
Und ich weiß einfach nicht WAS(?) nun am Registrieren im Fediverse „komplizierter“ oder gar „uneinladender“ sein soll. Das zu behaupten ist die billigste und blödeste Ausrede, nicht ins Fediverse zu wollen, die ich mir vorstellen kann.
Diese „Weisheit“ ist nur deshalb verbreitet, weil diese Mär von den Medien wieder und wieder geschrieben wird… oftmals von Schreiberlingen, die es selbst niemals ausprobiert haben. Aber gut… diese Blödbirnen sprechen ja auch nicht vom Fediverse, sondern immer von Mastodon, als wäre DAS das Fediverse. Dabei ist Mastodon nichts anderes als eine von vielen Softwares, mit denen man am Fediverse teilnehmen kann. So wie Firefox einer von vielen Browsern ist, mit dem man im Internet unterwegs sein kann… und wie z.B. der Golf nur eines von unzähligen Kraftfahrzeugen, mit dem man am Straßenverkehr teilnehmen kann…
Aber das geht in die bornierten Hirne vieler Schreiber einfach nicht rein.
So reiht sich Bullshit an Bullshit, wenn über das Fediverse geschrieben wird…
Nun aber mal zu den Vorgängen! Die unterscheiden sich nur in wenigen Details. So braucht man für Mastodon eine funktionierende Mailadresse, für Bluesky muss man zusätzlich seine Telefonnummer preisgeben (das ist schon etwas, was mich von solchen Diensten abhält… aber das ist nur meine Einstellung).
Bei Mastodon muss man sich (so wie man es auch muss, wenn man sich eine Mailadresse zulegen möchte), für eine Instanz entscheiden. Die simpelste Methode für die gängigsten Fediverse-Dienste ist das Aufrufen der Webseite Fediverse Observer. Dort werden einem sofort ein paar Instanzen vorgeschlagen. Wer sich keine großen Gedanken machen möchte, klickt einfach einen der Links an und landet auf der Startseite der Instanz. Und dort gibt es einen Button, mit dem man sich registrieren kann.
Man muss sich für einen Nutzernamen entscheiden und ein Passwort auswählen. Bei Mastodon muss man außerdem eine funktionierende, gültige Mailadresse eingeben, um den Freischalt-Link zu erhalten. Bei Bluesky wird einem zusätzlich die Telefonnummer abgenötigt, über die man dann einen Freischaltcode bekommt.
Beide Dienste führen einen anschließend auf unterschiedliche Art und Weise noch an die Software heran, man kann vorhandenen Nutzern folgen etc.
Hat man bei Mastodon seinen Account erstellt, erhält man eine E-Mail, in der auch darauf verwiesen wird, man solle sein Profil vervollständigen. Folgt man der Empfehlung, landet man auf der entsprechenden Einstellungs-Seite und kann da z.B. seinen Screen-Name und einen Avatar wählen und weitere sinnvolle Einstellungen vornehmen. Bei Bluesky muss man auf der Webseite den Link zur Profilbearbeitung wählen und kann da Namen, Avatar und Interessen eingeben. Der Rest der Einstellungen erfolgt über eine weitere Einstellungs-Seite.
Jedenfalls ist man dann in beiden Fällen „drin“ und kann loslegen.
Ich sehe da keine signifikanten Unterschiede… und der Prozess bei Bluesky ist nun auch nicht einfacher oder simpler… und „Schönheit“ liegt immer im Auge des Betrachters.
Tja… und bei den meisten anderen Fediverse-Diensten sieht das nicht anders aus. Manche helfen einem beim Start noch ein wenig mehr (z.B. die sogenannten Forkey-Dienste, wie z.B. Misskey selbst, Sharkey, Iceshrimp, Firefish, Catodon…). Insgesamt ist da aber auch nichts kompliziert oder unansehnlich bzw. unverständlich.
Wer das Fediverse noch nicht kennt: Probiert es einfach einmal aus… und lasst Euch überraschen, wie simpel und einladend das Fediverse ist.
Und man liest und hört es noch immer: Sich einen Account im Fediverse zu besorgen, sie ja so kompliziert, so „uneinladend“, so verwirrend… bei den großen Käfigen sei das alles einfacher und viel simpler. Das könne jeder… fürs Fediverse muss man eher ein Nerd sein.
Bei Bluesky hatte ich ja mal reingeschaut (nach wochenlangem Warten auf einen Einladungscode) und das Konto nach wenigen Wochen wieder geschlossen… nicht nur, weil ich den Account weder brauchte, noch haben wollte… sondern auch weil es da an Nutz- und Belanglosigkeit donnerte. Überflüssig.
Nun, da man sich auch ohne Einladung dort registrieren kann, hab ich nur für diesen Artikel noch einmal die Prozedur durchlaufen und als ein(!) Beispiel für das Fediverse, mich bei einer Mastodon-Instanz registriert (der Account ist auch schon wieder gelöscht… ich will keinen Instanzbetreiber mit unnötigen Account-Kadavern belasten).
Die beiden Registrierungsprozesse habe ich dann mal hier gegenübergestellt.
Und ich weiß einfach nicht WAS(?) nun am Registrieren im Fediverse „komplizierter“ oder gar „uneinladender“ sein soll. Das zu behaupten ist die billigste und blödeste Ausrede, nicht ins Fediverse zu wollen, die ich mir vorstellen kann.
Diese „Weisheit“ ist nur deshalb verbreitet, weil diese Mär von den Medien wieder und wieder geschrieben wird… oftmals von Schreiberlingen, die es selbst niemals ausprobiert haben. Aber gut… diese Blödbirnen sprechen ja auch nicht vom Fediverse, sondern immer von Mastodon, als wäre DAS das Fediverse. Dabei ist Mastodon nichts anderes als eine von vielen Softwares, mit denen man am Fediverse teilnehmen kann. So wie Firefox einer von vielen Browsern ist, mit dem man im Internet unterwegs sein kann… und wie z.B. der Golf nur eines von unzähligen Kraftfahrzeugen, mit dem man am Straßenverkehr teilnehmen kann…
Aber das geht in die bornierten Hirne vieler Schreiber einfach nicht rein.
So reiht sich Bullshit an Bullshit, wenn über das Fediverse geschrieben wird…
Nun aber mal zu den Vorgängen! Die unterscheiden sich nur in wenigen Details. So braucht man für Mastodon eine funktionierende Mailadresse, für Bluesky muss man zusätzlich seine Telefonnummer preisgeben (das ist schon etwas, was mich von solchen Diensten abhält… aber das ist nur meine Einstellung).
Bei Mastodon muss man sich (so wie man es auch muss, wenn man sich eine Mailadresse zulegen möchte), für eine Instanz entscheiden. Die simpelste Methode für die gängigsten Fediverse-Dienste ist das Aufrufen der Webseite Fediverse Observer. Dort werden einem sofort ein paar Instanzen vorgeschlagen. Wer sich keine großen Gedanken machen möchte, klickt einfach einen der Links an und landet auf der Startseite der Instanz. Und dort gibt es einen Button, mit dem man sich registrieren kann.
Man muss sich für einen Nutzernamen entscheiden und ein Passwort auswählen. Bei Mastodon muss man außerdem eine funktionierende, gültige Mailadresse eingeben, um den Freischalt-Link zu erhalten. Bei Bluesky wird einem zusätzlich die Telefonnummer abgenötigt, über die man dann einen Freischaltcode bekommt.
Beide Dienste führen einen anschließend auf unterschiedliche Art und Weise noch an die Software heran, man kann vorhandenen Nutzern folgen etc.
Hat man bei Mastodon seinen Account erstellt, erhält man eine E-Mail, in der auch darauf verwiesen wird, man solle sein Profil vervollständigen. Folgt man der Empfehlung, landet man auf der entsprechenden Einstellungs-Seite und kann da z.B. seinen Screen-Name und einen Avatar wählen und weitere sinnvolle Einstellungen vornehmen. Bei Bluesky muss man auf der Webseite den Link zur Profilbearbeitung wählen und kann da Namen, Avatar und Interessen eingeben. Der Rest der Einstellungen erfolgt über eine weitere Einstellungs-Seite.
Jedenfalls ist man dann in beiden Fällen „drin“ und kann loslegen.
Ich sehe da keine signifikanten Unterschiede… und der Prozess bei Bluesky ist nun auch nicht einfacher oder simpler… und „Schönheit“ liegt immer im Auge des Betrachters.
Tja… und bei den meisten anderen Fediverse-Diensten sieht das nicht anders aus. Manche helfen einem beim Start noch ein wenig mehr (z.B. die sogenannten Forkey-Dienste, wie z.B. Misskey selbst, Sharkey, Iceshrimp, Firefish, Catodon…). Insgesamt ist da aber auch nichts kompliziert oder unansehnlich bzw. unverständlich.
Wer das Fediverse noch nicht kennt: Probiert es einfach einmal aus… und lasst Euch überraschen, wie simpel und einladend das Fediverse ist.
Traurig aber (zumindest bei mir) wahr…
Erst im vergangenen September bin ich in intensiveren Kontakt zu `key-Software (Misskey, Misskey-Forks etc.) gekommen… Firefish war es. Aufgrund positiver Berichte habe ich es mit einer eigenen Instanz versucht. Und tatsächlich hat es riesigen Spaß gemacht. Mit Misskey wollte ich nix anfangen, weil es mir zu „exotisch“ erschien… Firefish als Fork hat mir gefallen. Leider ist die Entwicklung komplett zum Erliegen gekommen (inzwischen wurden auch die Server des Projekts vom Netz genommen… das war es wohl endgültig). ...
View article
View summary
Dieser Artikel wurde am 2. Februar 2024 erstmals veröffentlicht.
Erst im vergangenen September bin ich in intensiveren Kontakt zu `key-Software (Misskey, Misskey-Forks etc.) gekommen… Firefish war es. Aufgrund positiver Berichte habe ich es mit einer eigenen Instanz versucht. Und tatsächlich hat es riesigen Spaß gemacht. Mit Misskey wollte ich nix anfangen, weil es mir zu „exotisch“ erschien… Firefish als Fork hat mir gefallen. Leider ist die Entwicklung komplett zum Erliegen gekommen (inzwischen wurden auch die Server des Projekts vom Netz genommen… das war es wohl endgültig).
Also habe ich mir mit YunoHost das „Original“, also Misskey installiert und mit Docker auch eine Sharkey-Instanz aufgesetzt. Sharkey deshalb, weil ich es für die vielversprechendste Alternative zu Firefish hielt. Sharkey ist aber kein Firefish-Fork, sondern ein Misskey-Fork… und auch noch ein Softfork, hängt also eng am Code des Originals, folgt diesem und erweitert ihn an einige Stellen.
Mit beiden Instanzen hatte ich aber so meine Probleme. Sie föderierten nicht umfassend und insbesondere die Nutzersuche funktionierte (funktioniert noch immer) nahezu nicht. Was natürlich das Folgen/Verbinden problematisch macht. Was die Misskey-Instanz betrifft, läuft dann auch noch eine „steinalte“ Version ohne Aussicht auf ein Update, weil ich es als YunoHost App installiert habe und die Betreuung da wohl nicht mehr stattfindet. Bin auch echt nicht sehr ungeduldig… nur eine über ein Jahr alte Version lässt eher nicht darauf hoffen, dass das nochmal in absehbarer Zeit aktualisiert wird.
Sharkey aber basiert auf der jeweils aktuellen Misskey-Version. Also eigentlich nicht schlecht. Nur die… ich nenne es mal Föderations- und Suchprobleme… beim Uralt-Misskey und aktuellem Sharkey ähnelten sich schon sehr. Sachen, die ich von Hubzilla nicht kenne.
Ich hatte mir dann mal auf einer anderen Instanz mit aktueller Misskey-Version einen Probeaccount erstellt… und musste feststellen, dass auch da ähnliche Probleme vorherrschen.
Da Sharkey dicht an Misskey hängt und ich schlicht vieles nicht machen konnte, habe ich den Server weggeputzt und stattdessen noch einen Versuch mit einer Misskey-Instanz via Docker gestartet… also eine top-aktuelle Version.
Und… … … das war ja noch enttäuschender. Die Föderations- und Suchprobleme waren noch viel größer. Ich erhalte keinen wirklichen Anschluss ans Fediverse. Wenn ich Nutzer anhand ihres Handles suche, dann erhalte ich nie Ergebnisse. Nie!
Ich habe dann mühevoll einige meiner liebsten Kontakte zugefügt, indem ich in der Notizsuche nach den Domains der Handles gesucht habe. In den Ergebnislisten habe ich dann so lange gescrollt, bis einer der gewünschten Nutzerkontakte auftauchte. Denen konnte ich dann zumindest über das Handle folgen (Klick aufs „+“). Aber es tauchten nicht alle auf.
Was mich am meisten wundert: Gebe ich Handles von Kontakten, denen ich nun also tatsächlich folge (sind auch in der Liste und Beiträge von ihnen erscheinen in der Timeline), in der Nutzersuche ein, wird wieder nichts gefunden. Gebe ich nur den Nutzernamen ohne die nachfolgende Domain dort ein, dann erscheinen sie verschiedentlich in der Ergebnisliste. Mache ich das mit Nutzern, denen ich noch nicht folge, wird aber auch wieder nix gefunden.
Da stimmt doch was so wirklich nicht! Eine Gegenprobe bei der fremden Misskey-Instanz führt übrigens zu ähnlichen verwirrenden Ergebnissen. Das bringt mich zu dem Schluss, dass irgendwie in Misskey selbst der Wurm drin sein muss.
Firefish als Fork hatte die Probleme offensichtlich überwiegend beseitigt, denn da funktionierte alles. Firefish war ja auch kein brandneues Projekt, sondern existierte schon wesentlich länger unter dem Namen Calckey, bis es dann umbenannt (und zu einem Hardfork) wurde. Kurz nach der Umbenennung entstand dann auch noch ein Calckey/Firefish-Fork namens Iceshrimp.
Weil ich Zeit und Lust hatte… und weil ich weder mit Misskey, noch mit Sharkey letztlich wirklich zufrieden war, habe ich auch noch eine Iceshrimp-Instanz installiert.
So wie ich es jetzt sehe, hat das Team von Iceshrimp wirklich gute Arbeit geleistet und aus Firefish eine sehr ordentlich funktionierende Software gemacht. Es wurden Altlasten entsorgt, Fehler beseitigt und es wird aktualisiert. Vor allem aber treten die erwähnten Föderations- und Such-Probleme mit Iceshrimp nicht auf (wir vormals auch bei Firefish nicht). Es ist aufgeräumt, sehr flott und der würdigste Nachfolger von Firefish. Vor allem funktioniert es so, dass man damit wirklich am Fediverse teilnehmen kann.
Tja… also im Augenblick sieht für mich alles nach Iceshrimp als dritter Dienst neben Hubzilla und url=https://gnulinux.ch/fediverse-serie-streams-das-geordnete-chaos-im-fedivers[/url] aus. Von Misskey werde ich mich wohl früher oder später verabschieden. Wenn es für mich nicht funktioniert, gibt es keinen Grund, länger darauf zu setzen.
Erst im vergangenen September bin ich in intensiveren Kontakt zu `key-Software (Misskey, Misskey-Forks etc.) gekommen… Firefish war es. Aufgrund positiver Berichte habe ich es mit einer eigenen Instanz versucht. Und tatsächlich hat es riesigen Spaß gemacht. Mit Misskey wollte ich nix anfangen, weil es mir zu „exotisch“ erschien… Firefish als Fork hat mir gefallen. Leider ist die Entwicklung komplett zum Erliegen gekommen (inzwischen wurden auch die Server des Projekts vom Netz genommen… das war es wohl endgültig).
Also habe ich mir mit YunoHost das „Original“, also Misskey installiert und mit Docker auch eine Sharkey-Instanz aufgesetzt. Sharkey deshalb, weil ich es für die vielversprechendste Alternative zu Firefish hielt. Sharkey ist aber kein Firefish-Fork, sondern ein Misskey-Fork… und auch noch ein Softfork, hängt also eng am Code des Originals, folgt diesem und erweitert ihn an einige Stellen.
Mit beiden Instanzen hatte ich aber so meine Probleme. Sie föderierten nicht umfassend und insbesondere die Nutzersuche funktionierte (funktioniert noch immer) nahezu nicht. Was natürlich das Folgen/Verbinden problematisch macht. Was die Misskey-Instanz betrifft, läuft dann auch noch eine „steinalte“ Version ohne Aussicht auf ein Update, weil ich es als YunoHost App installiert habe und die Betreuung da wohl nicht mehr stattfindet. Bin auch echt nicht sehr ungeduldig… nur eine über ein Jahr alte Version lässt eher nicht darauf hoffen, dass das nochmal in absehbarer Zeit aktualisiert wird.
Sharkey aber basiert auf der jeweils aktuellen Misskey-Version. Also eigentlich nicht schlecht. Nur die… ich nenne es mal Föderations- und Suchprobleme… beim Uralt-Misskey und aktuellem Sharkey ähnelten sich schon sehr. Sachen, die ich von Hubzilla nicht kenne.
Ich hatte mir dann mal auf einer anderen Instanz mit aktueller Misskey-Version einen Probeaccount erstellt… und musste feststellen, dass auch da ähnliche Probleme vorherrschen.
Da Sharkey dicht an Misskey hängt und ich schlicht vieles nicht machen konnte, habe ich den Server weggeputzt und stattdessen noch einen Versuch mit einer Misskey-Instanz via Docker gestartet… also eine top-aktuelle Version.
Und… … … das war ja noch enttäuschender. Die Föderations- und Suchprobleme waren noch viel größer. Ich erhalte keinen wirklichen Anschluss ans Fediverse. Wenn ich Nutzer anhand ihres Handles suche, dann erhalte ich nie Ergebnisse. Nie!
Ich habe dann mühevoll einige meiner liebsten Kontakte zugefügt, indem ich in der Notizsuche nach den Domains der Handles gesucht habe. In den Ergebnislisten habe ich dann so lange gescrollt, bis einer der gewünschten Nutzerkontakte auftauchte. Denen konnte ich dann zumindest über das Handle folgen (Klick aufs „+“). Aber es tauchten nicht alle auf.
Was mich am meisten wundert: Gebe ich Handles von Kontakten, denen ich nun also tatsächlich folge (sind auch in der Liste und Beiträge von ihnen erscheinen in der Timeline), in der Nutzersuche ein, wird wieder nichts gefunden. Gebe ich nur den Nutzernamen ohne die nachfolgende Domain dort ein, dann erscheinen sie verschiedentlich in der Ergebnisliste. Mache ich das mit Nutzern, denen ich noch nicht folge, wird aber auch wieder nix gefunden.
Da stimmt doch was so wirklich nicht! Eine Gegenprobe bei der fremden Misskey-Instanz führt übrigens zu ähnlichen verwirrenden Ergebnissen. Das bringt mich zu dem Schluss, dass irgendwie in Misskey selbst der Wurm drin sein muss.
Firefish als Fork hatte die Probleme offensichtlich überwiegend beseitigt, denn da funktionierte alles. Firefish war ja auch kein brandneues Projekt, sondern existierte schon wesentlich länger unter dem Namen Calckey, bis es dann umbenannt (und zu einem Hardfork) wurde. Kurz nach der Umbenennung entstand dann auch noch ein Calckey/Firefish-Fork namens Iceshrimp.
Weil ich Zeit und Lust hatte… und weil ich weder mit Misskey, noch mit Sharkey letztlich wirklich zufrieden war, habe ich auch noch eine Iceshrimp-Instanz installiert.
So wie ich es jetzt sehe, hat das Team von Iceshrimp wirklich gute Arbeit geleistet und aus Firefish eine sehr ordentlich funktionierende Software gemacht. Es wurden Altlasten entsorgt, Fehler beseitigt und es wird aktualisiert. Vor allem aber treten die erwähnten Föderations- und Such-Probleme mit Iceshrimp nicht auf (wir vormals auch bei Firefish nicht). Es ist aufgeräumt, sehr flott und der würdigste Nachfolger von Firefish. Vor allem funktioniert es so, dass man damit wirklich am Fediverse teilnehmen kann.
Tja… also im Augenblick sieht für mich alles nach Iceshrimp als dritter Dienst neben Hubzilla und url=https://gnulinux.ch/fediverse-serie-streams-das-geordnete-chaos-im-fedivers[/url] aus. Von Misskey werde ich mich wohl früher oder später verabschieden. Wenn es für mich nicht funktioniert, gibt es keinen Grund, länger darauf zu setzen.
Einfacher Start ins Fediverse mit Hubzilla
Wiiie? Mit Hubzillaaa? Das ist doch viel zu kompliziert! Nö, nichts ist da „kompliziert“. Registrierung und erste Einrichtung sind nicht umständlicher oder unverständlicher als bei den anderen Fediversediensten. Und dann ist man „drin“. Man hat einen Kanal (so heißt das bei Hubzilla) im Fediverse und kann sich mit allen anderen Nutzern im Fediverse austauschen. ...
View article
View summary
Dieser Artikel wurde am 19. Januar 2024 erstmals veröffentlicht.
Wiiie? Mit Hubzillaaa? Das ist doch viel zu kompliziert!
Nö, nichts ist da „kompliziert“. Registrierung und erste Einrichtung sind nicht umständlicher oder unverständlicher als bei den anderen Fediversediensten. Und dann ist man „drin“. Man hat einen Kanal (so heißt das bei Hubzilla) im Fediverse und kann sich mit allen anderen Nutzern im Fediverse austauschen.
Man kann posten… und wenn man unbedingt nur im Telegramm-Stil kommunizieren möchte, dann beschränkt man sich selbst auf 500 Zeichen. Werden es 510 Zeichen… auch nicht schlimm… es gibt keine derart drastische Beschränkung… es sei denn, man erlegt sie sich selbst auf. Freiheit durch Selbstbestimmung. Find ich prima!
Man kann Beiträge anderer (sofern sie es nicht, wenn es ihr Dienst erlaubt, eingeschränkt haben) kommentieren, weitersagen / boosten / renoten / teilen, liken oder disliken und vieles mehr. Dateianhänge und Embeds sind ebenfalls möglich. Man kann Nutzern folgen und andere Nutzer können einem selbst folgen. Ganz normaler Fediverse-Alltag.
Tatsache ist auch, dass Hubzilla eine „eierlegende Wollmilchsau“ unter den Sozialen Netzwerkdiensten im Fediverse ist. Es bietet über den „Standard“ hinaus noch Unmengen anderer Funktionen. Man kann es wie ein CMS nutzen. Es bietet echte Webseiten mit vielfältigen Gestaltungsmöglichkeiten, man kann Wikis erstellen, mittels „Karten“ und einem Kalender im Team zusammenarbeiten, man kann „Blogartikel“ erstellen, verfügt über einen Cloudspeicher und noch viel mehr. Das mag manchen überfordern und nicht alles ist völlig unkompliziert oder leicht verständlich (ein Grund für meine Hubzilla KnowledgeDB)… aber… man MUSS das ja auch NICHT nutzen. Etliche Funktionalitäten muss man ohnehin erst „freischalten“. Im Standard sollte das Funktionsmenü niemanden überfordern. Man kann Hubzilla also auch so, wie Mastodon, Pleroma, Misskey etc. nutzen. Wer aber irgendwann vielleicht mehr will, muss dann nicht Dienst und Account wechseln, sondern Hubzilla einfach erweitert nutzen.
Obendrein bietet Hubzilla eine – gegenüber den anderen Fediverse-Diensten – deutlich höhere Sicherheit gegen „Ausfälle“: die [ul=https://info.hubzilla.hu/de/nomadi.html]nomadische Identität[/url].
Gerade kürzlich stand z.B. die Mastdon-Instanz „troet.cafe“ vor dem Aus (zum Glück konnte sie gerettet werden, weil sie zu den bedeutenden Instanzen in Deutschland gehört). Panik kam auf. Was nun? Wohin soll man umziehen? Wie macht man das? Kann man seine Kontakte oder Inhalte mitnehmen?
Bei Hubzilla kann man (und sollte man) auf solche und ähnlche Ereignisse gut vorbereitet sein. Man erstellt einfach bei einer anderen Instanz (bei Hubzilla „Hub“ genannt) und klont seinen bestehenden Kanal dort einfach. Ab sofort gibt es dann den ursprünglichen Kanal und einen Klon, der sich genau so verhält, wie das „Original“. Inhalte, Kontakte und vieles mehr werden automatisch synchronisiert. Man muss sich nicht darum kümmern.
Gibt es beim „Heimat-Hub“ z.B. mal einen unvorhergesehenen (oder vielleicht auch einen angekündigten und geplanten) Ausfall, so ist man nicht abgeschnitten. Man loggt sich einfach auf dem Hub mit dem Klon ein und kann dort Hubzilla ganz normal weiter nutzen. Und falls ein Hub seine Dienste endgültig einstellt, dann löscht man einfach in den Einstellungen den Kanal auf diesem Hub und macht den Kanal auf einem anderen Hub zum „primären“. Fertig. Erledigt.
Ein einfacher und nur als „normaler Fediversedienst“ genutzter Kanal ist jedenfalls ganz einfach handzuhaben. Auch das Menü erschlägt einen nicht.
Und noch etwas: Selbst einen Hub aufzusetzen ist unglaublich simpel und nach Anleitung wirklich gut zu erledigen. Dabei geht Hubzilla extrem schonend mit den Systemressourcen um. Selbst auf älterer oder minimalistischer Hardware (z.B. Raspberry Pi 3) schnurrt Hubzilla problemlos.
Aber hier richte ich mich an diejenigen, die ins Fediverse einsteigen oder von einem anderen Dienst umsteigen möchten, und liefere eine wirklich simple Anleitung, wie der Einstieg gelingt.
Um Hubs zu finden kann man die üblichen Wege beschreiben: man nutzt entsprechende Datenbanken oder Listen.
Z.B.
FediDB
Fediverse Observer
Hat man sich für einen Hub entschieden, dann ruft man die URL auf und landet auf einer Standard-Seite. Die kann von Hub zu Hub etwas variieren, aber in der Regel findet man am oberen Rand des Bildschirms zwei Menüeinträge: „Anmelden“ und „Registrieren“.
Registrieren möchte man sich ja nun… also auf den Link geklickt und man landet in einem Regsitrierungsformular. Hier gibt es mehrere mögliche Szenarien. Manche Hubs sind so eingestellt, dass man schon bei der Registrierung gleich einen Kanal mit erstellt (man kann – noch so eine Besonderheit von Hubzilla – mit einem Account mehrere Kanäle betreiben). Bei anderen Hubs legt man mit dem Formular zunächst nur einen Account an. Wenn man den erstellt hat und sich erstmalig einloggt, dann wird man auf das Formular zur Kanalerstellung geleitet.
Um einen Account anzulegen, braucht man eine (funktionierende) E-Mail-Adresse und man muss sich ein Passwort ausdenken. Außerdem muss man noch sein Alter bestätigen und kann die eigegebenen Informationen abschicken.
Nun landet man (meist, es soll auch Hubs geben, die diesen Schritt aussparen… halte ich für riskant) bei einer Eingabemaske, bei welcher man einen Verifizierungscode eingeben muss. Den bekommt man nach dem Absenden des Registrierungs-Formulars per E-Mail zugeschickt.
Musste man bei der Registrierung noch keinen Kanal anlegen, so wird man zu diesem Zeitpunkt zur Seite „Erstelle einen Kanal“ weitergeleitet. Hier muss man sich nun einen Namen für die eigene Identität ausdenken. Und zusätzlich eine Kurzbezeichnung („Spitzname“) für den Kanal (ein Vorschlag wird automatisch aus dem Kanalnamen erzeugt). Diese Kurzbezeichnung wird der wesentliche Bestandteil des Fediverse-Handles (also der eigenen „Fediverse-Adresse“).
Nach dem Anlegen das Kanals ist man dann auch endlich „drin“. Als Standard landet man bei Hubzilla im „Headquarter“ („HQ“), einer Übersichtsseite über den eigenen Kanal.
Und es ist, wie immer beim Einstieg im Fediverse, ziemlich leer dort. In der linken Seitenleiste findet man Tabs mit verschiedenen Informationen:
In der Mitte wird der persönliche Stream (Timeline) angezeigt. In der rechten Seitenleiste werden wichtige Informationen (Mitteilung über neue Kontakte, neue Beiträge etc.) angezeigt. Bei einem neu erzeugten Kanal erscheint hier auch eine Auflistung für die ersten Schritte bei Hubzilla und Links, die zu den entsprechenden Funktionen führen.
Benötigt man diese Einsteiger-Hilfe nicht mehr, lässt sie sich unter Einstellungen → Anzeige-Einstellungen → Inhaltseinstellungen per Schalter abschalten.
Zunächst sollte man sein Profil sinnvoll befüllen… wie bei jedem Fediverse-Dienst. Keine schwarze Magie!
Am oberen Bildschirmrand befindet sich die Navigationsleiste. Links ist das Menü zur Kanalauswahl, für das eigene Profil und für die Einstellungen zu sehen. Rechts befinden sich Icons für einige Funktionen und das sogenannte „App-Menü“ (⋮), über welches man zu den installierten Apps gelangt. Als Standard werden dort die wichtigsten Anwendungen bereits zur Verfügung gestellt:
Ich empfehle dringend, noch einige weitere Apps zu installieren und zu aktivieren: ActivityPub, Superblock und Öffentlicher Beitragsstream.
Die App ActivityPub ist essenziell, wenn man am Fediverse teilnehmen möchte. Diese App ist ein MUSS und erfordert lediglich die Installation und Aktivierung. Weitere Einstellungen sind nicht erforderlich (es gibt eh nur zwei Feineinstellungen, die man aber erstmal nicht weiter beachten muss).
Superblock halte ich auch für wichtig, denn damit ist es möglich, Postings von (auch nicht gefolgten) Nutzern aus dem Stream auszuschließen.
Bei vielen (leider, aber auch verständlicher Weise, nicht bei allen) Hubs steht außerdem die App „Öffentlicher Beitragsstream“ zur Verfügung. Diese zeigt die öffentliche Zeitleiste aller Fediverse-Instanzen, die mit dem eigenen Hub föderieren, zur Verfügung. Ein guter Ort sich zu orientieren und neue Kontakte zu finden.
Apps zu installieren und zu aktivieren ist kein Problem. Man wählt im App-Menü den letzten Eintrag „+ Apps“ um zur App-Verwaltung zu gelangen.
Hier kann man sich die installierten Apps (also die voreinestellten Apps) und die generell verfügbaren Apps (alle, auch die nicht installierten) anzeigen lassen.
ActivityPub, Superblock und Öffentlicher Beitragsstream befinden sich noch ausschließlich unter „Verfügbare Apps“. Ein Klick auf „Installieren“ installiert diese und sie landen bei „Installierte Apps“.
Die neu installierten Apps müssen noch „aktiviert“, also auch durch das Menü nutzbar gemacht werden. Man findet in der Box der App ein „Sternchen-Symbol“. Klickt man darauf, färbt sich der Stern gelb und die App ist aktiv und erscheint nun auch im App-Menü.
Es gibt auch noch ein Pin-Nadel-Symbol. Klickt man dies an, so landet die App auch in der Navigationsleiste oben rechts.
Ich empfehle außerdem, bei dieser Gelegenheit die Apps“Kanal“ und „Stream“ an die Navigationsleiste anzupinnen.
Wichtig noch, wie man Kontakte hinzufügt…
Hat man im öffentlichen Stream einen interessanten Nutzer gefunden, kann man einfach auf das Profilbild des Nutzers klicken und im aufklappenden Menü „Verbinden“ auswählen. Man kann aber auch auf das Handle des Nutzer klicken und landet auf einer Seite mit einem Button „Verbinden“.
Kennt man das Handle eines Fediverse-Nutzers, dann kann man auch einfach auf die App „Verbindungen“ klicken. Man landet im Verbindungs-Verzeichnis. Ganz oben befindet sich ein Button „+ Add“. Klickt man auf diesen, öffnet sich ein Eingabefeld, in welches man das Handle eingeben kann (dran denken: ohne führendes „@“). Ein Klick auf das daneben befindliche „+“ und der Kontakt wird hinzugefügt.
Schließlich kann man auch das Verzeichnis aufrufen (am besten „nur dieser Hub“ in der linken Seitenleiste deaktivieren, um das globale Verzeichnis zu nutzen). Hier kann man sich durchwühlen oder auch gezielt nach Namen oder Interessen suchen oder auch nach Tags (Schnellzugriff auch über eine Schlagwörterwolke in der linken Seitenleiste). Das Verbinden erfolgt hier durch Klick auf den Button „Verbinden“.
Hat man Kontakte, die Apps installiert und sein Profil vervollständigt, kann man Hubzilla nun ganz einfach wie jeden anderen Fediversedienst nutzen. Und wer unbedingt will, kann sich selbst freiwillig auch die Beschränkungen von Mastodon bei der Nutzung von Hubzilla auferlegen. 😉 😀
Wiiie? Mit Hubzillaaa? Das ist doch viel zu kompliziert!
Nö, nichts ist da „kompliziert“. Registrierung und erste Einrichtung sind nicht umständlicher oder unverständlicher als bei den anderen Fediversediensten. Und dann ist man „drin“. Man hat einen Kanal (so heißt das bei Hubzilla) im Fediverse und kann sich mit allen anderen Nutzern im Fediverse austauschen.
Man kann posten… und wenn man unbedingt nur im Telegramm-Stil kommunizieren möchte, dann beschränkt man sich selbst auf 500 Zeichen. Werden es 510 Zeichen… auch nicht schlimm… es gibt keine derart drastische Beschränkung… es sei denn, man erlegt sie sich selbst auf. Freiheit durch Selbstbestimmung. Find ich prima!
Man kann Beiträge anderer (sofern sie es nicht, wenn es ihr Dienst erlaubt, eingeschränkt haben) kommentieren, weitersagen / boosten / renoten / teilen, liken oder disliken und vieles mehr. Dateianhänge und Embeds sind ebenfalls möglich. Man kann Nutzern folgen und andere Nutzer können einem selbst folgen. Ganz normaler Fediverse-Alltag.
Tatsache ist auch, dass Hubzilla eine „eierlegende Wollmilchsau“ unter den Sozialen Netzwerkdiensten im Fediverse ist. Es bietet über den „Standard“ hinaus noch Unmengen anderer Funktionen. Man kann es wie ein CMS nutzen. Es bietet echte Webseiten mit vielfältigen Gestaltungsmöglichkeiten, man kann Wikis erstellen, mittels „Karten“ und einem Kalender im Team zusammenarbeiten, man kann „Blogartikel“ erstellen, verfügt über einen Cloudspeicher und noch viel mehr. Das mag manchen überfordern und nicht alles ist völlig unkompliziert oder leicht verständlich (ein Grund für meine Hubzilla KnowledgeDB)… aber… man MUSS das ja auch NICHT nutzen. Etliche Funktionalitäten muss man ohnehin erst „freischalten“. Im Standard sollte das Funktionsmenü niemanden überfordern. Man kann Hubzilla also auch so, wie Mastodon, Pleroma, Misskey etc. nutzen. Wer aber irgendwann vielleicht mehr will, muss dann nicht Dienst und Account wechseln, sondern Hubzilla einfach erweitert nutzen.
Obendrein bietet Hubzilla eine – gegenüber den anderen Fediverse-Diensten – deutlich höhere Sicherheit gegen „Ausfälle“: die [ul=https://info.hubzilla.hu/de/nomadi.html]nomadische Identität[/url].
Gerade kürzlich stand z.B. die Mastdon-Instanz „troet.cafe“ vor dem Aus (zum Glück konnte sie gerettet werden, weil sie zu den bedeutenden Instanzen in Deutschland gehört). Panik kam auf. Was nun? Wohin soll man umziehen? Wie macht man das? Kann man seine Kontakte oder Inhalte mitnehmen?
Bei Hubzilla kann man (und sollte man) auf solche und ähnlche Ereignisse gut vorbereitet sein. Man erstellt einfach bei einer anderen Instanz (bei Hubzilla „Hub“ genannt) und klont seinen bestehenden Kanal dort einfach. Ab sofort gibt es dann den ursprünglichen Kanal und einen Klon, der sich genau so verhält, wie das „Original“. Inhalte, Kontakte und vieles mehr werden automatisch synchronisiert. Man muss sich nicht darum kümmern.
Gibt es beim „Heimat-Hub“ z.B. mal einen unvorhergesehenen (oder vielleicht auch einen angekündigten und geplanten) Ausfall, so ist man nicht abgeschnitten. Man loggt sich einfach auf dem Hub mit dem Klon ein und kann dort Hubzilla ganz normal weiter nutzen. Und falls ein Hub seine Dienste endgültig einstellt, dann löscht man einfach in den Einstellungen den Kanal auf diesem Hub und macht den Kanal auf einem anderen Hub zum „primären“. Fertig. Erledigt.
Ein einfacher und nur als „normaler Fediversedienst“ genutzter Kanal ist jedenfalls ganz einfach handzuhaben. Auch das Menü erschlägt einen nicht.
Und noch etwas: Selbst einen Hub aufzusetzen ist unglaublich simpel und nach Anleitung wirklich gut zu erledigen. Dabei geht Hubzilla extrem schonend mit den Systemressourcen um. Selbst auf älterer oder minimalistischer Hardware (z.B. Raspberry Pi 3) schnurrt Hubzilla problemlos.
Aber hier richte ich mich an diejenigen, die ins Fediverse einsteigen oder von einem anderen Dienst umsteigen möchten, und liefere eine wirklich simple Anleitung, wie der Einstieg gelingt.
Der Einstieg
Wie bei jedem anderen Fediverse-Dienst steht am Anfang die Wahl des Servers (Hub). Das ist im Fediverse so und essenzieller Teil der dortigen Freiheit.Um Hubs zu finden kann man die üblichen Wege beschreiben: man nutzt entsprechende Datenbanken oder Listen.
Z.B.
FediDB
Fediverse Observer
Hat man sich für einen Hub entschieden, dann ruft man die URL auf und landet auf einer Standard-Seite. Die kann von Hub zu Hub etwas variieren, aber in der Regel findet man am oberen Rand des Bildschirms zwei Menüeinträge: „Anmelden“ und „Registrieren“.
Registrieren möchte man sich ja nun… also auf den Link geklickt und man landet in einem Regsitrierungsformular. Hier gibt es mehrere mögliche Szenarien. Manche Hubs sind so eingestellt, dass man schon bei der Registrierung gleich einen Kanal mit erstellt (man kann – noch so eine Besonderheit von Hubzilla – mit einem Account mehrere Kanäle betreiben). Bei anderen Hubs legt man mit dem Formular zunächst nur einen Account an. Wenn man den erstellt hat und sich erstmalig einloggt, dann wird man auf das Formular zur Kanalerstellung geleitet.
Um einen Account anzulegen, braucht man eine (funktionierende) E-Mail-Adresse und man muss sich ein Passwort ausdenken. Außerdem muss man noch sein Alter bestätigen und kann die eigegebenen Informationen abschicken.
Nun landet man (meist, es soll auch Hubs geben, die diesen Schritt aussparen… halte ich für riskant) bei einer Eingabemaske, bei welcher man einen Verifizierungscode eingeben muss. Den bekommt man nach dem Absenden des Registrierungs-Formulars per E-Mail zugeschickt.
Musste man bei der Registrierung noch keinen Kanal anlegen, so wird man zu diesem Zeitpunkt zur Seite „Erstelle einen Kanal“ weitergeleitet. Hier muss man sich nun einen Namen für die eigene Identität ausdenken. Und zusätzlich eine Kurzbezeichnung („Spitzname“) für den Kanal (ein Vorschlag wird automatisch aus dem Kanalnamen erzeugt). Diese Kurzbezeichnung wird der wesentliche Bestandteil des Fediverse-Handles (also der eigenen „Fediverse-Adresse“).
| Hinweis zum Handle bei Hubzilla: |
| Hubzilla macht beim Handle im Vergleich zu anderen Fediverse-Diensten eine Ausnahme. Während beinahe überall vor das Handle ein „@“ gesetzt wird, entfällt dies bei Hubzilla. Das verinnerlicht man aber schnell. Sucht man mit Hubzilla z.B. einen Nutzer, der ein Mastodon-Konto hat, über dessen Handle, dann lässt man das führende „@“ einfach weg. Will man hingegen von einem anderen Fediverse-Dienst aus einem Hubzilla-Nutzer folgen oder diesen suchen, stellt man dem Hubzilla-Handle einfach ein „@“ voran. |
Nach dem Anlegen das Kanals ist man dann auch endlich „drin“. Als Standard landet man bei Hubzilla im „Headquarter“ („HQ“), einer Übersichtsseite über den eigenen Kanal.
Und es ist, wie immer beim Einstieg im Fediverse, ziemlich leer dort. In der linken Seitenleiste findet man Tabs mit verschiedenen Informationen:
- Öffentliche (oder eingeschränkte) Nachrichten:
Das ist eine kompakte ansicht der persönlichen Timeline (bei Hubzilla „Stream“ genannt) - Direktnachrichten:
Postings, die nur unter ausgewählten Teilnehmern ausgetauscht werden. - Favorisierte Postings:
Man kann ein Posting mit einem „Sternchen“ versehen, um sie zu markieren. Solchermaßen markierte Beiträge landen hier. - Benachrichtigungen
In der Mitte wird der persönliche Stream (Timeline) angezeigt. In der rechten Seitenleiste werden wichtige Informationen (Mitteilung über neue Kontakte, neue Beiträge etc.) angezeigt. Bei einem neu erzeugten Kanal erscheint hier auch eine Auflistung für die ersten Schritte bei Hubzilla und Links, die zu den entsprechenden Funktionen führen.
Benötigt man diese Einsteiger-Hilfe nicht mehr, lässt sie sich unter Einstellungen → Anzeige-Einstellungen → Inhaltseinstellungen per Schalter abschalten.
Zunächst sollte man sein Profil sinnvoll befüllen… wie bei jedem Fediverse-Dienst. Keine schwarze Magie!
Am oberen Bildschirmrand befindet sich die Navigationsleiste. Links ist das Menü zur Kanalauswahl, für das eigene Profil und für die Einstellungen zu sehen. Rechts befinden sich Icons für einige Funktionen und das sogenannte „App-Menü“ (⋮), über welches man zu den installierten Apps gelangt. Als Standard werden dort die wichtigsten Anwendungen bereits zur Verfügung gestellt:
- Dateien:
Zugang zur eigenen Cloud - Fotos:
Zugang zum eigenen Fotoalbum - Hilfe
- Kalender
- Kanal:
Die Seite des eigenen Kanals mit den Kanalinformationen. Hier werden im Stream nur die eigenen Beiträge angezeigt. - Stream:
Es wird zur Streamansicht gewechselt. - Verbindungen:
Hier werden die vorhandenen Verbindungen aufgeführt („Follower“ und „Gefolgte“). Außerdem kann man im Verbindungsverzeichnis neue Verbindungen hinzufügen. - Verzeichnis:
Das Benutzerverzeichnis wird angezeigt. Beachte: Man kann das globale Verzeichnis anschauen oder auch nur ein Verzeichnis mit den Nutzern der eigenen Instanz. Auch hier kann man neue Verbindungen herstellen.
Ich empfehle dringend, noch einige weitere Apps zu installieren und zu aktivieren: ActivityPub, Superblock und Öffentlicher Beitragsstream.
Die App ActivityPub ist essenziell, wenn man am Fediverse teilnehmen möchte. Diese App ist ein MUSS und erfordert lediglich die Installation und Aktivierung. Weitere Einstellungen sind nicht erforderlich (es gibt eh nur zwei Feineinstellungen, die man aber erstmal nicht weiter beachten muss).
Superblock halte ich auch für wichtig, denn damit ist es möglich, Postings von (auch nicht gefolgten) Nutzern aus dem Stream auszuschließen.
Bei vielen (leider, aber auch verständlicher Weise, nicht bei allen) Hubs steht außerdem die App „Öffentlicher Beitragsstream“ zur Verfügung. Diese zeigt die öffentliche Zeitleiste aller Fediverse-Instanzen, die mit dem eigenen Hub föderieren, zur Verfügung. Ein guter Ort sich zu orientieren und neue Kontakte zu finden.
Apps zu installieren und zu aktivieren ist kein Problem. Man wählt im App-Menü den letzten Eintrag „+ Apps“ um zur App-Verwaltung zu gelangen.
Hier kann man sich die installierten Apps (also die voreinestellten Apps) und die generell verfügbaren Apps (alle, auch die nicht installierten) anzeigen lassen.
ActivityPub, Superblock und Öffentlicher Beitragsstream befinden sich noch ausschließlich unter „Verfügbare Apps“. Ein Klick auf „Installieren“ installiert diese und sie landen bei „Installierte Apps“.
Die neu installierten Apps müssen noch „aktiviert“, also auch durch das Menü nutzbar gemacht werden. Man findet in der Box der App ein „Sternchen-Symbol“. Klickt man darauf, färbt sich der Stern gelb und die App ist aktiv und erscheint nun auch im App-Menü.
Es gibt auch noch ein Pin-Nadel-Symbol. Klickt man dies an, so landet die App auch in der Navigationsleiste oben rechts.
Ich empfehle außerdem, bei dieser Gelegenheit die Apps“Kanal“ und „Stream“ an die Navigationsleiste anzupinnen.
Hat man im öffentlichen Stream einen interessanten Nutzer gefunden, kann man einfach auf das Profilbild des Nutzers klicken und im aufklappenden Menü „Verbinden“ auswählen. Man kann aber auch auf das Handle des Nutzer klicken und landet auf einer Seite mit einem Button „Verbinden“.
Kennt man das Handle eines Fediverse-Nutzers, dann kann man auch einfach auf die App „Verbindungen“ klicken. Man landet im Verbindungs-Verzeichnis. Ganz oben befindet sich ein Button „+ Add“. Klickt man auf diesen, öffnet sich ein Eingabefeld, in welches man das Handle eingeben kann (dran denken: ohne führendes „@“). Ein Klick auf das daneben befindliche „+“ und der Kontakt wird hinzugefügt.
Schließlich kann man auch das Verzeichnis aufrufen (am besten „nur dieser Hub“ in der linken Seitenleiste deaktivieren, um das globale Verzeichnis zu nutzen). Hier kann man sich durchwühlen oder auch gezielt nach Namen oder Interessen suchen oder auch nach Tags (Schnellzugriff auch über eine Schlagwörterwolke in der linken Seitenleiste). Das Verbinden erfolgt hier durch Klick auf den Button „Verbinden“.
Hat man Kontakte, die Apps installiert und sein Profil vervollständigt, kann man Hubzilla nun ganz einfach wie jeden anderen Fediversedienst nutzen. Und wer unbedingt will, kann sich selbst freiwillig auch die Beschränkungen von Mastodon bei der Nutzung von Hubzilla auferlegen. 😉 😀
Sharkey: Bis jetzt ausgesprochen positiv überrascht…
Mich jammert’s immer noch wegen Firefish. Das gebe ich gerne zu. Hat mir wirklich gut gefallen. Das war auch der Grund, weshalb ich mich so „wild“ draufgestürzt habe. ...
View article
View summary
Dieser Artikel wurde am 6. Januar 2024 erstmals veröffentlicht.
Mich jammert’s immer noch wegen Firefish. Das gebe ich gerne zu. Hat mir wirklich gut gefallen. Das war auch der Grund, weshalb ich mich so „wild“ draufgestürzt habe.
Ob es nun ein für alle mal „begraben“ wird, weiß ich nicht. Mag sein, dass es damit vielleicht irgendwann doch irgendwie weiter geht.
Angefressen war ich vor allem auch, weil ich wirklich viel Zeit und Arbeit in das Wiki zu Firefish gesteckt habe. Na ja… völlig vergeblich war es ja trotzdem nicht. Einmal hat es doch einigen Neueinsteigern bei Firefish helfen können… und ich habe einiges an Erfahrungen generell mit Fediverse-Software rund um Misskey sammeln können (Firefish ist ja ein Misskey-Fork).
Ich werde das Wiki also nun doch dauerhaft bestehen lassen. Und ich werde meine Firefish-Instanz auch erst einmal installiert lassen und ggf. updaten, falls da noch was kommt (und wenn nicht, ist es auch nicht schlimm).
Durch die unerwarteten Probleme mit Firefish war ich natürlich besonders skeptisch, was neue und ähnliche Forks betrifft. Deshalb dachte ich, ich probiere mal das „Original“ und habe eine Misskey-Instanz ins Netz gebracht. So wahnsinnig groß waren die Unterschiede jetzt nicht. Einiges an Funktionalität fehlt da zwar und auch die Bedienung ist in einigen Punkten etwas umständlicher, aber nix, womit man nicht leben könnte. Allerdings läuft bei mir eine ein(!) Jahr alte Version und einige der Problemchen, die ich habe, gehen mit Sicherheit genau darauf zurück.
Dass ich eine so alte Version nutze, liegt daran, dass ich Misskey als YunoHost-App installiert habe. Ich habe nicht so genau hingeschaut und auch nicht damit gerechnet, dass das wirklich eine Version installiert wird, die zwölf Monde alt ist. Bei mir läuft also Version 12.119.2. Inzwischen ist die Versionsnummerierung bei Misskey schon umgestellt und aktuell ist jetzt 2023.12.2. Zwischen meiner Version und der aktuellen liegen186(!) Versionen (wenn man Betaversionen mitrechnet). Das ist schon ein ordentlicher Stiefel. Au weia!
Leider kann man Apps, die mit YunoHost installiert hat, nicht einfach so per Hand aktualisieren. Und irgendwie scheinen die Betreuer da in letzter Zeit nix mehr zu machen. Nach einem Jahr erwarte ich nicht wirklich bald eine neue Version.
Grundsätzlich ist Misskey (auch in der alten Version) ordentlich und gut nutzbar. Trotzdem… bescheiden, dass ich auf der Version festhänge.
Nun ist kürzlich Catodon veröffentlich worden. Es ist ein Firefish-Fork, also ein Fork eines Misskey-Forks. Ins Leben gerufen wurde es von zwei ehemaligen Mitgliedern der Kernteams von Firefish. Ob ich das jetzt vertrauenserweckend finde, steht mal auf einem anderen Blatt… aber es war schnell eine Version da und dann wurde gleich mal „aufgeräumt“. Es wurden sehr viele Funktionen umbenannt (warum auch immer) und auch einiges gestrichen. Mein Probeaccount bei einer Catodon-Instanz macht mir jedenfalls nicht wirklich Spaß. Erstens wegen der anders lautenden Bezeichnungen (und der ebenfalls geänderten Icons) und wegen der Einschränkungen gegenüber Firefish.
Mag sein, dass sich das noch gut entwickelt, aber im Augenblick wäre es keine Alternative für mich.
Dann gibt es (schon länger) Iceshrimp, einen weiteren Firefish-Fork. Hab ich mir noch nicht wirklich angeschaut. Ist auch nicht so verbreitet.
Und schließlich gibt es derzeit noch Sharkey. Sharkey ist ein Soft-Fork von Misskey und damit näher am Original als die Firefish-Forks.
Mir fiel auf, dass Sharkey im Fediverse irgendwie präsenter erscheint, als die anderen Dienste. Hinzu kam dass ich in Kontakt zu Nutzern rund um das Projekt kam. Zwar aus einem eher „unerfreulichen“ Anlass…
Ich hatte ja die Fediverse-Gruppe (chirp) FirefishTalk erzeugt und da wurde auch ganz gut kommuniziert. Also ich nun meine Firefish-Aktivitäten auf Eis gelegt habe, dachte ich darüber nach, was aus der Gruppe werden soll, für die ich ja als Moderator verantwortlich bin. Ich dachte, sie könne ja zur Kommunikation nicht nur über Firefish, sondern auch über Misskey und die genannten Forks dienen. Deshalb habe ich die Gruppenbeschreibung entsprechend geändert. Das wurde dann von Sharkey-Nutzern kritisiert, weil natürlich der Titel „FirefishTalk“ wirklich nicht signalisiert, dass es nicht nur um diesen Dienst geht. Den Titel habe ich dann auch geändert. Das hätte vielleicht genügen können, aber hat es natürlich nicht. Das Handle war ja nicht änderbar und blieb bei @FirefishTalk@chirp.social.
Na… ich habe die Gruppe letztlich dann geschlossen und eine Gruppe MisskeyTalk erzeugt, die aber ebenfalls für Nutzer und Admins der anderen Forks gedacht ist.
So bin ich halt in Kontakt mit einigen Nutzern von Sharkey gekommen (auch welche aus dem Sharkey-Team). Ich war neugierig und habe mir dann erstmal einen Account bei shonk.social angelegt, um mich zu orientieren. Und ich muss sagen, es hat mich ziemlich schnell gepackt. Fühlte sich sofort prima an und ist gefühlt ein sehr schönes „Zwischending“ zwischen Misskey und dem guten alten Firefish R.I.P. 😉
Hätte ich gerne ausprobiert… aber da war ich wieder bei YunoHost und den Apps. Sharkey ist nicht in der App-Liste. Und auch nicht auf der Wunschliste für neue Apps.
Allerdings lässt sich Sharkey auch als Docker-Container installieren… und ich hatte gelesen, dass man mit Docker unter YunoHost durchaus Anwendungen nutzen kann, die nicht als Apps angeboten werden.
Grundsätzlich ja auch keine schwarze Magie! YH läuft (derzeit noch) unter Debian 11. Docker und Docker-Compose zu installieren ist also nicht nur möglich, sonder wirklich einfach. Das habe ich dann auch gleich mal erledigt. Nun war es nur noch erforderlich, den nginx-Server, der von YunoHost verwaltet wird, als Reverse Proxy für die gewünschte Docker-Software zu konfigurieren.
Auch dafür gibt es eine sehr einfach Lösung, nämlich die App „Redirect“. Die Konfiguration ist selbsterklärend und ganz einfach.
Also hab ich mir eine Subdomain angelegt, ein Zertifikat erzeugt und Sharkey nach der offiziellen Installationsanleitung mit Docker installiert. Dann die Redirect-App installiert und auf Sharkey „umgebogen“. Zack… da lief sie auch schon, meine Sharkey-Instanz Cápa (inzwischen eingestellt)!
Es tauchte dann aber recht schnell ein Problem auf. Ich konnte keine Dateien hochladen. Der Vorgang brach mit einer eher kryptischen Fehlermeldung ab, aus der ich nicht ersehe konnte, wo der Kern des Problems denn nun liegt. Kein Dateiupload bedeutet allein schon, dass man kein Profilbild, keinen Banner etc. festlegen kann. Ich habe dann geschaut und recherchiert, bin aber auf keine Lösung gekommen.
Deshalb habe ich „ins Fediverse gerufen“ und die Sharkey-Experten um Hinweise gebeten, mir auf die Sprünge zu helfen (auch in der MisskeyTalk-Gruppe). Und da meldete sich Not Cute (@Amelia) mit einem einfachen Tipp.
Es liegt vermutlich an den Berechtigungen für das files-Verzeichnis. Ich solle doch einfach einmal
ausführen. Ging erstmal nicht, weil mir die Berechtigung fehlte und exec direkt im Sharkey-Container arbeitet. Also statt /sharkey/files nur files und das Ganze mit Root-Rechten:
Und schon war das Problem gelöst. Und zwar innerhalb kürzester Zeit.
Dann war mir aber auch aufgefallen, dass meine Sharkey-Instanz kaum föderierte… und überdies kaum Nutzer über die Suchfunktion zu finden waren. Also hab ich an gleicher Stelle nochmal nachgefragt.
Und dabei stellte sich heraus, dass ich trotz frischer Installation eine „alte“ Version von Sharkey nutzte.
Mein Fehler. Ich habe mich zwar recht streng an die Installationsanleitung gehalten, habe aber stur nur die dort genannte Änderung im Docker-Compose-File gemacht, aber nicht gelesen, was eine Zeile drüber im Kommentar stand. So habe ich ein altes Image gezogen. Inzwischen läuft die Entwicklung nämlich in einem neuen Repo unter git.joinsharkey.org, wo natürlich die neueste Version liegt.
Nach den Infos zum Sharkey Release 2023.12.0 habe ich dann die docker-compose.yml und die default.yml entsprechend geändert (und dabei einen Fehler eingebaut… dazu gleich noch) und das Update durchgeführt.
Lief auch durch… nur der Sharkey-Container startete nicht korrekt. Er hing in einer Restart-Schleife fest. Ich habe dann eine ganze Weile experimentiert und versucht, den Fehler einzugrenzen. Aber es wollte mir nicht gelingen. Dann wurde ich von Amelia gebeten, doch in den Support-Kanal bei Discord zu wechseln. Dort bat sie mich um das Docker-Logfile zu Sharkey, das ich ihr per Pastebin zukommen ließ. Und nach kürzester Zeit war das Problem behoben. Ich hatte, wie in der erwähnten Update-Anleitung angegeben, den Parameter
an die default.yml angehängt. Allerdings gab es diesen Parameter in der Datei ohnehin schon… so mittendrin, dass mir nicht aufgefallen, war, dass es doppelt drin war. Und das hat den Containerstart verhindert.
Und nun läuft die aktuelle Version… und auch das Finden von Kontakten läuft wie gewohnt. Und meine Instanz föderiert.
Jetzt geht es an die Test-Phase. Vernünftig eingerichtet ist die Instanz. Ich bin gespannt, wie sich Sharkey nun in den nächsten Monaten entwickelt.
Ich muss aber sagen, dass ich sehr positiv überrascht bin (war ja, wie gesagt, nach dem Firefish-Desaster eher skeptisch). Sharkey fühlt sich gut an, läuft sauber und ist funktional echt klasse.
Was ich aber besonders herausstellen möchte: Der Support ist sehr, sehr gut! Mir wurde nett, zuvorkommend und kompetent geholfen, wenn ich mit eigenen Versuchen und Recherchen nicht weiter kam. Und das auch noch rasant! In der Hinsicht ist das Sharkey-Team ein absolutes Vorbild… so sollte es bei viel mehr Projekten laufen.
Deshalb an dieser Stelle nochmal der ausgesprochene Dank an Amelia.
Ich weiß nicht, ob ich überhaupt selbst auf den Fehler gekommen wäre. Logfiles von Software, in der man nicht „drinsteckt“ sind schwer zu analysieren… weil man ja nicht weiß, was wie denn eigentlich korrekt laufen sollte.
Ich möchte jetzt „so früh“ noch keine Empfehlung aussprechen… aber wenn ich eine aussprechen müsste, dann würde ich zu Sharkey raten, wenn jemand von Firefish umsteigen möchte… oder zu Misskey, dann allerdings zu einer Instanz mit aktueller Software. 😉 😀
Apropos aktuelle Software… ich werde, wenn ich mal etwas mehr Zeit übrig habe, sehen, dass ich meine veraltete Misskey-Instanz auf eine Docker-Installation umstelle, damit ich auch damit auf dem neuesten Stand bleiben kann.
Mich jammert’s immer noch wegen Firefish. Das gebe ich gerne zu. Hat mir wirklich gut gefallen. Das war auch der Grund, weshalb ich mich so „wild“ draufgestürzt habe.
Ob es nun ein für alle mal „begraben“ wird, weiß ich nicht. Mag sein, dass es damit vielleicht irgendwann doch irgendwie weiter geht.
Angefressen war ich vor allem auch, weil ich wirklich viel Zeit und Arbeit in das Wiki zu Firefish gesteckt habe. Na ja… völlig vergeblich war es ja trotzdem nicht. Einmal hat es doch einigen Neueinsteigern bei Firefish helfen können… und ich habe einiges an Erfahrungen generell mit Fediverse-Software rund um Misskey sammeln können (Firefish ist ja ein Misskey-Fork).
Ich werde das Wiki also nun doch dauerhaft bestehen lassen. Und ich werde meine Firefish-Instanz auch erst einmal installiert lassen und ggf. updaten, falls da noch was kommt (und wenn nicht, ist es auch nicht schlimm).
Durch die unerwarteten Probleme mit Firefish war ich natürlich besonders skeptisch, was neue und ähnliche Forks betrifft. Deshalb dachte ich, ich probiere mal das „Original“ und habe eine Misskey-Instanz ins Netz gebracht. So wahnsinnig groß waren die Unterschiede jetzt nicht. Einiges an Funktionalität fehlt da zwar und auch die Bedienung ist in einigen Punkten etwas umständlicher, aber nix, womit man nicht leben könnte. Allerdings läuft bei mir eine ein(!) Jahr alte Version und einige der Problemchen, die ich habe, gehen mit Sicherheit genau darauf zurück.
Dass ich eine so alte Version nutze, liegt daran, dass ich Misskey als YunoHost-App installiert habe. Ich habe nicht so genau hingeschaut und auch nicht damit gerechnet, dass das wirklich eine Version installiert wird, die zwölf Monde alt ist. Bei mir läuft also Version 12.119.2. Inzwischen ist die Versionsnummerierung bei Misskey schon umgestellt und aktuell ist jetzt 2023.12.2. Zwischen meiner Version und der aktuellen liegen186(!) Versionen (wenn man Betaversionen mitrechnet). Das ist schon ein ordentlicher Stiefel. Au weia!
Leider kann man Apps, die mit YunoHost installiert hat, nicht einfach so per Hand aktualisieren. Und irgendwie scheinen die Betreuer da in letzter Zeit nix mehr zu machen. Nach einem Jahr erwarte ich nicht wirklich bald eine neue Version.
Grundsätzlich ist Misskey (auch in der alten Version) ordentlich und gut nutzbar. Trotzdem… bescheiden, dass ich auf der Version festhänge.
Nun ist kürzlich Catodon veröffentlich worden. Es ist ein Firefish-Fork, also ein Fork eines Misskey-Forks. Ins Leben gerufen wurde es von zwei ehemaligen Mitgliedern der Kernteams von Firefish. Ob ich das jetzt vertrauenserweckend finde, steht mal auf einem anderen Blatt… aber es war schnell eine Version da und dann wurde gleich mal „aufgeräumt“. Es wurden sehr viele Funktionen umbenannt (warum auch immer) und auch einiges gestrichen. Mein Probeaccount bei einer Catodon-Instanz macht mir jedenfalls nicht wirklich Spaß. Erstens wegen der anders lautenden Bezeichnungen (und der ebenfalls geänderten Icons) und wegen der Einschränkungen gegenüber Firefish.
Mag sein, dass sich das noch gut entwickelt, aber im Augenblick wäre es keine Alternative für mich.
Dann gibt es (schon länger) Iceshrimp, einen weiteren Firefish-Fork. Hab ich mir noch nicht wirklich angeschaut. Ist auch nicht so verbreitet.
Und schließlich gibt es derzeit noch Sharkey. Sharkey ist ein Soft-Fork von Misskey und damit näher am Original als die Firefish-Forks.
Mir fiel auf, dass Sharkey im Fediverse irgendwie präsenter erscheint, als die anderen Dienste. Hinzu kam dass ich in Kontakt zu Nutzern rund um das Projekt kam. Zwar aus einem eher „unerfreulichen“ Anlass…
Ich hatte ja die Fediverse-Gruppe (chirp) FirefishTalk erzeugt und da wurde auch ganz gut kommuniziert. Also ich nun meine Firefish-Aktivitäten auf Eis gelegt habe, dachte ich darüber nach, was aus der Gruppe werden soll, für die ich ja als Moderator verantwortlich bin. Ich dachte, sie könne ja zur Kommunikation nicht nur über Firefish, sondern auch über Misskey und die genannten Forks dienen. Deshalb habe ich die Gruppenbeschreibung entsprechend geändert. Das wurde dann von Sharkey-Nutzern kritisiert, weil natürlich der Titel „FirefishTalk“ wirklich nicht signalisiert, dass es nicht nur um diesen Dienst geht. Den Titel habe ich dann auch geändert. Das hätte vielleicht genügen können, aber hat es natürlich nicht. Das Handle war ja nicht änderbar und blieb bei @FirefishTalk@chirp.social.
Na… ich habe die Gruppe letztlich dann geschlossen und eine Gruppe MisskeyTalk erzeugt, die aber ebenfalls für Nutzer und Admins der anderen Forks gedacht ist.
So bin ich halt in Kontakt mit einigen Nutzern von Sharkey gekommen (auch welche aus dem Sharkey-Team). Ich war neugierig und habe mir dann erstmal einen Account bei shonk.social angelegt, um mich zu orientieren. Und ich muss sagen, es hat mich ziemlich schnell gepackt. Fühlte sich sofort prima an und ist gefühlt ein sehr schönes „Zwischending“ zwischen Misskey und dem guten alten Firefish R.I.P. 😉
Hätte ich gerne ausprobiert… aber da war ich wieder bei YunoHost und den Apps. Sharkey ist nicht in der App-Liste. Und auch nicht auf der Wunschliste für neue Apps.
Allerdings lässt sich Sharkey auch als Docker-Container installieren… und ich hatte gelesen, dass man mit Docker unter YunoHost durchaus Anwendungen nutzen kann, die nicht als Apps angeboten werden.
Grundsätzlich ja auch keine schwarze Magie! YH läuft (derzeit noch) unter Debian 11. Docker und Docker-Compose zu installieren ist also nicht nur möglich, sonder wirklich einfach. Das habe ich dann auch gleich mal erledigt. Nun war es nur noch erforderlich, den nginx-Server, der von YunoHost verwaltet wird, als Reverse Proxy für die gewünschte Docker-Software zu konfigurieren.
Auch dafür gibt es eine sehr einfach Lösung, nämlich die App „Redirect“. Die Konfiguration ist selbsterklärend und ganz einfach.
Also hab ich mir eine Subdomain angelegt, ein Zertifikat erzeugt und Sharkey nach der offiziellen Installationsanleitung mit Docker installiert. Dann die Redirect-App installiert und auf Sharkey „umgebogen“. Zack… da lief sie auch schon, meine Sharkey-Instanz Cápa (inzwischen eingestellt)!
Es tauchte dann aber recht schnell ein Problem auf. Ich konnte keine Dateien hochladen. Der Vorgang brach mit einer eher kryptischen Fehlermeldung ab, aus der ich nicht ersehe konnte, wo der Kern des Problems denn nun liegt. Kein Dateiupload bedeutet allein schon, dass man kein Profilbild, keinen Banner etc. festlegen kann. Ich habe dann geschaut und recherchiert, bin aber auf keine Lösung gekommen.
Deshalb habe ich „ins Fediverse gerufen“ und die Sharkey-Experten um Hinweise gebeten, mir auf die Sprünge zu helfen (auch in der MisskeyTalk-Gruppe). Und da meldete sich Not Cute (@Amelia) mit einem einfachen Tipp.
Es liegt vermutlich an den Berechtigungen für das files-Verzeichnis. Ich solle doch einfach einmal
docker exec -it sharkeycontianernyame chown -R sharkey:sharkey /sharkey/filesausführen. Ging erstmal nicht, weil mir die Berechtigung fehlte und exec direkt im Sharkey-Container arbeitet. Also statt /sharkey/files nur files und das Ganze mit Root-Rechten:
docker exec -it -u root sharkeycontianernyame chown -R sharkey:sharkey filesUnd schon war das Problem gelöst. Und zwar innerhalb kürzester Zeit.
Dann war mir aber auch aufgefallen, dass meine Sharkey-Instanz kaum föderierte… und überdies kaum Nutzer über die Suchfunktion zu finden waren. Also hab ich an gleicher Stelle nochmal nachgefragt.
Und dabei stellte sich heraus, dass ich trotz frischer Installation eine „alte“ Version von Sharkey nutzte.
Mein Fehler. Ich habe mich zwar recht streng an die Installationsanleitung gehalten, habe aber stur nur die dort genannte Änderung im Docker-Compose-File gemacht, aber nicht gelesen, was eine Zeile drüber im Kommentar stand. So habe ich ein altes Image gezogen. Inzwischen läuft die Entwicklung nämlich in einem neuen Repo unter git.joinsharkey.org, wo natürlich die neueste Version liegt.
Nach den Infos zum Sharkey Release 2023.12.0 habe ich dann die docker-compose.yml und die default.yml entsprechend geändert (und dabei einen Fehler eingebaut… dazu gleich noch) und das Update durchgeführt.
Lief auch durch… nur der Sharkey-Container startete nicht korrekt. Er hing in einer Restart-Schleife fest. Ich habe dann eine ganze Weile experimentiert und versucht, den Fehler einzugrenzen. Aber es wollte mir nicht gelingen. Dann wurde ich von Amelia gebeten, doch in den Support-Kanal bei Discord zu wechseln. Dort bat sie mich um das Docker-Logfile zu Sharkey, das ich ihr per Pastebin zukommen ließ. Und nach kürzester Zeit war das Problem behoben. Ich hatte, wie in der erwähnten Update-Anleitung angegeben, den Parameter
maxNoteLength: 6000an die default.yml angehängt. Allerdings gab es diesen Parameter in der Datei ohnehin schon… so mittendrin, dass mir nicht aufgefallen, war, dass es doppelt drin war. Und das hat den Containerstart verhindert.
Und nun läuft die aktuelle Version… und auch das Finden von Kontakten läuft wie gewohnt. Und meine Instanz föderiert.
Jetzt geht es an die Test-Phase. Vernünftig eingerichtet ist die Instanz. Ich bin gespannt, wie sich Sharkey nun in den nächsten Monaten entwickelt.
Ich muss aber sagen, dass ich sehr positiv überrascht bin (war ja, wie gesagt, nach dem Firefish-Desaster eher skeptisch). Sharkey fühlt sich gut an, läuft sauber und ist funktional echt klasse.
Was ich aber besonders herausstellen möchte: Der Support ist sehr, sehr gut! Mir wurde nett, zuvorkommend und kompetent geholfen, wenn ich mit eigenen Versuchen und Recherchen nicht weiter kam. Und das auch noch rasant! In der Hinsicht ist das Sharkey-Team ein absolutes Vorbild… so sollte es bei viel mehr Projekten laufen.
Deshalb an dieser Stelle nochmal der ausgesprochene Dank an Amelia.
Ich weiß nicht, ob ich überhaupt selbst auf den Fehler gekommen wäre. Logfiles von Software, in der man nicht „drinsteckt“ sind schwer zu analysieren… weil man ja nicht weiß, was wie denn eigentlich korrekt laufen sollte.
Ich möchte jetzt „so früh“ noch keine Empfehlung aussprechen… aber wenn ich eine aussprechen müsste, dann würde ich zu Sharkey raten, wenn jemand von Firefish umsteigen möchte… oder zu Misskey, dann allerdings zu einer Instanz mit aktueller Software. 😉 😀
Apropos aktuelle Software… ich werde, wenn ich mal etwas mehr Zeit übrig habe, sehen, dass ich meine veraltete Misskey-Instanz auf eine Docker-Installation umstelle, damit ich auch damit auf dem neuesten Stand bleiben kann.
Toter Fisch
Seit einiger Zeit geisterte das Gerücht durchs Fediverse, dass die Entwicklung der Fediverse-Software Firefish zum Erliegen gekommen sei. Das beunruhigte mich schon ein wenig, weil ich mich 1. in Firefish verliebt hatte, 2. eine Firefish-Instanz installiert hatte… nicht nur kurz zum Testen, sondern als längerfristigen Server im Fediverse und ich 3. auch ordentlich „Werbung“ für Firefish betrieben habe und sehr viele Stunden in die Firefish KnowledgeDB (ein Wiki) gesteckt habe. ...
View article
View summary
Dieser Artikel wurde erstmals am 31. Dezember 2023 veröffentlicht.
Seit einiger Zeit geisterte das Gerücht durchs Fediverse, dass die Entwicklung der Fediverse-Software Firefish zum Erliegen gekommen sei. Das beunruhigte mich schon ein wenig, weil ich mich 1. in Firefish verliebt hatte, 2. eine Firefish-Instanz installiert hatte… nicht nur kurz zum Testen, sondern als längerfristigen Server im Fediverse und ich 3. auch ordentlich „Werbung“ für Firefish betrieben habe und sehr viele Stunden in die Firefish KnowledgeDB (ein Wiki) gesteckt habe.
Es wurde dann vor einiger Zeit noch eine neue Version (die aktuelle stabile Version war und ist 1.0.3) veröffentlicht, auf die ich dann auch umgestellt habe: 1.0.5-rc. Das „rc“ steht für „Release Candidate“. Das sind Versionen einer Software, die eine Betatest-Phase hinter sich gebracht haben und der endgültigen Version entsprechen sollten. Es ist sowas wie ein letzter „Betatest“, bei dem nur noch die letzten Fehlerkorrekturen erfolgen, bevor dann die finale Version veröffentlicht wird.
Das vermittelte mir den Eindruck, dass da doch noch etwas geht.
Im Fediverse wurde immer wieder darauf hingewiesen, dass im Software-Repository nicht mehr viel passiert… das sei ein Zeichen dafür, dass das Projekt tot sei. Auch diese „Meldungen“ (ich hatte das ja auch selbst beobachtet) waren für mich durch die RC-Phase erklärbar. Während der letzten Phase der Softwareentwicklung, in der ein RC im Echtbetrieb getestet wird, passiert an der Software nicht mehr viel. Hier und da noch ein paar Feinschliffe, die eine oder andere Übersetzung… aber nichts grundlegendes oder beachtliches.
Bei größeren Projekten mag das anders sein, weil da dann schon von einigen des großen Entwicklerteams an der nächsten Version gebastelt wird, aber Firefish hatte ja ein kleines Team. Da stürzt man sich nicht schon vorher auf die Entwicklung der nächsten Version, wenn die aktuelle noch nicht veröffentlicht ist.
Das waren alles aber nur (begründete) Vermutungen meinerseits. Leider war es bei Firefish schon lange (mindestens seit ich es nutze) die Kommunikation nach Außen schlecht. Aber auch das ist ein Phänomen, das man von Open Source Projekten kennt.
Auffallend war aber die nachlassende Zahl derer, die noch irgendwie im Repo aktiv waren.
Dann erschienen in letzter Zeit auch noch vermehrt andere Forks von Misskey, die in die gleiche Richtung gingen, wie Firefish und sogar ein Firefish-Fork.
Die Stimmen, dass Firefish wohl tot sei, wurden mehr und lauter.
Schließlich gab es die Ankündigung eines weiteren Forks mit dem Namen „Catodon“… und dabei war die Besonderheit, dass sie von einem Kern-Mitglied des Firefish-Teams kam, von Panos.
Gestern nun platzte die Bombe.
Panos teilte mit, dass Firefish als Projekt faktisch tot ist. Das Hauptproblem lag wohl darin, dass Firefish, trotz gar nicht so kleinem Kernteams trotzdem ein One-Man-Show war. Der „Besitzer“ Kainoa hat das Projekt offensichtlich aufgegeben, ist kaum noch aktiv und auch quasi nicht erreichbar. Dem Rest des Kernteams sind aber, was Entscheidungen anbelangt, die Hände gebunden. Der Kapitän ist von Bord und die Mannschaft huckt gefesselt am Mastbaum.
Original-Post von Panos
Ich finde das ausgesprochen schade und bin traurig. Ich kann und will aber nun auch keine Fediverse-Instanz betreiben, die nicht mehr weiterentwickelt und auch nicht einmal mehr gepflegt wird. Ungepflegte Software ist ein Sicherheitsrisiko und auch keine zukunftsfähige Sache. Ich möchte sowas aber weder mir, noch den wenigen Nutzern meiner Instanz zumuten. Als Instanzbetreiber trage ich auch eine gewisse Verantwortung.
Als ersten Schritt habe ich Pepefish für die Registrierung neuer Accounts geschlossen. Es soll niemand aus Versehen noch einsteigen, um dann womöglich in kurzer Zeit eine neue Heimat suchen zu müssen.
Neue Heimat… das ist nun natürlich auch so ein Punkt. Es sind, wie gesagt, inzwischen einige Forks erschienen… Sharkey, Iceshrimp und nun auch Catodon.
Das ist einerseits eine tolle Sache, andererseits beruhigt mich das auch nicht wirklich. Solche Abspaltungen sind eine tolle Sache und meist herrscht anfangs auch eine große Euphorie, viele Helfer kommen dazu, viele probieren die Software aus… es passiert so einiges. Doch das ebbt irgendwann auch wieder ab. Und dann kommt es darauf an, dass das Kernteam ausreichend groß und engagiert genug ist, das Projekt auf Dauer fortzuführen. Und es ist, wie Firefish gerade gezeigt hat, wichtig, dass die Hauptverantwortung für ein solches Projekt tatsächlich auch auf mehrere Schultern verteilt ist und nicht auf nur einen oder zwei aus dem Team… denn wenn der oder die, aus welchen Gründen auch immer, aussteigen, ohne eine Nachfolge zu regeln, steht da die nächste „Bauruine“ in der Gegend herum.
Ich werde mit Sicherheit nicht sofort auf einen diese neuen Züge aufspringen, sondern diesmal wirklich genau hinschauen und auch deutlich länger abwarten, bevor ich eine eigene Instanz aufsetze.
Aber… auch wenn ich an das Weiterbestehen von Firefish geglaubt hatte (weil ich einfach daran glauben wollte), hatte ich mir schon länger Gedanken darüber gemacht, was denn eine Alternative sein könnte.
Na… wie wäre es denn mit dem „Ohrischinaaal“? Misskey existiert nun schon recht lange und wird noch immer aktiv entwickelt. Es hat eine große Userbase und auch eine große Zahl an laufender Instanzen.
So habe ich schon vor ein paar Wochen mal selbst eine Instanz aufgesetzt und mich damit befasst.
Perikey – meine öffentliche und für Registrierungen offene Misskey-Instanz
Ok… Firefish hatte schon einige Features mehr und es gab auch praktische Verbesserungen. Aber grundsätzlich ist Misskey gar nicht so weit weg vom jetzt toten Fisch. Kann man mit Firefish umgehen, findet man sich sehr schnell auch bei Misskey zurecht.
Inzwischen habe ich meine Kontakte herübergeholt und ich hatte es bis gestern „so nebenher“ zu laufen.
Nach der Hiobsbotschaft gestern habe ich mich nun entschlossen, meine Aktivitäten auf meiner Firefish-Instanz auszusetzen. Die Instanz bleibt vorerst noch am Netz. Bei der geringen Zahl an Nutzern kann ich auch jedem persönlich schreiben, die Schließung ankündigen, zu meiner Misskey-Instanz einladen und erläutern, wie man z.B. seine Kontakte mitnimmt.
Ich hoffe halt immer noch auf ein „Wunder“… aber spätestens in vier Wochen, wenn sich besagtes Wunder nicht abzeichnet, werde ich Pepefish vom Netz nehmen.
[d]Die FirefishTalk-Gruppe lasse ich bestehen und werde in der Beschreibung ergänzen, dass dort nunmehr über alle Forks diskutiert werden kann.[/d]
Das in sehr vielen Stunden aufgebaute Firefish-Wiki nehme ichdann auch nicht vom Netz… ich werde vermutlich ein weiteres zu Misskey und Sharkey (vielversprechender Misskey-Softfork) aufbauen… dafür kann ich immerhin einiges an Inhalten übernehmen und leicht modifizieren.
Schade… aber anscheinend ist der Fisch wirklich tot…
Seit einiger Zeit geisterte das Gerücht durchs Fediverse, dass die Entwicklung der Fediverse-Software Firefish zum Erliegen gekommen sei. Das beunruhigte mich schon ein wenig, weil ich mich 1. in Firefish verliebt hatte, 2. eine Firefish-Instanz installiert hatte… nicht nur kurz zum Testen, sondern als längerfristigen Server im Fediverse und ich 3. auch ordentlich „Werbung“ für Firefish betrieben habe und sehr viele Stunden in die Firefish KnowledgeDB (ein Wiki) gesteckt habe.
Es wurde dann vor einiger Zeit noch eine neue Version (die aktuelle stabile Version war und ist 1.0.3) veröffentlicht, auf die ich dann auch umgestellt habe: 1.0.5-rc. Das „rc“ steht für „Release Candidate“. Das sind Versionen einer Software, die eine Betatest-Phase hinter sich gebracht haben und der endgültigen Version entsprechen sollten. Es ist sowas wie ein letzter „Betatest“, bei dem nur noch die letzten Fehlerkorrekturen erfolgen, bevor dann die finale Version veröffentlicht wird.
Das vermittelte mir den Eindruck, dass da doch noch etwas geht.
Im Fediverse wurde immer wieder darauf hingewiesen, dass im Software-Repository nicht mehr viel passiert… das sei ein Zeichen dafür, dass das Projekt tot sei. Auch diese „Meldungen“ (ich hatte das ja auch selbst beobachtet) waren für mich durch die RC-Phase erklärbar. Während der letzten Phase der Softwareentwicklung, in der ein RC im Echtbetrieb getestet wird, passiert an der Software nicht mehr viel. Hier und da noch ein paar Feinschliffe, die eine oder andere Übersetzung… aber nichts grundlegendes oder beachtliches.
Bei größeren Projekten mag das anders sein, weil da dann schon von einigen des großen Entwicklerteams an der nächsten Version gebastelt wird, aber Firefish hatte ja ein kleines Team. Da stürzt man sich nicht schon vorher auf die Entwicklung der nächsten Version, wenn die aktuelle noch nicht veröffentlicht ist.
Das waren alles aber nur (begründete) Vermutungen meinerseits. Leider war es bei Firefish schon lange (mindestens seit ich es nutze) die Kommunikation nach Außen schlecht. Aber auch das ist ein Phänomen, das man von Open Source Projekten kennt.
Auffallend war aber die nachlassende Zahl derer, die noch irgendwie im Repo aktiv waren.
Dann erschienen in letzter Zeit auch noch vermehrt andere Forks von Misskey, die in die gleiche Richtung gingen, wie Firefish und sogar ein Firefish-Fork.
Die Stimmen, dass Firefish wohl tot sei, wurden mehr und lauter.
Schließlich gab es die Ankündigung eines weiteren Forks mit dem Namen „Catodon“… und dabei war die Besonderheit, dass sie von einem Kern-Mitglied des Firefish-Teams kam, von Panos.
Gestern nun platzte die Bombe.
Panos teilte mit, dass Firefish als Projekt faktisch tot ist. Das Hauptproblem lag wohl darin, dass Firefish, trotz gar nicht so kleinem Kernteams trotzdem ein One-Man-Show war. Der „Besitzer“ Kainoa hat das Projekt offensichtlich aufgegeben, ist kaum noch aktiv und auch quasi nicht erreichbar. Dem Rest des Kernteams sind aber, was Entscheidungen anbelangt, die Hände gebunden. Der Kapitän ist von Bord und die Mannschaft huckt gefesselt am Mastbaum.
Original-Post von Panos
Falls Sie es noch nicht bemerkt haben: Es sieht nicht gut aus für firefish. Sein Besitzer, Kainoa, hat das Projekt, dessen letzte stabile Version im Juli veröffentlicht wurde, praktisch aufgegeben. Meine letzte Nachricht an den Betreiber war vor einer Woche, und seitdem habe ich keine Antwort mehr erhalten. Firefish.social hat neben den anderen schwerwiegenden technischen Problemen, die es aufgrund von Missmanagement in den letzten Monaten hatte, nun auch ernsthafte Probleme mit der Föderation. Ich hoffe, dass es Kainoa persönlich gut geht, aber das ist unverantwortlich und inakzeptabel.
…
In der Zwischenzeit möchte ich mich für etwaige Unannehmlichkeiten im Zusammenhang mit Firefish entschuldigen, da ich technisch gesehen immer noch ein Mitglied des Kernteams bin, was auch immer das bedeutet. Aber ehrlich gesagt habe ich mich sehr bemüht, die Dinge anders zu gestalten – aber man kann nicht viel tun, wenn es sich um das Projekt eines anderen handelt. Es tut mir wirklich leid, wie die Dinge gelaufen sind.
Ich finde das ausgesprochen schade und bin traurig. Ich kann und will aber nun auch keine Fediverse-Instanz betreiben, die nicht mehr weiterentwickelt und auch nicht einmal mehr gepflegt wird. Ungepflegte Software ist ein Sicherheitsrisiko und auch keine zukunftsfähige Sache. Ich möchte sowas aber weder mir, noch den wenigen Nutzern meiner Instanz zumuten. Als Instanzbetreiber trage ich auch eine gewisse Verantwortung.
Als ersten Schritt habe ich Pepefish für die Registrierung neuer Accounts geschlossen. Es soll niemand aus Versehen noch einsteigen, um dann womöglich in kurzer Zeit eine neue Heimat suchen zu müssen.
Neue Heimat… das ist nun natürlich auch so ein Punkt. Es sind, wie gesagt, inzwischen einige Forks erschienen… Sharkey, Iceshrimp und nun auch Catodon.
Das ist einerseits eine tolle Sache, andererseits beruhigt mich das auch nicht wirklich. Solche Abspaltungen sind eine tolle Sache und meist herrscht anfangs auch eine große Euphorie, viele Helfer kommen dazu, viele probieren die Software aus… es passiert so einiges. Doch das ebbt irgendwann auch wieder ab. Und dann kommt es darauf an, dass das Kernteam ausreichend groß und engagiert genug ist, das Projekt auf Dauer fortzuführen. Und es ist, wie Firefish gerade gezeigt hat, wichtig, dass die Hauptverantwortung für ein solches Projekt tatsächlich auch auf mehrere Schultern verteilt ist und nicht auf nur einen oder zwei aus dem Team… denn wenn der oder die, aus welchen Gründen auch immer, aussteigen, ohne eine Nachfolge zu regeln, steht da die nächste „Bauruine“ in der Gegend herum.
Ich werde mit Sicherheit nicht sofort auf einen diese neuen Züge aufspringen, sondern diesmal wirklich genau hinschauen und auch deutlich länger abwarten, bevor ich eine eigene Instanz aufsetze.
Aber… auch wenn ich an das Weiterbestehen von Firefish geglaubt hatte (weil ich einfach daran glauben wollte), hatte ich mir schon länger Gedanken darüber gemacht, was denn eine Alternative sein könnte.
Na… wie wäre es denn mit dem „Ohrischinaaal“? Misskey existiert nun schon recht lange und wird noch immer aktiv entwickelt. Es hat eine große Userbase und auch eine große Zahl an laufender Instanzen.
So habe ich schon vor ein paar Wochen mal selbst eine Instanz aufgesetzt und mich damit befasst.
Ok… Firefish hatte schon einige Features mehr und es gab auch praktische Verbesserungen. Aber grundsätzlich ist Misskey gar nicht so weit weg vom jetzt toten Fisch. Kann man mit Firefish umgehen, findet man sich sehr schnell auch bei Misskey zurecht.
Inzwischen habe ich meine Kontakte herübergeholt und ich hatte es bis gestern „so nebenher“ zu laufen.
Nach der Hiobsbotschaft gestern habe ich mich nun entschlossen, meine Aktivitäten auf meiner Firefish-Instanz auszusetzen. Die Instanz bleibt vorerst noch am Netz. Bei der geringen Zahl an Nutzern kann ich auch jedem persönlich schreiben, die Schließung ankündigen, zu meiner Misskey-Instanz einladen und erläutern, wie man z.B. seine Kontakte mitnimmt.
Ich hoffe halt immer noch auf ein „Wunder“… aber spätestens in vier Wochen, wenn sich besagtes Wunder nicht abzeichnet, werde ich Pepefish vom Netz nehmen.
[d]Die FirefishTalk-Gruppe lasse ich bestehen und werde in der Beschreibung ergänzen, dass dort nunmehr über alle Forks diskutiert werden kann.[/d]
Das in sehr vielen Stunden aufgebaute Firefish-Wiki nehme ich
Schade… aber anscheinend ist der Fisch wirklich tot…
Die Threads-Frage
Genau die selbe Frage, wie die von @don@microblog.social, stelle ich mir auch. Er schreibt: Ich habe das Problem mit #Threads noch nicht so ganz verstanden. Ich verstehe die Aufregung auch nicht. ...
View article
View summary
Dieser Artikel wurde erstmals am 14. Dezember 2023 veröffentlicht.
Genau die selbe Frage, wie die von @don@microblog.social, stelle ich mir auch. Er schreibt:
Ich habe das Problem mit Threads noch nicht so ganz verstanden.
Ich verstehe die Aufregung auch nicht.
Ich akzeptiere, das Threads von vielen „verteufelt“ oder mindestens „nicht“ gemocht wird, weil es Teil von Meta ist. Ich verstehe auch, dass viele Mitglieder des Fediverse (ich schätze die Mehrheit) nicht auf die Idee kommen würde, nun selbst einen Account bei Threads zu eröffnen, weil man da nun allen Kontakten im Fediverse folgen kann (kann man noch nicht und wird man eh nicht können, weil etliche Instanzen threads.net gesperrt haben). Sicher wird es einige wenige geben, die zu Threads umziehen, weil sie es „cooler“ finden, vermeintlich mit größerer „Reichweite“ (Bullshit, wenn man vom Fediverse spricht) wegen der Größe der Instanz rechnen, oder weil ihnen das Interface besser gefällt. Aber das werden Ausnahmen bleiben. Und vielleicht werden von diesen „Wenigen“ ein paar weitere „Wenige“ auch wieder zurückkehren, weil sie geschätzte Kontakte aus dem Fediverse (außerhalb von Threads) verlieren, da diese einen Account bei einer Instanz haben, die Threads blockt.
Und genau das ist es, was ich nicht verstehe. Weshalb wollen Instanzbetreiber unbedingt Threads blocken? Sie greifen damit recht stark in die Autonomie der Nutzer ihrer Instanz ein, denn sie verbieten ihnen, mit bestimmten Nutzern, die bei Threads sind, zu interagieren. Doch was sind die Gründe, bzw. die Argumente?
Also… man „wisse“, dass bei Threads nicht anständig moderiert werde. Woher man das weiß? Das weiß man einfach. Ohne Threads zu kennen. Weil, ja weil bei Facebook ja auch nicht ordentlich moderiert wird. Und weil das deshalb bei Threads ganz sicher auch so ist.
Hmmm… das nenne ich „Vorurteile“. Wenn es Belege für schlechte Moderation bei Threads gibt, dann nur her damit. Aber eine Behauptung. „Weil die sind ja alle so“ ist für mich nur Geblubber ohne Substanz. Es mag Erfahrungen geben, die schlechte Moderation befürchten lassen… aber Erfahrungen ersetzen keine Fakten.
Sollte es so sein, dann würde das bedeuten, dass bei Threads schlecht moderiert wird. Doch das ist innerhalb des bisherigen Fediverse doch auch so. Es gibt sicher auch Instanzen, bei denen nicht ordentlich moderiert wird. Wobei „ordentlich“ auch noch eine Definitionssache ist und auf eigenen Vorstellungen basiert. Was wären denn nun die Auswirkungen? Na ja… ich kann mir nur Auswirkungen auf die globale Timeline der Instanzen, die mit Threads föderieren, vorstellen. Wenn ein Nutzer einer Fediverse-Instanz einem Thread-Account folgt und er da dann „favorisiert“ / „sternt“ / „likes setzt“… wie auch immer… oder dessen Beiträge „teilt“ / „boostet“… wie auch immer…, dann können Beiträge, die nicht allen gefallen natürlich auch in der eigenen Timeline landen, sofern man dem Nutzer der Fediverse-Instanz folgt. Und dann ist es am Nutzer, zu entscheiden. Er kann den Threads-Nutzer stummschalten, blocken, etc. Damit schließt er aus, dass er mit Inhalten dieses Nutzers konfrontiert wird. Dafür muss nicht die eigene Instanz den Threads-Nutzer, den Fediverse-Nutzer oder gar Threads selbst blocken. Ich bin als reiner Nutzer von Fediverse-Diensten schon unabhängig und groß genug, dass ich selbst persönlich für mich entscheiden kann, was ich sehen will und was nicht. Gibt mir der Fediverse-Dienst die Möglichkeit, solche Inhalte zu unterdrücken, dann mach ich das. Dafür brauche ich keinen „Betreuer“.
Verstoßen solche Inhalte gegen die Regeln der Instanz, dann ist der Admin oder das Moderatoren-Team der Instanz in der Pflicht, diese zu entfernen und künftig ggf. zu unterdrücken. Das müssen sie ja auch tun, wenn sich Nutzer der eigenen Instanz wirklich daneben benehmen.
Das Auftauchen „unangemessener“ Inhalte in der globalen Timeline sehe ich als nicht so kritisch an. Erstmal nutzen die wenigsten diese Timeline überhaupt intensiv. Und man kann über solche Inhalte hinwegsehen. Außerdem kann man als Nutzer Quellen dieser Inhalte, wie erwähnt, ohnehin für die Zukunft unterdrücken.
Das ist also als Argument für einen kompletten Instanzblock von Threads doch Pillepalle.
Ein weiteres Argument gegen die Föderation mit Threads sei die Gefahr von „embrace, extend and extinguish“ (#eee). Da wird heraufbeschworen, Threads würde, wenn es erstmal fest via ActivityPub im Fediverse angekommen sei, die Standards verändern und festlegen… und andere Instanzen quasi dazu zwingen, dies auch zu tun, weil die Föderation, also das Zusammenwirken mit Threads sonst nicht mehr richtig funktioniere. Threads hätte diese „Macht“, weil es ja so viele Nutzer habe. Mal ehrlich: Dann wäre immer noch ausreichend Zeit, Threads zu blocken. Das ändert am Status Quo des Fediverse dann doch auch nichts. Die Nutzerzahlen sind doch eh mehr Augenwischerei. Und ich bezweifle, dass sich jetzt alle Threads-Nutzer als Teil des Fediverse sehen und hauptsächlich Accounts dort folgen.
Das AP wird auch Threads nicht komplett „umstülpen“ können.
Damit ich diese Mär glaube, bräuchte ich mal konkrete Beispiele, wie sich Threads, also Meta das AP zu eigen machen könnte, so dass es negative Auswirkungen auf den Rest des Fediverse hätte.
Bis jetzt ist der ganze Stress um Threads und das Fediverse nur aufgeblähte Panikmache in Verbindung mit moralisierender Einschüchterung.
Und für mich widerspricht der Block-Reflex der grundlegenden Idee des Fediverse, nämlich dem der Offenheit. Ich empfinde das eher als Beißreflex gegen alles, was der eigenen Moral nicht zu 100% entspricht. Und als Bevormundung der Nutzer der eigenen Instanz.
Gibt es Argumente die mich umstimmen könnten? Bitte her damit!
Genau die selbe Frage, wie die von @don@microblog.social, stelle ich mir auch. Er schreibt:
Ich habe das Problem mit Threads noch nicht so ganz verstanden.
Ich verstehe die Aufregung auch nicht.
Ich akzeptiere, das Threads von vielen „verteufelt“ oder mindestens „nicht“ gemocht wird, weil es Teil von Meta ist. Ich verstehe auch, dass viele Mitglieder des Fediverse (ich schätze die Mehrheit) nicht auf die Idee kommen würde, nun selbst einen Account bei Threads zu eröffnen, weil man da nun allen Kontakten im Fediverse folgen kann (kann man noch nicht und wird man eh nicht können, weil etliche Instanzen threads.net gesperrt haben). Sicher wird es einige wenige geben, die zu Threads umziehen, weil sie es „cooler“ finden, vermeintlich mit größerer „Reichweite“ (Bullshit, wenn man vom Fediverse spricht) wegen der Größe der Instanz rechnen, oder weil ihnen das Interface besser gefällt. Aber das werden Ausnahmen bleiben. Und vielleicht werden von diesen „Wenigen“ ein paar weitere „Wenige“ auch wieder zurückkehren, weil sie geschätzte Kontakte aus dem Fediverse (außerhalb von Threads) verlieren, da diese einen Account bei einer Instanz haben, die Threads blockt.
Und genau das ist es, was ich nicht verstehe. Weshalb wollen Instanzbetreiber unbedingt Threads blocken? Sie greifen damit recht stark in die Autonomie der Nutzer ihrer Instanz ein, denn sie verbieten ihnen, mit bestimmten Nutzern, die bei Threads sind, zu interagieren. Doch was sind die Gründe, bzw. die Argumente?
Also… man „wisse“, dass bei Threads nicht anständig moderiert werde. Woher man das weiß? Das weiß man einfach. Ohne Threads zu kennen. Weil, ja weil bei Facebook ja auch nicht ordentlich moderiert wird. Und weil das deshalb bei Threads ganz sicher auch so ist.
Hmmm… das nenne ich „Vorurteile“. Wenn es Belege für schlechte Moderation bei Threads gibt, dann nur her damit. Aber eine Behauptung. „Weil die sind ja alle so“ ist für mich nur Geblubber ohne Substanz. Es mag Erfahrungen geben, die schlechte Moderation befürchten lassen… aber Erfahrungen ersetzen keine Fakten.
Sollte es so sein, dann würde das bedeuten, dass bei Threads schlecht moderiert wird. Doch das ist innerhalb des bisherigen Fediverse doch auch so. Es gibt sicher auch Instanzen, bei denen nicht ordentlich moderiert wird. Wobei „ordentlich“ auch noch eine Definitionssache ist und auf eigenen Vorstellungen basiert. Was wären denn nun die Auswirkungen? Na ja… ich kann mir nur Auswirkungen auf die globale Timeline der Instanzen, die mit Threads föderieren, vorstellen. Wenn ein Nutzer einer Fediverse-Instanz einem Thread-Account folgt und er da dann „favorisiert“ / „sternt“ / „likes setzt“… wie auch immer… oder dessen Beiträge „teilt“ / „boostet“… wie auch immer…, dann können Beiträge, die nicht allen gefallen natürlich auch in der eigenen Timeline landen, sofern man dem Nutzer der Fediverse-Instanz folgt. Und dann ist es am Nutzer, zu entscheiden. Er kann den Threads-Nutzer stummschalten, blocken, etc. Damit schließt er aus, dass er mit Inhalten dieses Nutzers konfrontiert wird. Dafür muss nicht die eigene Instanz den Threads-Nutzer, den Fediverse-Nutzer oder gar Threads selbst blocken. Ich bin als reiner Nutzer von Fediverse-Diensten schon unabhängig und groß genug, dass ich selbst persönlich für mich entscheiden kann, was ich sehen will und was nicht. Gibt mir der Fediverse-Dienst die Möglichkeit, solche Inhalte zu unterdrücken, dann mach ich das. Dafür brauche ich keinen „Betreuer“.
Verstoßen solche Inhalte gegen die Regeln der Instanz, dann ist der Admin oder das Moderatoren-Team der Instanz in der Pflicht, diese zu entfernen und künftig ggf. zu unterdrücken. Das müssen sie ja auch tun, wenn sich Nutzer der eigenen Instanz wirklich daneben benehmen.
Das Auftauchen „unangemessener“ Inhalte in der globalen Timeline sehe ich als nicht so kritisch an. Erstmal nutzen die wenigsten diese Timeline überhaupt intensiv. Und man kann über solche Inhalte hinwegsehen. Außerdem kann man als Nutzer Quellen dieser Inhalte, wie erwähnt, ohnehin für die Zukunft unterdrücken.
Das ist also als Argument für einen kompletten Instanzblock von Threads doch Pillepalle.
Ein weiteres Argument gegen die Föderation mit Threads sei die Gefahr von „embrace, extend and extinguish“ (#eee). Da wird heraufbeschworen, Threads würde, wenn es erstmal fest via ActivityPub im Fediverse angekommen sei, die Standards verändern und festlegen… und andere Instanzen quasi dazu zwingen, dies auch zu tun, weil die Föderation, also das Zusammenwirken mit Threads sonst nicht mehr richtig funktioniere. Threads hätte diese „Macht“, weil es ja so viele Nutzer habe. Mal ehrlich: Dann wäre immer noch ausreichend Zeit, Threads zu blocken. Das ändert am Status Quo des Fediverse dann doch auch nichts. Die Nutzerzahlen sind doch eh mehr Augenwischerei. Und ich bezweifle, dass sich jetzt alle Threads-Nutzer als Teil des Fediverse sehen und hauptsächlich Accounts dort folgen.
Das AP wird auch Threads nicht komplett „umstülpen“ können.
Damit ich diese Mär glaube, bräuchte ich mal konkrete Beispiele, wie sich Threads, also Meta das AP zu eigen machen könnte, so dass es negative Auswirkungen auf den Rest des Fediverse hätte.
Bis jetzt ist der ganze Stress um Threads und das Fediverse nur aufgeblähte Panikmache in Verbindung mit moralisierender Einschüchterung.
Und für mich widerspricht der Block-Reflex der grundlegenden Idee des Fediverse, nämlich dem der Offenheit. Ich empfinde das eher als Beißreflex gegen alles, was der eigenen Moral nicht zu 100% entspricht. Und als Bevormundung der Nutzer der eigenen Instanz.
Gibt es Argumente die mich umstimmen könnten? Bitte her damit!
Mein Wohlfühl-Zuhause
Ja, ich muss gestehen, ich hab‘s getan. Ich hab mal reingeschaut, bei Bluesky (BS). Einfach, um mir selbst ein Bild zu machen. Man liest ja so viel darüber. ...
View article
View summary
Dieser Artikel wurde erstmals am 22. November 2023 veröffentlicht.
Ja, ich muss gestehen, ich hab‘s getan. Ich hab mal reingeschaut, bei Bluesky (BS).
Einfach, um mir selbst ein Bild zu machen. Man liest ja so viel darüber.
Dafür habe ich aber nirgends um einen Invite-Code gebettelt oder zugegriffen, wenn die irgendwo angeboten wurden. Ich habe ganz ordentlich, wie es sich für einen Beamten (im Ruhestand) gehört, auf der Webseite der App vom blauen Himmel mit einer speziellen Mailadresse um eine Einladung „beworben“.
Nach zwei Monaten hatte ich schon nicht mehr damit gerechnet, dass da noch was kommt… plötzlich bekomme ich von aller-offiziellster Himmelsstelle einen Code. Nach kurzem Zögern hab ich mir dann auch einen Account angelegt (nix mit „Pepe“… aus Gründen).
Kein spektakulärer Anmeldeprozess… aber das Anlegen eines Accounts irgendwo im Fediverse ist auch nicht komplizierter. Irgendwann wurde mir dann auch Vorschläge zum Folgen angeboten. Aber da war mal so gar nix dabei, was mein Interesse hätte wecken können. Also bin ich „unfolgend“ eingestiegen.
Na ja… wer Mastodon „langweilig“ oder nicht intuitiv findet, der wird auch beim blauen Himmel nichts anderes empfinden. Es sieht halt noch ein wenig mehr nach „X“ aus, das war es aber auch schon.
Die Timeline war, weil ich ja niemandem folgte, leer… so wie es beim allerersten Einstieg im Fediverse auch ist.
Ok… das konnte ich nachvollziehen. Also hab ich mal angefangen, nach Nutzern/Accounts zu suchen, denen ich folgen könnte. „Discover“ war da mein erster Weg.
Ehrlich mal… ich glaube, ich habe im Fediverse noch nie so lange gescrollt, bis ich überhaupt auf irgendwelche für mich interessanten Postings gestoßen bin. Allerdings wurden mir das Beiträge von Accounts reingespült, denen ich nun wirklich nicht würde folgen wollen. Weder bei Blue Sky, noch irgendwo sonst.
Über die Suchfunktion habe ich dann nach längerer Zeit genau einen(!) Account gefunden, dem ich gerne folgen wollte (das wäre auch im Fediverse ein Account gewesen, mit dem ich mich verbunden hätte). Bei täglichen „Discovern“ kam dann noch einer dazu, der wohl auch selbst im Fediverse unterwegs ist (und dem ich im Fediverse als Pepe auch folge)… und ein paar „Bots“ von Nachrichtensendern, aus dem Bereich der Wissenschaft, sowie anderen Protagonisten, die auch zu meinen Interessengebieten im Fedi gehören.
Nun ist meine Timeline nach dem Aufruf der Seite nicht mehr so leer, aber Spaß kommt noch immer nicht auf.
Was mir aufgefallen ist: Der hochgelobte „Algorithmus“.. die „künstliche Dummheit“ schätzte mich anfangs wohl völlig falsch ein… aber Irren ist ja auch menschlich. 😉
Nun ist das Auftauchen von Postings und Nutzern, auf die ich gar keine Böcke habe, deutlich weniger geworden. Dafür hat völlig(!) belangloser Kram überhand genommen. Was mir nun präsentiert wird, ist so belanglos, dass ich das Reinschauen für absolute Zeitverschwendung halte.
Wenn ich das nun mal mit dem Fediverse vergleiche… uiuiui… Erstmal ist BS derart spartanisch, dass ich mich an meine ersten Gehversuche mit GNU Social erinnert fühlte.
Der größte Unterschied ist aber, dass ich bei BS nicht einmal im Ansatz heimische Gefühle bekomme. Mein Ein- und Umstieg zu meinem favorisierten Netzwerk Firefish ist ja auch noch nicht so lange her. Und ich bin da auch recht „leicht bekleidet“ eingestiegen (obwohl ich in anderen Fediverse-Netzen sehr viele Kontakte hatte)… soll heißen: Ich habe nur ein paar wenige Mastodon-Kontakte „mitgenommen“. Trotzdem hatte ich nach kürzester Zeit eine Timeline nach meinem Geschmack. Es ließen sich viel einfacher Nutzer zum Interagieren finden und ich habe mich gemütlich eingerichtet. Bei BS hänge ich im Prinzip noch immer da, wo ich nach der Anmeldung war. Der Inhalt der Timeline hat sich, wie gesagt, ein wenig geändert (muss am tollen Algorithmus liegen), doch eine soziale Vernetzung entsteht nicht.
Bluesky ist für mich so überflüssig wie ein Kropf! Mag sein, dass es für Twitterflüchtlinge ne nette Sache sein man, weil sie da alte Kontakte von X wiederfinden… aber für mich isses nix. Na und so habe ich den Account heute nach gut zwei Wochen wieder geschlossen.
Was hat es mir gebracht? Nun, ich weiß jetzt, wie es da aussieht. Und ich weiß, dass ich zu sehr im Fediverse verwurzelt bin, als dass ich dort heimisch werden könnte. Die Zeit spare ich mir.
Ich dachte eigentlich, ich schau da länger rein… aber… nein, danke, reicht schon.
Mein Wohlfühl-Zuhause ist das Fediverse!
Ja, ich muss gestehen, ich hab‘s getan. Ich hab mal reingeschaut, bei Bluesky (BS).
Einfach, um mir selbst ein Bild zu machen. Man liest ja so viel darüber.
Dafür habe ich aber nirgends um einen Invite-Code gebettelt oder zugegriffen, wenn die irgendwo angeboten wurden. Ich habe ganz ordentlich, wie es sich für einen Beamten (im Ruhestand) gehört, auf der Webseite der App vom blauen Himmel mit einer speziellen Mailadresse um eine Einladung „beworben“.
Nach zwei Monaten hatte ich schon nicht mehr damit gerechnet, dass da noch was kommt… plötzlich bekomme ich von aller-offiziellster Himmelsstelle einen Code. Nach kurzem Zögern hab ich mir dann auch einen Account angelegt (nix mit „Pepe“… aus Gründen).
Kein spektakulärer Anmeldeprozess… aber das Anlegen eines Accounts irgendwo im Fediverse ist auch nicht komplizierter. Irgendwann wurde mir dann auch Vorschläge zum Folgen angeboten. Aber da war mal so gar nix dabei, was mein Interesse hätte wecken können. Also bin ich „unfolgend“ eingestiegen.
Na ja… wer Mastodon „langweilig“ oder nicht intuitiv findet, der wird auch beim blauen Himmel nichts anderes empfinden. Es sieht halt noch ein wenig mehr nach „X“ aus, das war es aber auch schon.
Die Timeline war, weil ich ja niemandem folgte, leer… so wie es beim allerersten Einstieg im Fediverse auch ist.
Ok… das konnte ich nachvollziehen. Also hab ich mal angefangen, nach Nutzern/Accounts zu suchen, denen ich folgen könnte. „Discover“ war da mein erster Weg.
Ehrlich mal… ich glaube, ich habe im Fediverse noch nie so lange gescrollt, bis ich überhaupt auf irgendwelche für mich interessanten Postings gestoßen bin. Allerdings wurden mir das Beiträge von Accounts reingespült, denen ich nun wirklich nicht würde folgen wollen. Weder bei Blue Sky, noch irgendwo sonst.
Über die Suchfunktion habe ich dann nach längerer Zeit genau einen(!) Account gefunden, dem ich gerne folgen wollte (das wäre auch im Fediverse ein Account gewesen, mit dem ich mich verbunden hätte). Bei täglichen „Discovern“ kam dann noch einer dazu, der wohl auch selbst im Fediverse unterwegs ist (und dem ich im Fediverse als Pepe auch folge)… und ein paar „Bots“ von Nachrichtensendern, aus dem Bereich der Wissenschaft, sowie anderen Protagonisten, die auch zu meinen Interessengebieten im Fedi gehören.
Nun ist meine Timeline nach dem Aufruf der Seite nicht mehr so leer, aber Spaß kommt noch immer nicht auf.
Was mir aufgefallen ist: Der hochgelobte „Algorithmus“.. die „künstliche Dummheit“ schätzte mich anfangs wohl völlig falsch ein… aber Irren ist ja auch menschlich. 😉
Nun ist das Auftauchen von Postings und Nutzern, auf die ich gar keine Böcke habe, deutlich weniger geworden. Dafür hat völlig(!) belangloser Kram überhand genommen. Was mir nun präsentiert wird, ist so belanglos, dass ich das Reinschauen für absolute Zeitverschwendung halte.
Wenn ich das nun mal mit dem Fediverse vergleiche… uiuiui… Erstmal ist BS derart spartanisch, dass ich mich an meine ersten Gehversuche mit GNU Social erinnert fühlte.
Der größte Unterschied ist aber, dass ich bei BS nicht einmal im Ansatz heimische Gefühle bekomme. Mein Ein- und Umstieg zu meinem favorisierten Netzwerk Firefish ist ja auch noch nicht so lange her. Und ich bin da auch recht „leicht bekleidet“ eingestiegen (obwohl ich in anderen Fediverse-Netzen sehr viele Kontakte hatte)… soll heißen: Ich habe nur ein paar wenige Mastodon-Kontakte „mitgenommen“. Trotzdem hatte ich nach kürzester Zeit eine Timeline nach meinem Geschmack. Es ließen sich viel einfacher Nutzer zum Interagieren finden und ich habe mich gemütlich eingerichtet. Bei BS hänge ich im Prinzip noch immer da, wo ich nach der Anmeldung war. Der Inhalt der Timeline hat sich, wie gesagt, ein wenig geändert (muss am tollen Algorithmus liegen), doch eine soziale Vernetzung entsteht nicht.
Bluesky ist für mich so überflüssig wie ein Kropf! Mag sein, dass es für Twitterflüchtlinge ne nette Sache sein man, weil sie da alte Kontakte von X wiederfinden… aber für mich isses nix. Na und so habe ich den Account heute nach gut zwei Wochen wieder geschlossen.
Was hat es mir gebracht? Nun, ich weiß jetzt, wie es da aussieht. Und ich weiß, dass ich zu sehr im Fediverse verwurzelt bin, als dass ich dort heimisch werden könnte. Die Zeit spare ich mir.
Ich dachte eigentlich, ich schau da länger rein… aber… nein, danke, reicht schon.
Mein Wohlfühl-Zuhause ist das Fediverse!
Conversation Features
Loading...