#dfrn — Public Fediverse posts

@Kristian Na ja, Friendica war ja ausgereift. Zumindest soweit ausgereift, wie Friendica selbst und das DFRN-Protokoll es zuließen. Smartphone-Apps gab es nicht, weil man damals, 2010/2011, Smartphone-Apps für Sachen, die es auch als Websites gab, noch als Gimmicks ansah und noch nicht als lebensnotwendig. Das war, bevor die Leute gewisse Websites mehr über dedizierte Apps nutzten als über die Websites selbst.

Nur: Eine Weiterentwicklung war zwingend notwendig. Und die ging nicht mit Friendica, wie es war, denn die ging auch nicht mit DFRN.

Der Auslöser: 2011 waren binnen kurzer Zeit mehrere größere Friendica-Nodes von jetzt auf sofort ohne Ankündigung verschwunden. Einfach so weg. Friendica war durch das Verschwinden einiger weniger, aber jeweils sehr großer öffentlicher Nodes auf die Hälfte seiner Größe geschrumpft. Die andere Hälfte der Nutzer hatte alles verloren ohne die Chance, irgendwas zu retten. Die konnten wieder ganz neu bei null anfangen.

Das beste, was Mike an Friendica selbst machen konnte, war, eine Export- und Importfunktion einzubauen. Damit konnte man Backups des eigenen Konto machen. Das half aber nur, wenn man entweder brav ein tägliches Backup machte oder die Schließung eines Node vorher angekündigt wurde. Noch einmal: Genau das war 2011 nicht passiert. Die Nodes waren einfach futsch. Da hilft dir auch eine Backup-Funktion nicht, wenn du nicht laufend regelmäßig Backups machst.

Mike sah nur eine mögliche wirkliche Lösung. Und das war, indem deine Identität nicht bombenfest an einen Server gebunden ist, sondern simultan gleichzeitig als identische Klone auf mehreren unabhängigen Servern existieren kann. Wenn davon mal einer ausfällt, egal, die anderen laufen ja noch, also läuft deine Identität noch.

Problem: Mit DFRN ging das nicht umzusetzen. Es brauchte ein ganz neues Protokoll. Auch deshalb, weil Mike noch andere Verbesserungen im Kopf hatte wie ein nochmals deutlich aufgebohrtes Berechtigungssystem. Auch das ging mit DFRN so nicht und brauchte ein neues Protokoll. So entstand Zot.

Zum einen hieß ein neues Protokoll aber auch, wo auch immer das eingebaut werden soll, muß das komplette Backend ausgetauscht und neu geschrieben werden. Und große Teile des Frontend gleich mit. Das konnte Mike aber nicht auf Friendica im laufenden Betrieb machen. Friendica hätte unmöglich seine Grundfunktionalität gleichzeitig auf DFRN und auf Zot betreiben können. Und ein Protokollaustausch hätte bedeutet, daß Nodes, die die neue Friendica-Version mit Zot fahren, sich nicht mehr nativ hätten verbinden können mit Nodes, die alte Versionen mit DFRN fahren. Die wären zueinander inkompatibel gewesen.

Mike hatte als neue Entwicklungsplattform ja gerade das neue Red, das ein Fork seiner bisherigen "geheimen" Entwicklungsplattform Free-Friendika war. Das war ebenso "geheim", das konnte er also entsprechend umbauen.

Mike hätte aber niemals gleichzeitig Red komplett umbauen und Friendica selbst auf Free-Friendika weiterpflegen und die Weiterentwicklungen von Free-Friendika nach Friendica selbst bringen können. Und die einzige Alternative zum Umbau von Red auf Zot war, wieder solche Massencrashs wie 2011 mit exakt denselben Auswirkungen zu haben, ohne irgendwas tun zu können.

Also hat Mike sich auf Red konzentriert (dessen Umbau ja alleine schon länger dauern sollte als die Entwicklung von Friendica) und Friendica in die Hände von Tobias und Michael gegeben, die es seitdem nach ihren Vorstellungen weiterentwickeln. Die beiden waren ja meines Wissens sowieso schon Co-Entwickler von Friendica. Das hat Mike ja längst nicht mehr alles alleine gemacht.

Bei Red war das wieder anders. Das machte Mike ganz alleine. Das mußte er ja erstmal aufbauen. Und selbst als es fertig war, wurde es kaum angenommen. Es war zwar kein Geheimprojekt mehr, nachdem es sich von Friendica gelöst hatte. Aber es wurde kaum angenommen.

Auch als es umbenannt wurde in Red Matrix, was es leichter machte, es zu googlen, wurde es nicht angenommen. Die Friendica-Nutzer nahmen es wahr als Friendica mit nomadischer Identität. Was nomadische Identität ist, verstanden sie gar nicht. Selbst wenn doch: Die meisten von ihnen hatten inzwischen ihre eigenen privaten Einzelnutzer-Nodes.

So sahen sie in der Red Matrix gegenüber Friendica keine Vorteile, also warum umsteigen? Mal ganz davon abgesehen, daß Friendica und die Red Matrix nur über das diaspora*-Protokoll oder OStatus kommunizieren konnten. Die einzigen, die wechselten, dürften die gewesen sein, die eh immer das neueste, heißeste Zeug ausprobieren wollten.

Außerhalb von Friendica wußte eh keine Sau, daß die Red Matrix existierte. Herzlich wenige Leute wußten ja überhaupt auch nur, daß Friendica existierte. Mikes "Wenn du es baust, werden sie kommen" funktionierte damals schon nicht. Kleckerweise kamen noch neue Leute nach Friendica. Aber kaum einer ging von Friendica auf die Red Matrix, und absolut niemand ging von null auf die Red Matrix.

Interessant wurde die Red Matrix eigentlich erst 2015, als sie zu Hubzilla aufgebohrt wurde, also auf einmal Sachen konnte, die Friendica nicht konnte, die aber vielleicht nützlich sein konnten. Damit konnte Hubzilla auch für ganz andere Sachen eingesetzt werden als Friendica, also nicht nur als Facebook-Ersatz oder Blog.

Aber wenn Mario schon Anfang 2015 das noch brandneue Hubzilla übernahm, was ja so auf der offiziellen Website steht (nach meinen Informationen war es erst 2018), dann war es ein Wunder, daß Mike überhaupt jemanden fand, der übernehmen würde, der also schon seit Red-Matrix-Zeiten dabei war. Aber Mike hat ja an der Weiterentwicklung von Hubzilla noch weiter aktiv mitgewirkt, nur eben nicht als Projektleiter.

Hubzilla selbst wurde ja erst ab Ende 2015 interessant, als es seinen ersten stabilen Release hatte. Und auch Hubzillas Existenz war eigentlich nur auf Friendica bekannt. Selbst heute noch sind die allermeisten Hubzilla-Nutzer Friendica-Veteranen. Direkt von Mastodon nach Hubzilla ist kaum einer gekommen, von null nach Hubzilla schon gar nicht.

Selbst da war Mike keiner, der Sachen so läßt, wie sie sind, und sie nur noch weiter poliert. Wenn es etwas zu verbessern gibt, dann macht er das auch. Und wenn das nicht auf existierender Software im laufenden Produktivbetrieb geht, dann forkt er eben, und dann nimmt er sich weit mehr Zeit für seinen Fork als für das, was er vorher gemacht hatte. Und das ist auch gut so. Ansonsten hätten wir heute noch nur Friendica und immer noch keine Lösung für das Problem, daß die Leute alles verlieren, wenn mal wieder ein großer Node verschwindet.

Jetzt wollte Mike Zot weiterentwickeln, wohl auch deshalb, weil Zot, wie es damals war, nicht gut mit ActivityPub zusammenspielte. Aber potentiell kompatibilitätsbrechend. In einem eigenen zusätzlichen Branch von Hubzilla wäre das nicht gegangen, schon deshalb, weil Hubzilla für solche Experimente schlicht und ergreifend zu groß war.

Also hat Mike 2018 Osada von Hubzilla abgeforkt und alles rausgerissen, was im Weg war. Artikel, Karten, Wikis, Webpages, alle Verbindungsmöglichkeiten außer Zot, ActivityPub und RSS/Atom, alles raus.

Weil dann abzusehen war, daß nomadisches Zot6 (zumindest vorerst) mit ActivityPub überhaupt nicht mehr funktionieren würde, brauchte Mike zwei Projekte: Osada behielt ActivityPub, wurde aber nichtnomadisch. Zusätzlich forkte er Zap von Osada, ließ es nomadisch, entfernte aber ActivityPub.

Jetzt konnte Mike endgültig nicht gleichzeitig Zot6 entwickeln und Osada entwickeln und Zap entwickeln und Hubzilla weiterpflegen. Auch dieses Mal half ihm bei den Neuentwicklungen niemand. Also überließ er Hubzilla gänzlich Mario.

Wie es dann weiterging, lag nicht an Mikes Sprunghaftigkeit.

Anfang 2019 fand er einen Weg, auch nomadisches Zot6 mit ActivityPub kompatibel zu machen. Abgesehen davon war die Idee, einen nomadischen Zap-Kanal über einen nichtnomadischen Osada-Kanal mit dem Fediverse zu verbinden, sowieso kompletter Blödsinn und technisch in der Praxis kaum realisierbar, selbst mit Kanalquellen nicht. Also stellte Mike Osada ein, forkte von Zap ein ganz neues Osada und baute da ActivityPub-Support ein. Noch war nomadisches Zot6 + ActivityPub ja noch experimentell, deswegen hat er es nicht in Zap eingebaut.

Dann aber wurden Osada und Zap stabil und bekamen sogar einen 1.0-Release. Inzwischen gab es Leute, die Osada oder Zap produktiv nutzten. Die kamen alle von Hubzilla, denn nur da wußte man, daß es Osada und Zap gab. Nicht mal auf Friendica wußte das jemand, im übrigen Fediverse erst recht nicht und außerhalb des Fediverse schon gar nicht.

So baute Mike dann Osadas ActivityPub-Support auch in Zap ein, schaltete ihn aber standardmäßig auf Serverebene ab, auf Kanalebene sowieso. Das führte dazu, daß Osada und Zap bis auf das Branding und die Standardeinstellungen völlig identisch waren. Es brauchte gar nicht mehr beide. Mike ließ das aber so.

Irgendwie gab es wohl genug Osada- und Zap-Anwender, daß Mike jemanden fand, der beides weiterpflegen wollte. Denn Mike hatte wieder neue Weiterentwicklungen im Sinne, die er aber nicht mehr auf Osada und Zap machen konnte, weil die jetzt beide als stabile Produktivsoftware galten. So gab er Osada und Zap dann wieder an "die Community" weiter, die als quasi erste Amtshandlung mit Mikes Segen Osada nach Zap mergete, in dem Zuge auch auf Zap ActivityPub standardmäßig aktivierte und Osada kurzerhand einstellte.

2020 ging es dann weiter. Zap war damals State of the Art. Zot6 war so stabil, daß es nach Hubzilla zurückportiert wurde. Zap war jetzt quasi der modernere kleine Bruder von Hubzilla, der sich etwas eleganter bediente und einen nicht mit Features erschlug. Nur war Zap immer noch obskurer als Hubzilla, Hubzilla war obskurer als Friendica, und Friendica war selbst sehr obskur, weil für keins der drei wirklich Werbung gemacht wurde. Zap war weiterhin sonst nur auf Hubzilla bekannt und Hubzilla sonst nur auf Friendica.

Und Mike bastelte an Zot8, das nochmals besser werden sollte. Dafür brauchte er aber Software zum Experimentieren. Und so entstanden drei neue Forks in so kurzer Folge, daß heute nicht mehr bekannt ist, was jetzt wovon geforkt wurde, nur daß irgendwas von Zap geforkt worden ist. Im einzelnen waren das schon wieder ein neues Osada, ein neues Mistpark und eine neue Redmatrix.

Warum drei?

Es ging das Gerücht um, das seien verschiedene Stabilitätsstufen. Redmatrix 2020 sei experimentell mit wie früher bei Zap standardmäßig deaktiviertem ActivityPub, das damit der Entwicklung von Zot8 nicht im Wege stehe. Osada sei auch experimentell, aber wie früher schon bei Osada mit standardmäßig aktiviertem ActivityPub, um zu gucken, wie die Weiterentwicklungen von Zot8 sich mit ActivityPub vertragen. Mistpark 2020 wiederum sei "halbstabil" wie Debian testing, also stabiler als Osada und eher für den Produktiveinsatz geeignet, aber aktueller als Zap.

Zap sei also für die, die etwas neueres als Hubzilla haben wollten und auf die Zusatzfeatures von Hubzilla verzichten konnten. Misty sei für die, die etwas noch aktuelleres als Zap haben wollten, also das neueste Zeug noch früher, und die etwaige Instabilitäten in Kauf zu nehmen bereit waren. Osada sei für die, die unbedingt bleeding-edge wollten, instabil oder nicht. Und Redmatrix 2020 sei eh nur für Mike.

In Wahrheit waren Osada, Misty und Redmatrix 2020 bis auf das Branding völlig identisch und quasi Soft-Forks. Alle Commits wurden gleichermaßen und fast gleichzeitig in alle drei eingepflegt.

Warum?

Weil Mike der Markenfetischismus im Fediverse auf den Keks ging. Es gab Leute, die bildeten sich ein, die Software, die sie nutzten, sei die beste, einfach, weil sie Fans der Softwaremarke waren. Ganz besonders gab es die natürlich auf Mastodon, aber auch sonst. Genau diese Leute wollte er trollen, indem er drei bis auf den Namen und das Logo völlig identische Serveranwendungen pflegte. Misty z. B. konnte überhaupt nicht "die beste Fediverse-Serversoftware" sein, egal, wer sich das einbildete, wenn Osada und Redmatrix bis auf die Marke völlig baugleich waren.

Anfang 2021 kam dann Roadhouse dazu. Das Abenteuer Zot8 war im Grunde vorbei, bevor Zot8 stabil war. Denn Zot11 sollte noch besser werden. Vor allem sollte Zot11 von allen Zot-Versionen die beste Kompatibilität mit ActivityPub bekommen. Blöderweise konnte Mike aber Zot11 nicht auf Osada, Misty und Redmatrix entwickeln. Zot11 sollte nämlich zu allen Vorgängern so inkompatibel werden, daß es letztlich nicht mehr Zot heißen sollte. Aber es gab Leute, die Osada, Misty oder Redmatrix produktiv nutzten.

Also mußte Mike von einem von den dreien Roadhouse forken. War ihm aber egal, weil er damit die Leute mit noch einer weiteren Marke trollen konnte. Wohlgemerkt, effektiv hatte er sogar Zap noch an der Backe, weil es in der Community dann wohl doch zuwenig Interesse an der Weiterentwicklung gab.

Nomad, eigentlich ja Zot11, wurde zum Erfolg. Und das Erfolgsrezept lag auch darin, zusätzlich Support für Hubzillas Zot6 einzubauen, über den Roadhouse auch mit Osada, Misty und Redmatrix kommunizieren konnte. Ansonsten waren von den praktischen Features her Zap, Osada, Misty, Redmatrix und Roadhouse identisch und von der Benutzeroberfläche her auch beinahe. Es machte in der Praxis keinen großen Unterschied, welches man nutzte. Außerhalb waren sie eh, wenn überhaupt, nur auf Hubzilla bekannt. Das heißt, Roadhouse war beinahe komplett unbekannt, weil da endgültig nur Mike drüber redete.

Daß es (streams) gibt, obwohl Roadhouse doch gut war, hatte andere Gründe.

Grund 1: Mike fand einen neuen Weg, die Markenfetischisten zu trollen. Nämlich mit Software, die gar keinen Namen und gar keine Markenidentität hat. Also nahm Mike dem neuen Roadhouse-Fork von Ende 2021 den Namen und sogar den fediverseinternen festen Identifikator weg. Letzteren kann man entweder händisch ausfüllen, oder (streams) übernimmt ihn vom Instanznamen. Alleine das wäre mit einem "Debranding" von Roadhouse nicht getan gewesen, weil weiter alle von "Roadhouse" gesprochen hätten.

Grund 2: Dieses ständige Wetteifern, welche Software auf The Federation, Fediverse Observer, der FediDB usw. jetzt am populärsten ist und am meisten genutzt wird, ging ihm inzwischen auch auf dem Zeiger. Ein weiteres "Feature" von (streams) ist, daß Mike neben dem Namen und der Markenidentität auch nodeinfo praktisch komplett entfernt hat. (streams) sendet überhaupt keine Statistiken und hält sich von allen Instanzlisten-Websites fern. Und das ist so gewollt.

Grund 3: Zusätzlich wollte Mike es der Free-Software- und Open-Source-Community leichter machen. Da kloppt man sich ja bekanntlich darum, welche Lizenzen wirklich frei sind und welche nicht. Also hat Mike (streams), dessen sämtliche Vorgänger unter der MIT-Lizenz stehen, in die Public Domain gestellt. Freier als das geht's nun wirklich nicht mehr. Gleichzeitig wollte Mike diejenigen ärgern, die vielleicht vorhaben könnten, aus (streams) proprietäre, kommerzielle Closed-Source-Software zu machen. Die ganzen Apps sind nämlich durchaus schon mal Fremdcode und stehen unter eigenen Lizenzen. Und die sind untereinander inkompatibel.

(streams) sollte stabil werden und wurde stabil. Im Grunde war Mikes Plan, (streams) zu der Fediverse-Software der Zukunft zu machen. So hat er am 31.12.2022 offiziell Zap, Osada, Misty, Redmatrix und Roadhouse eingestellt. Das war aber kein Problem, denn zwischen den fünfen konnten Admins durch einfaches Rebasen nicht nur crossgraden, sondern auch zu (streams) upgraden.

Jetzt gab es nur noch Friendica, Hubzilla und (streams), wovon Mike nur noch (streams) betreute.

Dann kam ja silverpill auf Mike zu mit der Idee der nomadischen Identität über ActivityPub. Mike war interessiert. silverpill trieb das ziemlich voran inklusive dem einen oder anderen neuen FEP, darunter auch FEP-ef61, das in ActivityPub dezentrale Identitäten einführen sollte. Zot hat so etwas, Nomad natürlich auch, aber anders, und ActivityPub hatte das natürlich nicht.

Diese dezentralen Identitäten hat Mike auch in (streams) eingebaut. Langfristig sollte es ja möglich sein, zwischen verschiedenen Serveranwendungen zu klonen, so auch zwischen (streams) und Mitra. Zumindest aber sollten sie voneinander die dezentralen Identitäten als ebensolche verstehen. So sollte (streams) geklonte Mitra-Identitäten als solche erkennen, und Mitra sollte geklonte (streams)-Kanäle als solche erkennen.

Unter Laborbedingungen in Mikes nomadic-Zweig funktionierten die. Also mergete Mike im Juni 2024 den nomadic-Zweig in den dev-Zweig, den allgemeinen Entwicklungszweig. Auch der lief nur unter Laborbedingungen, weil (im Gegensatz zu Hubzilla, wo zwei öffentliche Produktivhubs Entwicklerversionen fahren) niemand außer Mike den dev-Zweig von (streams) produktiv fuhr.

Im Juli 2024 mergete Mike dann den dev-Zweig in den release-Zweig, um die neuesten Weiterentwicklungen an die produktiv gefahrenen, stabilen Server auszurollen. Da war allerdings Schluß mit Laborbedingungen. Jetzt mußten sich FEP-ef61 und die DIDs unter täglichen und breitgefächerten Realbedingungen beweisen.

Genau das taten sie nicht. Erst jetzt stellte sich heraus, daß (streams) mit den vielen Identitäten nicht klarkam. Es föderierte nicht mehr über ActivityPub. Es föderierte nicht mehr mit Hubzilla. Es föderierte nicht mal mehr mit sich selbst. Es konnte sich mit nichts mehr vernünftig verbinden.

Mike brauchte eine Weile, um überhaupt festzustellen, daß der Verursacher dieser Misere ein Identitätenchaos war. Das konnte er aber nicht auf (streams) selbst beheben. Hilfe hatte er auch keine. Die (streams)-Community war so winzig, da gab es niemanden, der ihm hätte helfen können. Der einzige, der die Fähigkeit gehabt hätte, hatte keine Zeit. Und der einzige, der Zeit und Bock hatte, hatte vom Coden keine Ahnung.

So mußte Mike sich erstmal einen Überblick verschaffen. Im August, also dem Monat nach dem Crash, als der Crash noch nicht behoben war, forkte er das streams-Repository und schuf Forte. Da wiederum riß er alles raus, was nicht ActivityPub war, also die Unterstützung sowohl von Nomad als auch von Zot6, um einen freien, ungehinderten Blick auf ActivityPub zu haben.

Inzwischen hatte er auch zwei andere Sachen gelernt: Software, die keinen Namen hat, interessiert keinen. Das verwirrt die Leute eher. Also bekam Forte wieder einen Namen. Die Public Domain brachte auch nichts. Also kam Forte wieder unter die MIT-Lizenz. Und Fediverse-Software, die überhaupt keine nodeinfo hat, ist praktisch unsichtbar. Also bekam Forte wieder nodeinfo, zunächst aber, ohne brauchbare Zahlen zu versenden. So konnte Forte zumindest vom Fediverse Observer und später vom FediIndex gelistet werden.

Forte half ihm, die ID-Misere zu entwirren, zu entflechten und zu lösen. Das reichte er dann auch nach (streams) weiter, das allmählich wieder funktionierte. Allerdings brannte er sich in dem August derart aus, daß er zum 31.8.2024 offiziell sowohl das streams-Repository als auch Forte zur Übernahme anbot und seinen Ruhestand ankündigte.

Dieses Mal fand eine Übernahme gleich gar nicht statt. Wie gesagt, in der (streams)-Community gab es niemanden, der sowohl die Zeit als auch das Know-how hatte, um auch nur Mike zu helfen, geschweige denn, eine Rolle wie Tobias oder Michael oder Mario anzunehmen.

Außerhalb von (streams) war (streams) selbst sogar auf Hubzilla kaum bekannt. Forte war sogar auf Hubzilla noch unbekannter, zumal es noch eine obskure, nichtöffentliche Bastelbude war, bis Mike im September 2024 die erste "offizielle" Entwicklerversion von Forte (und damit Forte selbst) veröffentlichte.

Und außerhalb von Hubzilla? Mike war es so leid, daß Mastodon als alternativlose Referenzimplementation des Fediverse angesehen wurde, daß er um 2023 anfing, Werbung für (streams) zu machen. Das erste Mal überhaupt, daß Mike von "wenn du es baust, werden sie kommen" abkam (es kam ja keiner) und irgendwas bewarb. Nur wußte Mike nicht, wie man zu Mastodon-Leuten spricht; ehrlich gesagt, das weiß auch auf Friendica und Hubzilla kaum jemand.

Oft genug ging aus Mikes Posts nicht mal hervor, daß er über ein konkretes Fediverse-Produkt sprach, und schon gar nicht, über welches. Wie auch, sprach er doch von etwas Namenlosem. Das heißt, auch er fing langsam an, den Namen des Repository zu verwenden. Aber er machte nicht unbedingt wirklich glasklar, daß er von etwas sprach, das jetzt in diesem Augenblick im Fediverse existierte. Schon gar nicht erwähnte er, daß es auch mit Mastodon verbunden ist, denn kaum jemand außerhalb von Mastodon weiß, daß Mastodon-Nutzer das nicht unbedingt automatisch verstehen.

Stand Mitte September 2024 hatte (streams) keine 100 aktiven Nutzer und Forte außer Mike gar keine. Traurigerweise hatte (streams) damals mehr öffentliche Server als heute, derweil Forte anderthalb Jahre gebraucht hat, um auch nur einen hervorzubringen. Wo sollen da Entwickler herkommen?

Mike hat übrigens nicht vor, (streams) einzustellen. Er und nicht nur er sagt, (streams) hat weiterhin seine Existenzberechtigung, und zwar als moderne Fediverse-Software, die von ActivityPub unabhängig ist. Er und nicht nur er sieht den ActivityPub-Schalter als eine Art letztes Bollwerk gegen Mastodon an und das einzige, das auf Kanalebene funktioniert, also nicht nur serverweit.

So, nun noch das Wort zu Smartphone-Apps.

Von Mike selbst war da nie etwas zu erwarten. Fediverse-Apps sind reine Frontend-Sachen. Und wir sollten inzwischen wissen, daß Mike nicht mal Web-UIs kann. Hubzilla ist für seine Oberfläche berüchtigt. Es ist doch erst schick geworden, als Saiwal mit seinen Utsukta-Themes anfing.

Außerdem hatte Mike immer schon genügend mit Webentwicklung zu tun. Da konnte man von ihm nicht auch noch erwarten, eine Smartphone-App zu entwickeln. Besser gesagt, zwei Smartphone-Apps, weil die iOS-App wahrscheinlich separat hätte entwickelt werden müssen. Mike wäre ja auch keiner gewesen, der in einer Smartphone-App nur das nötigste an Features eingebaut hätte. Wenn, dann alles. Er hätte also neben der Serversoftware zwei ziemliche Monster-Apps entwickeln und pflegen müssen.

Apps von Drittentwicklern?

Guck dir mal an, wie lange es gedauert hat, bis es von RaccoonForFriendica einen öffentlich verfügbaren Android-Release gab. Für iOS ist es meines Wissens bis heute nur über TestDrive verfügbar, aber nicht im App Store. Und selbst auf Android ist es noch nicht so stabil und fully featured, daß man es als Daily Driver nutzen könnte.

Für Hubzilla gab es mal Nomad für Android. Das wird seit gut sechs Jahren nicht mehr weiterentwickelt. Unter aktuellen Android-Versionen läuft es inzwischen gar nicht mehr. Und auch das ist nur ein Wrapper für die Weboberfläche, also ein glorifizierter Webbrowser. Ansonsten gibt's nur eine Minimalst-App von Mario, mit der er mal versuchsweise getestet hat, ob man von Android aus nach Hubzilla posten kann. Das ist absolut das einzige, was die App überhaupt kann.

Hubzilla hat eine Client API. Ob die aber funktioniert, ist weitestgehend unbekannt, weil noch nie jemand versucht hat, dagegen eine hinreichend mit Features ausgestattete App zu bauen. Dasselbe dürfte für (streams) und Forte gelten, für die es überhaupt noch nie irgendwelche Apps gegeben hat. Alle drei setzen statt dessen auf den Einsatz als PWA, nur daß da draußen keine Sau weiß, daß es das überhaupt gibt, geschweige denn, wie man das einrichtet.

Auf Drittentwickler kann man hier erst recht nicht hoffen. Von den Leuten im Fediverse, die Smartphone-Apps entwickeln können, kennt genau niemand Hubzilla, geschweige denn (streams) oder Forte. Selbst wenn sie Hubzilla kennenlernen würden, hätten sie keinen Bock, dafür eine App zu entwickeln. Lohnt sich nicht, weil nutzt keiner. Es lohnt sich viel mehr, die drölfzigtausendste reine Mastodon-App fürs iPhone zu bauen. Das heißt, mindestens die Hälfte von denen weiß doch sowieso nicht, was es außer Mastodon sonst noch so im Fediverse gibt.

Auf Hubzilla selbst gibt's nicht einen Mobilentwickler. Auf (streams) und Forte dürfte es niemanden geben, der überhaupt wirklich irgendwas entwickeln kann, nicht mal Webanwendungen (sonst hätte Mike Hilfe), Smartphone-Apps schon gar nicht.

#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #DFRN #Zot #Zot6 #Zot8 #Nomad #Mistpark #Friendica #RedMatrix #Hubzilla #Osada #Zap #Roadhouse #Streams #(streams) #Forte

@Kristian Na ja, Friendica war ja ausgereift. Zumindest soweit ausgereift, wie Friendica selbst und das DFRN-Protokoll es zuließen. Smartphone-Apps gab es nicht, weil man damals, 2010/2011, Smartphone-Apps für Sachen, die es auch als Websites gab, noch als Gimmicks ansah und noch nicht als lebensnotwendig. Das war, bevor die Leute gewisse Websites mehr über dedizierte Apps nutzten als über die Websites selbst.

Nur: Eine Weiterentwicklung war zwingend notwendig. Und die ging nicht mit Friendica, wie es war, denn die ging auch nicht mit DFRN.

Der Auslöser: 2011 waren binnen kurzer Zeit mehrere größere Friendica-Nodes von jetzt auf sofort ohne Ankündigung verschwunden. Einfach so weg. Friendica war durch das Verschwinden einiger weniger, aber jeweils sehr großer öffentlicher Nodes auf die Hälfte seiner Größe geschrumpft. Die andere Hälfte der Nutzer hatte alles verloren ohne die Chance, irgendwas zu retten. Die konnten wieder ganz neu bei null anfangen.

Das beste, was Mike an Friendica selbst machen konnte, war, eine Export- und Importfunktion einzubauen. Damit konnte man Backups des eigenen Konto machen. Das half aber nur, wenn man entweder brav ein tägliches Backup machte oder die Schließung eines Node vorher angekündigt wurde. Noch einmal: Genau das war 2011 nicht passiert. Die Nodes waren einfach futsch. Da hilft dir auch eine Backup-Funktion nicht, wenn du nicht laufend regelmäßig Backups machst.

Mike sah nur eine mögliche wirkliche Lösung. Und das war, indem deine Identität nicht bombenfest an einen Server gebunden ist, sondern simultan gleichzeitig als identische Klone auf mehreren unabhängigen Servern existieren kann. Wenn davon mal einer ausfällt, egal, die anderen laufen ja noch, also läuft deine Identität noch.

Problem: Mit DFRN ging das nicht umzusetzen. Es brauchte ein ganz neues Protokoll. Auch deshalb, weil Mike noch andere Verbesserungen im Kopf hatte wie ein nochmals deutlich aufgebohrtes Berechtigungssystem. Auch das ging mit DFRN so nicht und brauchte ein neues Protokoll. So entstand Zot.

Zum einen hieß ein neues Protokoll aber auch, wo auch immer das eingebaut werden soll, muß das komplette Backend ausgetauscht und neu geschrieben werden. Und große Teile des Frontend gleich mit. Das konnte Mike aber nicht auf Friendica im laufenden Betrieb machen. Friendica hätte unmöglich seine Grundfunktionalität gleichzeitig auf DFRN und auf Zot betreiben können. Und ein Protokollaustausch hätte bedeutet, daß Nodes, die die neue Friendica-Version mit Zot fahren, sich nicht mehr nativ hätten verbinden können mit Nodes, die alte Versionen mit DFRN fahren. Die wären zueinander inkompatibel gewesen.

Mike hatte als neue Entwicklungsplattform ja gerade das neue Red, das ein Fork seiner bisherigen "geheimen" Entwicklungsplattform Free-Friendika war. Das war ebenso "geheim", das konnte er also entsprechend umbauen.

Mike hätte aber niemals gleichzeitig Red komplett umbauen und Friendica selbst auf Free-Friendika weiterpflegen und die Weiterentwicklungen von Free-Friendika nach Friendica selbst bringen können. Und die einzige Alternative zum Umbau von Red auf Zot war, wieder solche Massencrashs wie 2011 mit exakt denselben Auswirkungen zu haben, ohne irgendwas tun zu können.

Also hat Mike sich auf Red konzentriert (dessen Umbau ja alleine schon länger dauern sollte als die Entwicklung von Friendica) und Friendica in die Hände von Tobias und Michael gegeben, die es seitdem nach ihren Vorstellungen weiterentwickeln. Die beiden waren ja meines Wissens sowieso schon Co-Entwickler von Friendica. Das hat Mike ja längst nicht mehr alles alleine gemacht.

Bei Red war das wieder anders. Das machte Mike ganz alleine. Das mußte er ja erstmal aufbauen. Und selbst als es fertig war, wurde es kaum angenommen. Es war zwar kein Geheimprojekt mehr, nachdem es sich von Friendica gelöst hatte. Aber es wurde kaum angenommen.

Auch als es umbenannt wurde in Red Matrix, was es leichter machte, es zu googlen, wurde es nicht angenommen. Die Friendica-Nutzer nahmen es wahr als Friendica mit nomadischer Identität. Was nomadische Identität ist, verstanden sie gar nicht. Selbst wenn doch: Die meisten von ihnen hatten inzwischen ihre eigenen privaten Einzelnutzer-Nodes.

So sahen sie in der Red Matrix gegenüber Friendica keine Vorteile, also warum umsteigen? Mal ganz davon abgesehen, daß Friendica und die Red Matrix nur über das diaspora*-Protokoll oder OStatus kommunizieren konnten. Die einzigen, die wechselten, dürften die gewesen sein, die eh immer das neueste, heißeste Zeug ausprobieren wollten.

Außerhalb von Friendica wußte eh keine Sau, daß die Red Matrix existierte. Herzlich wenige Leute wußten ja überhaupt auch nur, daß Friendica existierte. Mikes "Wenn du es baust, werden sie kommen" funktionierte damals schon nicht. Kleckerweise kamen noch neue Leute nach Friendica. Aber kaum einer ging von Friendica auf die Red Matrix, und absolut niemand ging von null auf die Red Matrix.

Interessant wurde die Red Matrix eigentlich erst 2015, als sie zu Hubzilla aufgebohrt wurde, also auf einmal Sachen konnte, die Friendica nicht konnte, die aber vielleicht nützlich sein konnten. Damit konnte Hubzilla auch für ganz andere Sachen eingesetzt werden als Friendica, also nicht nur als Facebook-Ersatz oder Blog.

Aber wenn Mario schon Anfang 2015 das noch brandneue Hubzilla übernahm, was ja so auf der offiziellen Website steht (nach meinen Informationen war es erst 2018), dann war es ein Wunder, daß Mike überhaupt jemanden fand, der übernehmen würde, der also schon seit Red-Matrix-Zeiten dabei war. Aber Mike hat ja an der Weiterentwicklung von Hubzilla noch weiter aktiv mitgewirkt, nur eben nicht als Projektleiter.

Hubzilla selbst wurde ja erst ab Ende 2015 interessant, als es seinen ersten stabilen Release hatte. Und auch Hubzillas Existenz war eigentlich nur auf Friendica bekannt. Selbst heute noch sind die allermeisten Hubzilla-Nutzer Friendica-Veteranen. Direkt von Mastodon nach Hubzilla ist kaum einer gekommen, von null nach Hubzilla schon gar nicht.

Selbst da war Mike keiner, der Sachen so läßt, wie sie sind, und sie nur noch weiter poliert. Wenn es etwas zu verbessern gibt, dann macht er das auch. Und wenn das nicht auf existierender Software im laufenden Produktivbetrieb geht, dann forkt er eben, und dann nimmt er sich weit mehr Zeit für seinen Fork als für das, was er vorher gemacht hatte. Und das ist auch gut so. Ansonsten hätten wir heute noch nur Friendica und immer noch keine Lösung für das Problem, daß die Leute alles verlieren, wenn mal wieder ein großer Node verschwindet.

Jetzt wollte Mike Zot weiterentwickeln, wohl auch deshalb, weil Zot, wie es damals war, nicht gut mit ActivityPub zusammenspielte. Aber potentiell kompatibilitätsbrechend. In einem eigenen zusätzlichen Branch von Hubzilla wäre das nicht gegangen, schon deshalb, weil Hubzilla für solche Experimente schlicht und ergreifend zu groß war.

Also hat Mike 2018 Osada von Hubzilla abgeforkt und alles rausgerissen, was im Weg war. Artikel, Karten, Wikis, Webpages, alle Verbindungsmöglichkeiten außer Zot, ActivityPub und RSS/Atom, alles raus.

Weil dann abzusehen war, daß nomadisches Zot6 (zumindest vorerst) mit ActivityPub überhaupt nicht mehr funktionieren würde, brauchte Mike zwei Projekte: Osada behielt ActivityPub, wurde aber nichtnomadisch. Zusätzlich forkte er Zap von Osada, ließ es nomadisch, entfernte aber ActivityPub.

Jetzt konnte Mike endgültig nicht gleichzeitig Zot6 entwickeln und Osada entwickeln und Zap entwickeln und Hubzilla weiterpflegen. Auch dieses Mal half ihm bei den Neuentwicklungen niemand. Also überließ er Hubzilla gänzlich Mario.

Wie es dann weiterging, lag nicht an Mikes Sprunghaftigkeit.

Anfang 2019 fand er einen Weg, auch nomadisches Zot6 mit ActivityPub kompatibel zu machen. Abgesehen davon war die Idee, einen nomadischen Zap-Kanal über einen nichtnomadischen Osada-Kanal mit dem Fediverse zu verbinden, sowieso kompletter Blödsinn und technisch in der Praxis kaum realisierbar, selbst mit Kanalquellen nicht. Also stellte Mike Osada ein, forkte von Zap ein ganz neues Osada und baute da ActivityPub-Support ein. Noch war nomadisches Zot6 + ActivityPub ja noch experimentell, deswegen hat er es nicht in Zap eingebaut.

Dann aber wurden Osada und Zap stabil und bekamen sogar einen 1.0-Release. Inzwischen gab es Leute, die Osada oder Zap produktiv nutzten. Die kamen alle von Hubzilla, denn nur da wußte man, daß es Osada und Zap gab. Nicht mal auf Friendica wußte das jemand, im übrigen Fediverse erst recht nicht und außerhalb des Fediverse schon gar nicht.

So baute Mike dann Osadas ActivityPub-Support auch in Zap ein, schaltete ihn aber standardmäßig auf Serverebene ab, auf Kanalebene sowieso. Das führte dazu, daß Osada und Zap bis auf das Branding und die Standardeinstellungen völlig identisch waren. Es brauchte gar nicht mehr beide. Mike ließ das aber so.

Irgendwie gab es wohl genug Osada- und Zap-Anwender, daß Mike jemanden fand, der beides weiterpflegen wollte. Denn Mike hatte wieder neue Weiterentwicklungen im Sinne, die er aber nicht mehr auf Osada und Zap machen konnte, weil die jetzt beide als stabile Produktivsoftware galten. So gab er Osada und Zap dann wieder an "die Community" weiter, die als quasi erste Amtshandlung mit Mikes Segen Osada nach Zap mergete, in dem Zuge auch auf Zap ActivityPub standardmäßig aktivierte und Osada kurzerhand einstellte.

2020 ging es dann weiter. Zap war damals State of the Art. Zot6 war so stabil, daß es nach Hubzilla zurückportiert wurde. Zap war jetzt quasi der modernere kleine Bruder von Hubzilla, der sich etwas eleganter bediente und einen nicht mit Features erschlug. Nur war Zap immer noch obskurer als Hubzilla, Hubzilla war obskurer als Friendica, und Friendica war selbst sehr obskur, weil für keins der drei wirklich Werbung gemacht wurde. Zap war weiterhin sonst nur auf Hubzilla bekannt und Hubzilla sonst nur auf Friendica.

Und Mike bastelte an Zot8, das nochmals besser werden sollte. Dafür brauchte er aber Software zum Experimentieren. Und so entstanden drei neue Forks in so kurzer Folge, daß heute nicht mehr bekannt ist, was jetzt wovon geforkt wurde, nur daß irgendwas von Zap geforkt worden ist. Im einzelnen waren das schon wieder ein neues Osada, ein neues Mistpark und eine neue Redmatrix.

Warum drei?

Es ging das Gerücht um, das seien verschiedene Stabilitätsstufen. Redmatrix 2020 sei experimentell mit wie früher bei Zap standardmäßig deaktiviertem ActivityPub, das damit der Entwicklung von Zot8 nicht im Wege stehe. Osada sei auch experimentell, aber wie früher schon bei Osada mit standardmäßig aktiviertem ActivityPub, um zu gucken, wie die Weiterentwicklungen von Zot8 sich mit ActivityPub vertragen. Mistpark 2020 wiederum sei "halbstabil" wie Debian testing, also stabiler als Osada und eher für den Produktiveinsatz geeignet, aber aktueller als Zap.

Zap sei also für die, die etwas neueres als Hubzilla haben wollten und auf die Zusatzfeatures von Hubzilla verzichten konnten. Misty sei für die, die etwas noch aktuelleres als Zap haben wollten, also das neueste Zeug noch früher, und die etwaige Instabilitäten in Kauf zu nehmen bereit waren. Osada sei für die, die unbedingt bleeding-edge wollten, instabil oder nicht. Und Redmatrix 2020 sei eh nur für Mike.

In Wahrheit waren Osada, Misty und Redmatrix 2020 bis auf das Branding völlig identisch und quasi Soft-Forks. Alle Commits wurden gleichermaßen und fast gleichzeitig in alle drei eingepflegt.

Warum?

Weil Mike der Markenfetischismus im Fediverse auf den Keks ging. Es gab Leute, die bildeten sich ein, die Software, die sie nutzten, sei die beste, einfach, weil sie Fans der Softwaremarke waren. Ganz besonders gab es die natürlich auf Mastodon, aber auch sonst. Genau diese Leute wollte er trollen, indem er drei bis auf den Namen und das Logo völlig identische Serveranwendungen pflegte. Misty z. B. konnte überhaupt nicht "die beste Fediverse-Serversoftware" sein, egal, wer sich das einbildete, wenn Osada und Redmatrix bis auf die Marke völlig baugleich waren.

Anfang 2021 kam dann Roadhouse dazu. Das Abenteuer Zot8 war im Grunde vorbei, bevor Zot8 stabil war. Denn Zot11 sollte noch besser werden. Vor allem sollte Zot11 von allen Zot-Versionen die beste Kompatibilität mit ActivityPub bekommen. Blöderweise konnte Mike aber Zot11 nicht auf Osada, Misty und Redmatrix entwickeln. Zot11 sollte nämlich zu allen Vorgängern so inkompatibel werden, daß es letztlich nicht mehr Zot heißen sollte. Aber es gab Leute, die Osada, Misty oder Redmatrix produktiv nutzten.

Also mußte Mike von einem von den dreien Roadhouse forken. War ihm aber egal, weil er damit die Leute mit noch einer weiteren Marke trollen konnte. Wohlgemerkt, effektiv hatte er sogar Zap noch an der Backe, weil es in der Community dann wohl doch zuwenig Interesse an der Weiterentwicklung gab.

Nomad, eigentlich ja Zot11, wurde zum Erfolg. Und das Erfolgsrezept lag auch darin, zusätzlich Support für Hubzillas Zot6 einzubauen, über den Roadhouse auch mit Osada, Misty und Redmatrix kommunizieren konnte. Ansonsten waren von den praktischen Features her Zap, Osada, Misty, Redmatrix und Roadhouse identisch und von der Benutzeroberfläche her auch beinahe. Es machte in der Praxis keinen großen Unterschied, welches man nutzte. Außerhalb waren sie eh, wenn überhaupt, nur auf Hubzilla bekannt. Das heißt, Roadhouse war beinahe komplett unbekannt, weil da endgültig nur Mike drüber redete.

Daß es (streams) gibt, obwohl Roadhouse doch gut war, hatte andere Gründe.

Grund 1: Mike fand einen neuen Weg, die Markenfetischisten zu trollen. Nämlich mit Software, die gar keinen Namen und gar keine Markenidentität hat. Also nahm Mike dem neuen Roadhouse-Fork von Ende 2021 den Namen und sogar den fediverseinternen festen Identifikator weg. Letzteren kann man entweder händisch ausfüllen, oder (streams) übernimmt ihn vom Instanznamen. Alleine das wäre mit einem "Debranding" von Roadhouse nicht getan gewesen, weil weiter alle von "Roadhouse" gesprochen hätten.

Grund 2: Dieses ständige Wetteifern, welche Software auf The Federation, Fediverse Observer, der FediDB usw. jetzt am populärsten ist und am meisten genutzt wird, ging ihm inzwischen auch auf dem Zeiger. Ein weiteres "Feature" von (streams) ist, daß Mike neben dem Namen und der Markenidentität auch nodeinfo praktisch komplett entfernt hat. (streams) sendet überhaupt keine Statistiken und hält sich von allen Instanzlisten-Websites fern. Und das ist so gewollt.

Grund 3: Zusätzlich wollte Mike es der Free-Software- und Open-Source-Community leichter machen. Da kloppt man sich ja bekanntlich darum, welche Lizenzen wirklich frei sind und welche nicht. Also hat Mike (streams), dessen sämtliche Vorgänger unter der MIT-Lizenz stehen, in die Public Domain gestellt. Freier als das geht's nun wirklich nicht mehr. Gleichzeitig wollte Mike diejenigen ärgern, die vielleicht vorhaben könnten, aus (streams) proprietäre, kommerzielle Closed-Source-Software zu machen. Die ganzen Apps sind nämlich durchaus schon mal Fremdcode und stehen unter eigenen Lizenzen. Und die sind untereinander inkompatibel.

(streams) sollte stabil werden und wurde stabil. Im Grunde war Mikes Plan, (streams) zu der Fediverse-Software der Zukunft zu machen. So hat er am 31.12.2022 offiziell Zap, Osada, Misty, Redmatrix und Roadhouse eingestellt. Das war aber kein Problem, denn zwischen den fünfen konnten Admins durch einfaches Rebasen nicht nur crossgraden, sondern auch zu (streams) upgraden.

Jetzt gab es nur noch Friendica, Hubzilla und (streams), wovon Mike nur noch (streams) betreute.

Dann kam ja silverpill auf Mike zu mit der Idee der nomadischen Identität über ActivityPub. Mike war interessiert. silverpill trieb das ziemlich voran inklusive dem einen oder anderen neuen FEP, darunter auch FEP-ef61, das in ActivityPub dezentrale Identitäten einführen sollte. Zot hat so etwas, Nomad natürlich auch, aber anders, und ActivityPub hatte das natürlich nicht.

Diese dezentralen Identitäten hat Mike auch in (streams) eingebaut. Langfristig sollte es ja möglich sein, zwischen verschiedenen Serveranwendungen zu klonen, so auch zwischen (streams) und Mitra. Zumindest aber sollten sie voneinander die dezentralen Identitäten als ebensolche verstehen. So sollte (streams) geklonte Mitra-Identitäten als solche erkennen, und Mitra sollte geklonte (streams)-Kanäle als solche erkennen.

Unter Laborbedingungen in Mikes nomadic-Zweig funktionierten die. Also mergete Mike im Juni 2024 den nomadic-Zweig in den dev-Zweig, den allgemeinen Entwicklungszweig. Auch der lief nur unter Laborbedingungen, weil (im Gegensatz zu Hubzilla, wo zwei öffentliche Produktivhubs Entwicklerversionen fahren) niemand außer Mike den dev-Zweig von (streams) produktiv fuhr.

Im Juli 2024 mergete Mike dann den dev-Zweig in den release-Zweig, um die neuesten Weiterentwicklungen an die produktiv gefahrenen, stabilen Server auszurollen. Da war allerdings Schluß mit Laborbedingungen. Jetzt mußten sich FEP-ef61 und die DIDs unter täglichen und breitgefächerten Realbedingungen beweisen.

Genau das taten sie nicht. Erst jetzt stellte sich heraus, daß (streams) mit den vielen Identitäten nicht klarkam. Es föderierte nicht mehr über ActivityPub. Es föderierte nicht mehr mit Hubzilla. Es föderierte nicht mal mehr mit sich selbst. Es konnte sich mit nichts mehr vernünftig verbinden.

Mike brauchte eine Weile, um überhaupt festzustellen, daß der Verursacher dieser Misere ein Identitätenchaos war. Das konnte er aber nicht auf (streams) selbst beheben. Hilfe hatte er auch keine. Die (streams)-Community war so winzig, da gab es niemanden, der ihm hätte helfen können. Der einzige, der die Fähigkeit gehabt hätte, hatte keine Zeit. Und der einzige, der Zeit und Bock hatte, hatte vom Coden keine Ahnung.

So mußte Mike sich erstmal einen Überblick verschaffen. Im August, also dem Monat nach dem Crash, als der Crash noch nicht behoben war, forkte er das streams-Repository und schuf Forte. Da wiederum riß er alles raus, was nicht ActivityPub war, also die Unterstützung sowohl von Nomad als auch von Zot6, um einen freien, ungehinderten Blick auf ActivityPub zu haben.

Inzwischen hatte er auch zwei andere Sachen gelernt: Software, die keinen Namen hat, interessiert keinen. Das verwirrt die Leute eher. Also bekam Forte wieder einen Namen. Die Public Domain brachte auch nichts. Also kam Forte wieder unter die MIT-Lizenz. Und Fediverse-Software, die überhaupt keine nodeinfo hat, ist praktisch unsichtbar. Also bekam Forte wieder nodeinfo, zunächst aber, ohne brauchbare Zahlen zu versenden. So konnte Forte zumindest vom Fediverse Observer und später vom FediIndex gelistet werden.

Forte half ihm, die ID-Misere zu entwirren, zu entflechten und zu lösen. Das reichte er dann auch nach (streams) weiter, das allmählich wieder funktionierte. Allerdings brannte er sich in dem August derart aus, daß er zum 31.8.2024 offiziell sowohl das streams-Repository als auch Forte zur Übernahme anbot und seinen Ruhestand ankündigte.

Dieses Mal fand eine Übernahme gleich gar nicht statt. Wie gesagt, in der (streams)-Community gab es niemanden, der sowohl die Zeit als auch das Know-how hatte, um auch nur Mike zu helfen, geschweige denn, eine Rolle wie Tobias oder Michael oder Mario anzunehmen.

Außerhalb von (streams) war (streams) selbst sogar auf Hubzilla kaum bekannt. Forte war sogar auf Hubzilla noch unbekannter, zumal es noch eine obskure, nichtöffentliche Bastelbude war, bis Mike im September 2024 die erste "offizielle" Entwicklerversion von Forte (und damit Forte selbst) veröffentlichte.

Und außerhalb von Hubzilla? Mike war es so leid, daß Mastodon als alternativlose Referenzimplementation des Fediverse angesehen wurde, daß er um 2023 anfing, Werbung für (streams) zu machen. Das erste Mal überhaupt, daß Mike von "wenn du es baust, werden sie kommen" abkam (es kam ja keiner) und irgendwas bewarb. Nur wußte Mike nicht, wie man zu Mastodon-Leuten spricht; ehrlich gesagt, das weiß auch auf Friendica und Hubzilla kaum jemand.

Oft genug ging aus Mikes Posts nicht mal hervor, daß er über ein konkretes Fediverse-Produkt sprach, und schon gar nicht, über welches. Wie auch, sprach er doch von etwas Namenlosem. Das heißt, auch er fing langsam an, den Namen des Repository zu verwenden. Aber er machte nicht unbedingt wirklich glasklar, daß er von etwas sprach, das jetzt in diesem Augenblick im Fediverse existierte. Schon gar nicht erwähnte er, daß es auch mit Mastodon verbunden ist, denn kaum jemand außerhalb von Mastodon weiß, daß Mastodon-Nutzer das nicht unbedingt automatisch verstehen.

Stand Mitte September 2024 hatte (streams) keine 100 aktiven Nutzer und Forte außer Mike gar keine. Traurigerweise hatte (streams) damals mehr öffentliche Server als heute, derweil Forte anderthalb Jahre gebraucht hat, um auch nur einen hervorzubringen. Wo sollen da Entwickler herkommen?

Mike hat übrigens nicht vor, (streams) einzustellen. Er und nicht nur er sagt, (streams) hat weiterhin seine Existenzberechtigung, und zwar als moderne Fediverse-Software, die von ActivityPub unabhängig ist. Er und nicht nur er sieht den ActivityPub-Schalter als eine Art letztes Bollwerk gegen Mastodon an und das einzige, das auf Kanalebene funktioniert, also nicht nur serverweit.

So, nun noch das Wort zu Smartphone-Apps.

Von Mike selbst war da nie etwas zu erwarten. Fediverse-Apps sind reine Frontend-Sachen. Und wir sollten inzwischen wissen, daß Mike nicht mal Web-UIs kann. Hubzilla ist für seine Oberfläche berüchtigt. Es ist doch erst schick geworden, als Saiwal mit seinen Utsukta-Themes anfing.

Außerdem hatte Mike immer schon genügend mit Webentwicklung zu tun. Da konnte man von ihm nicht auch noch erwarten, eine Smartphone-App zu entwickeln. Besser gesagt, zwei Smartphone-Apps, weil die iOS-App wahrscheinlich separat hätte entwickelt werden müssen. Mike wäre ja auch keiner gewesen, der in einer Smartphone-App nur das nötigste an Features eingebaut hätte. Wenn, dann alles. Er hätte also neben der Serversoftware zwei ziemliche Monster-Apps entwickeln und pflegen müssen.

Apps von Drittentwicklern?

Guck dir mal an, wie lange es gedauert hat, bis es von RaccoonForFriendica einen öffentlich verfügbaren Android-Release gab. Für iOS ist es meines Wissens bis heute nur über TestDrive verfügbar, aber nicht im App Store. Und selbst auf Android ist es noch nicht so stabil und fully featured, daß man es als Daily Driver nutzen könnte.

Für Hubzilla gab es mal Nomad für Android. Das wird seit gut sechs Jahren nicht mehr weiterentwickelt. Unter aktuellen Android-Versionen läuft es inzwischen gar nicht mehr. Und auch das ist nur ein Wrapper für die Weboberfläche, also ein glorifizierter Webbrowser. Ansonsten gibt's nur eine Minimalst-App von Mario, mit der er mal versuchsweise getestet hat, ob man von Android aus nach Hubzilla posten kann. Das ist absolut das einzige, was die App überhaupt kann.

Hubzilla hat eine Client API. Ob die aber funktioniert, ist weitestgehend unbekannt, weil noch nie jemand versucht hat, dagegen eine hinreichend mit Features ausgestattete App zu bauen. Dasselbe dürfte für (streams) und Forte gelten, für die es überhaupt noch nie irgendwelche Apps gegeben hat. Alle drei setzen statt dessen auf den Einsatz als PWA, nur daß da draußen keine Sau weiß, daß es das überhaupt gibt, geschweige denn, wie man das einrichtet.

Auf Drittentwickler kann man hier erst recht nicht hoffen. Von den Leuten im Fediverse, die Smartphone-Apps entwickeln können, kennt genau niemand Hubzilla, geschweige denn (streams) oder Forte. Selbst wenn sie Hubzilla kennenlernen würden, hätten sie keinen Bock, dafür eine App zu entwickeln. Lohnt sich nicht, weil nutzt keiner. Es lohnt sich viel mehr, die drölfzigtausendste reine Mastodon-App fürs iPhone zu bauen. Das heißt, mindestens die Hälfte von denen weiß doch sowieso nicht, was es außer Mastodon sonst noch so im Fediverse gibt.

Auf Hubzilla selbst gibt's nicht einen Mobilentwickler. Auf (streams) und Forte dürfte es niemanden geben, der überhaupt wirklich irgendwas entwickeln kann, nicht mal Webanwendungen (sonst hätte Mike Hilfe), Smartphone-Apps schon gar nicht.

#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #DFRN #Zot #Zot6 #Zot8 #Nomad #Mistpark #Friendica #RedMatrix #Hubzilla #Osada #Zap #Roadhouse #Streams #(streams) #Forte

@Kristian Na ja, Friendica war ja ausgereift. Zumindest soweit ausgereift, wie Friendica selbst und das DFRN-Protokoll es zuließen. Smartphone-Apps gab es nicht, weil man damals, 2010/2011, Smartphone-Apps für Sachen, die es auch als Websites gab, noch als Gimmicks ansah und noch nicht als lebensnotwendig. Das war, bevor die Leute gewisse Websites mehr über dedizierte Apps nutzten als über die Websites selbst.

Nur: Eine Weiterentwicklung war zwingend notwendig. Und die ging nicht mit Friendica, wie es war, denn die ging auch nicht mit DFRN.

Der Auslöser: 2011 waren binnen kurzer Zeit mehrere größere Friendica-Nodes von jetzt auf sofort ohne Ankündigung verschwunden. Einfach so weg. Friendica war durch das Verschwinden einiger weniger, aber jeweils sehr großer öffentlicher Nodes auf die Hälfte seiner Größe geschrumpft. Die andere Hälfte der Nutzer hatte alles verloren ohne die Chance, irgendwas zu retten. Die konnten wieder ganz neu bei null anfangen.

Das beste, was Mike an Friendica selbst machen konnte, war, eine Export- und Importfunktion einzubauen. Damit konnte man Backups des eigenen Konto machen. Das half aber nur, wenn man entweder brav ein tägliches Backup machte oder die Schließung eines Node vorher angekündigt wurde. Noch einmal: Genau das war 2011 nicht passiert. Die Nodes waren einfach futsch. Da hilft dir auch eine Backup-Funktion nicht, wenn du nicht laufend regelmäßig Backups machst.

Mike sah nur eine mögliche wirkliche Lösung. Und das war, indem deine Identität nicht bombenfest an einen Server gebunden ist, sondern simultan gleichzeitig als identische Klone auf mehreren unabhängigen Servern existieren kann. Wenn davon mal einer ausfällt, egal, die anderen laufen ja noch, also läuft deine Identität noch.

Problem: Mit DFRN ging das nicht umzusetzen. Es brauchte ein ganz neues Protokoll. Auch deshalb, weil Mike noch andere Verbesserungen im Kopf hatte wie ein nochmals deutlich aufgebohrtes Berechtigungssystem. Auch das ging mit DFRN so nicht und brauchte ein neues Protokoll. So entstand Zot.

Zum einen hieß ein neues Protokoll aber auch, wo auch immer das eingebaut werden soll, muß das komplette Backend ausgetauscht und neu geschrieben werden. Und große Teile des Frontend gleich mit. Das konnte Mike aber nicht auf Friendica im laufenden Betrieb machen. Friendica hätte unmöglich seine Grundfunktionalität gleichzeitig auf DFRN und auf Zot betreiben können. Und ein Protokollaustausch hätte bedeutet, daß Nodes, die die neue Friendica-Version mit Zot fahren, sich nicht mehr nativ hätten verbinden können mit Nodes, die alte Versionen mit DFRN fahren. Die wären zueinander inkompatibel gewesen.

Mike hatte als neue Entwicklungsplattform ja gerade das neue Red, das ein Fork seiner bisherigen "geheimen" Entwicklungsplattform Free-Friendika war. Das war ebenso "geheim", das konnte er also entsprechend umbauen.

Mike hätte aber niemals gleichzeitig Red komplett umbauen und Friendica selbst auf Free-Friendika weiterpflegen und die Weiterentwicklungen von Free-Friendika nach Friendica selbst bringen können. Und die einzige Alternative zum Umbau von Red auf Zot war, wieder solche Massencrashs wie 2011 mit exakt denselben Auswirkungen zu haben, ohne irgendwas tun zu können.

Also hat Mike sich auf Red konzentriert (dessen Umbau ja alleine schon länger dauern sollte als die Entwicklung von Friendica) und Friendica in die Hände von Tobias und Michael gegeben, die es seitdem nach ihren Vorstellungen weiterentwickeln. Die beiden waren ja meines Wissens sowieso schon Co-Entwickler von Friendica. Das hat Mike ja längst nicht mehr alles alleine gemacht.

Bei Red war das wieder anders. Das machte Mike ganz alleine. Das mußte er ja erstmal aufbauen. Und selbst als es fertig war, wurde es kaum angenommen. Es war zwar kein Geheimprojekt mehr, nachdem es sich von Friendica gelöst hatte. Aber es wurde kaum angenommen.

Auch als es umbenannt wurde in Red Matrix, was es leichter machte, es zu googlen, wurde es nicht angenommen. Die Friendica-Nutzer nahmen es wahr als Friendica mit nomadischer Identität. Was nomadische Identität ist, verstanden sie gar nicht. Selbst wenn doch: Die meisten von ihnen hatten inzwischen ihre eigenen privaten Einzelnutzer-Nodes.

So sahen sie in der Red Matrix gegenüber Friendica keine Vorteile, also warum umsteigen? Mal ganz davon abgesehen, daß Friendica und die Red Matrix nur über das diaspora*-Protokoll oder OStatus kommunizieren konnten. Die einzigen, die wechselten, dürften die gewesen sein, die eh immer das neueste, heißeste Zeug ausprobieren wollten.

Außerhalb von Friendica wußte eh keine Sau, daß die Red Matrix existierte. Herzlich wenige Leute wußten ja überhaupt auch nur, daß Friendica existierte. Mikes "Wenn du es baust, werden sie kommen" funktionierte damals schon nicht. Kleckerweise kamen noch neue Leute nach Friendica. Aber kaum einer ging von Friendica auf die Red Matrix, und absolut niemand ging von null auf die Red Matrix.

Interessant wurde die Red Matrix eigentlich erst 2015, als sie zu Hubzilla aufgebohrt wurde, also auf einmal Sachen konnte, die Friendica nicht konnte, die aber vielleicht nützlich sein konnten. Damit konnte Hubzilla auch für ganz andere Sachen eingesetzt werden als Friendica, also nicht nur als Facebook-Ersatz oder Blog.

Aber wenn Mario schon Anfang 2015 das noch brandneue Hubzilla übernahm, was ja so auf der offiziellen Website steht (nach meinen Informationen war es erst 2018), dann war es ein Wunder, daß Mike überhaupt jemanden fand, der übernehmen würde, der also schon seit Red-Matrix-Zeiten dabei war. Aber Mike hat ja an der Weiterentwicklung von Hubzilla noch weiter aktiv mitgewirkt, nur eben nicht als Projektleiter.

Hubzilla selbst wurde ja erst ab Ende 2015 interessant, als es seinen ersten stabilen Release hatte. Und auch Hubzillas Existenz war eigentlich nur auf Friendica bekannt. Selbst heute noch sind die allermeisten Hubzilla-Nutzer Friendica-Veteranen. Direkt von Mastodon nach Hubzilla ist kaum einer gekommen, von null nach Hubzilla schon gar nicht.

Selbst da war Mike keiner, der Sachen so läßt, wie sie sind, und sie nur noch weiter poliert. Wenn es etwas zu verbessern gibt, dann macht er das auch. Und wenn das nicht auf existierender Software im laufenden Produktivbetrieb geht, dann forkt er eben, und dann nimmt er sich weit mehr Zeit für seinen Fork als für das, was er vorher gemacht hatte. Und das ist auch gut so. Ansonsten hätten wir heute noch nur Friendica und immer noch keine Lösung für das Problem, daß die Leute alles verlieren, wenn mal wieder ein großer Node verschwindet.

Jetzt wollte Mike Zot weiterentwickeln, wohl auch deshalb, weil Zot, wie es damals war, nicht gut mit ActivityPub zusammenspielte. Aber potentiell kompatibilitätsbrechend. In einem eigenen zusätzlichen Branch von Hubzilla wäre das nicht gegangen, schon deshalb, weil Hubzilla für solche Experimente schlicht und ergreifend zu groß war.

Also hat Mike 2018 Osada von Hubzilla abgeforkt und alles rausgerissen, was im Weg war. Artikel, Karten, Wikis, Webpages, alle Verbindungsmöglichkeiten außer Zot, ActivityPub und RSS/Atom, alles raus.

Weil dann abzusehen war, daß nomadisches Zot6 (zumindest vorerst) mit ActivityPub überhaupt nicht mehr funktionieren würde, brauchte Mike zwei Projekte: Osada behielt ActivityPub, wurde aber nichtnomadisch. Zusätzlich forkte er Zap von Osada, ließ es nomadisch, entfernte aber ActivityPub.

Jetzt konnte Mike endgültig nicht gleichzeitig Zot6 entwickeln und Osada entwickeln und Zap entwickeln und Hubzilla weiterpflegen. Auch dieses Mal half ihm bei den Neuentwicklungen niemand. Also überließ er Hubzilla gänzlich Mario.

Wie es dann weiterging, lag nicht an Mikes Sprunghaftigkeit.

Anfang 2019 fand er einen Weg, auch nomadisches Zot6 mit ActivityPub kompatibel zu machen. Abgesehen davon war die Idee, einen nomadischen Zap-Kanal über einen nichtnomadischen Osada-Kanal mit dem Fediverse zu verbinden, sowieso kompletter Blödsinn und technisch in der Praxis kaum realisierbar, selbst mit Kanalquellen nicht. Also stellte Mike Osada ein, forkte von Zap ein ganz neues Osada und baute da ActivityPub-Support ein. Noch war nomadisches Zot6 + ActivityPub ja noch experimentell, deswegen hat er es nicht in Zap eingebaut.

Dann aber wurden Osada und Zap stabil und bekamen sogar einen 1.0-Release. Inzwischen gab es Leute, die Osada oder Zap produktiv nutzten. Die kamen alle von Hubzilla, denn nur da wußte man, daß es Osada und Zap gab. Nicht mal auf Friendica wußte das jemand, im übrigen Fediverse erst recht nicht und außerhalb des Fediverse schon gar nicht.

So baute Mike dann Osadas ActivityPub-Support auch in Zap ein, schaltete ihn aber standardmäßig auf Serverebene ab, auf Kanalebene sowieso. Das führte dazu, daß Osada und Zap bis auf das Branding und die Standardeinstellungen völlig identisch waren. Es brauchte gar nicht mehr beide. Mike ließ das aber so.

Irgendwie gab es wohl genug Osada- und Zap-Anwender, daß Mike jemanden fand, der beides weiterpflegen wollte. Denn Mike hatte wieder neue Weiterentwicklungen im Sinne, die er aber nicht mehr auf Osada und Zap machen konnte, weil die jetzt beide als stabile Produktivsoftware galten. So gab er Osada und Zap dann wieder an "die Community" weiter, die als quasi erste Amtshandlung mit Mikes Segen Osada nach Zap mergete, in dem Zuge auch auf Zap ActivityPub standardmäßig aktivierte und Osada kurzerhand einstellte.

2020 ging es dann weiter. Zap war damals State of the Art. Zot6 war so stabil, daß es nach Hubzilla zurückportiert wurde. Zap war jetzt quasi der modernere kleine Bruder von Hubzilla, der sich etwas eleganter bediente und einen nicht mit Features erschlug. Nur war Zap immer noch obskurer als Hubzilla, Hubzilla war obskurer als Friendica, und Friendica war selbst sehr obskur, weil für keins der drei wirklich Werbung gemacht wurde. Zap war weiterhin sonst nur auf Hubzilla bekannt und Hubzilla sonst nur auf Friendica.

Und Mike bastelte an Zot8, das nochmals besser werden sollte. Dafür brauchte er aber Software zum Experimentieren. Und so entstanden drei neue Forks in so kurzer Folge, daß heute nicht mehr bekannt ist, was jetzt wovon geforkt wurde, nur daß irgendwas von Zap geforkt worden ist. Im einzelnen waren das schon wieder ein neues Osada, ein neues Mistpark und eine neue Redmatrix.

Warum drei?

Es ging das Gerücht um, das seien verschiedene Stabilitätsstufen. Redmatrix 2020 sei experimentell mit wie früher bei Zap standardmäßig deaktiviertem ActivityPub, das damit der Entwicklung von Zot8 nicht im Wege stehe. Osada sei auch experimentell, aber wie früher schon bei Osada mit standardmäßig aktiviertem ActivityPub, um zu gucken, wie die Weiterentwicklungen von Zot8 sich mit ActivityPub vertragen. Mistpark 2020 wiederum sei "halbstabil" wie Debian testing, also stabiler als Osada und eher für den Produktiveinsatz geeignet, aber aktueller als Zap.

Zap sei also für die, die etwas neueres als Hubzilla haben wollten und auf die Zusatzfeatures von Hubzilla verzichten konnten. Misty sei für die, die etwas noch aktuelleres als Zap haben wollten, also das neueste Zeug noch früher, und die etwaige Instabilitäten in Kauf zu nehmen bereit waren. Osada sei für die, die unbedingt bleeding-edge wollten, instabil oder nicht. Und Redmatrix 2020 sei eh nur für Mike.

In Wahrheit waren Osada, Misty und Redmatrix 2020 bis auf das Branding völlig identisch und quasi Soft-Forks. Alle Commits wurden gleichermaßen und fast gleichzeitig in alle drei eingepflegt.

Warum?

Weil Mike der Markenfetischismus im Fediverse auf den Keks ging. Es gab Leute, die bildeten sich ein, die Software, die sie nutzten, sei die beste, einfach, weil sie Fans der Softwaremarke waren. Ganz besonders gab es die natürlich auf Mastodon, aber auch sonst. Genau diese Leute wollte er trollen, indem er drei bis auf den Namen und das Logo völlig identische Serveranwendungen pflegte. Misty z. B. konnte überhaupt nicht "die beste Fediverse-Serversoftware" sein, egal, wer sich das einbildete, wenn Osada und Redmatrix bis auf die Marke völlig baugleich waren.

Anfang 2021 kam dann Roadhouse dazu. Das Abenteuer Zot8 war im Grunde vorbei, bevor Zot8 stabil war. Denn Zot11 sollte noch besser werden. Vor allem sollte Zot11 von allen Zot-Versionen die beste Kompatibilität mit ActivityPub bekommen. Blöderweise konnte Mike aber Zot11 nicht auf Osada, Misty und Redmatrix entwickeln. Zot11 sollte nämlich zu allen Vorgängern so inkompatibel werden, daß es letztlich nicht mehr Zot heißen sollte. Aber es gab Leute, die Osada, Misty oder Redmatrix produktiv nutzten.

Also mußte Mike von einem von den dreien Roadhouse forken. War ihm aber egal, weil er damit die Leute mit noch einer weiteren Marke trollen konnte. Wohlgemerkt, effektiv hatte er sogar Zap noch an der Backe, weil es in der Community dann wohl doch zuwenig Interesse an der Weiterentwicklung gab.

Nomad, eigentlich ja Zot11, wurde zum Erfolg. Und das Erfolgsrezept lag auch darin, zusätzlich Support für Hubzillas Zot6 einzubauen, über den Roadhouse auch mit Osada, Misty und Redmatrix kommunizieren konnte. Ansonsten waren von den praktischen Features her Zap, Osada, Misty, Redmatrix und Roadhouse identisch und von der Benutzeroberfläche her auch beinahe. Es machte in der Praxis keinen großen Unterschied, welches man nutzte. Außerhalb waren sie eh, wenn überhaupt, nur auf Hubzilla bekannt. Das heißt, Roadhouse war beinahe komplett unbekannt, weil da endgültig nur Mike drüber redete.

Daß es (streams) gibt, obwohl Roadhouse doch gut war, hatte andere Gründe.

Grund 1: Mike fand einen neuen Weg, die Markenfetischisten zu trollen. Nämlich mit Software, die gar keinen Namen und gar keine Markenidentität hat. Also nahm Mike dem neuen Roadhouse-Fork von Ende 2021 den Namen und sogar den fediverseinternen festen Identifikator weg. Letzteren kann man entweder händisch ausfüllen, oder (streams) übernimmt ihn vom Instanznamen. Alleine das wäre mit einem "Debranding" von Roadhouse nicht getan gewesen, weil weiter alle von "Roadhouse" gesprochen hätten.

Grund 2: Dieses ständige Wetteifern, welche Software auf The Federation, Fediverse Observer, der FediDB usw. jetzt am populärsten ist und am meisten genutzt wird, ging ihm inzwischen auch auf dem Zeiger. Ein weiteres "Feature" von (streams) ist, daß Mike neben dem Namen und der Markenidentität auch nodeinfo praktisch komplett entfernt hat. (streams) sendet überhaupt keine Statistiken und hält sich von allen Instanzlisten-Websites fern. Und das ist so gewollt.

Grund 3: Zusätzlich wollte Mike es der Free-Software- und Open-Source-Community leichter machen. Da kloppt man sich ja bekanntlich darum, welche Lizenzen wirklich frei sind und welche nicht. Also hat Mike (streams), dessen sämtliche Vorgänger unter der MIT-Lizenz stehen, in die Public Domain gestellt. Freier als das geht's nun wirklich nicht mehr. Gleichzeitig wollte Mike diejenigen ärgern, die vielleicht vorhaben könnten, aus (streams) proprietäre, kommerzielle Closed-Source-Software zu machen. Die ganzen Apps sind nämlich durchaus schon mal Fremdcode und stehen unter eigenen Lizenzen. Und die sind untereinander inkompatibel.

(streams) sollte stabil werden und wurde stabil. Im Grunde war Mikes Plan, (streams) zu der Fediverse-Software der Zukunft zu machen. So hat er am 31.12.2022 offiziell Zap, Osada, Misty, Redmatrix und Roadhouse eingestellt. Das war aber kein Problem, denn zwischen den fünfen konnten Admins durch einfaches Rebasen nicht nur crossgraden, sondern auch zu (streams) upgraden.

Jetzt gab es nur noch Friendica, Hubzilla und (streams), wovon Mike nur noch (streams) betreute.

Dann kam ja silverpill auf Mike zu mit der Idee der nomadischen Identität über ActivityPub. Mike war interessiert. silverpill trieb das ziemlich voran inklusive dem einen oder anderen neuen FEP, darunter auch FEP-ef61, das in ActivityPub dezentrale Identitäten einführen sollte. Zot hat so etwas, Nomad natürlich auch, aber anders, und ActivityPub hatte das natürlich nicht.

Diese dezentralen Identitäten hat Mike auch in (streams) eingebaut. Langfristig sollte es ja möglich sein, zwischen verschiedenen Serveranwendungen zu klonen, so auch zwischen (streams) und Mitra. Zumindest aber sollten sie voneinander die dezentralen Identitäten als ebensolche verstehen. So sollte (streams) geklonte Mitra-Identitäten als solche erkennen, und Mitra sollte geklonte (streams)-Kanäle als solche erkennen.

Unter Laborbedingungen in Mikes nomadic-Zweig funktionierten die. Also mergete Mike im Juni 2024 den nomadic-Zweig in den dev-Zweig, den allgemeinen Entwicklungszweig. Auch der lief nur unter Laborbedingungen, weil (im Gegensatz zu Hubzilla, wo zwei öffentliche Produktivhubs Entwicklerversionen fahren) niemand außer Mike den dev-Zweig von (streams) produktiv fuhr.

Im Juli 2024 mergete Mike dann den dev-Zweig in den release-Zweig, um die neuesten Weiterentwicklungen an die produktiv gefahrenen, stabilen Server auszurollen. Da war allerdings Schluß mit Laborbedingungen. Jetzt mußten sich FEP-ef61 und die DIDs unter täglichen und breitgefächerten Realbedingungen beweisen.

Genau das taten sie nicht. Erst jetzt stellte sich heraus, daß (streams) mit den vielen Identitäten nicht klarkam. Es föderierte nicht mehr über ActivityPub. Es föderierte nicht mehr mit Hubzilla. Es föderierte nicht mal mehr mit sich selbst. Es konnte sich mit nichts mehr vernünftig verbinden.

Mike brauchte eine Weile, um überhaupt festzustellen, daß der Verursacher dieser Misere ein Identitätenchaos war. Das konnte er aber nicht auf (streams) selbst beheben. Hilfe hatte er auch keine. Die (streams)-Community war so winzig, da gab es niemanden, der ihm hätte helfen können. Der einzige, der die Fähigkeit gehabt hätte, hatte keine Zeit. Und der einzige, der Zeit und Bock hatte, hatte vom Coden keine Ahnung.

So mußte Mike sich erstmal einen Überblick verschaffen. Im August, also dem Monat nach dem Crash, als der Crash noch nicht behoben war, forkte er das streams-Repository und schuf Forte. Da wiederum riß er alles raus, was nicht ActivityPub war, also die Unterstützung sowohl von Nomad als auch von Zot6, um einen freien, ungehinderten Blick auf ActivityPub zu haben.

Inzwischen hatte er auch zwei andere Sachen gelernt: Software, die keinen Namen hat, interessiert keinen. Das verwirrt die Leute eher. Also bekam Forte wieder einen Namen. Die Public Domain brachte auch nichts. Also kam Forte wieder unter die MIT-Lizenz. Und Fediverse-Software, die überhaupt keine nodeinfo hat, ist praktisch unsichtbar. Also bekam Forte wieder nodeinfo, zunächst aber, ohne brauchbare Zahlen zu versenden. So konnte Forte zumindest vom Fediverse Observer und später vom FediIndex gelistet werden.

Forte half ihm, die ID-Misere zu entwirren, zu entflechten und zu lösen. Das reichte er dann auch nach (streams) weiter, das allmählich wieder funktionierte. Allerdings brannte er sich in dem August derart aus, daß er zum 31.8.2024 offiziell sowohl das streams-Repository als auch Forte zur Übernahme anbot und seinen Ruhestand ankündigte.

Dieses Mal fand eine Übernahme gleich gar nicht statt. Wie gesagt, in der (streams)-Community gab es niemanden, der sowohl die Zeit als auch das Know-how hatte, um auch nur Mike zu helfen, geschweige denn, eine Rolle wie Tobias oder Michael oder Mario anzunehmen.

Außerhalb von (streams) war (streams) selbst sogar auf Hubzilla kaum bekannt. Forte war sogar auf Hubzilla noch unbekannter, zumal es noch eine obskure, nichtöffentliche Bastelbude war, bis Mike im September 2024 die erste "offizielle" Entwicklerversion von Forte (und damit Forte selbst) veröffentlichte.

Und außerhalb von Hubzilla? Mike war es so leid, daß Mastodon als alternativlose Referenzimplementation des Fediverse angesehen wurde, daß er um 2023 anfing, Werbung für (streams) zu machen. Das erste Mal überhaupt, daß Mike von "wenn du es baust, werden sie kommen" abkam (es kam ja keiner) und irgendwas bewarb. Nur wußte Mike nicht, wie man zu Mastodon-Leuten spricht; ehrlich gesagt, das weiß auch auf Friendica und Hubzilla kaum jemand.

Oft genug ging aus Mikes Posts nicht mal hervor, daß er über ein konkretes Fediverse-Produkt sprach, und schon gar nicht, über welches. Wie auch, sprach er doch von etwas Namenlosem. Das heißt, auch er fing langsam an, den Namen des Repository zu verwenden. Aber er machte nicht unbedingt wirklich glasklar, daß er von etwas sprach, das jetzt in diesem Augenblick im Fediverse existierte. Schon gar nicht erwähnte er, daß es auch mit Mastodon verbunden ist, denn kaum jemand außerhalb von Mastodon weiß, daß Mastodon-Nutzer das nicht unbedingt automatisch verstehen.

Stand Mitte September 2024 hatte (streams) keine 100 aktiven Nutzer und Forte außer Mike gar keine. Traurigerweise hatte (streams) damals mehr öffentliche Server als heute, derweil Forte anderthalb Jahre gebraucht hat, um auch nur einen hervorzubringen. Wo sollen da Entwickler herkommen?

Mike hat übrigens nicht vor, (streams) einzustellen. Er und nicht nur er sagt, (streams) hat weiterhin seine Existenzberechtigung, und zwar als moderne Fediverse-Software, die von ActivityPub unabhängig ist. Er und nicht nur er sieht den ActivityPub-Schalter als eine Art letztes Bollwerk gegen Mastodon an und das einzige, das auf Kanalebene funktioniert, also nicht nur serverweit.

So, nun noch das Wort zu Smartphone-Apps.

Von Mike selbst war da nie etwas zu erwarten. Fediverse-Apps sind reine Frontend-Sachen. Und wir sollten inzwischen wissen, daß Mike nicht mal Web-UIs kann. Hubzilla ist für seine Oberfläche berüchtigt. Es ist doch erst schick geworden, als Saiwal mit seinen Utsukta-Themes anfing.

Außerdem hatte Mike immer schon genügend mit Webentwicklung zu tun. Da konnte man von ihm nicht auch noch erwarten, eine Smartphone-App zu entwickeln. Besser gesagt, zwei Smartphone-Apps, weil die iOS-App wahrscheinlich separat hätte entwickelt werden müssen. Mike wäre ja auch keiner gewesen, der in einer Smartphone-App nur das nötigste an Features eingebaut hätte. Wenn, dann alles. Er hätte also neben der Serversoftware zwei ziemliche Monster-Apps entwickeln und pflegen müssen.

Apps von Drittentwicklern?

Guck dir mal an, wie lange es gedauert hat, bis es von RaccoonForFriendica einen öffentlich verfügbaren Android-Release gab. Für iOS ist es meines Wissens bis heute nur über TestDrive verfügbar, aber nicht im App Store. Und selbst auf Android ist es noch nicht so stabil und fully featured, daß man es als Daily Driver nutzen könnte.

Für Hubzilla gab es mal Nomad für Android. Das wird seit gut sechs Jahren nicht mehr weiterentwickelt. Unter aktuellen Android-Versionen läuft es inzwischen gar nicht mehr. Und auch das ist nur ein Wrapper für die Weboberfläche, also ein glorifizierter Webbrowser. Ansonsten gibt's nur eine Minimalst-App von Mario, mit der er mal versuchsweise getestet hat, ob man von Android aus nach Hubzilla posten kann. Das ist absolut das einzige, was die App überhaupt kann.

Hubzilla hat eine Client API. Ob die aber funktioniert, ist weitestgehend unbekannt, weil noch nie jemand versucht hat, dagegen eine hinreichend mit Features ausgestattete App zu bauen. Dasselbe dürfte für (streams) und Forte gelten, für die es überhaupt noch nie irgendwelche Apps gegeben hat. Alle drei setzen statt dessen auf den Einsatz als PWA, nur daß da draußen keine Sau weiß, daß es das überhaupt gibt, geschweige denn, wie man das einrichtet.

Auf Drittentwickler kann man hier erst recht nicht hoffen. Von den Leuten im Fediverse, die Smartphone-Apps entwickeln können, kennt genau niemand Hubzilla, geschweige denn (streams) oder Forte. Selbst wenn sie Hubzilla kennenlernen würden, hätten sie keinen Bock, dafür eine App zu entwickeln. Lohnt sich nicht, weil nutzt keiner. Es lohnt sich viel mehr, die drölfzigtausendste reine Mastodon-App fürs iPhone zu bauen. Das heißt, mindestens die Hälfte von denen weiß doch sowieso nicht, was es außer Mastodon sonst noch so im Fediverse gibt.

Auf Hubzilla selbst gibt's nicht einen Mobilentwickler. Auf (streams) und Forte dürfte es niemanden geben, der überhaupt wirklich irgendwas entwickeln kann, nicht mal Webanwendungen (sonst hätte Mike Hilfe), Smartphone-Apps schon gar nicht.

#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #DFRN #Zot #Zot6 #Zot8 #Nomad #Mistpark #Friendica #RedMatrix #Hubzilla #Osada #Zap #Roadhouse #Streams #(streams) #Forte

@Kristian Na ja, Friendica war ja ausgereift. Zumindest soweit ausgereift, wie Friendica selbst und das DFRN-Protokoll es zuließen. Smartphone-Apps gab es nicht, weil man damals, 2010/2011, Smartphone-Apps für Sachen, die es auch als Websites gab, noch als Gimmicks ansah und noch nicht als lebensnotwendig. Das war, bevor die Leute gewisse Websites mehr über dedizierte Apps nutzten als über die Websites selbst.

Nur: Eine Weiterentwicklung war zwingend notwendig. Und die ging nicht mit Friendica, wie es war, denn die ging auch nicht mit DFRN.

Der Auslöser: 2011 waren binnen kurzer Zeit mehrere größere Friendica-Nodes von jetzt auf sofort ohne Ankündigung verschwunden. Einfach so weg. Friendica war durch das Verschwinden einiger weniger, aber jeweils sehr großer öffentlicher Nodes auf die Hälfte seiner Größe geschrumpft. Die andere Hälfte der Nutzer hatte alles verloren ohne die Chance, irgendwas zu retten. Die konnten wieder ganz neu bei null anfangen.

Das beste, was Mike an Friendica selbst machen konnte, war, eine Export- und Importfunktion einzubauen. Damit konnte man Backups des eigenen Konto machen. Das half aber nur, wenn man entweder brav ein tägliches Backup machte oder die Schließung eines Node vorher angekündigt wurde. Noch einmal: Genau das war 2011 nicht passiert. Die Nodes waren einfach futsch. Da hilft dir auch eine Backup-Funktion nicht, wenn du nicht laufend regelmäßig Backups machst.

Mike sah nur eine mögliche wirkliche Lösung. Und das war, indem deine Identität nicht bombenfest an einen Server gebunden ist, sondern simultan gleichzeitig als identische Klone auf mehreren unabhängigen Servern existieren kann. Wenn davon mal einer ausfällt, egal, die anderen laufen ja noch, also läuft deine Identität noch.

Problem: Mit DFRN ging das nicht umzusetzen. Es brauchte ein ganz neues Protokoll. Auch deshalb, weil Mike noch andere Verbesserungen im Kopf hatte wie ein nochmals deutlich aufgebohrtes Berechtigungssystem. Auch das ging mit DFRN so nicht und brauchte ein neues Protokoll. So entstand Zot.

Zum einen hieß ein neues Protokoll aber auch, wo auch immer das eingebaut werden soll, muß das komplette Backend ausgetauscht und neu geschrieben werden. Und große Teile des Frontend gleich mit. Das konnte Mike aber nicht auf Friendica im laufenden Betrieb machen. Friendica hätte unmöglich seine Grundfunktionalität gleichzeitig auf DFRN und auf Zot betreiben können. Und ein Protokollaustausch hätte bedeutet, daß Nodes, die die neue Friendica-Version mit Zot fahren, sich nicht mehr nativ hätten verbinden können mit Nodes, die alte Versionen mit DFRN fahren. Die wären zueinander inkompatibel gewesen.

Mike hatte als neue Entwicklungsplattform ja gerade das neue Red, das ein Fork seiner bisherigen "geheimen" Entwicklungsplattform Free-Friendika war. Das war ebenso "geheim", das konnte er also entsprechend umbauen.

Mike hätte aber niemals gleichzeitig Red komplett umbauen und Friendica selbst auf Free-Friendika weiterpflegen und die Weiterentwicklungen von Free-Friendika nach Friendica selbst bringen können. Und die einzige Alternative zum Umbau von Red auf Zot war, wieder solche Massencrashs wie 2011 mit exakt denselben Auswirkungen zu haben, ohne irgendwas tun zu können.

Also hat Mike sich auf Red konzentriert (dessen Umbau ja alleine schon länger dauern sollte als die Entwicklung von Friendica) und Friendica in die Hände von Tobias und Michael gegeben, die es seitdem nach ihren Vorstellungen weiterentwickeln. Die beiden waren ja meines Wissens sowieso schon Co-Entwickler von Friendica. Das hat Mike ja längst nicht mehr alles alleine gemacht.

Bei Red war das wieder anders. Das machte Mike ganz alleine. Das mußte er ja erstmal aufbauen. Und selbst als es fertig war, wurde es kaum angenommen. Es war zwar kein Geheimprojekt mehr, nachdem es sich von Friendica gelöst hatte. Aber es wurde kaum angenommen.

Auch als es umbenannt wurde in Red Matrix, was es leichter machte, es zu googlen, wurde es nicht angenommen. Die Friendica-Nutzer nahmen es wahr als Friendica mit nomadischer Identität. Was nomadische Identität ist, verstanden sie gar nicht. Selbst wenn doch: Die meisten von ihnen hatten inzwischen ihre eigenen privaten Einzelnutzer-Nodes.

So sahen sie in der Red Matrix gegenüber Friendica keine Vorteile, also warum umsteigen? Mal ganz davon abgesehen, daß Friendica und die Red Matrix nur über das diaspora*-Protokoll oder OStatus kommunizieren konnten. Die einzigen, die wechselten, dürften die gewesen sein, die eh immer das neueste, heißeste Zeug ausprobieren wollten.

Außerhalb von Friendica wußte eh keine Sau, daß die Red Matrix existierte. Herzlich wenige Leute wußten ja überhaupt auch nur, daß Friendica existierte. Mikes "Wenn du es baust, werden sie kommen" funktionierte damals schon nicht. Kleckerweise kamen noch neue Leute nach Friendica. Aber kaum einer ging von Friendica auf die Red Matrix, und absolut niemand ging von null auf die Red Matrix.

Interessant wurde die Red Matrix eigentlich erst 2015, als sie zu Hubzilla aufgebohrt wurde, also auf einmal Sachen konnte, die Friendica nicht konnte, die aber vielleicht nützlich sein konnten. Damit konnte Hubzilla auch für ganz andere Sachen eingesetzt werden als Friendica, also nicht nur als Facebook-Ersatz oder Blog.

Aber wenn Mario schon Anfang 2015 das noch brandneue Hubzilla übernahm, was ja so auf der offiziellen Website steht (nach meinen Informationen war es erst 2018), dann war es ein Wunder, daß Mike überhaupt jemanden fand, der übernehmen würde, der also schon seit Red-Matrix-Zeiten dabei war. Aber Mike hat ja an der Weiterentwicklung von Hubzilla noch weiter aktiv mitgewirkt, nur eben nicht als Projektleiter.

Hubzilla selbst wurde ja erst ab Ende 2015 interessant, als es seinen ersten stabilen Release hatte. Und auch Hubzillas Existenz war eigentlich nur auf Friendica bekannt. Selbst heute noch sind die allermeisten Hubzilla-Nutzer Friendica-Veteranen. Direkt von Mastodon nach Hubzilla ist kaum einer gekommen, von null nach Hubzilla schon gar nicht.

Selbst da war Mike keiner, der Sachen so läßt, wie sie sind, und sie nur noch weiter poliert. Wenn es etwas zu verbessern gibt, dann macht er das auch. Und wenn das nicht auf existierender Software im laufenden Produktivbetrieb geht, dann forkt er eben, und dann nimmt er sich weit mehr Zeit für seinen Fork als für das, was er vorher gemacht hatte. Und das ist auch gut so. Ansonsten hätten wir heute noch nur Friendica und immer noch keine Lösung für das Problem, daß die Leute alles verlieren, wenn mal wieder ein großer Node verschwindet.

Jetzt wollte Mike Zot weiterentwickeln, wohl auch deshalb, weil Zot, wie es damals war, nicht gut mit ActivityPub zusammenspielte. Aber potentiell kompatibilitätsbrechend. In einem eigenen zusätzlichen Branch von Hubzilla wäre das nicht gegangen, schon deshalb, weil Hubzilla für solche Experimente schlicht und ergreifend zu groß war.

Also hat Mike 2018 Osada von Hubzilla abgeforkt und alles rausgerissen, was im Weg war. Artikel, Karten, Wikis, Webpages, alle Verbindungsmöglichkeiten außer Zot, ActivityPub und RSS/Atom, alles raus.

Weil dann abzusehen war, daß nomadisches Zot6 (zumindest vorerst) mit ActivityPub überhaupt nicht mehr funktionieren würde, brauchte Mike zwei Projekte: Osada behielt ActivityPub, wurde aber nichtnomadisch. Zusätzlich forkte er Zap von Osada, ließ es nomadisch, entfernte aber ActivityPub.

Jetzt konnte Mike endgültig nicht gleichzeitig Zot6 entwickeln und Osada entwickeln und Zap entwickeln und Hubzilla weiterpflegen. Auch dieses Mal half ihm bei den Neuentwicklungen niemand. Also überließ er Hubzilla gänzlich Mario.

Wie es dann weiterging, lag nicht an Mikes Sprunghaftigkeit.

Anfang 2019 fand er einen Weg, auch nomadisches Zot6 mit ActivityPub kompatibel zu machen. Abgesehen davon war die Idee, einen nomadischen Zap-Kanal über einen nichtnomadischen Osada-Kanal mit dem Fediverse zu verbinden, sowieso kompletter Blödsinn und technisch in der Praxis kaum realisierbar, selbst mit Kanalquellen nicht. Also stellte Mike Osada ein, forkte von Zap ein ganz neues Osada und baute da ActivityPub-Support ein. Noch war nomadisches Zot6 + ActivityPub ja noch experimentell, deswegen hat er es nicht in Zap eingebaut.

Dann aber wurden Osada und Zap stabil und bekamen sogar einen 1.0-Release. Inzwischen gab es Leute, die Osada oder Zap produktiv nutzten. Die kamen alle von Hubzilla, denn nur da wußte man, daß es Osada und Zap gab. Nicht mal auf Friendica wußte das jemand, im übrigen Fediverse erst recht nicht und außerhalb des Fediverse schon gar nicht.

So baute Mike dann Osadas ActivityPub-Support auch in Zap ein, schaltete ihn aber standardmäßig auf Serverebene ab, auf Kanalebene sowieso. Das führte dazu, daß Osada und Zap bis auf das Branding und die Standardeinstellungen völlig identisch waren. Es brauchte gar nicht mehr beide. Mike ließ das aber so.

Irgendwie gab es wohl genug Osada- und Zap-Anwender, daß Mike jemanden fand, der beides weiterpflegen wollte. Denn Mike hatte wieder neue Weiterentwicklungen im Sinne, die er aber nicht mehr auf Osada und Zap machen konnte, weil die jetzt beide als stabile Produktivsoftware galten. So gab er Osada und Zap dann wieder an "die Community" weiter, die als quasi erste Amtshandlung mit Mikes Segen Osada nach Zap mergete, in dem Zuge auch auf Zap ActivityPub standardmäßig aktivierte und Osada kurzerhand einstellte.

2020 ging es dann weiter. Zap war damals State of the Art. Zot6 war so stabil, daß es nach Hubzilla zurückportiert wurde. Zap war jetzt quasi der modernere kleine Bruder von Hubzilla, der sich etwas eleganter bediente und einen nicht mit Features erschlug. Nur war Zap immer noch obskurer als Hubzilla, Hubzilla war obskurer als Friendica, und Friendica war selbst sehr obskur, weil für keins der drei wirklich Werbung gemacht wurde. Zap war weiterhin sonst nur auf Hubzilla bekannt und Hubzilla sonst nur auf Friendica.

Und Mike bastelte an Zot8, das nochmals besser werden sollte. Dafür brauchte er aber Software zum Experimentieren. Und so entstanden drei neue Forks in so kurzer Folge, daß heute nicht mehr bekannt ist, was jetzt wovon geforkt wurde, nur daß irgendwas von Zap geforkt worden ist. Im einzelnen waren das schon wieder ein neues Osada, ein neues Mistpark und eine neue Redmatrix.

Warum drei?

Es ging das Gerücht um, das seien verschiedene Stabilitätsstufen. Redmatrix 2020 sei experimentell mit wie früher bei Zap standardmäßig deaktiviertem ActivityPub, das damit der Entwicklung von Zot8 nicht im Wege stehe. Osada sei auch experimentell, aber wie früher schon bei Osada mit standardmäßig aktiviertem ActivityPub, um zu gucken, wie die Weiterentwicklungen von Zot8 sich mit ActivityPub vertragen. Mistpark 2020 wiederum sei "halbstabil" wie Debian testing, also stabiler als Osada und eher für den Produktiveinsatz geeignet, aber aktueller als Zap.

Zap sei also für die, die etwas neueres als Hubzilla haben wollten und auf die Zusatzfeatures von Hubzilla verzichten konnten. Misty sei für die, die etwas noch aktuelleres als Zap haben wollten, also das neueste Zeug noch früher, und die etwaige Instabilitäten in Kauf zu nehmen bereit waren. Osada sei für die, die unbedingt bleeding-edge wollten, instabil oder nicht. Und Redmatrix 2020 sei eh nur für Mike.

In Wahrheit waren Osada, Misty und Redmatrix 2020 bis auf das Branding völlig identisch und quasi Soft-Forks. Alle Commits wurden gleichermaßen und fast gleichzeitig in alle drei eingepflegt.

Warum?

Weil Mike der Markenfetischismus im Fediverse auf den Keks ging. Es gab Leute, die bildeten sich ein, die Software, die sie nutzten, sei die beste, einfach, weil sie Fans der Softwaremarke waren. Ganz besonders gab es die natürlich auf Mastodon, aber auch sonst. Genau diese Leute wollte er trollen, indem er drei bis auf den Namen und das Logo völlig identische Serveranwendungen pflegte. Misty z. B. konnte überhaupt nicht "die beste Fediverse-Serversoftware" sein, egal, wer sich das einbildete, wenn Osada und Redmatrix bis auf die Marke völlig baugleich waren.

Anfang 2021 kam dann Roadhouse dazu. Das Abenteuer Zot8 war im Grunde vorbei, bevor Zot8 stabil war. Denn Zot11 sollte noch besser werden. Vor allem sollte Zot11 von allen Zot-Versionen die beste Kompatibilität mit ActivityPub bekommen. Blöderweise konnte Mike aber Zot11 nicht auf Osada, Misty und Redmatrix entwickeln. Zot11 sollte nämlich zu allen Vorgängern so inkompatibel werden, daß es letztlich nicht mehr Zot heißen sollte. Aber es gab Leute, die Osada, Misty oder Redmatrix produktiv nutzten.

Also mußte Mike von einem von den dreien Roadhouse forken. War ihm aber egal, weil er damit die Leute mit noch einer weiteren Marke trollen konnte. Wohlgemerkt, effektiv hatte er sogar Zap noch an der Backe, weil es in der Community dann wohl doch zuwenig Interesse an der Weiterentwicklung gab.

Nomad, eigentlich ja Zot11, wurde zum Erfolg. Und das Erfolgsrezept lag auch darin, zusätzlich Support für Hubzillas Zot6 einzubauen, über den Roadhouse auch mit Osada, Misty und Redmatrix kommunizieren konnte. Ansonsten waren von den praktischen Features her Zap, Osada, Misty, Redmatrix und Roadhouse identisch und von der Benutzeroberfläche her auch beinahe. Es machte in der Praxis keinen großen Unterschied, welches man nutzte. Außerhalb waren sie eh, wenn überhaupt, nur auf Hubzilla bekannt. Das heißt, Roadhouse war beinahe komplett unbekannt, weil da endgültig nur Mike drüber redete.

Daß es (streams) gibt, obwohl Roadhouse doch gut war, hatte andere Gründe.

Grund 1: Mike fand einen neuen Weg, die Markenfetischisten zu trollen. Nämlich mit Software, die gar keinen Namen und gar keine Markenidentität hat. Also nahm Mike dem neuen Roadhouse-Fork von Ende 2021 den Namen und sogar den fediverseinternen festen Identifikator weg. Letzteren kann man entweder händisch ausfüllen, oder (streams) übernimmt ihn vom Instanznamen. Alleine das wäre mit einem "Debranding" von Roadhouse nicht getan gewesen, weil weiter alle von "Roadhouse" gesprochen hätten.

Grund 2: Dieses ständige Wetteifern, welche Software auf The Federation, Fediverse Observer, der FediDB usw. jetzt am populärsten ist und am meisten genutzt wird, ging ihm inzwischen auch auf dem Zeiger. Ein weiteres "Feature" von (streams) ist, daß Mike neben dem Namen und der Markenidentität auch nodeinfo praktisch komplett entfernt hat. (streams) sendet überhaupt keine Statistiken und hält sich von allen Instanzlisten-Websites fern. Und das ist so gewollt.

Grund 3: Zusätzlich wollte Mike es der Free-Software- und Open-Source-Community leichter machen. Da kloppt man sich ja bekanntlich darum, welche Lizenzen wirklich frei sind und welche nicht. Also hat Mike (streams), dessen sämtliche Vorgänger unter der MIT-Lizenz stehen, in die Public Domain gestellt. Freier als das geht's nun wirklich nicht mehr. Gleichzeitig wollte Mike diejenigen ärgern, die vielleicht vorhaben könnten, aus (streams) proprietäre, kommerzielle Closed-Source-Software zu machen. Die ganzen Apps sind nämlich durchaus schon mal Fremdcode und stehen unter eigenen Lizenzen. Und die sind untereinander inkompatibel.

(streams) sollte stabil werden und wurde stabil. Im Grunde war Mikes Plan, (streams) zu der Fediverse-Software der Zukunft zu machen. So hat er am 31.12.2022 offiziell Zap, Osada, Misty, Redmatrix und Roadhouse eingestellt. Das war aber kein Problem, denn zwischen den fünfen konnten Admins durch einfaches Rebasen nicht nur crossgraden, sondern auch zu (streams) upgraden.

Jetzt gab es nur noch Friendica, Hubzilla und (streams), wovon Mike nur noch (streams) betreute.

Dann kam ja silverpill auf Mike zu mit der Idee der nomadischen Identität über ActivityPub. Mike war interessiert. silverpill trieb das ziemlich voran inklusive dem einen oder anderen neuen FEP, darunter auch FEP-ef61, das in ActivityPub dezentrale Identitäten einführen sollte. Zot hat so etwas, Nomad natürlich auch, aber anders, und ActivityPub hatte das natürlich nicht.

Diese dezentralen Identitäten hat Mike auch in (streams) eingebaut. Langfristig sollte es ja möglich sein, zwischen verschiedenen Serveranwendungen zu klonen, so auch zwischen (streams) und Mitra. Zumindest aber sollten sie voneinander die dezentralen Identitäten als ebensolche verstehen. So sollte (streams) geklonte Mitra-Identitäten als solche erkennen, und Mitra sollte geklonte (streams)-Kanäle als solche erkennen.

Unter Laborbedingungen in Mikes nomadic-Zweig funktionierten die. Also mergete Mike im Juni 2024 den nomadic-Zweig in den dev-Zweig, den allgemeinen Entwicklungszweig. Auch der lief nur unter Laborbedingungen, weil (im Gegensatz zu Hubzilla, wo zwei öffentliche Produktivhubs Entwicklerversionen fahren) niemand außer Mike den dev-Zweig von (streams) produktiv fuhr.

Im Juli 2024 mergete Mike dann den dev-Zweig in den release-Zweig, um die neuesten Weiterentwicklungen an die produktiv gefahrenen, stabilen Server auszurollen. Da war allerdings Schluß mit Laborbedingungen. Jetzt mußten sich FEP-ef61 und die DIDs unter täglichen und breitgefächerten Realbedingungen beweisen.

Genau das taten sie nicht. Erst jetzt stellte sich heraus, daß (streams) mit den vielen Identitäten nicht klarkam. Es föderierte nicht mehr über ActivityPub. Es föderierte nicht mehr mit Hubzilla. Es föderierte nicht mal mehr mit sich selbst. Es konnte sich mit nichts mehr vernünftig verbinden.

Mike brauchte eine Weile, um überhaupt festzustellen, daß der Verursacher dieser Misere ein Identitätenchaos war. Das konnte er aber nicht auf (streams) selbst beheben. Hilfe hatte er auch keine. Die (streams)-Community war so winzig, da gab es niemanden, der ihm hätte helfen können. Der einzige, der die Fähigkeit gehabt hätte, hatte keine Zeit. Und der einzige, der Zeit und Bock hatte, hatte vom Coden keine Ahnung.

So mußte Mike sich erstmal einen Überblick verschaffen. Im August, also dem Monat nach dem Crash, als der Crash noch nicht behoben war, forkte er das streams-Repository und schuf Forte. Da wiederum riß er alles raus, was nicht ActivityPub war, also die Unterstützung sowohl von Nomad als auch von Zot6, um einen freien, ungehinderten Blick auf ActivityPub zu haben.

Inzwischen hatte er auch zwei andere Sachen gelernt: Software, die keinen Namen hat, interessiert keinen. Das verwirrt die Leute eher. Also bekam Forte wieder einen Namen. Die Public Domain brachte auch nichts. Also kam Forte wieder unter die MIT-Lizenz. Und Fediverse-Software, die überhaupt keine nodeinfo hat, ist praktisch unsichtbar. Also bekam Forte wieder nodeinfo, zunächst aber, ohne brauchbare Zahlen zu versenden. So konnte Forte zumindest vom Fediverse Observer und später vom FediIndex gelistet werden.

Forte half ihm, die ID-Misere zu entwirren, zu entflechten und zu lösen. Das reichte er dann auch nach (streams) weiter, das allmählich wieder funktionierte. Allerdings brannte er sich in dem August derart aus, daß er zum 31.8.2024 offiziell sowohl das streams-Repository als auch Forte zur Übernahme anbot und seinen Ruhestand ankündigte.

Dieses Mal fand eine Übernahme gleich gar nicht statt. Wie gesagt, in der (streams)-Community gab es niemanden, der sowohl die Zeit als auch das Know-how hatte, um auch nur Mike zu helfen, geschweige denn, eine Rolle wie Tobias oder Michael oder Mario anzunehmen.

Außerhalb von (streams) war (streams) selbst sogar auf Hubzilla kaum bekannt. Forte war sogar auf Hubzilla noch unbekannter, zumal es noch eine obskure, nichtöffentliche Bastelbude war, bis Mike im September 2024 die erste "offizielle" Entwicklerversion von Forte (und damit Forte selbst) veröffentlichte.

Und außerhalb von Hubzilla? Mike war es so leid, daß Mastodon als alternativlose Referenzimplementation des Fediverse angesehen wurde, daß er um 2023 anfing, Werbung für (streams) zu machen. Das erste Mal überhaupt, daß Mike von "wenn du es baust, werden sie kommen" abkam (es kam ja keiner) und irgendwas bewarb. Nur wußte Mike nicht, wie man zu Mastodon-Leuten spricht; ehrlich gesagt, das weiß auch auf Friendica und Hubzilla kaum jemand.

Oft genug ging aus Mikes Posts nicht mal hervor, daß er über ein konkretes Fediverse-Produkt sprach, und schon gar nicht, über welches. Wie auch, sprach er doch von etwas Namenlosem. Das heißt, auch er fing langsam an, den Namen des Repository zu verwenden. Aber er machte nicht unbedingt wirklich glasklar, daß er von etwas sprach, das jetzt in diesem Augenblick im Fediverse existierte. Schon gar nicht erwähnte er, daß es auch mit Mastodon verbunden ist, denn kaum jemand außerhalb von Mastodon weiß, daß Mastodon-Nutzer das nicht unbedingt automatisch verstehen.

Stand Mitte September 2024 hatte (streams) keine 100 aktiven Nutzer und Forte außer Mike gar keine. Traurigerweise hatte (streams) damals mehr öffentliche Server als heute, derweil Forte anderthalb Jahre gebraucht hat, um auch nur einen hervorzubringen. Wo sollen da Entwickler herkommen?

Mike hat übrigens nicht vor, (streams) einzustellen. Er und nicht nur er sagt, (streams) hat weiterhin seine Existenzberechtigung, und zwar als moderne Fediverse-Software, die von ActivityPub unabhängig ist. Er und nicht nur er sieht den ActivityPub-Schalter als eine Art letztes Bollwerk gegen Mastodon an und das einzige, das auf Kanalebene funktioniert, also nicht nur serverweit.

So, nun noch das Wort zu Smartphone-Apps.

Von Mike selbst war da nie etwas zu erwarten. Fediverse-Apps sind reine Frontend-Sachen. Und wir sollten inzwischen wissen, daß Mike nicht mal Web-UIs kann. Hubzilla ist für seine Oberfläche berüchtigt. Es ist doch erst schick geworden, als Saiwal mit seinen Utsukta-Themes anfing.

Außerdem hatte Mike immer schon genügend mit Webentwicklung zu tun. Da konnte man von ihm nicht auch noch erwarten, eine Smartphone-App zu entwickeln. Besser gesagt, zwei Smartphone-Apps, weil die iOS-App wahrscheinlich separat hätte entwickelt werden müssen. Mike wäre ja auch keiner gewesen, der in einer Smartphone-App nur das nötigste an Features eingebaut hätte. Wenn, dann alles. Er hätte also neben der Serversoftware zwei ziemliche Monster-Apps entwickeln und pflegen müssen.

Apps von Drittentwicklern?

Guck dir mal an, wie lange es gedauert hat, bis es von RaccoonForFriendica einen öffentlich verfügbaren Android-Release gab. Für iOS ist es meines Wissens bis heute nur über TestDrive verfügbar, aber nicht im App Store. Und selbst auf Android ist es noch nicht so stabil und fully featured, daß man es als Daily Driver nutzen könnte.

Für Hubzilla gab es mal Nomad für Android. Das wird seit gut sechs Jahren nicht mehr weiterentwickelt. Unter aktuellen Android-Versionen läuft es inzwischen gar nicht mehr. Und auch das ist nur ein Wrapper für die Weboberfläche, also ein glorifizierter Webbrowser. Ansonsten gibt's nur eine Minimalst-App von Mario, mit der er mal versuchsweise getestet hat, ob man von Android aus nach Hubzilla posten kann. Das ist absolut das einzige, was die App überhaupt kann.

Hubzilla hat eine Client API. Ob die aber funktioniert, ist weitestgehend unbekannt, weil noch nie jemand versucht hat, dagegen eine hinreichend mit Features ausgestattete App zu bauen. Dasselbe dürfte für (streams) und Forte gelten, für die es überhaupt noch nie irgendwelche Apps gegeben hat. Alle drei setzen statt dessen auf den Einsatz als PWA, nur daß da draußen keine Sau weiß, daß es das überhaupt gibt, geschweige denn, wie man das einrichtet.

Auf Drittentwickler kann man hier erst recht nicht hoffen. Von den Leuten im Fediverse, die Smartphone-Apps entwickeln können, kennt genau niemand Hubzilla, geschweige denn (streams) oder Forte. Selbst wenn sie Hubzilla kennenlernen würden, hätten sie keinen Bock, dafür eine App zu entwickeln. Lohnt sich nicht, weil nutzt keiner. Es lohnt sich viel mehr, die drölfzigtausendste reine Mastodon-App fürs iPhone zu bauen. Das heißt, mindestens die Hälfte von denen weiß doch sowieso nicht, was es außer Mastodon sonst noch so im Fediverse gibt.

Auf Hubzilla selbst gibt's nicht einen Mobilentwickler. Auf (streams) und Forte dürfte es niemanden geben, der überhaupt wirklich irgendwas entwickeln kann, nicht mal Webanwendungen (sonst hätte Mike Hilfe), Smartphone-Apps schon gar nicht.

#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #DFRN #Zot #Zot6 #Zot8 #Nomad #Mistpark #Friendica #RedMatrix #Hubzilla #Osada #Zap #Roadhouse #Streams #(streams) #Forte

@Gaming on the Fediverse That's quite a bit simplified. For one, four server applications and one protocol were lumped together. Besides, Zap is dead, and Forte isn't even mentioned.

So here's an attempt at telling the whole story (server applications are in bold type, protocols are in bold type and italics):

tl;dr:

2010:

• DFRN
• Mistpark/Friendika/Friendica
  (DFRN)

2011:

• Zot
• Free-Friendika
  (DFRN)
  (forked from Friendika)
• several other Friendika forks
  (DFRN)
  (forked from Friendika)
  (discontinued 2011)
• Red/Red Matrix
  (DFRN, from 2012 Zot)
  (forked from Free-Friendika)
  (rebuilt into Hubzilla 2015)

2015:

• Hubzilla
  (Zot, later Zot6)
  (rebuilt from the Red Matrix)

2018:

Zot6
• Osada
  (Zot6)
  (forked from Hubzilla)
  (discontinued in 2018)
• Zap
  (Zot6)
  (forked most likely from Osada, maybe from Hubzilla)
  (discontinued in 2022)
• Osada
  (Zot6)
  (forked from Zap)
  (discontinued in 2019)

2020:

Zot8
• Redmatrix 2020
  (Zot8)
  (forked from either Zap or Mistpark 2020 or (the third) Osada)
  (discontinued in 2022)
• Mistpark 2020 a.k.a. Misty
  (Zot8)
  (forked from either Zap or Redmatrix 2020 or (the third) Osada)
  (discontinued in 2022)
• Osada
  (Zot8)
  (forked from either Zap or Redmatrix 2020 or Mistpark 2020)
  (discontinued in 2022)

2022:

• Nomad
  (originally Zot11)
• Roadhouse
  (Nomad)
  (forked from either Redmatrix 2020 or Mistpark 2020 or (the third) Osada)
  (discontinued in 2022)
• (streams)
  (Nomad)
  (forked from Roadhouse)

2024:
Forte
(ActivityPub)
(forked from (streams))[/list]
So as far as Fediverse server applications go, he created Friendica, Free-Friendika, a few more Friendika forks, the Red Matrix, Hubzilla, three Osadas, Zap, Redmatrix 2020, Mistpark 2020, Roadhouse, (streams) and Forte. Depending on how you want to count them, that's at least 13 or 14 server applications. Four of these are still being maintained (Friendica by a new team, Hubzilla by another new team, (streams) and Forte by himself).

The long version:

In 2010, he created

• the DFRN protocol
• Mistpark (renamed first into Friendika later in 2010 and then into Friendica in 2011)

In 2011, he made several forks of Friendika. The reason was licensing: Friendika was getting quite some attention. As it was under the MIT license, chances were that it was tempting to fork it and turn the fork into a commercial, proprietary, closed-source monolith or something. On the other hand, the GPL in any shape or form would have hindered further development.

So Mike made a number of forks and relicensed all but one: Free-Friendika kept the MIT license and became the main development platform for Friendika. Friendika itself was relicensed under the AGPLv3.

Shortly afterwards, Mike discontinued all forks except Free-Friendika.

The same year, Mike needed something to keep people from losing everything whenever their Friendika home node was shut down. So he invented nomadic identity and created the Zot protocol.

Also the same year, Mike forked Free-Friendika into Red (spanish la red = the network). It would be renamed Red Matrix in late 2012 because "Red" is hard to Google.

In 2012, Mike rewrote Red almost completely. The whole backend was rebuilt against Zot.

However, the Red Matrix didn't take off. Most Friendica users were hosting their own private nodes. Nomadic identity made no sense for them. Besides, it seemed like many Friendica users didn't understand nomadic identity anyway, so they saw no advantage in the Red Matrix over Friendica, seeing as the features were almost identical otherwise. The Red Matrix had to be made more popular for hosting public servers.

So in 2015, the Red Matrix was rebuilt and greatly expanded into Hubzilla.

In 2018, Mike wanted to develop the Zot protocol further into Zot6. But this would have meant compatibility-breaking changes, also because what he wanted to do with nomadic identity over Zot6 was likely to not work with non-nomadic protocols anymore. So he couldn't do that on Hubzilla.

Instead, he made two new forks:

• first Osada, forked from Hubzilla, which was the original Zot6 development platform and then evolved into a non-nomadic "gateway" between Zot6 and everything else
• then Zap, forked most likely from Osada or maybe from Hubzilla, which got the whole Zot6 feature set, including nomadic identity, but which lost support for any and all non-nomadic protocols

A bit later, Zot6 became compatible enough with non-nomadic protocols. Forwarding content from Zap via Osada to the rest of the Fediverse was clunky anyway, forwarding content from the rest of the Fediverse via Osada to Zap even more so. So Osada was discontinued.

Instead, a new Osada was forked from Zap and got ActivityPub support. This and the branding were the only differences between Osada and Zap.

In 2019, when both Osada and Zap had become stable, Zap got ActivityPub support itself. The only difference between the two was now that Osada servers had ActivityPub turned on by default, and Zap servers had it turned off by default. It simply didn't make much sense to keep both alive, so Osada was discontinued again.

I think it was also in 2019 that Hubzilla was upgraded to Zot6.

In 2020, Mike made three more forks to develop Zot8, at least one of which was forked from Zap, and those that weren't were forked from one another: Redmatrix 2020, Mistpark 2020 a.k.a. Misty and Osada.

There was a rumour that Zap was the stable one, Misty was a bit more up-to-date, but potentially less stable, Osada was experimental with ActivityPub support on by default, and Redmatrix 2020 was experimental with ActivityPub support off by default. In fact, however, Misty, Osada and Redmatrix 2020 were absolutely identical in all but branding. Mike kept four server applications around to mess with brand fetishists.

In 2022, Mike forked one of the three into Roadhouse to develop Zot11. But Zot11 was no longer compatible with Zot6 as implemented on Hubzilla and Zap, so he declared it a new protocol named Nomad. Roadhouse got additional support for Zot6.

Now Mike had five server applications, still in order to mess with brand fetishists.

Later the same year, Mike forked Roadhouse into something intentionally nameless and brandless. Again, this was done to troll brand fetishists, this time also to facilitate forking and make people think up their own individual names for the fork rather than keeping the existing one. However, the code repository absolutely required a name, so Mike called it streams.

The community needed something to name this nameless thing by, so they took the name of the repository and wrapped it in parentheses to make sure that this is not actually the name. Ever since, it is colloquially being called (streams). By the way, (streams) is running on what would be Zot12 if it wasn't Nomad now.

On New Year's Eve 2022, Mike discontinued Zap, Redmatrix 2020, Misty, Osada and Roadhouse. (streams) was stable enough, and the other five could be upgraded not only to each other by rebasing the server code, but also to (streams). He asked all admins of Zap, Redmatrix 2020, Misty, Osada and Roadhouse servers to upgrade to (streams).

In 2024, (streams) got bogged down by some identity confusion after the stable release branch introduced decentralised IDs as per FEP-ef61, a part of the development of nomadic identity via ActivityPub. Partially in order to be able to sort this out, partially because the time seemed to have come for this to actually work, Mike forked the streams repository into Forte and removed all support for any protocols other than ActivityPub while still keeping it nomadic. And so Forte became the very first Fediverse server application that establishes nomadic identity via ActivityPub.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #DFRN #Zot #Zot6 #Zot8 #Nomad #Mistpark #Friendika #FreeFriendika #Friendica #Red #RedMatrix #Hubzilla #Osada #Zap #Redmatrix2020 #Mistpark2020 #Misty #Roadhouse #Streams #(streams) #Forte

The Fediverse is the network and #DFRN is one of its networks

Fediversums Facebook -Friendica

Friendica är integrerad del av Fediversum, precis som Mastodon eller Pixelfed, GNU Social och WordPress. Men programmet kan även kommunicera med Bluesky, Diaspora och flera andra sociala medier och plattformar.

https://fedinyheter.nyhetskartan.se/fediversums-facebook-friendica/

@cy

The people who wrote the Fediverse

There were no "people who wrote the Fediverse". These was no committee who laid down the standards.

The Fediverse was invented by @Evan Prodromou. In 2008. By first creating a centralised Twitter alternative silo named Identi.ca.

And then open-sourcing the underlying technology as Laconi.ca, later StatusNet (merged into GNU social in 2013).

And then laying the protocol open as OpenMicroBlogging, later superseded by OStatus.

Then, in 2010, @Mike Macgirvin ?️ decided that the world needs a free, open-source, decentralised, secure alternative to Facebook that's better than Facebook. And so he made Mistpark, today Friendica.

But the features he wanted Friendica to have were impossible to achieve with any existing protocol. OStatus wasn't even that good for microblogging, much less Mike's ambitious plans. Besides, he's an experienced protocol designer. So he created a whole new protocol, DFRN, and built Friendica on top of it. Friendica did adopt OStatus as an extra protocol, though, because Friendica's goal was and still is to federate with everything and then some.

In 2011, Mike had seen many public Friendica nodes shut down with or without warning and people always losing everything and having to start over from scratch. So he decided to do something against it.

He invented nomadic identity. And built a new protocol around it, Zot, because there was no way DFRN could take care of this, let alone OStatus.

In 2012, he forked Friendica into Red and rewrote the whole backend against Zot, which, however, required the creation of yet another identity scheme.

For one, one login could now have multiple fully separate and independent identities on it. For example, my Hubzilla channel URL is https://hub.netzgemeinde.eu/channel/jupiter_rowland.

Besides, one identity could now reside on multiple server instances which is what nomadic identity means.

Red was later renamed Red Matrix and, in 2015, refactored, redesigned and renamed into Hubzilla.

Mastodon and Pleroma started in 2016 as OStatus-based alternative UIs for GNU social. Mastodon was the first to be turned into a stand-alone project with not much interest in connecting to anything outside, all in spite of already being federated with Pleroma, GNU social, Friendica and Hubzilla via OStatus.

ActivityPub came out in 2017. No, not 2018. It was standardised in 2018. But it came out in 2017.

In July, 2017, Hubzilla was the first Fediverse project to integrate ActivityPub. Next to its own Zot, next to diaspora*, next to OStatus etc. On the one hand, Hubzilla tried to stay as close to the ActivityPub spec as possible and feasible. On the other hand, Hubzilla had to make its ActivityPub integration, which has always been an optional add-on, compatible to its own technology, to its own Zot protocol, to the way it works.

In September, Mastodon was the second Fediverse project to adopt ActivityPub. But Mastodon was more interested in doing its own thing and being as close to Twitter as it could than in sticking to a protocol spec, much less connecting to non-Mastodon stuff such as Hubzilla with which it already shared two protocols now.

Mastodon was the one that added Webfinger. ActivityPub doesn't even require Webfinger. The ActivityPub spec doesn't contain Webfinger. But Mastodon requires Webfinger. It can't live without Webfinger. So everything that wants to properly federate with Mastodon needs to implement Webfinger.

After ActivityPub had become a standard, more projects adopted it. But as lax a specification as ActivityPub is, it allowed for a lot of liberties.

Some devs looked at how Mastodon had integrated ActivityPub, decided it was rubbish and did it their own way.

Some devs looked at how Mastodon had integrated ActivityPub, decided they couldn't do it the same way because what they did was too different from Mastodon and did it their own way.

Some devs didn't look at what anyone else did and did it their own way.

Probably none of them looked at how Hubzilla had integrated ActivityPub because none of them even knew that Hubzilla existed. Except for those who were maintaining Friendica now. And Friendica had to make it compatible with DFRN and with the way it had been working since 2010.

Fast-forward to 2023. Mike's current piece of work was the streams repository which contains an intentionally nameless fork of a fork of three forks of a fork (of a fork) of Hubzilla, slimmed down from Hubzilla, but modernised and technologically even more advanced.

It was then that @silverpill, creator and maintainer of Mitra, got into contact with him because he wanted to add nomadic identity to Mitra. Something that's built on ActivityPub and only supports ActivityPub. A first. No-one had ever done nomadic identity with nothing but ActivityPub before.

So the two started working on how to implement nomadic identity using only ActivityPub. Mike had a vision of a Fediverse with nomadic identity all over and Fediverse identities cloned beyond server application borders. Like, a (streams) channel cloned to Mitra, Mastodon, PeerTube and Mobilizon, all with the same identity.

This, however, required another, brand-new way of identifying Fediverse actors. And so FEP-ef61 "Portable Objects" was created.

We're probably in the middle of xkcd 927 now.

Mike set up an experimental branch of (streams) to develop and test nomadic identity via ActivityPub, also since (streams) already had nomadic identity anyway.

Around summer, the "nomadic" branch (for nomadic identity via ActivityPub) seemed reliable enough to merge it into "dev". And in July, "dev" was merged into "release", complete with nomadic-identity-via-ActivityPub code.

It was shortly after that merge that I created my two (streams) channels. The channel URL of my channel for Fediverse memes is https://streams.elsmussols.net/channel/fedimemes_on_streams. But its DID, which all channels created on accounts registered after that merge got, is https://streams.elsmussols.net/.well-known/apgateway/did:⁠key:z6Mkf2dhUa65zBYCNVqs3AHyt8uPixauZ7bPzEJn15LJANsd/actor. And that's only two IDs of the same channel. There are also others for (streams)' native Nomad protocol, Hubzilla's Zot6 protocol, ActivityPub, OAuth, OAuth2 and probably also OpenWebAuth magic single sign-on, another one of Mike's creations. Not to mention that (streams) channels, like Hubzilla channels and Friendica accounts, can also optionally be group actors.

In fact, this blew up into (streams) users' faces because (streams) confused the various IDs to such degrees that it wouldn't federate at all anymore. It took Mike a whole lot of work to iron this out again, so much that he officially retired from Fediverse development on August 31st.

And in the middle of this, he even created yet another fork, Forte, which is (streams) minus Nomad, minus Zot6, based on and supporting only ActivityPub. My guess is still that one of the reasons to create Forte at that point was to get rid of the Nomad and Zot6 IDs to sort the ID mess out.

Even if nomadic identity via ActivityPub should ever become stable and start spreading, I don't expect DIDs to become the one norm in the Fediverse. Not with all those barely or unmaintained projects and those devs who refuse to acknowledge that devs of other projects do great stuff, too.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #OStatus #DFRN #Zot #ActivityPub #Nomad #Laconi.ca #Identi.ca #StatusNet #GNUsocial #Friendica #Hubzilla #Mastodon #Pleroma #Streams #(streams) #Forte #FEP_ef61

@David Lohner Nein.

Denn Hubzilla basiert nicht auf ActivityPub. Es basiert auf Zot. ActivityPub ist zwar seit Juli 2017 verfügbar. Hubzilla hatte es zuerst, zwei Monate vor Mastodon. Aber es ist ein Add-on, es ist optional, standardmäßig ist es auf Nutzerseite sogar deaktiviert, und es kann für ganze Hubs (= Serverinstanzen) deaktiviert werden. Und selbst mit deaktiviertem ActivityPub wäre Hubzilla immer noch föderiert.

Wenn Hubzilla qua Basisprotokoll nicht Teil des Fediverse wäre, würde ich dir jetzt von außerhalb des Fediverse antworten.

Auch (streams) basiert nicht auf ActivityPub, sondern auf Nomad, einer Weiterentwicklung von Zot, nur daß hier ActivityPub in den Kern eingebaut und standardmäßig aktiviert ist. Aber es kann im Gegensatz zu Nomad abgeschaltet werden.

Und soweit ich das mitbekommen habe, hat auch Friendica erst 2023 von seinem eigenen DFRN als Basisprotokoll auf ActivityPub umgestellt, das es schon seit 2019 unterstützt.

Gemäß der Definition "Fediverse = ActivityPub als Basisprotokoll" gehört Friendica also erst seit der Umstellung auf ActivityPub dazu und nicht schon seit 2010, und Hubzilla und (streams) gehören gar nicht dazu. Gemäß dieser Definition fing das Fediverse erst an zu existieren, als das erste Projekt direkt auf ActivityPub aufgesetzt wurde.

Darüber wird aber nirgendwo diskutiert und auf Mastodon schon gar nicht. 75% der Fediverse-Nutzer haben von Hubzilla noch nie auch nur gehört, von (streams) haben noch weniger gehört. Und daß diese drei nicht schon immer auf ActivityPub basiert haben, wissen noch viel weniger Leute.

#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #ActivityPub #DFRN #Friendica #Zot #Hubzilla #Nomad #Streams #(streams)

tl;dr: Hubzilla has had at least some of this for over a decade now. And it won't replace any of it with a new standard tailor-made for Mastodon.

@silverpill If you look past projects based on ActivityPub and at projects that have ActivityPub as an additional protocol, some of this already exists.

- Data portability. In my opinion, this is the most important problem. I'm in favor of FEP-ef61, which also solves identity portability and unlocks many new features.

Exists in the shape of nomadic identity. Invented by @Mike Macgirvin 🖥️ in 2011 with his Zot protocol and first deplayed in 2012 with the Red Matrix, nowadays known as Hubzilla. Also available on (streams), Mike's current project at the end of a string of forks from Hubzilla, now based on the Nomad protocol.

Mike would like to see nomadic identity and other special features of the Zot and Nomad protocols included in the ActivityPub protocol. He has actually submitted a number of proposals for this. They were all rejected. Even though he is a protocol developer first and foremost, and he has both created and worked on more Fediverse protocols than anyone else, so he should be considered competent.

Nomadic identity with ActivityPub won't come unless either Evan Prodromou and the W3C commission cave in and allow Mike's suggestions, or someone re-invents the wheel from scratch in a way that's utterly incompatible to Hubzilla and (streams). And it won't come to Mastodon unless Eugen Rochko can imply that Mastodon has had it first.

And there will never be a nomadic identity standard that meets Mike's requirements as well as Eugen's wishes.

- End-to-end encryption. MLS has become a standard, and it would be wise to adopt it. Issue 3 at fediverse-ideas provides a good overview of what we have at the moment (not much). Some variation of FEP-ae97 is likely needed to make end-to-end encryption work.

AFAIK, all three of Mike's still existing projects, Friendica from 2010, Hubzilla from 2012/2015 and (streams) from 2021, have it. Optionally, but still. I think Friendica actually advertises military-grade encryption.

- Plugins. Something like Pleroma MRF, but cross-platform (e.g. Wasm-based). Also, pluggable timeline algorithms.

Friendica, Hubzilla and (streams) have had support for add-ons, including third-party add-ons, plus a number of official add-ons since their respective inceptions. If you want a cross-platform add-on standard, I hope you don't expect these three to throw their own standards over board in favour of the new standard. Otherwise, good luck developing a replacement for Pubcrawl that makes Zot-based Hubzilla compatible with ActivityPub while working on ActivityPub-based Mastodon just the same. Friendica, Hubzilla and (streams) rely on add-ons for all federation beyond their respective base protocols (DFRN, Zot, Nomad).

- Groups. We have several competing standards for groups: FEP-1b12, FEP-400e, Mastodon developers are working on their own standard. It would be nice to converge on a single standard, that also supports private groups.

Friendica, Hubzilla and (streams) have had support for discussion groups/forums since their respective inception. On Friendica, a group is a user account with special settings; on Hubzilla and (streams), it's a channel with special settings. In addition, especially Hubzilla and (streams) have access permission control on a level that most people for whom the Fediverse is only ActivityPub couldn't imagine in their wildest dreams. All three can be used by users from all over the Fediverse already now.

Good luck forcing Friendica to give up its 13-year-old standard that's used by Fediverse News, just to name one, and Hubzilla to give up its 11-year-old standard that blows everything else but what (streams) does out of the water. Good luck forcing them to adopt something inferior.

On the other hand, good luck forcing Lemmy and /kbin to switch to a wholly different standard. Don't forget that these two exist as well. And good luck having the Fediverse outside of Hubzilla and (streams) adopt both server-side and client-side OpenWebAuth.

And I'm not even talking about how different Fediverse projects handle threads differently. Mastodon has a Twitter-like thread structure: many posts, tied together with mentiones. Just about everything that's built on ActivityPub has taken this over. Friendica, Hubzilla and (streams) have a Facebook/blog/Tumblr-like thread structure: one post, the start post, and many comments which aren't posts. It's similar on Lemmy and /kbin which are Reddit clones, only that they don't allow thread starters to moderate their own threads.

- Quoting. FEP-e232 is a proposed standard, but most fediverse applications still use non-standard properties. Mastodon developers are trying to invent something completely different.

This is something that almost the whole Fediverse has implemented, save for Mastodon.

And again, Friendica has had quotes since its inception in 2010, almost six years before Mastodon was launched (which, by the way, federated with Friendica and Hubzilla on the spot). Hubzilla has had quotes since 2012, inherited from Friendica. Their way of quoting is dead-simple: BBcode. [quote][/quote] (streams) supports Markdown and HTML in addition to BBcode, but otherwise it's the same.

Oh, and by the way: Friendica, Hubzilla and (streams) have also supported quote-posts a.k.a. quote-tweets a.k.a. quote-toots a.k.a. quote-boosts from their very beginnings.

- Markets. So far there's only one server implementation capable of processing payments.

At least two. Hubzilla has a payment add-on, too. It isn't installed on all hubs, but it's there.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #CWFedisplaining #Fediverse #Mastodon #MastodonIsNotTheFediverse #NotOnlyMastodon #ActivityPub #Friendica #DFRN #Hubzilla #Zot #Streams #(streams) #Nomad #Lemmy #kbin #/kbin #NomadicIdentity #OpenWebAuth #Group #Groups #Forum #Forums #Quote #Quotes #Encryption #E2EE #E2EEncryption

(Sollte dieser Kommentar abgehackt wirken, öffnet ihn an seiner Quelle. Da sollte er komplett sein.)

@Dalbo (extinct) | flo Das kann man gar nicht vereinheitlichen. Schon gar nicht so, daß es für alle Use-Cases und alle Anforderungen immer zu 100% paßt.

Ich bin der Jupiter Rowland, von dem @Dalbo (extinct) | flo einen Kommentar verlinkt hat. Und ich schlage mich schon seit geraumer Zeiten mit dem Thema #AltText und #Bildbeschreibung herum. Aus mehreren Gründen.

Zunächst einmal bin ich zwar im #Fediverse, aber nicht auf #Mastodon. Ich bin auf #Hubzilla, das weder für Posts selbst noch für Alt-Text eine in der Praxis wirklich relevante Längenbeschränkung hat und noch dazu sehr drastisch anders funktioniert als Mastodon.

Auf Mastodon hast du 500 Zeichen für den Post. Bilder werden als Dateien direkt an den Post angehängt. Jedes Bild hat 1500 Zeichen für den Alt-Text. Und für den Alt-Text gibt es ein separates Eingabefeld.

Auf Hubzilla hast du einige zigtausend Zeichen für den Post. Bilder werden hochgeladen auf den in Hubzilla eingebauten Cloud File Space und dann wie in einem Blogpost oder auf einer Website in den Post eingebettet. Nix mit Dateianhang. Der Alt-Text ist auch kein separates Feld. Er muß per Hand eingearbeitet werden in den BBcode, mit dem das Bild eingebettet wird. Er ist also Teil des Post und unterliegt damit denselben (quasi nicht vorhandenen) Beschränkungen.

Mario Vavti wird einen Deibel tun, das über den Haufen zu schmeißen, damit es genauso funktioniert wie auf Mastodon. Und Mike Macgirvin, der #DFRN, #Friendica, #Zot, #NomadischeIdentität, #Hubzilla und #Streams erfunden hat und heute noch (streams) betreut, das dahingehend genauso funktioniert wie Hubzilla, wird einen Deibel tun, (streams) so umzubauen.

So, dazu kommt noch etwas: Im Fediverse liebt man lange, detailreiche #Bildbeschreibungen. Alles, was dir auf "So schreibt man inklusiven Alt-Text für eine kommerzielle/wissenschaftliche Website"-Seiten beigebracht wird, ist hier kompletter Käse.

Die Leute auf Mastodon freuen sich ein Loch in den Bauch, wahnwitzige 1500 Zeichen für Alt-Text zu haben. Im Tröt selber haben sie nur 500 Zeichen. Minus den eigentlichen Tröt, minus CWs, minus Hashtags. Da packen sie dann für ihre Begriffe hochdetaillierte Bildbeschreibungen rein. Nix mit kurz und prägnant und nur das für den Post Wesentliche.

Deswegen sind hier im Fediverse meistens "Alt-Text" und "Bildbeschreibung" absolut synonym und vollwertig gegeneinander austauschbar.

Aber: Ich habe vor Monaten mal debattiert mit einer Nutzerin, die aufgrund einer körperlichen Behinderung so tatterig und grobmotorisch ist, daß sie einen Mauszeiger nicht so präzise und ruhig auf ein Bild bewegen kann, daß sie so den Alt-Text lesen kann.

Die hat mir gesagt: Detaillierte, informative Bildbeschreibungen im Alt-Text sind Mist. Und zwar dann, wenn sie Informationen enthalten, die sonst nirgendwo im Post zu finden sind. Nicht im eigentlichen Post-Text und auch nicht im Bild, jedenfalls nicht für komplette Laien. Wenn es im Alt-Text steht, ist es für Leute wie sie unerreichbar, und die Informationen sind für Leute wie sie verloren.

Okay, auf Mastodon geht es nicht anders. Die einzige Alternative wäre ein Thread, der auch nicht sehr barrierefrei ist.

Aber überall sonst geht es anders. Überall sonst hat man für den Post selbst ein Vielfaches der Kapazität, die man für den Alt-Text hat. Außer auf Friendica, Hubzilla und (streams), wo beides quasi unbeschränkt ist, zumal der Alt-Text ja eh Teil des Posts ist.

Wenn man nicht einfach nur einen kurzen, aufs Wesentlichen reduzierten Bildersatz schreibt, sondern wirklich in der Bildbeschreibung groß und detailliert beschreibt und erklärt und informiert, dann sollte man die nicht auf Biegen und Brechen in den Alt-Text tun, wenn man es nicht muß. Und überall, was nicht Mastodon ist, muß man das nicht.

Ich selbst bin dazu übergegangen, Bildbeschreibungen nur noch in den Post-Text zu tun. Es sieht nicht gut aus, aber barrierefreier wird es nicht mehr. Und ich bin endgültig nicht mehr gebunden an das 1500-Zeichen-Limit beim Alt-Text. Das setzen Mastodon & Co. nämlich im Gegensatz zum Post-Text rigoros durch und schneiden alles dauerhaft ab, was über 1500 Zeichen hinausgeht.

Meine Bildbeschreibungen erreichen nämlich regelmäßig geradezu titanische Ausmaße. Ich habe häufig sehr viel zu beschreiben, weil es in meinen Bildern fast nur Dinge gibt, die niemand kennt. Mitunter sogar sehr viele davon. Mit einfach nur Nennen ist es da nicht getan; dann kommen die Sehbehinderten und fragen: "Ist ja schön und gut, aber wie sieht das aus?" Und ohne Erklärung kommen im Grunde alle und fragen: "Was ist das jetzt genau, was tut es, wie funktioniert es?" Alleine um zu erklären, wo die Bilder entstehen, brauche ich manchmal über tausend Zeichen.

Gut, das ist eine Randerscheinung, aber so etwas gibt es eben. Und das läßt sich nicht in einen angeblich für alle gleichermaßen funktionierenden Standard pressen.

CC: @Anne Roth @Free Software Foundation Europe

Basically, everything in the #Fediverse that's based on #ActivityPub is built against #Mastodon. Because Mastodon defines the ActivityPub spec all alone.

Says the man who has created more federated protocols - #DFRN, #Zot, #Nomad - and Fediverse projects than anyone else and invented #NomadicIdentity.

Mike Macgirvin wrote the following post Tue, 05 Sep 2023 22:28:16 +0200 I provided my input to the AP spec editor and it was rejected outright. Everything I provided to the ActivityPub editor was rejected outright. If there were any questions, it had to go through the Mastodon dictator, who rejected anything he didn't invent. And then the ActivityPub editor would likewise reject it. "Mastodon has millions of users, you don't".

That's the way the process works.  

The major concern was that nomadic identity is hard, and the clock was ticking on when the spec had to be finalised. The ActivityPub editor also insisted that it be done using the draft digital identity spec. So that ensured it would never make it into ActivityPub.

Here we are 5-6 years later and they still can't figure out how to do nomadic identity in a decentralised framework (outside of using torrents or centralised resolvers). Meanwhile we've had it, used it, and improved it for well over a decade.

There's a specification in the public domain. Some complain that it isn't enough, but I'm one person in a planet of 8 billion and haven't had any help developing this. The only help I ever get is with bike shed stuff - web interfaces. Not one person has offered any help polishing up the spec or improving the actual implementation code or even offered critique and discussing the subject.  Just "I can't use this. Bye." [edit: apologies. That isn't entirely correct. I did get help from one person.]

I've started to pick it up and try again using did's as a proof of concept, but I'm retired now and really can't be bothered dying on the same hill over and over again.

But I will try and update Nomad (the protocol, formerly Zot) to use a did: form. It's just a replacement WebMTA for delivering JSON ActivityStreams which is nomadic aware. There's still no chance of it ever getting into ActivityPub unless it's invented by the Mastodon dictator.

Meanwhile the spec is in the public domain and there are working implementations and it federates with ActivityPub and nobody is holding a gun to anybody's head.

https://codeberg.org/streams/streams

@volkris The belief that each Fediverse project is a different graphical front-end app for the exact same technological back-end is complete non-sense. It sounds like all Fediverse projects run the self-same back-end Web server technology and just put different Web interfaces or mobile apps on top.

#Firefish, formerly known as #CalcKey, is quite a bit different from #Mastodon. And it's still microblogging based on #ActivityPub.

#Friendica is vastly different from Mastodon, also because its base protocol is #DFRN and not ActivityPub. It has an add-on for ActivityPub connectivity.

#Hubzilla and #Streams are even more different from Mastodon. They're based on two versions of #Zot, and they even have an architecture that's extremely different from all other Fediverse projects, even Friendica included, and that wouldn't even be possible with ActivityPub.

@Chris Trottier In the #Fediverse, you're only semi-safe from search warrants at best.

If a #Mastodon instance hosted in the USA is being targetted by the authorities, the admin can easily go through even private communication. Instances hosted abroad can shrug this off, and most US newcomers to Mastodon reside on mastodon.social hosted in Germany where US Federal law and state laws don't apply, but many have moved to US-based instances since.

If you want actual privacy, if you want access control that's worth the name, if you want encrypted communication, forget #ActivityPub and everything that's based on it. Instead, go for #DFRN or, better yet, #Zot and what's based on it, and keep your close friends all on instances using at least largely the same protocol.

@CynthesisToday If you want to speak to someone who really knows his way around communications protocols, I'll have to refer you to @mike, creator of #Friendica, #RedMatrix, #Hubzilla, #Osada, #Zap, #Misty, #Roadhouse and #Streams and of the #FederatedSocialWeb protocols #DFRN (base protocol for Friendica) and #Zot (base protocol for all the others), thus also inventor of #NomadicIdentity, as well as contributor to both the #Diaspora protocol and #ActivityPub.

@Codex ☯️♈☮ @CynthesisToday I think the #Fediverse is the easiest to understand for those who halfway know their way around computer stuff if you start at the protocol level.

#ActivityPub is a digital communications protocol standard. Like e-mail or RSS or Atom or XMPP or Matrix, for example. Or like #StatusNet or the #Diaspora protocol or #DFRN or #Zot, now known as #Nomad in its latest incarnation.

The server application projects that are based on ActivityPub are different server-side software implementations of the same protocol. Some have more features, some have fewer, some specialise in particular tasks which is possible because ActivityPub is not specialised itself, not a one-trick pony.

Like, for XMPP, you have jabberd and ejabberd and Openfire and Prosody and Tigase. For e-mail, you've got various mail servers and MTAs.

The main difference here is that ActivityPub is so versatile in its capabilities that it can be used for a whole lot of different things. #Mastodon, #Pleroma, #Akkoma, #MissKey, #CalcKey etc. were made for microblogging. But ActivityPub can also be used for actual blogging platforms like #Plume or #WriteFreely, for video streaming like in the cases of #PeerTube and #Owncast, for audio streaming like in the cases of #Funkwhale and #Castopod and for link aggregators/discussion communities like in the cases of #Lemmy and #kbin. Only to name a few examples.

Still, there are enough parts of this protocol fixed so that all these projects, all these implementations of ActivityPub can connect to one another and ideally communicate with one another.

Now, why is all this made so that they can connect to one another?

That's because they all use the same protocol. The alternative would have been to do like Mike MacGirvin did with DFRN for #Mistpark, later #Friendika, today known as #Friendica, and create a whole new protocol from scratch, even though StatusNet was readily available. Well, only that Mike's intention was to federate Friendica with everything that moved, regardless of protocol.

Okay, better comparison: The alternative would have been to do like the four Diaspora* creators and create a whole new protocol from scratch with no intention whatsoever to connect to the outside world.

Well, instead, all those clones of YouTube and Instagram and Reddit and GoodReads and so forth chose ActivityPub. It was a win-win situation: They could use an existing protocol which actually worked for them instead of taking upon themselves designing a whole new protocol first and then their server application on top. And they could expect a wider audience, namely everything else that uses ActivityPub. Two birds, one stone.

Oh, and by the way: Neither the Fediverse nor ActivityPub was designed around Mastodon, nor was ActivityPub designed by Eugen Rochko (Mike Macgirvin did have some saying in it, though, AFAIK), and quite a few Fediverse projects already existed before Mastodon. Pleroma is three and a half weeks older. MissKey is two years older AFAIK. #Hubzilla was forked from Friendica four years before Mastodon came out. This means that Friendica has to be even older: six years older than Mastodon.

None of these projects will ever give in to Mastodon's limitations and reduce their own feature set for the convenience of Mastodon users. Oh, and neither will the projects that came after Mastodon. If something from another Fediverse project doesn't look good on Mastodon, it's Mastodon's problem.

@Dr. Jorge Caballero

Hear me out: 1-click privacy-conscious quoting.

@Dr. Jorge Caballero schrieb:

Hear me out: 1-click privacy-conscious quoting.

>Hear me out: 1-click privacy-conscious quoting.

"Hear me out: 1-click privacy-conscious quoting."

«Hear me out: 1-click privacy-conscious quoting.»

(↑ All these were copy-pasted, by the way. But at least the upper two are fully legitimate quotes here. ↑)

I don't want to alarm you, but here on a bone-stock #Hubzilla 8.4 Web interface, I can gleefully circumvent any and all privacy safeguards any #Mastodon fork or any mobile app connected to any Mastodon instance could possibly present to me with absolutely no obstacles. And I have countless ways of quoting. I could #quote anyone.

That's because Hubzilla is neither a Mastodon fork nor an alternate Mastodon interface nor a Mastodon client app. It's a wholly separate project that's almost four years older than Mastodon, based on the #Zot protocol that's five years older than Mastodon and seven years older than #ActivityPub. It federates to Mastodon and everything else based on ActivityPub through an optional built-in connector, but internally, it speaks a language more powerful than ActivityPub.

By the way, the same goes for #Friendica, another separate project that's the direct predecessor of Hubzilla, based on the #DFRN protocol and six years older than Mastodon, as well as #Streams, another separate project that was launched last year as an "indirect" fork of a fork... of Hubzilla, based on the latest incarnation of Zot, now named #Nomad. Unlike Hubzilla, both have ActivityPub on by default.

Now I'm curious whether your privacy safeguards have any effect on other #Fediverse projects based on ActivityPub such as #Mitra, #Pleroma, #Akkoma, #MissKey, #CalcKey or #FoundKey.

#MastodonIsNotTheFediverse

@Kaity A @Ada While I do appreciate your effort, how much of the Fediverse do you plan this to cover within less than, say, two months?

blahaj.zone?

All #Mastodon instances?

Or all instances of all #Fediverse projects?

The latter, so much I can tell you, will be impossible to achieve. First of all, of course, this would require extensive modification to many Fediverse projects that aren't Mastodon. Keep in mind that there are some projects that are both years older than Mastodon and based on a protocol that is not #ActivityPub.

#Friendica (6 years older than Mastodon) might have to dig deeply into its UI, its underlying #DFRN protocol (8 years older than ActivityPub), of course the ActivityPub connector and maybe actually also all the other connectors, of which Friendica has many. If bad comes to worse, Friendica would have to enforce Mastodon users' quote and interaction limits upon #Diaspora users, and Diaspora* and Mastodon aren't even federated with one another and only touch each other on a few projects that are federated with both.

Second, the development of some projects has slowed down to an almost or actual still-stand. You won't see #Plume integrate everything that you've planned before July. It'd be a miracle to see Plume even roll out a bugfix release until then.

Third, @Mario Vavti and @mike are very unlikely let anyone on Mastodon force them to design #Hubzilla and #Streams, or even the #Zot or #Nomad protocol, in any particular way. It's bad enough that the Mastodon core devs try to bully them into re-designing stuff that's many years older than Mastodon.

By the way, both Hubzilla and (streams) have part of what you want to introduce built in already now. Hubzilla actually had it before Mastodon even existed.

What you're trying to do is
a) re-invent the wheel
b) make your wheel design mandatory for the whole Fediverse
c) force Hubzilla and (streams) to discard their way of handling permissions which is firmly integrated with the Zot/Nomad protocol and its own very detailed and fine-grained permission control, the kind of which even the #CalcKey devs couldn't imagine in their wildest dreams, and which has seen some 11 years of daily operation, and replace it with yours

Fourth, there are still some instances of some projects out there that haven't seen a single update this whole year. Or for over a year. There still seem to be Hubzilla hubs alive that run 5.x or even 4.x while the current version is 8.2, and 8.4 is just around the corner. There are also still instances of the (indirect) Hubzilla forks #Osada and #Zap alive, and both projects have been EOL and discontinued since New Year's Eve. These instances will continue not having what you want the whole Fediverse to have.

Next question: How exactly do you want such limitations to be enforced? Do you simply want to keep offending posts/comments from being created? Or do you actually want to go as far as UI buttons being greyed out or disappearing altogether on the UIs of all Web interfaces of all projects and on all desktop and mobile apps?

In the case of quoting, either will be very difficult to achieve outside of Mastodon, especially on the old #FederatedSocialWeb projects Friendica and Hubzilla and their newest offspring, (streams).

See, when Mastodon will introduce quotes, it'd be a button, and everything else will be hocus-pocus happening in the background. On Friendica and Hubzilla, quotes, just like any kind of text formatting, are done with BBcode which is in the post/comment editor in plain sight and can be edited. In (streams)' case, Markdown and HTML come on top.

There are about a thousand and one ways for me to quote you or anyone else. I'd demonstrate a selection of them, but Mastodon's text formatting limitations won't let me, at least not short of taking a screenshot of both the source code and what it looks like. If you want to keep everyone on Friendica, Hubzilla and (streams) from quoting those who don't want to be quoted with 100% reliability, these three projects would need editors that could catch all possible ways of quoting someone. If you still want them to rule out false positives, it's really approaching impossibility.

@stefanm
#Plattform war während meiner IT-Tätigkeit immer die Hardware. #Fediverse ist nach meinem Verständnis der Oberbegriff für das #Netzwerk, das Posts/Nachrichten über unterschiedliche #Protokolle, wie #ActivityPub, #Zot, #Diaspora und/oder #DFRN zwischen unterschiedlichen #Knoten, wie #Mastodon, #friendica, #hubzilla, #pixelfed, etc. verteilt, so dass auf diese in jedem #Knoten im #Netzwerk zugegriffen werden kann.

@Kevin Davidson @LabSpokane @Chris Trottier It's the very same thing as people demanding the #Linux ecosystem be reduced to ONE distribution with no variants, ONE graphics toolkit, ONE display manager with ONE desktop environment. Because Linux is "too complicated" otherwise. Because it makes people choose where Windows and Mac users don't even have a choice.

But this would leave many dissatisfied because that unified Linux will not cater to their individual tastes. If it sucks, Linux sucks altogether.

Of course, in the #Fediverse case, the one unified project which the Fediverse must be reduced to is always #Mastodon. Preferably always with the same set of features. No other projects, not even forks.

First of all, this would mean that the Fediverse would lose a great deal of its features. Mastodon can't do podcasts; #Funkwhale and #Castopod can. Mastodon can't do blogs; #WriteFreely and #Plume can. Mastodon can't do YouTube; #PeerTube can. Not to mention the many things that #Hubzilla can do that Mastodon can't.

Now, someone could suggest to cram all features of all these projects into Mastodon. But not only is this very likely impossible without re-designing great deals of Mastodon which, for example, doesn't offer the multiple-channels-per-account model and doesn't even differentiate between posts and comments. It would also irritate those who stick with Mastodon because it's the most simple of all Fediverse projects.

And indeed, there are many who wish for Mastodon to be frozen on the feature level of late 2022 when they joined. They're even opposed to the introduction of text formatting or quotes to Mastodon, features which would thereby vanish from the Fediverse altogether if the Fediverse was reduced to late-2022 Mastodon.

Besides, you won't be able to get everyone to cooperate on Mastodon, much less on Mastodon staying at the level of late 2022. Literally every project leader who isn't Eugen Rochko will demand more features than Mastodon had half a year ago, actually, even more features than Mastodon has right now.

So you've got two possibilies.

One, Mastodon ends up an even heavier feature monster than Hubzilla because everyone can add to it what they deem necessary or useful.

Two, Eugen Rochko becomes the supreme ruler over the Fediverse, and only he decides which features the Fediverse is allowed to have. And he bases his decision on the wishes of those who want Mastodon to stay simple. Everyone else is reduced to a code monkey with no free will, including Mike Macgirvin, inventor of the #DFRN protocol, #Friendica (both 6 years before Mastodon), the #Zot protocol, #NomadicIdentity (both 5 years before Mastodon), Red Matrix/Hubzilla (4 years before Mastodon), Osada, Zap, Roadhouse, #Streams etc.

@Fred Brooker Not on #Mastodon with #ActivityPub as it is right now.

But the #Zot protocol, created by the #Friendica inventor Mike Macgirvin in 2011, seven years before ActivityPub became a standard, allows for something that's called #NomadicIdentity. In fact, Zot was created specifically for this feature.

Friendica with its #DFRN protocol already allows full account portability between instances on a degree that Mastodon users still think is absolutely impossible, and a Friendica account contains much more data than a Mastodon account.

Nomadic identity goes even further: It lets you have the very same channel on multiple instances at the same time. So you don't move to a new instance, leaving a dead and disconnected account behind. You create a 100% clone of your channel. And that clone will remain a clone, for it's kept in-sync with the original in real-time. And you can have as many clones as possible.

Sounds like utter science-fiction, right? But it's reality.

In 2012, four years before Mastodon, Macgirvin himself forked his own Friendica, ported it to Zot and renamed it Red. It was later renamed #RedMatrix, and when it saw its 1.0 stable release in late 2015, still months before Mastodon, it got its final and current name, #Hubzilla.

If you think it's still born, if you think something like this couldn't possibly have survived: Hubzilla is still around. It is still being developed. Its current version is 8.2 from last month, and 8.3 is being field-tested.

And yes, it still offers nomadic identity while each channel has features which Mastodon users couldn't imagine in their wildest dreams. And all of it is kept in-sync between instances by nomadic identity.

Also: I speak to you from Hubzilla right now. No, I'm not on Mastodon, although this should be clear from how long this post already is. Hubzilla has optional ActivityPub support per channel.

And even Zot itself is advancing. Not long after the launch of Hubzilla, Macgirvin created two forks for the development of Zot/6, #Osada with ActivityPub and #Zap without it. More forks came after Hubzilla had been upgraded to Zot/6 in order to develop Zot/8, #Mistpark2020 and #Roadhouse. All four are EOL now and superseded by #Streams which first saw the light of day last year, and which runs on #Nomad, formerly known as Zot/11, providing better integration of non-nomadic protocols such as ActivityPub.

@fastfinge What if I told you that just about the whole Fediverse supports quotes, only Mastodon doesn't?

What if I told you that #MastodonIsNotTheFediverse? What if I told you that I myself am not on Mastodon, although this post of mine has appeared on your timeline?

What if I told you that, in fact, the Fediverse has been around for much longer than Mastodon?

What if I told you that it started in 2008 with something called Laconi.ca, now known as #GNUsocial (#^https://en.wikipedia.org/wiki/GNU_social)

Okay, GNU social doesn't really count as part of today's Fediverse because it doesn't support #ActivityPub. And okay, it wasn't called the Fediverse back then but the #FederatedSocialWeb. But still, the whole concept isn't new. It was not invented by Eugen Rochko.

Still, even today's Fediverse is more than Mastodon and older than Mastodon. And just about everything that isn't Mastodon supports quotes while still being fully federated with Mastodon.

But let me elaborate (warning, this post is over 12 times as long as a toot can possibly be):

#Friendica (#^https://friendi.ca, #^https://en.wikipedia.org/wiki/Friendica, #^https://joinfediverse.wiki/Special:MyLanguage/What_is_Friendica%3F) was launched in July 2010. That was six years before Mastodon. It was created by a guy named Mike Macgirvin as a decentralised, distributed, federated replacement for Facebook. No, not Twitter. Facebook.

From the very beginning, it had many features which Mastodon users keep demanding today. Including quotes. Again, when Mastodon was launched, Friendica had had these features in daily productive use for six years already.

And yet, people don't use quotes to harass others by "stealing" discussions. This is technically impossible on Friendica due to its architecture which is more like Facebook or a blog or a forum and less like Twitter or Mastodon. Threads aren't stand-alone posts floating around the timelines, loosely tied together by increasing numbers of mentions. Instead, they're start-post-and-comments structures. Replies aren't stand-alone posts. Replies are comments firmly tied to one start post by Friendica's internal structure.

Oh, and Friendica doesn't run on ActivityPub. It has its own internal protocol, #DFRN. Still, Friendica quickly created an ActivityPub connector and federated with Mastodon, thus becoming part of the Fediverse. Friendica federates with a whole lot of projects and platforms. In fact, there is a growing number of forums mostly frequented by Mastodon users which run on Friendica, such as FediverseNews.

I myself am on #Hubzilla (#^https://hubzilla.org, #^https://joinfediverse.wiki/Special:MyLanguage/What_is_Hubzilla%3F). It started life in 2012, still four years before Mastodon, as a fork of Friendica, created by Friendica's own inventor. In 2011 already, Mike had conceived an even more powerful protocol named #Zot which comes with features that are outright utterly unimaginable for Mastodon users such as #NomadicIdentity. Hubzilla even had its first stable release before Mastodon was launched.

And Hubzilla still has almost all the features Friendica has with a whole lot more on top. Again, including quotes. Again, yes, before Mastodon refused to have them. And again, yes, without anyone misusing them for harassment.

And again, it's part of the Fediverse and federated with Mastodon. Otherwise you wouldn't be able to read this.

I should also mention that both Friendica and Hubzilla have technical barriers in the way of publicly quoting private or restricted posts, at least with references/a connection to the quoted post. Hubzilla in particular has access rights control on a level you couldn't possibly imagine in your wildest dreams.

And just about everything else in the Fediverse that's microblogging or macroblogging has official, built-in quote support.

• #Pleroma (#^https://pleroma.social/, #^https://joinfediverse.wiki/What_is_Pleroma%253F) has quotes. And it's part of the Fediverse and federated with Mastodon.
  
• #Akkoma (#^https://akkoma.social/), a Pleroma fork, has quotes. And it's part of the Fediverse and federated with Mastodon.
  
• #MissKey (#^https://misskey-hub.net/en/, #^https://joinfediverse.wiki/What_is_Misskey%253F) has quotes. And it's part of the Fediverse and federated with Mastodon.
  
• #CalcKey (#^https://calckey.cloud/, #^https://joinfediverse.wiki/What_is_Calckey%3F) has quotes. And it's part of the Fediverse and federated with Mastodon.
  
• #FoundKey (#^https://akkoma.dev/FoundKeyGang/FoundKey) has quotes. And it's part of the Fediverse and federated with Mastodon.
  
• #GoToSocial (#^https://docs.gotosocial.org/, #^https://joinfediverse.wiki/What_is_GoToSocial%3F) has quotes. And it's part of the Fediverse and federated with Mastodon.
  
• #Socialhome (#^https://socialhome.network/) has quotes. And it's part of the Fediverse and federated with Mastodon.

Yes, they're all federated with Mastodon. This means that users of any of these projects, including Friendica and Hubzilla, can read Mastodon posts and quote them in their replies, and these replies, in turn, can be read on Mastodon.

Okay, so the Fediverse has two, three, four... ten projects, and all but Mastodon support quotes, and nowhere are there people demanding the feature be removed due to rampant harassment?

No, these are only the microblogging and macroblogging projects, and only those of the macroblogging projects that aren't primarily for long-form blogging, i.e. that aren't mimicking Medium, that aren't mimicking WordPress, that aren't #Wordpress itself. Yes, there are WordPress blogs in the Fediverse, federated with Mastodon.

In fact, the Fediverse is even much, much bigger than that (#^https://fediverse.party/en/miscellaneous/, #^https://the-federation.info/).

Now go block me for harassing you, for being an ableist swine because I treat blind people equally instead of mollycoddling them wherever possibly, even for being a fascist or just for shattering your worldview into itty bitty pieces. This post of mine stands.

CC @Patrick, the Linux guy so that you know that the Fediverse is more than Mastodon, too
Also CC @Ada @James

@lafnlab @Bluedepth @Ada @Dave Troy :toad: @Supernovae aka Byron Miller @Mark Earnest @Paul Chambers :chambers: @Darren du Nord @Flaming June @Flatbush Gardener 🌈 @HistoPol @Qazm @David Boles @Fediverse Report

#Diaspora has its own protocol. It's distributed and federated within itself, but it is not interested in federating to anything else. All federation to the outside was established by the developers of other networks and by reverse-engineering Diaspora*'s protocol and directly tapping into its databases because it didn't have an API back then.

#Friendica has its own internal protocol, #DFRN. But Friendica's main goal was to federate with everything that moved. It was Friendica which established the first cross-project federation with Diaspora*. And Friendica also has #ActivityPub support. Otherwise, pretty much none of you could connect to @Fediverse News.

#Hubzilla has its own internal protocol, #Zot. Hubzilla also has ActivityPub support, this time optionally for each user channel because everything that isn't Zot kind of stands in the way of Zot's main killer feature, #NomadicIdentity.

Anything built from #Streams uses a successor of Zot, #Nomad. (streams)-based projects and instances have ActivityPub support, too, and like on Friendica, it's on by default.

So the latter three can directly connect to everything that uses ActivityPub. Interaction between Diaspora* users and, for example, Mastodon users can only happen in the comments on a post from Friendica or Hubzilla.

@Brennan Stehling It isn't even the first. Not even for social networking.

Laconica = #StatusNet = #GNUsocial was the first. It was what drove Identi.ca. That was in 2008.

Then, in 2010, came #DFRN, the internal protocol created for and used by #Friendica. (Friendica can also use ActivityPub, that's how you can post on @Fediverse News.)

A bit later, also in 2010, came the internal protocol created for and used by #Diaspora.

In 2011 came #Zot, the first protocol that went beyond decentralisation and federation and introduced #NomadicIdentity. Starting the next year, it became the technical basis of what is known today as #Hubzilla. (Hubzilla can use ActivityPub as well, that's how you can read this post of mine. But its nomadic features don't translate fully to ActivityPub.)

All of this was before #ActivityPub.

The newest version of Zot, Zot/11, was renamed #Nomad and has been used by #Streams since last year. And (streams) being a "fork me and build something nice out of me" code repository rather than a run-as-is branded platform like Mastodon or Hubzilla indicates that Nomad, much like Zot, is quite versatile, as does the fact that Hubzilla's entire huge set of features is made nomadic by Zot.

Oh, and by the way, e-mail and #XMPP predate them all. And there's also #Matrix, for example.

@John Socks @Chris Trottier @{[email protected]}

@Bob Wyman #Friendica doesn't use #ActivityPub because it predates ActivityPub by 7½ years.

The ActivityPub standard was published in January 2018. Friendica, then still called #Mistpark, had its 1.0 release in July 2010.

Switching seven-year-old Friendica to ActivityPub would have meant a complete re-write of an established social networking project in daily productive use. During the migration, it would have disrupted connections between instances. Also, Friendica would have suffered and degraded from the switch because current ActivityPub doesn't have nearly the feature set which #DFRN, Friendica's scratch-made internal protocol, had in 2010 already.

#Hubzilla had its 1.0 release, along with being renamed from #RedMatrix, in December 2015. This was still 2½ years before there was ActivityPub. Hubzilla had been in the making since 2012, originally being a Friendica fork named Friendica Red, created by Friendica's own inventor, Mike Macgirvin, then renamed Red, then renamed Red Matrix, then renamed Hubzilla.

Essentially, Hubzilla was created around a new protocol idea which Mike had in 2011 with an all-new feature: #NomadicIdentity. This feature could not be made possible by upgrading DFRN, so a new protocol was conceived in 2011, #Zot.

Migrating Hubzilla from Zot to ActivityPub as its base protocol would degrade it even more than migrating Friendica from DFRN to ActivityPub. Hubzilla has got even more features beyond what ActivityPub supports. Switching it to ActivityPub would mean axing one of its absolute killer features, nomadic identity.

@Nuno Nonetheless, both Friendica and Hubzilla are part of the Fediverse and fully and bidirectionally federated with, amongst other projects, Mastodon. Proof: You're on Mastodon, I'm on Hubzilla, and yet, you can read this post.

Still, the idea of requesting a mobile app for Android and iOS that can harness Hubzilla's full feature set, just like Tusky can harness pretty much Mastodon's full feature set, along with the full feature sets of all other Fediverse projects, no exception, can only come from someone who only knows Mastodon. You want easy access to all of Hubzilla's features through a touch screen? You better get yourself a USB touch screen the size of a newspaper, and even that wouldn't be sufficient.

Go back in this thread, and read through the feature list once again.

@Bob Wyman For starters, everything I've listed is not only part of the #Fediverse, but bi-directionally federated with #Mastodon. So there's little to do with regards to establishing interoperability in the first place.

Beyond that: You can't blindly write a mobile app for these projects without knowing these projects in the first place. They aren't all Twitter-like microblogging services.

You need to know that these projects exist. You need to know how they work. You need to know their features. You need to know their specific APIs if they have any.

Also, #Friendica and #Hubzilla aren't even native #ActivityPub platforms. They have ActivityPub bolted-on as applications. On Hubzilla, you as a user even have to activate ActivityPub on your channel(s).

Friendica uses its own protocol internally, #DFRN, which, along with Friendica, was created eight years before ActivityPub was established as a standard.

Hubzilla was created around a protocol named #Zot which was invented in 2011 and introduced a concept named #NomadicIdentity. I can't see ActivityPub being expanded to everything that Hubzilla's current #Zot6 can do, much less everything that its direct successor, #Nomad, used by #Streams, can do.

Also, if you wanted to standardise Hubzilla's full feature set in ActivityPub so that app developers can create a mobile app for Hubzilla without ever having seen Hubzilla, you'd have to blow that standard up to gigantic proportions.

Since you obviously have never heard of it, let me list up some of its features:

• cross-instance authorisation via #OpenWebAuth (which really only makes sense in a Web browser)
  
• multiple separate channels per user account with separate identities, each with multiple profiles à la Friendica which can assigned to individual users or privacy groups
  
• nomadic identity; not only easy moving of channels to other instances, but real-time mirroring of individual channels between multiple instances
  
• fine-grained privacy/access rights control through both channel roles and pre-definable sets of contact roles
  
• posts can have an almost unlimited number of characters; formatting is possible through the full standard set of BBcode plus Hubzilla-specific extensions, some of which tie into Zot/OpenWebAuth
  
• additional long-form writing support through articles which support the same BBcode set
  
• support for simple webpages which support the same BBcode set plus Markdown plus HTML
  
• built-in wiki engine which supports BBcode and Markdown plus individual edit access control for other users/channels
  
• built-in file server with WebDAV support and individual access rights control per directory
  
• image gallery which can tie into the file server
  
• public calendar inherited from Friendica
  
• secondary calendar engine with variable access control for other users/channels and CalDAV support
  
• address book with CardDAV support
  
• ca. 55 built-in per-channel applications, most of which are optional
  
• etc.

Let me put it this way: Hubzilla is something which, at its current state, can barely be harnessed in a desktop browser with a hardware mouse, a hardware keyboard and a 20+" display. I can't see Hubzilla's full set of features be made accessible in a mobile app, much less more easily than on the desktop.

If you really want to have all features from all Fediverse platforms standardised in ActivityPub, then ActivityPub would end up with three different calendar implementations alone, two of which Hubzilla uses (and they aren't connected to one another in any way), the third being that used by #Mobilizon.

Besides, I can't even see long-form blogging working on mobile phones. Apps for writing articles on #Plume, #WriteFreely or Hubzilla's article application don't make much sense without a hardware keyboard. Not to mention that Plume, WriteFreely and Hubzilla have different implementations of long-form blog post writing.

@Stark @Chris Trottier @Fediverse News This kind of also explains the transition from #DFRN to #Zot to #Zot6 to #Nomad.

@mike

Streams is basically an acknowledgement that my work has no value to anybody but me.

The lack of popularity for #Friendica, #Hubzilla, #Zap & Co. never came from nobody caring.

It always came from nobody even knowing that they exist in the first place.

In 2010, people were ready and willing to pump a few hundred thousand US dollars into the development of #Diaspora. They hoped that Diaspora* would be a free, decentralised Social Web revolution. But the development of Diaspora* took an eternity, and out came something lack-lustre and underwhelming that spent several years in public alpha.

Why didn't people save their money and use #Friendika instead which was everything they had dreamed of and then some? Which was vastly more powerful in spring 2010 before Diaspora* was developed than Diaspora* itself would ever become? Why was Diaspora* developed in the first place? Why was the wheel re-invented, but worse?

Because nobody knew that Friendika existed. That's why. Diaspora* made it into all big news because its developers a) announced to mass media that they want to compete with #Facebook and b) asked people for crowdfunding, hence the big publicity campaign. If Friendika had been as well-known as, for example, #Firefox, Diaspora* wouldn't exist.

I myself only found Friendika back in the day by actively searching the Web for decentralised social network platforms. It was a thorough, intense search. And I eventually stumbled upon it.

As for Hubzilla, I happened upon it on Friendica when someone mentioned it.

As for #Osada and #Zap, I think it was you who mentioned them within the Hubzilla dev bubble which I occasionally got a glance into. Someone from that bubble also led me to #Misty a.k.a. #Mistpark2020.

As for #Roadhouse and #Streams, I discovered them on Zotlabs by chance. And their Zotlabs pages were never filled with any information on what they are and what they do.

I didn't find out about any of these projects through any form of advertising or publicity campaign, nor did I learn about any of them through tech media.

Only once do I recall that any of these projects has ever been presented at a FLOSS or hacker event. That was years ago at the #ChaosCommunicationCongress where a panel about Friendica was held. But even that panel was like Friendica devs talking to other devs about developing Friendica and Friendica node admins talking to other LAMP stack admins about installing and running Friendica nodes. What Friendica can do was only mentioned briefly. The first step, namely getting people interested in using Friendica as end users to see what it's good for, was skipped entirely. And there was no info booth, there was no promotional material, there were no flyers, no nothing. Even #OpenStreetMap had flyers.

#Mastodon was just lucky. For starters, it was the first free and decentralised microblogging service that was launched in years. The whole #StatusNet and #GNUsocial things had been so long ago that even those few who had come across it barely remembered, so Mastodon didn't seem like it was aping them. And it must have attracted enough disgruntled #birdsite users already then to gain a critical mass.

Before 2022, we already had a situation in which the vast majority of Mastodon users believed that the #Fediverse was Mastodon, and Mastodon was the Fediverse, and there was nothing else out there. Pleroma was already vastly superior to Mastodon technologically, but Mastodon had the critical mass. Still, Mastodon itself was so obscure that #TimBernersLee had never heard of it, much less of any of your projects or Diaspora*, and therefore decided to re-invent the free, open-source, non-commercial, decentralised social wheel all from scratch once more.

When the #TwitterTakeover started looming on the horizon, people started recommending Mastodon on #Twitter. And pretty much only Mastodon because that was all they knew. Again, critical mass. This critical mass enlarged itself in several waves.

I guess not a single birdsite refugee had ever heard of any Fediverse project beyond Mastodon when they joined it, and I guess over 80% still never have. And they keep wondering how people can toot more than 500 characters, whether their Mastodon instance has different settings and such. I know from personal experience that it often takes several attempts to explain to people that, no, I am not on Mastodon, and Hubzilla is not a Mastodon instance.

Mass media don't make it any better. Both general news media and tech media have meanwhile picked up the Mastodon phenomenon, and many have accepted that Mastodon is here to stay. Still, all general news media and nearly all tech media "know" that Mastodon is the Fediverse and vice versa, and that there isn't anything else out there. Some media outlets have joined the Fediverse themselves. They could be way better off with #Akkoma or #Pixelfed or Hubzilla or their own take on Streams. But they're on Mastodon. Why? Because that's all they knew when they got there. Because they've settled with Mastodon before even knowing that there are projects that'd suit them better. And they'll probably never know.

Now don't get me wrong, I'm not blaming you personally. I'm not even sure if it's good style for the main dev of a project to go peddling their own work. Making your projects known should have been a task for the whole community. Not only the devs, not only the hub admins, but the users. Because if someone can talk to aspiring users, it's actual users. "If you build it, they will come" has failed, and we should have seen this coming.

Large-scale migration away from proprietary, commercial projects and towards free, open-source, non-commercial alternatives only happens under pressure from outside and even then not always. Large-scale adoption of Firefox in Germany happened when the most widely-used browser was #InternetExplorer 6 which was not only hopelessly outdated but so insecure that the malware spread through it alone caused millions upon millions of Euros in damage. And it only happened because the reaction upon this was our Mother Of The Nation, Federal Chancellor #AngelaMerkel, herself telling the Germans to move from IE6 to Firefox.

And the mass migration from Twitter to Mastodon only happened for two reasons: One, Twitter was threatening to get more and more hard to take. Two, Twitter didn't and still doesn't really have a commercial, corporate-owned, centralised competitor. All possible Twitter alternatives are decentralised #FLOSS. There was nowhere else to go than down the Fediverse route.

Right now, however, I don't see a #Facebook takeover that'd turn it into yet another Nazi hive and cause people to flee to Friendica and/or Hubzilla. Nor does #OlafScholz tell people to quit Facebook and join Friendica/Hubzilla instead. He doesn't even tell people to join Mastodon.

No, growth for Friendica, Hubzilla and Streams still has to come from within. And again, this won't be a task for the core devs. All they'll have to do is tell the community what there is to advertise. But I don't expect anything really new to come anytime soon, seeing as Streams seems to be a be-all, end-all project that can be turned into anything without involvement by the core devs. So we already know what there basically is to advertise. And when it comes to cool new features, we learn about them quickly when new versions come around, and the devs do talk about these beforehand.

So the first step would be to get these projects known outside the #DFRN, #Zot and #Nomad bubble. This would lead us into two different, bigger bubbles. One is the Fediverse which, as I've already mentioned, the vast majority of its own users still sees as synonymous with Mastodon. Granted, we'd have tough competition there, for if someone desires more than 500 characters per post, maybe they're better off with Akkoma or a different Mastodon instance. And federation with Diaspora* is no longer a unique selling point because hardly anyone uses Diaspora* exclusively anymore, so I guess hardly anyone misses the Diaspora* connector on Streams. But maybe a "federated social Swiss army knife" like Friendica or even Hubzilla or a "federated social construction kit" like Streams is exactly what some people are looking for. Remember that the Fediverse alone covers millions of people. 1% of them is slowly but steadily closing in on being 100,000.

The other bubble is the FLOSS scene. This may be more difficult because, curiously, the FLOSS scene barely knows about the Fediverse, even about Mastodon, and thus has barely adopted it. This will be somewhat tougher. Some people in that scene reject social media altogether because they associate social media with corporate spyware, and they've convinced themselves that they don't need any social media (or their social media hub is either a git repository hoster, ironically often a #Microsoft property, or a mailing list). Others have a general dislike towards GUIs, only using ultra-minimalist #i3wm and no pointing devices themselves. Or they cling to the UNIX philosophy that each tool has to be able to only do one thing which gets to the point that they actually use different tools for receiving, composing and sending e-mails. Even Friendica can do too much for their tastes.

Still, I think that other people in the FLOSS bubble may be more welcoming, also because the Fediverse is yet another rather successful attempt at competing against corporate monopolies with FLOSS, with decentralised FLOSS à la #XMPP or #Matrix even. Also, while the #GAFAM bubble sees us as a bunch of idealistic but ultimately successless basement-dwelling nerds, the FLOSS bubble will see us as some of their own ilk doing more cool stuff in addition to all the cool stuff that has already been done. Not to mention that the FLOSS bubble has its own news outlets. We just must not repeat the mistake of only trying to talk to potential devs or potential instance admins. We have to reach out to aspiring end users first and foremost. Devs and admins will come in their wake. FLOSS people aren't keen on developing something they've never even tried using.

Media coverage outside the FLOSS bubble might give us an even wider audience. Sure, it may appear like even specialised tech media aren't interested in anything that isn't commercial. And some outlets do flat-out refuse to publish anything about anything FLOSS, or they only write about whoever pays them to write about them. But generally, they don't have an aversion against FLOSS alternatives to commercial products. Mass media helped Firefox spread. Mass media helped Diaspora* exceed their crowd-funding goal buy suggesting it'll be a Facebook killer. And mass media are right now accepting Mastodon and the Fediverse as the next big thing instead of some wacky nerd stuff. It may actually happen that media outlets which still reject the Fediverse in favour of Twitter will be seen as not only backwards-oriented, but outright right-wing.

It's hard to say how easy it'd be in 2023 to even only get tech media to write about Friendica, Hubzilla or even Streams. On the one hand, there may still be an attitude of, "Nobody wants to read about it if it wasn't launched with venture capital." On the other hand, the Fediverse itself has more than one foot in the door, what with journalists joining Mastodon and entire media outlets launching their own instances. All we have to do is get the knowledge into their heads that the Fediverse is more than Mastodon. Maybe they'll find this discovery so amazing that they'll write about it.

I think Friendica would be the easiest case. Okay, it'll be hard to treat something as cool new stuff if it has been around for 13 years or so. But it isn't so modular, it's more like an all-in-one "black box" of the kind that non-techy types prefer, and it concentrates on social networking and doesn't overwhelm its users with features, at least not that much. Also, it's the closes to being "to Facebook what Mastodon is to Twitter."

Hubzilla could mainly score with its sheer, all-encompassing power. It's certainly the most powerful, most versatile Fediverse project. This, however, may make it too powerful for casuals. It's also more modular than Friendica which means that many cool features, even including #ActivityPub support, have to be activated by the user. That said, Hubzilla's main issues, its user interface which capitulates before its vast amount of features, its documentation which reads more like a technical spec than a user manual and its outdated and less-than-welcoming representation on the Web, are being tackled as we speak (or rather type). Thanks to @Scott M. Stolz, Hubzilla may soon have one or multiple user interfaces that make it much easier to harness its vast power and flexibility.

Streams, or (streams) as some spell it, is still the odd one out. I must admit that even experienced Hubzilla veterans often have a hard time understanding what it actually is, much less Mastodon users, not to mention the GAFAM-only bubble. While bone-stock Streams itself is easier to use than Hubzilla, partly thanks to a reworked UI, partly thanks to lots of features having been cut and therefore no longer cluttering the UI, the whole concept may be confusing to many. It's not only even less of a "black box" than Hubzilla, it isn't a project or even a platform like Mastodon or Friendica at all; it's only a code repository which you can yoink and make something nice out of. Streams says, "Fork me!" It wasn't made to be run vanilla as a Zap successor which is a rather subversive idea. In fact, running Streams as-is is subverting the subversion again; it doesn't help that vanilla Streams makes for a decent Fediverse server already.

So Streams will be difficult to explain even to tinker-happy FLOSS people, its main target audience, and even more so to those who have only just left the commercial, corporate software bubble they had called their cosy home for many years and managed to wrap their minds around Mastodon. What Streams needs more than Hubzilla is reference implementations that show in practice rather than in theory what can be done with it. I mean, it's hard enough to grasp that Hubzilla can serve as a macroblog or a wiki until you've seen it happen with your own eyes.

A typical Hubzilla reference implementation would be a regular instance with all bells and whistles with open registration (until it's full, that is). People can join it, play around with it and make it their social homebase. Along with it, there could be Hubzilla instances that aren't social networking platforms but something different, yet still "powered by Hubzilla" as would be written on them. These could show Hubzilla's versatility. Something you were told is "something like Facebook" suddenly powers a blog. Or a community webpage, including a public event calendar. Or a wiki. Or a personal website with a personal DAV cloud server silently running in the background. Things that make Hubzilla get away with ActivityPub being optional, especially if these websites have nomadic clones. In this case, #Zot only serves to keep the clones in sync.

With Streams, the focus should be vice-versa. It'd be more important to show off what can be done on top of Streams or by forking Streams and making something nice and "unexpected" with it, preferably with multiple identical nomadic clones to show off what #Nomad can do, but still with a "powered by Streams" badge on it. A social networking platform or two could come later and mainly to demonstrate that Streams can do that, too. If this came first, Streams would be reduced to being "the next Friendica" or the next attempt at a Facebook competitor, and nobody would try to use it for anything else. Rather than that, Streams deserves a reputation as "nomadic WordPress" at the very least.

There's a lot that can be done to help these projects gain popularity. Some of it is already being done, especially for Hubzilla. And Streams can be given some time to take off, new as it is. Sitting around and waiting for people to come only gains us those who came from Twitter to Mastodon and then happened upon Friendica or Hubzilla through posts with over 500 characters.

♲ @[email protected]:

The Fediverse - A decision-making aid

There are four different protocols the #ActivitiPub, #Diaspora and #OStatus and there is also the #DFRN protocol which is as good as dead.

Mastodon is the number 1 network with over 4.000.000 users followed by Diaspora with over 600.000 members. On place 3 comes #Pleroma with over 30.000 members followed by #Hubzilla on place 4 with over 10.000 members and on place 5 comes #Friendica with almost 4.000 members.

According to this calculation it would be clear that #Mastodon is the clear winner but here the idea of the #Federation (Association) takes hold. Let's see who can communicate with whom and what the result is, start with the winner.

Mastodon can communicate with Pleroma, Hubzilla and Friendica so that results in 4.044.00 users.

Diaspora can communicate with Hubzilla and Friendica, resulting in a total of 614,000 users.

Pleroma can communicate with Mastodon, Hubzilla and Friendica and has a comparable reach to Mastodon of 4,044,000 members.

Hubzilla can communicate with Friendica and Pleroma, resulting in a reach of 44,000 members.

Friendica can communicate with Mastodon, Diaspora, Pleroma, and Hubzilla, resulting in a reach of 4,644,000 people.

Friendica is the clear winner in terms of reach. Now everyone just has to find out for themselves which platform suits them best.