#forte — 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

UNA STORIA DELLA GIOIA COLLETTIVA - presentazione del libro

CSOA Forte Prenestino, mercoledì 13 maggio alle ore 19:00 CEST

CSOA Forte Prenestino
mercoledì 13/05/2026
dalle 19:00 durante l’aperitivo

Forte Infoshop presenta:

UNA STORIA DELLA GIOIA COLLETTIVA
di Barbara Ehrenreich (Eleuthera 2024)

in dialogo con:
- Agnese 'macchina' Trocchi (circex.org)
- Antonio Rocca (Accademia Belle Arti di Viterbo)
- Ana Nitu (autrice di “Incognita K”)

///

Per diecimila anni l'umanità si è riunita nei campi, nelle piazze e persino nei templi per abbandonarsi a feste sfrenate e raggiungere, soprattutto con la danza, uno stato di beatitudine condivisa.
Questa millenaria abitudine in Occidente ha resistito fino al XVI secolo, per poi scomparire progressivamente.
Chi ha ucciso la gioia collettiva, e perché?
Questa indagine storica dà alcune risposte, ma è soprattutto un inno alla libertà di godere. Insieme.

Come testimoniano i rituali del Paleolitico, il culto di Dioniso o le pratiche danzanti del cristianesimo medievale, in passato le società umane hanno sempre dato vita a momenti di festa ed estasi collettiva. Un invito a «perdersi» che permetteva a ognuno di entrare in comunione diretta con gli altri (e con il divino).
Perché allora questa festività spontanea, un tempo così diffusa, oggi è quasi scomparsa, se non nella forma di un consumo passivo?
Perché il suo afflato liberatorio ha sempre più scatenato nelle élite il timore – in effetti giustificato – che questi raduni potessero sfidare le gerarchie sociali.
Così, in una repressione secolare che ha visto i protestanti criminalizzare il carnevale, i musulmani wahhabiti combattere il sufismo, i colonizzatori europei cancellare i riti estatici dei nativi, i raduni di massa hanno cominciato a essere irregimentati e istituzionalizzati.
E tuttavia le esplosioni di gioia collettiva, con la loro carica sovversiva, persistono tuttora. D'altronde, siamo esseri sociali, e la voglia di mascherarsi, danzare, irridere i potenti e condividere l'esultanza con dei perfetti sconosciuti non è affatto facile da reprimere.

https://www.eleuthera.it/scheda_libro.php?idlib=585

https://roma.convoca.la/event/storia-gioia-collettiva

@Kristian

Es ist freilich ein anderes Konzept als die portable Identität in Hubzilla. Wenn es "nur" letztere stabil über alle Fediverse-Dienste gäbe, wäre schon viel gewonnen.

Und genau die ist nur sehr schwer einzuführen.

Als allererstes müssen dafür die Grundlagen geschaffen werden. Die Technologie gibt es, aber die gibt es nur auf Forte, und vor allem gibt es sie nicht in Form eines vollständigen Satzes von FEPs, die definieren, wie das Ganze aufgebaut zu sein hat.

Wenn es FEPs gibt, wird man das Ganze jeweils pro Serveranwendung einführen müssen.

Das fängt damit an, daß das Konzept der Identität komplett umgeschmissen werden muß. Der Account darf nicht mehr die Identität sein. Die Identität, die Beiträge, die hochgeladenen Dateien, die Verbindungen, die Filter, die Einstellungen usw. usf., das darf nicht mehr direkt im Account liegen. Denn einen Account, einen Login, kann man nicht kopieren. Die Identität mit allem Drum und Dran muß vorher containerisiert und vom Account getrennt werden, und der Account dient dann nur noch als Login, um an den Container ranzukommen.

Das Containerisieren ist auch deshalb notwendig, weil man ja irgendwann vielleicht mal von oder nach Hubzilla oder (streams) oder Forte umziehen oder klonen will. Und da sind Identitäten als sogenannte "Kanäle" containerisiert und werden es auch bleiben.

Dann wird die Serversoftware das Klonen lernen müssen. Richtig gelesen: Das Klonen kommt vorm Umziehen. Denn das Umziehen basiert auf Klonen, das ist keine komplett separate Funktion. Beim Umziehen wird immer geklont. Sagen wir, du willst von foo.social nach bar.social umziehen:

1. Lege einen Account auf bar.social an.
2. Klone deinen Kanal nach bar.social.
3. Erkläre die Instanz deines Kanals auf bar.social zur Hauptinstanz; das macht die bisherige Hauptinstanz auf foo.social zum Klon.
4. Warte, bis die Umstellung der Hauptinstanz und die Änderung deiner Identität (die endet jetzt nicht mehr auf @foo.social, sondern auf @bar.social) sich überall ausgewirkt hat, wo sie soll.
5. Synchronisiere zur Sicherheit noch einmal nach.
6. Lösche die Instanz deines Kanals auf foo.social.
7. Wenn du auf deinem Account auf foo.social keine weiteren Kanäle hast, lösche den ganzen Account.

Auf Hubzilla, (streams) und Forte läuft das bis auf den ersten Schritt vollautomatisch so ab. Das heißt, du legst dir einen Account an und sagst dann, du willst in diesen neuen Account einen existierenden Kanal reinklonen oder wahlweise umziehen.

Problem: Damit es alleine hierfür die notwendigen FEPs gibt, wird irgendein Entwickler seine Serversoftware erstmal funktionsfähig bis zu diesem Stadium ausentwickeln müssen. Auf der Grundlage dieser Entwicklung können dann FEPs definiert werden.

Wenn das Klonen von Identitätscontainern innerhalb der Serversoftware funktioniert, kann man als nächstes den Automatismus in Angriff nehmen, der so einen Umzug durchführt für diejenigen, die wirklich nicht nur klonen, sondern komplett umziehen wollen.

Auch das braucht wieder das eine oder andere FEP, damit z. B. Serversoftware ABC nach erfolgtem Umzug von Serversoftware XYZ auf ebendieser Serversoftware XYZ einen Kanal und ggf. einen leeren Account löschen kann.

Dann heißt es warten, bis andere Fediverse-Software Klonen von bzw. nach wiederum anderer Fediverse-Software ermöglicht. Es bringt dir als Entwickler gar nichts, das Klonen nach Forte zu entwickeln, wenn Forte selbst das Reingeklontwerden von woanders noch gar nicht unterstützt.

Und genau hier liegt das nächste Problem: Wer wird das einführen?

Mastodon wird es nicht einführen. Erstens wäre das ein riesiger Umbauaufwand. Zweitens könnte Mastodon das nicht als Eigenerfindung verkaufen, und Mastodon wird todsicher kein neues Feature einbauen, das es dann nicht als Eigenerfindung und erstmalig überhaupt im Fediverse verfügbar verkaufen kann. Und drittens hat Gargron wohl immer noch genug Beef mit Mike Macgirvin, als daß er eine von Mikes Erfindungen nach Mastodon holen würde. OpenWebAuth ist ja auch still und leise abgelehnt worden, und das hat es bis zum mergefähigen Pull Request geschafft, der heute noch im Mastodon-GitHub-Repository liegt.

Misskey wird es nicht einführen. Misskey hat noch sehr viel größere, störende Baustellen und Bugs, die syuilo bis heute nicht angefaßt hat. Vielleicht liegt es auch daran, daß es Leute bräuchte, die das alles mal auf Gebrauchsjapanisch erklären, und zwar händisch übersetzt und nicht maschinell.

Wenn Misskey es nicht hat, ist es unwahrscheinlich, daß irgendwelche Forkeys es eigenmächtig einbauen.

Iceshrimp.NET wird es nicht einführen. Zum einen war es schon Aufwand genug, es so von Grund auf neu zu entwickeln, wie es jetzt ist (nichtnomadisch, Account = Identität). Zum anderen hat Iceshrimp.NET bis heute nicht mal Feature-Parität mit Iceshrimp-JS. Da ist an so ein Mammutprojekt wie nomadische Identität nicht zu denken.

Pleroma wird es nicht einführen. Das hat so einen unübersichtlichen Spaghetticode, daß seine eigenen Entwickler laufend daran scheitern, Bugs im Code zu lokalisieren, geschweige denn, sie zu fixen. Da ist an einen Totalumbau für nomadische Identität nicht zu denken.

Akkoma wird es auch nicht einführen. Im Prinzip ist es derselbe Spaghetticode, auch wenn die Entwickler ihn wohl schon ein bißchen entwirrt haben.

Friendica wird es nicht einführen. Wann hat Friendica das letzte Mal ein Feature von einem seiner Nachfahren übernommen? Das wäre im Prinzip ein Zugeständnis, daß Hubzilla und Mikes aktuelle Projekte doch etwas richtig machen. Friendica würde allerhöchstens nomadisch werden, wenn vorher Mastodon nomadisch wird.

Lemmy wird es nicht einführen. Lemmy hat noch nie versucht, mit irgendetwas kompatibel zu sein, das nicht Lemmy ist.

Am ehesten könnte ich das noch auf PeerTube eingeführt sehen. Das hat eh schon das Konzept von Kanälen und "klont" zumindest einzelne Videos per P2P zwecks Lastverteilung.

Relativ einfach dürfte es auch sein, wenn neue Projekte von vornherein nomadisch gemacht werden. Aber erstens wird auch das ein Mehraufwand. Zweitens werden selbst dann die allermeisten Serverentwickler nichts von nomadischer Identität wissen, wenn Mastodon sie nicht hat, weil sie das Fediverse jenseits von Mastodon kaum kennen. Drittens bauen die meisten ihre Serverprojekte eh hauptsächlich gegen Mastodon. Und viertens sind typische neue Fediverse-Projekte eher auf Minimalismus getrimmt, um etwas Leichteres als Mastodon zu haben.

#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Hubzilla #Streams #(streams) #Forte #NomadischeIdentität

Um mal die ersten drei Punkte einzeln anzugehen (Achtung @Mastodon-Nutzer, jetzt wird's extrem lang):

Leichteres und besseres Onboarding

Wie sieht denn heutzutage das Onboarding aus:

• man erfährt von Mastodon
• man lädt die offizielle Mastodon-App aufs Handy
• man ignoriert die Server-Voreinstellung mastodon.social
• Name, Paßwort, los

Was soll denn da noch mehr vereinfacht werden? Soll in Zukunft nicht nur das Fediverse (im Sinne des Gerade-eben-nicht-nur-Mastodon-Netzwerks) vor den Nutzern verschleiert werden, sondern auch die Dezentralität von Mastodon selbst? Sollen die Leute zwei Jahre lang glauben, Mastodon (bzw. das Fediverse, wenn sie von dem Begriff lesen) sei nur eine einzelne Website oder gar nur eine einzelne Handy-App?

Übrigens, falls das jemand noch nicht mitbekommen hat: Es gibt Nutzer im Fediverse außerhalb von Mastodon, die schon lange dagegen Sturm laufen, daß jedem Neuling das Fediverse als nur Mastodon dargestellt wird, weil das einfacher zu verstehen ist. Daran wiederum stören sich all diejenigen auf Mastodon, die lieber ein reines Mastodon-Fediverse hätten, weil sie zu lange an genau so ein reines Mastodon-Fediverse gewöhnt waren (das es so übrigens nie gab).

leichtere und bessere Migration von Accounts zwischen Instanzen (inkl. Portabilität von Accounts)

Die Technologie gibt's längst. Und ich rede nicht von Bluesky, das das nie unter Beweis gestellt hat.

Ich rede von nomadischer Identität, die schon 2012, fast vier Jahre vor dem Start von Mastodon, erstmals implementiert wurde. Kein grobes Konzept, kein Laborexperiment, sondern seit mehr als einem Jahrzehnt tagtäglich produktiv genutzte Technologie.

Der Hubzilla-Kanal, von dem ich hier jetzt gerade kommentiere, ist voll nomadisch. Ich könnte ihn mit allem, aber auch wirklich allem Drum und Dran auf einen anderen Hub verschieben. Ich bin aber noch weiter gegangen: Ich habe ihn geklont. Dieser Kanal existiert gleichzeitig auf zwei unabhängigen Hubs in zwei beinahe komplett identischen Instanzen, die fast in Echtzeit synchron gehalten werden. Sogar beide Male mit derselben Identität, auch wenn der weit überwiegende Teil des Fediverse das nicht wahrnehmen kann.

Seit 2024 geht nomadische Identität auf Forte sogar rein über ActivityPub.

Was allerdings bis heute nicht gelungen ist, ist, eine typische Fediverse-Serversoftware (nur ActivityPub, nicht nomadisch, Account/Login = Identität) serverseitig voll nomadisch zu machen, also auf demselben Niveau wie auf Hubzilla oder (streams) oder Forte. @silverpill hatte das mit Mitra vor, hat aber letzten Endes lieber einen Client entwickelt, der das erledigen soll.

So wird es bis auf weiteres vier riesige Hürden auf dem Weg zu dem vollnomadischen Fediverse geben, von dem längst schon geträumt worden ist:

• Existierende, nicht nomadische Fediverse-Software vollnomadisch zu machen, bedeutet einen gigantischen Totalumbau.
• Das ist so noch nie gemacht worden.
• Es ist auch bis heute noch nie gelungen, mittels nomadischer Identität über ActivityPub eine Fediverse-Identität von einer Software auf eine andere zu verschieben oder zu klonen. Auch das ist ein rein theoretisches Konzept, von dem keiner weiß, ob und wie gut es funktionieren kann.
• Selbst wenn das ginge, wird Mastodon sich mit Händen und Füßen dagegen sträuben, eine Technologie einzuführen, die ausgerechnet der Friendica- und Hubzilla-Erfinder Mike Macgirvin erfunden hat. Überhaupt baut Mastodon nur sehr ungern Dinge ein, die sie dann nicht als revolutionär neue komplette Eigenentwicklungen verkaufen können.

größere Benutzerfreundlichkeit

Und das wiederum kann nur heißen: Die existierenden Fediverse-Serveranwendungen müssen noch mehr wie die populären kommerziellen Silos aussehen und sich auch so bedienen.

Das heißt auf die Spitze getrieben: Das ganze Fediverse muß zu einem 1:1-Klon von Twitter werden. Mastodon muß die Oberfläche von Twitter nachbauen. Die offizielle Mastodon-App muß zu einem 1:1-Klon der Twitter-App werden. Und alles, was nicht Mastodon ist, muß "aus dem Fediverse ausgesperrt" werden, weil es Mastodon-Nutzer nur verwirrt.

CC für die im Thread, deren Fediverse-Anwendungen keine Konversationen unterstützen: @Kristian @samvie @candy in the wind @💀 Mirko 💀

#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #NichtNurMastodon #Hubzilla #Streams #(streams) #Forte #NomadischeIdentität #Onboarding

@Thomas Fricke (he/his) Da gibt's doch schon längst einige.

• Write Freely
  https://writefreely.org/
  https://fedidb.com/software/writefreely
  https://writefreely.fediverse.observer/list
  https://fedi.wrm.sr/software/writefreely
  Reine Bloggingsoftware mit puristischer, störungsfreier Oberfläche wie Medium. Kann allerdings leider (noch) keine Kommentare, und einen eingebauten Filespace für Bilder hat es auch nicht.
• Ghost
  https://ghost.org/
  Eigentlich ein Substack-Konkurrent, aber wenn man unbedingt etwas Zentralistisches will und keinen Bock hat, sich einen Server auszusuchen...
• WordPress kann mit dem Fediverse verbunden werden
  https://wordpress.org/plugins/activitypub/
  https://wordpress.com/support/enter-the-fediverse/
• Die Facebook-Alternativen können samt und sonders auch als vollwertige Bloggingplattformen mit allem Drum und Dran eingesetzt werden inklusive dazugehörigem Filespace und mit Features, die auf Mastodon unvorstellbar sind. Die können 𝕏 und Facebook und Bluesky und Medium (und womöglich auch noch andere Sachen) auf einen Schlag ersetzen.
  
  • Friendica
    https://friendi.ca
    https://de.wikipedia.org/wiki/Friendica
    https://joinfediverse.wiki/Friendica
    https://fedidb.com/software/friendica
    https://friendica.fediverse.observer/list
    https://fedi.wrm.sr/software/friendica
  • (streams)
    https://codeberg.org/streams/streams
  • Forte
    https://codeberg.org/fortified/forte
    https://forte.fediverse.observer/list
• Hubzilla bietet sogar noch mehr Features obendrauf. Da kann man z. B. auch Artikel einstellen, die nicht automatisch über das Fediverse verbreitet werden (kann man immer noch in föderierenden Beiträgen verlinken). Oder man kann Webpages anlegen oder Wikis. Es gibt für Hubzilla sogar mindestens ein Third-Party-Theme, das es optisch besser auf Blogging auslegt; das ist aber nicht auf allen Hubs verfügbar.
  https://hubzilla.org (die offizielle Hubzilla-Website ist selbst auf Hubzilla gebaut)
  https://de.wikipedia.org/wiki/Hubzilla
  https://joinfediverse.wiki/Hubzilla
  https://fedidb.com/software/hubzilla
  https://hubzilla.fediverse.observer/list
  https://fedi.wrm.sr/software/hubzilla

Alle im Fediverse, alle auch mit Mastodon verbunden (muß bei Hubzilla allerdings erst aktiviert werden). Und Friendica und Hubzilla gibt's beide sogar schon länger als Mastodon.

CC: @lj·rk @Marcus Rohrmoser 🌻

#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Medium #WriteFreely #Ghost #WordPress #Friendica #Hubzilla #Streams #(streams) #Forte #Blog #Blogs #Blogging

@Quasit I wouldn't build it on Mastodon. Nor would I build it from scratch and then against Mastodon, only Mastodon and nothing but Mastodon. The Fediverse is not only much more than Mastodon, but technologically much more diverse than just Mastodon.

The best way would be to build it as an add-on (a so-called "app") for (streams) or Forte. That way, you would neither have to deal with Mastodon's limitations (yes, Mastodon is very limited although this isn't apparent to those of its users who don't know anything else), nor would you have to develop Fediverse server software from scratch.

In case you don't know them:

(streams) is the unofficial community name of a very powerful but technically nameless Fediverse application whose code is in the streams repository (https://codeberg.org/streams/streams). It's essentially a Facebook-style social networking application with quite a number of extra features and the second-most recent member of a software family that dates all the way back to Friendica from 2010 (https://friendi.ca). It's a fork of a fork of three forks of a fork (of a fork?) of Hubzilla (https://hubzilla.org) which, in turn, was reworked from a fork of a fork of what's now Friendica.

And Forte (https://codeberg.org/fortified/forte) is a fork of the streams repository that's very similar to (streams) itself.

All this was originally done by one and the same developer, a professional in IT and software for close to half a century.

Here is an article I've put together with tables that compare Mastodon, Friendica, Hubzilla, (streams) and Forte: https://hub.netzgemeinde.eu/item/0a75de76-eb27-4149-b708-f20b2f79d392

Unlike Mastodon which has only got four general-purpose profile fields in addition to the profile text, both (streams) and Forte already come with the profile fields that a good dating app would need such as:

• pronouns (pick one out of 3 or none at all)
• birthday (from which the age is calculated)
• six free-text location fields, even including Facebook-style "hometown" where you used to live; you can select for yourself how far you want to go into detail with revealing your location
• gender (pick one out of 14 or none at all)
• marital status (pick one out of 31 or none at all) plus who plus date since
• sexual preference (pick one out of 9 or none at all)
• a separate keyword field
• political views
• religious views
• hobbies/interests
• likes
• dislikes
• other channels/Fediverse identities
• musical interests
• books/literature
• television
• film/dance/culture/entertainment
• love/romance
• work/employment
• school/education

A dating app could easily tie into the directory and make use of these profile fields. It could use a tag of its own in the keyword field so that it only shows channels that use this app (I'm not sure if it's possible to detect which channel has which apps installed).

One big advantage for users is that they don't have to use their daily-driver channel for the dating app. On Mastodon and in most of the Fediverse, your account is both your login and your identity. On (streams) and Forte, you can have multiple fully independent identities, each with its own name, its own ID, its own profile, its own contacts, its own posts and conversations, its own settings etc. etc., all behind one and the same login. It's like having multiple Mastodon accounts behind one login. That way, users don't have to reveal to everyone who knows their official daily-driver channel that they're using this dating app.

Also, Mastodon is hard-coded to 500 characters. You literally have to soft-fork it and edit the source code to change the limit. Both (streams) and Forte are essentially unlimited in characters (their actual character limit is over 24 million).

Privacy and security are much higher on (streams) and Forte than on Mastodon, in fact, much higher than most Fediverse users can even imagine. Private messages are actually literally private. On Mastodon, a direct message only defines whom it's sent to. On (streams) and Forte, permissions come into play. The start post in a conversation defines who is allowed to see the conversation. Not only that post, but all comments as well. It's literally impossible to pull someone else into an existing private conversation by mentioning because that someone simply isn't allowed to see anything in the conversation.

So when you're chatting with a woman via PM, and she dislikes you, she can't shame or dogpile you by pulling her friends into the conversation.

On top of that, although even Friendica already had quote-posts since 2010, private messages cannot be quote-posted.

For a developer, all it takes to build this is PHP plus database know-how. Like the whole rest of the family, (streams) and Forte don't need anything more than a LAMP stack. No Ruby on Rails, no Elixir, no TypeScript or Vue.js or any other JavaScript, no .NET.

Deploying a (streams) or Forte app is easy, too: Create a public git repository for it, keep it there, and server admins can add your repository to their servers and activate your app server-side. Both (streams) and Forte are very modular and designed to be easy to expand.

Most of this would be possible with Hubzilla as well which is much bigger in terms of users and available servers. However, Hubzilla has got one disadvantage: Its directory only shows Hubzilla and (streams) channels, i.e. channels that use Hubzilla's native Zot protocol. That's because ActivityPub support on Hubzilla is provided by another app, it's optional, it's off by default, and the directory can't tie into it. On (streams), ActivityPub support is still optional, but more advanced than on Hubzilla, built into the core and on by default. And Forte doesn't support anything else than ActivityPub.

In theory, it should be possible to build such a dating app for all three.

Also, yes, in theory, channels that use such a dating app can connect to Mastodon. But Mastodon users couldn't use that dating app. Mastodon simply doesn't have any support for profile fields which it itself doesn't have. Also, Mastodon is too unsecure, and meaningful conversations are difficult if one side is limited to 500 characters. And I would hate to see this dating app bound hard to Mastodon's culture and Mastodon's unwritten rules, neither of which take the Fediverse outside of Mastodon into account.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #NotOnlyMastodon #FediverseIsNotMastodon #MastodonIsNotTheFediverse #MastodonCulture #Hubzilla #Streams #(streams) #Forte #CharacterLimit #CharacterLimits #CharacterLimitMeta #CWCharacterLimitMeta #FediDate

@Quasit I wouldn't build it on Mastodon. Nor would I build it from scratch and then against Mastodon, only Mastodon and nothing but Mastodon. The Fediverse is not only much more than Mastodon, but technologically much more diverse than just Mastodon.

The best way would be to build it as an add-on (a so-called "app") for (streams) or Forte. That way, you would neither have to deal with Mastodon's limitations (yes, Mastodon is very limited although this isn't apparent to those of its users who don't know anything else), nor would you have to develop Fediverse server software from scratch.

In case you don't know them:

(streams) is the unofficial community name of a very powerful but technically nameless Fediverse application whose code is in the streams repository (https://codeberg.org/streams/streams). It's essentially a Facebook-style social networking application with quite a number of extra features and the second-most recent member of a software family that dates all the way back to Friendica from 2010 (https://friendi.ca). It's a fork of a fork of three forks of a fork (of a fork?) of Hubzilla (https://hubzilla.org) which, in turn, was reworked from a fork of a fork of what's now Friendica.

And Forte (https://codeberg.org/fortified/forte) is a fork of the streams repository that's very similar to (streams) itself.

All this was originally done by one and the same developer, a professional in IT and software for close to half a century.

Here is an article I've put together with tables that compare Mastodon, Friendica, Hubzilla, (streams) and Forte: https://hub.netzgemeinde.eu/item/0a75de76-eb27-4149-b708-f20b2f79d392

Unlike Mastodon which has only got four general-purpose profile fields in addition to the profile text, both (streams) and Forte already come with the profile fields that a good dating app would need such as:

• pronouns (pick one out of 3 or none at all)
• birthday (from which the age is calculated)
• six free-text location fields, even including Facebook-style "hometown" where you used to live; you can select for yourself how far you want to go into detail with revealing your location
• gender (pick one out of 14 or none at all)
• marital status (pick one out of 31 or none at all) plus who plus date since
• sexual preference (pick one out of 9 or none at all)
• a separate keyword field
• political views
• religious views
• hobbies/interests
• likes
• dislikes
• other channels/Fediverse identities
• musical interests
• books/literature
• television
• film/dance/culture/entertainment
• love/romance
• work/employment
• school/education

A dating app could easily tie into the directory and make use of these profile fields. It could use a tag of its own in the keyword field so that it only shows channels that use this app (I'm not sure if it's possible to detect which channel has which apps installed).

One big advantage for users is that they don't have to use their daily-driver channel for the dating app. On Mastodon and in most of the Fediverse, your account is both your login and your identity. On (streams) and Forte, you can have multiple fully independent identities, each with its own name, its own ID, its own profile, its own contacts, its own posts and conversations, its own settings etc. etc., all behind one and the same login. It's like having multiple Mastodon accounts behind one login. That way, users don't have to reveal to everyone who knows their official daily-driver channel that they're using this dating app.

Also, Mastodon is hard-coded to 500 characters. You literally have to soft-fork it and edit the source code to change the limit. Both (streams) and Forte are essentially unlimited in characters (their actual character limit is over 24 million).

Privacy and security are much higher on (streams) and Forte than on Mastodon, in fact, much higher than most Fediverse users can even imagine. Private messages are actually literally private. On Mastodon, a direct message only defines whom it's sent to. On (streams) and Forte, permissions come into play. The start post in a conversation defines who is allowed to see the conversation. Not only that post, but all comments as well. It's literally impossible to pull someone else into an existing private conversation by mentioning because that someone simply isn't allowed to see anything in the conversation.

So when you're chatting with a woman via PM, and she dislikes you, she can't shame or dogpile you by pulling her friends into the conversation.

On top of that, although even Friendica already had quote-posts since 2010, private messages cannot be quote-posted.

For a developer, all it takes to build this is PHP plus database know-how. Like the whole rest of the family, (streams) and Forte don't need anything more than a LAMP stack. No Ruby on Rails, no Elixir, no TypeScript or Vue.js or any other JavaScript, no .NET.

Deploying a (streams) or Forte app is easy, too: Create a public git repository for it, keep it there, and server admins can add your repository to their servers and activate your app server-side. Both (streams) and Forte are very modular and designed to be easy to expand.

Most of this would be possible with Hubzilla as well which is much bigger in terms of users and available servers. However, Hubzilla has got one disadvantage: Its directory only shows Hubzilla and (streams) channels, i.e. channels that use Hubzilla's native Zot protocol. That's because ActivityPub support on Hubzilla is provided by another app, it's optional, it's off by default, and the directory can't tie into it. On (streams), ActivityPub support is still optional, but more advanced than on Hubzilla, built into the core and on by default. And Forte doesn't support anything else than ActivityPub.

In theory, it should be possible to build such a dating app for all three.

Also, yes, in theory, channels that use such a dating app can connect to Mastodon. But Mastodon users couldn't use that dating app. Mastodon simply doesn't have any support for profile fields which it itself doesn't have. Also, Mastodon is too unsecure, and meaningful conversations are difficult if one side is limited to 500 characters. And I would hate to see this dating app bound hard to Mastodon's culture and Mastodon's unwritten rules, neither of which take the Fediverse outside of Mastodon into account.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #NotOnlyMastodon #FediverseIsNotMastodon #MastodonIsNotTheFediverse #MastodonCulture #Hubzilla #Streams #(streams) #Forte #CharacterLimit #CharacterLimits #CharacterLimitMeta #CWCharacterLimitMeta #FediDate

@Quasit I wouldn't build it on Mastodon. Nor would I build it from scratch and then against Mastodon, only Mastodon and nothing but Mastodon. The Fediverse is not only much more than Mastodon, but technologically much more diverse than just Mastodon.

The best way would be to build it as an add-on (a so-called "app") for (streams) or Forte. That way, you would neither have to deal with Mastodon's limitations (yes, Mastodon is very limited although this isn't apparent to those of its users who don't know anything else), nor would you have to develop Fediverse server software from scratch.

In case you don't know them:

(streams) is the unofficial community name of a very powerful but technically nameless Fediverse application whose code is in the streams repository (https://codeberg.org/streams/streams). It's essentially a Facebook-style social networking application with quite a number of extra features and the second-most recent member of a software family that dates all the way back to Friendica from 2010 (https://friendi.ca). It's a fork of a fork of three forks of a fork (of a fork?) of Hubzilla (https://hubzilla.org) which, in turn, was reworked from a fork of a fork of what's now Friendica.

And Forte (https://codeberg.org/fortified/forte) is a fork of the streams repository that's very similar to (streams) itself.

All this was originally done by one and the same developer, a professional in IT and software for close to half a century.

Here is an article I've put together with tables that compare Mastodon, Friendica, Hubzilla, (streams) and Forte: https://hub.netzgemeinde.eu/item/0a75de76-eb27-4149-b708-f20b2f79d392

Unlike Mastodon which has only got four general-purpose profile fields in addition to the profile text, both (streams) and Forte already come with the profile fields that a good dating app would need such as:

• pronouns (pick one out of 3 or none at all)
• birthday (from which the age is calculated)
• six free-text location fields, even including Facebook-style "hometown" where you used to live; you can select for yourself how far you want to go into detail with revealing your location
• gender (pick one out of 14 or none at all)
• marital status (pick one out of 31 or none at all) plus who plus date since
• sexual preference (pick one out of 9 or none at all)
• a separate keyword field
• political views
• religious views
• hobbies/interests
• likes
• dislikes
• other channels/Fediverse identities
• musical interests
• books/literature
• television
• film/dance/culture/entertainment
• love/romance
• work/employment
• school/education

A dating app could easily tie into the directory and make use of these profile fields. It could use a tag of its own in the keyword field so that it only shows channels that use this app (I'm not sure if it's possible to detect which channel has which apps installed).

One big advantage for users is that they don't have to use their daily-driver channel for the dating app. On Mastodon and in most of the Fediverse, your account is both your login and your identity. On (streams) and Forte, you can have multiple fully independent identities, each with its own name, its own ID, its own profile, its own contacts, its own posts and conversations, its own settings etc. etc., all behind one and the same login. It's like having multiple Mastodon accounts behind one login. That way, users don't have to reveal to everyone who knows their official daily-driver channel that they're using this dating app.

Also, Mastodon is hard-coded to 500 characters. You literally have to soft-fork it and edit the source code to change the limit. Both (streams) and Forte are essentially unlimited in characters (their actual character limit is over 24 million).

Privacy and security are much higher on (streams) and Forte than on Mastodon, in fact, much higher than most Fediverse users can even imagine. Private messages are actually literally private. On Mastodon, a direct message only defines whom it's sent to. On (streams) and Forte, permissions come into play. The start post in a conversation defines who is allowed to see the conversation. Not only that post, but all comments as well. It's literally impossible to pull someone else into an existing private conversation by mentioning because that someone simply isn't allowed to see anything in the conversation.

So when you're chatting with a woman via PM, and she dislikes you, she can't shame or dogpile you by pulling her friends into the conversation.

On top of that, although even Friendica already had quote-posts since 2010, private messages cannot be quote-posted.

For a developer, all it takes to build this is PHP plus database know-how. Like the whole rest of the family, (streams) and Forte don't need anything more than a LAMP stack. No Ruby on Rails, no Elixir, no TypeScript or Vue.js or any other JavaScript, no .NET.

Deploying a (streams) or Forte app is easy, too: Create a public git repository for it, keep it there, and server admins can add your repository to their servers and activate your app server-side. Both (streams) and Forte are very modular and designed to be easy to expand.

Most of this would be possible with Hubzilla as well which is much bigger in terms of users and available servers. However, Hubzilla has got one disadvantage: Its directory only shows Hubzilla and (streams) channels, i.e. channels that use Hubzilla's native Zot protocol. That's because ActivityPub support on Hubzilla is provided by another app, it's optional, it's off by default, and the directory can't tie into it. On (streams), ActivityPub support is still optional, but more advanced than on Hubzilla, built into the core and on by default. And Forte doesn't support anything else than ActivityPub.

In theory, it should be possible to build such a dating app for all three.

Also, yes, in theory, channels that use such a dating app can connect to Mastodon. But Mastodon users couldn't use that dating app. Mastodon simply doesn't have any support for profile fields which it itself doesn't have. Also, Mastodon is too unsecure, and meaningful conversations are difficult if one side is limited to 500 characters. And I would hate to see this dating app bound hard to Mastodon's culture and Mastodon's unwritten rules, neither of which take the Fediverse outside of Mastodon into account.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #NotOnlyMastodon #FediverseIsNotMastodon #MastodonIsNotTheFediverse #MastodonCulture #Hubzilla #Streams #(streams) #Forte #CharacterLimit #CharacterLimits #CharacterLimitMeta #CWCharacterLimitMeta #FediDate

@Quasit I wouldn't build it on Mastodon. Nor would I build it from scratch and then against Mastodon, only Mastodon and nothing but Mastodon. The Fediverse is not only much more than Mastodon, but technologically much more diverse than just Mastodon.

The best way would be to build it as an add-on (a so-called "app") for (streams) or Forte. That way, you would neither have to deal with Mastodon's limitations (yes, Mastodon is very limited although this isn't apparent to those of its users who don't know anything else), nor would you have to develop Fediverse server software from scratch.

In case you don't know them:

(streams) is the unofficial community name of a very powerful but technically nameless Fediverse application whose code is in the streams repository (https://codeberg.org/streams/streams). It's essentially a Facebook-style social networking application with quite a number of extra features and the second-most recent member of a software family that dates all the way back to Friendica from 2010 (https://friendi.ca). It's a fork of a fork of three forks of a fork (of a fork?) of Hubzilla (https://hubzilla.org) which, in turn, was reworked from a fork of a fork of what's now Friendica.

And Forte (https://codeberg.org/fortified/forte) is a fork of the streams repository that's very similar to (streams) itself.

All this was originally done by one and the same developer, a professional in IT and software for close to half a century.

Here is an article I've put together with tables that compare Mastodon, Friendica, Hubzilla, (streams) and Forte: https://hub.netzgemeinde.eu/item/0a75de76-eb27-4149-b708-f20b2f79d392

Unlike Mastodon which has only got four general-purpose profile fields in addition to the profile text, both (streams) and Forte already come with the profile fields that a good dating app would need such as:

• pronouns (pick one out of 3 or none at all)
• birthday (from which the age is calculated)
• six free-text location fields, even including Facebook-style "hometown" where you used to live; you can select for yourself how far you want to go into detail with revealing your location
• gender (pick one out of 14 or none at all)
• marital status (pick one out of 31 or none at all) plus who plus date since
• sexual preference (pick one out of 9 or none at all)
• a separate keyword field
• political views
• religious views
• hobbies/interests
• likes
• dislikes
• other channels/Fediverse identities
• musical interests
• books/literature
• television
• film/dance/culture/entertainment
• love/romance
• work/employment
• school/education

A dating app could easily tie into the directory and make use of these profile fields. It could use a tag of its own in the keyword field so that it only shows channels that use this app (I'm not sure if it's possible to detect which channel has which apps installed).

One big advantage for users is that they don't have to use their daily-driver channel for the dating app. On Mastodon and in most of the Fediverse, your account is both your login and your identity. On (streams) and Forte, you can have multiple fully independent identities, each with its own name, its own ID, its own profile, its own contacts, its own posts and conversations, its own settings etc. etc., all behind one and the same login. It's like having multiple Mastodon accounts behind one login. That way, users don't have to reveal to everyone who knows their official daily-driver channel that they're using this dating app.

Also, Mastodon is hard-coded to 500 characters. You literally have to soft-fork it and edit the source code to change the limit. Both (streams) and Forte are essentially unlimited in characters (their actual character limit is over 24 million).

Privacy and security are much higher on (streams) and Forte than on Mastodon, in fact, much higher than most Fediverse users can even imagine. Private messages are actually literally private. On Mastodon, a direct message only defines whom it's sent to. On (streams) and Forte, permissions come into play. The start post in a conversation defines who is allowed to see the conversation. Not only that post, but all comments as well. It's literally impossible to pull someone else into an existing private conversation by mentioning because that someone simply isn't allowed to see anything in the conversation.

So when you're chatting with a woman via PM, and she dislikes you, she can't shame or dogpile you by pulling her friends into the conversation.

On top of that, although even Friendica already had quote-posts since 2010, private messages cannot be quote-posted.

For a developer, all it takes to build this is PHP plus database know-how. Like the whole rest of the family, (streams) and Forte don't need anything more than a LAMP stack. No Ruby on Rails, no Elixir, no TypeScript or Vue.js or any other JavaScript, no .NET.

Deploying a (streams) or Forte app is easy, too: Create a public git repository for it, keep it there, and server admins can add your repository to their servers and activate your app server-side. Both (streams) and Forte are very modular and designed to be easy to expand.

Most of this would be possible with Hubzilla as well which is much bigger in terms of users and available servers. However, Hubzilla has got one disadvantage: Its directory only shows Hubzilla and (streams) channels, i.e. channels that use Hubzilla's native Zot protocol. That's because ActivityPub support on Hubzilla is provided by another app, it's optional, it's off by default, and the directory can't tie into it. On (streams), ActivityPub support is still optional, but more advanced than on Hubzilla, built into the core and on by default. And Forte doesn't support anything else than ActivityPub.

In theory, it should be possible to build such a dating app for all three.

Also, yes, in theory, channels that use such a dating app can connect to Mastodon. But Mastodon users couldn't use that dating app. Mastodon simply doesn't have any support for profile fields which it itself doesn't have. Also, Mastodon is too unsecure, and meaningful conversations are difficult if one side is limited to 500 characters. And I would hate to see this dating app bound hard to Mastodon's culture and Mastodon's unwritten rules, neither of which take the Fediverse outside of Mastodon into account.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #NotOnlyMastodon #FediverseIsNotMastodon #MastodonIsNotTheFediverse #MastodonCulture #Hubzilla #Streams #(streams) #Forte #CharacterLimit #CharacterLimits #CharacterLimitMeta #CWCharacterLimitMeta #FediDate

@ValorZard No dice.

First of all, implementing nomadic identity would drastically alter the way how Mastodon works. It would make Mastodon, something that's supposed to be dead-simple, a great deal more complex.

I mean, in order to really pull this through all the way (as in Hubzilla/(streams)/Forte-level nomadic identity), your identity, your posts, your followers, your followed, your settings, your filters, your everything, all this must no longer directly reside in your account. It must be containerised in something that Hubzilla calls "channel", and that container would then reside in your account and be able to reside in multiple accounts on multiple independent servers.

Next, when Mastodon introduces a new feature, they tend to try to market it as their own original pioneering invention. They can't do that with nomadic identity. There are already enough people who know that nomadic identity was actually pioneered by Hubzilla before Mastodon even existed.

Furthermore, before Gargron implements something invented by Mike Macgirvin, hell will freeze over. Even if he tried to sell it as a unique feature of Mastodon, he'd still secretly have to admit that there's something that Mike did right. And quite a few eyes would be on him in hope of Mastodon getting more features from stuff created by Mike.

Ever heard of OpenWebAuth magic sign-on? Invented by Mike for Osada and Zap in the late 2010s, then backported to Hubzilla.

It was proposed for Mastodon, even if it was only client-side (as in, Mastodon logins would be detected by Hubzilla, (streams) and Forte, but Mastodon wouldn't be able to detect OpenWebAuth logins itself). This went as far as a merge request on GitHub. It could have been built into Mastodon. The code was literally there.

The merge request was silently rejected. And that would have been a fairly small change in comparison to the complete rebuild that'd be necessary for a full-blown, Forte-level, server-side implementation of nomadic identity.

I mean, @silverpill had to implement nomadic identity on Mitra client-side. That wouldn't be possible on Mastodon, what with every other Fediverse app being a Mastodon client. Mastodon would require a server-side implementation.

Seriously, it'd be easier to strap Mastodon's Web UI to Forte or Hubzilla with the necessary changes to adapt it to a vastly different backend.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Hubzilla #Streams #(streams) #Forte #Mitra #FEP_ef61 #NomadicIdentity

@silverpill Would be interesting to add Hubzilla's Zot6 and (streams)' Nomad (which would be Zot12 if it wasn't incompatible with Zot6) to the list.

By the way: Forte doesn't require a gateway to communicate with non-nomadic ActivityPub. A fully cloned Forte channel can communicate with a Mastodon account without jumping through hoops. Remember that Forte has almost fully-featured Hubzilla-level nomadic identity (i.e. everything except real-time syncing between channel instances; unlike Hubzilla and (streams) which do sync in real time, it needs a cronjob for that) directly built into its core.

(streams) does support nomadic identity via ActivityPub. But internally, it uses and relies upon Nomad for its nomadic identity. It only supports nomadic identity via ActivityPub a) because it was used as a development platform for just this and b) in order to be able to understand cloned nomadic ActivityPub actors elsewhere. This is also why it isn't possible to move from (streams) to Forte, to move from Forte to (streams) or to clone between (streams) and Forte.

(streams) itself doesn't require gateways to communicate with Mastodon & Co. either. It speaks three protocols natively: its own Nomad, Hubzilla's Zot6 and (optionally, but on by default) standard ActivityPub.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #ActivityPub #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #Forte #NomadicIdentity

@silverpill @Connected Places The problem with the Mastodon client API is still that it's a Mastodon API. As in, geared towards only one Fediverse server application. In fact, as in, geared towards a very lack-lustre server application that lacks features which have been present in many other places in the Fediverse for years.

This means that you can use a whole lot of microblogging server applications with Mastodon clients. You can even use Friendica with some Mastodon clients. But then you're limited to the features which Mastodon has as well because the Mastodon client API doesn't support any features that Mastodon doesn't have. Why should it, after all?

At the end of the day, the Mastodon client API is designed and maintained by the Mastodon developers. It's them who decide what it can do and what it can't do. For one, they won't waste their time adding features to it that Mastodon itself doesn't have. Besides, if they did, they'd support Mastodon's direct competition and strengthen their advantages over Mastodon when they could throw rocks into their paths instead like they've always done.

This, by the way, is also one reason why both the developers of Hubzilla and the developer of (streams) and Forte refuse to implement the Mastodon client API. It simply wouldn't cover at least 90% of the features of these server applications, including features which you'll need all the time, everyday. That, and they don't want their software to end up at the mercy of Mastodon's developers and Mastodon's product politics by making it depend on Mastodon's technology. They'd rather have no native mobile app at all (and currently they do).

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Hubzilla #Streams #(streams) #Forte #MastodonAPI #MastodonClientAPI

@洪 民憙 (Hong Minhee) :nonbinary: Two people you may consider consulting in this case:

• @Mike Macgirvin ?️. He invented nomadic identity in 2011. He was the first to implement it in Red (which became Hubzilla in 2015) in 2012.
  His streams repository, a fork of a fork of three forks of a fork (of a fork?) of Hubzilla, is the place where he laid the foundations of FEP-ef61 out of necessity because he was working on nomadic identity via ActivityPub (Hubzilla and (streams) use their own protocols for that), and it was the first nomadic server software that had it implemented.
  Also, his Forte, itself a fork of the streams repository, is the only Fediverse server software that uses nothing but ActivityPub to establish nomadic identity and relies on FEP-ef61 to do that. Basically, it's (streams) with no Nomad and Zot6 support, and syncing between clones is triggered by a cronjob because, unlike Zot6 and Nomad, ActivityPub doesn't provide any ways to trigger immediate, near-real-time syncs.
  Mike hasn't been caught online for quite a while, though, although he's still working on both (streams) and Forte.
• @silverpill is gradually turning Mitra from a typical non-nomadic, account/login-equals-identity, one-identity-per-account Fediverse software into something that's every bit as nomadic as Hubzilla, (streams) and Forte while casting everything necessary for this process into FEPs.
  I'm not sure whether this will include containerising identities like the channels on Hubzilla, (streams) and Forte and allowing multiple fully independent identities on the same account, just like the same identity (channel) would be able to exist on independent accounts on different servers.

That said, is your goal only to use FEP-ef61 for identities that are tied to their accounts and their servers? Or is your goal fully-fledged nomadic identity on the same level as on Forte?

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hubzilla #Streams #(streams) #Forte #Mitra #NomadicIdentity #FEP_ef61

@zotheca @Stefan Bohacek It isn't the title field. It's the summary field. It has been the summary field since Evan Prodromou added it to Identi.ca in 2008. And it only became a CW field when a Mastodon user for the demo scene submitted a merge request to Mastodon's GitHub repository in 2017 which repurposed this summary field, unused by Mastodon at this point, as a CW field.

My own POV on this is a whole lot different from typical Mastodon POVs. I've joined the Fediverse on Friendica in the early 2010s as opposed to on Mastodon in the 2020s before I moved on to fledgling Hubzilla.

Now, both Friendica and Hubzilla as well as the whole rest of the family (of which (streams) of 2021 and Forte of 2024 still exist) have a nifty optional feature called "NSFW": It's a list of keywords which, if detected in a message, hide the entire message behind a button. Much like the hiding feature in Mastodon's filters, only not built into the actual filters, much more simple and over 12 years older than Mastodon's solution.

In this software family, the NSFW feature is not perceived as a filter, even though it's very similar to the actual channel-wide filters (which, by the way, are among the few things which are more simple even on Hubzilla than on Mastodon because they've only got two keyword lists, an allowlist and a blocklist).

Rather, it's seen as an automated, individual, reader-side CW generator. It's deeply engrained into the culture of these Fediverse server applications which is a great deal different from Mastodon's culture. And it's seen as vastly superior to poster-side CWs that are forced upon all readers all the same.

A takeaway from this software family: If you write a potentially sensitive post, and you have no way of artificially weaving NSFW-triggering keywords into the actual post text, add them to the bottom line as hashtags. I do that all the time, hence the hashtags that start with "CW" to make clear that they're supposed to trigger reader-side CW generators.

By the way, the Friendica and Hubzilla inventor and (streams) developer Mike Macgirvin proposed two catch-all hashtags for sensitive posts to the (streams) users (that was before he forked Forte off the streams repository). One is #sensitive which also has the side-effect that (streams) and potentially also Forte make Mastodon blank out all images in the post. The other one is #⚠️. Or, if your post is really disturbing, #⚠️⚠️⚠️⚠️⚠️. However, this has yet to find its way into Hubzilla, not to mention Friendica or even Mastodon and the rest of the Fediverse.

As for the summary field, if Mastodon actually managed to push its entire community away from fixed poster-side CWs towards automated reader-side CWs, the whole field would be useless. I mean, Mastodon didn't support it at all before it had a CW field because, frankly, you don't need summaries for 500 characters.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #CW #CWs #CWMeta #ContentWarning #ContentWarnings #ContentWarningMeta #Hashtag #Hashtags #HashtagMeta #CWHashtagMeta #Filter #Filters #Mastodon #MastodonCulture #Friendica #Hubzilla #Streams #(streams) #Forte