#zot — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #zot, aggregated by home.social.
-
@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 -
One of my fears of homelabbing is the reliance on (3rd party) #Docker/#container images that could just be gone someday. I've already had it happen once, with #Bitnami images (fuck #Broadcom).
One way I previously thought to combat this is to manually pull the image bundle and host it in your own container registry. This works, but obviously not a reasonable effort to do and reproduce for more than ~1-2 images.
Then, the moment I discovered #Amazon/#AWS has such a thing that addresses this - pull through cache for their #ECR, I looked up on how I can have the same kind of setup on my #homelab, and sure enough, there are already several options. I went with #Zot, and it's working pretty freaking well. Now, anytime I pull any images from registries I've configured Zot to sync like #GitHub'sghcr.io,docker.io,public.ecr.aws, they'll all be pulled/cached first on my own Zot instance and stored for good there.
Man, I wish I looked into this much earlier - but better late than never.
🔗 https://github.com/project-zot/zot
🔗 https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html -
@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 -
I've been mostly heads down in the #OCI conformance test redesign. But I managed to ship a new #regclient release yesterday with a feature that will hopefully help the #zot registry.
-
#^Hubzilla und das Grid - Wo lässt sich Hubzilla eigentlich einordnen?Im Zusammenhang mit Hubzilla liest man immer wieder vom "Grid".
Was ist damit denn gemeint? ...
..:: WEITERLESEN ::..
#hubzilla #grid #cms #wordpress #ghost #fediverse #zot #activitypub -
@Gaming on the Fediverse That's quite a bit simplified. For one, four server applications and one protocol were lumped together. Besides, Zap is dead, and Forte isn't even mentioned.
So here's an attempt at telling the whole story (server applications are in bold type, protocols are in bold type and italics):
tl;dr:
2010:- DFRN
- Mistpark/Friendika/Friendica
(DFRN)
- Zot
- Free-Friendika
(DFRN)
(forked from Friendika) - several other Friendika forks
(DFRN)
(forked from Friendika)
(discontinued 2011) - Red/Red Matrix
(DFRN, from 2012 Zot)
(forked from Free-Friendika)
(rebuilt into Hubzilla 2015)
- Hubzilla
(Zot, later Zot6)
(rebuilt from the Red Matrix)
- Zot6
- Osada
(Zot6)
(forked from Hubzilla)
(discontinued in 2018) - Zap
(Zot6)
(forked most likely from Osada, maybe from Hubzilla)
(discontinued in 2022) - Osada
(Zot6)
(forked from Zap)
(discontinued in 2019)
- Zot8
- Redmatrix 2020
(Zot8)
(forked from either Zap or Mistpark 2020 or (the third) Osada)
(discontinued in 2022) - Mistpark 2020 a.k.a. Misty
(Zot8)
(forked from either Zap or Redmatrix 2020 or (the third) Osada)
(discontinued in 2022) - Osada
(Zot8)
(forked from either Zap or Redmatrix 2020 or Mistpark 2020)
(discontinued in 2022)
- Nomad
(originally Zot11) - Roadhouse
(Nomad)
(forked from either Redmatrix 2020 or Mistpark 2020 or (the third) Osada)
(discontinued in 2022) - (streams)
(Nomad)
(forked from Roadhouse)
Forte
(ActivityPub)
(forked from (streams))[/list]
So as far as Fediverse server applications go, he created Friendica, Free-Friendika, a few more Friendika forks, the Red Matrix, Hubzilla, three Osadas, Zap, Redmatrix 2020, Mistpark 2020, Roadhouse, (streams) and Forte. Depending on how you want to count them, that's at least 13 or 14 server applications. Four of these are still being maintained (Friendica by a new team, Hubzilla by another new team, (streams) and Forte by himself).
The long version:
In 2010, he created- the DFRN protocol
- Mistpark (renamed first into Friendika later in 2010 and then into Friendica in 2011)
In 2011, he made several forks of Friendika. The reason was licensing: Friendika was getting quite some attention. As it was under the MIT license, chances were that it was tempting to fork it and turn the fork into a commercial, proprietary, closed-source monolith or something. On the other hand, the GPL in any shape or form would have hindered further development.
So Mike made a number of forks and relicensed all but one: Free-Friendika kept the MIT license and became the main development platform for Friendika. Friendika itself was relicensed under the AGPLv3.
Shortly afterwards, Mike discontinued all forks except Free-Friendika.
The same year, Mike needed something to keep people from losing everything whenever their Friendika home node was shut down. So he invented nomadic identity and created the Zot protocol.
Also the same year, Mike forked Free-Friendika into Red (spanish la red = the network). It would be renamed Red Matrix in late 2012 because "Red" is hard to Google.
In 2012, Mike rewrote Red almost completely. The whole backend was rebuilt against Zot.
However, the Red Matrix didn't take off. Most Friendica users were hosting their own private nodes. Nomadic identity made no sense for them. Besides, it seemed like many Friendica users didn't understand nomadic identity anyway, so they saw no advantage in the Red Matrix over Friendica, seeing as the features were almost identical otherwise. The Red Matrix had to be made more popular for hosting public servers.
So in 2015, the Red Matrix was rebuilt and greatly expanded into Hubzilla.
In 2018, Mike wanted to develop the Zot protocol further into Zot6. But this would have meant compatibility-breaking changes, also because what he wanted to do with nomadic identity over Zot6 was likely to not work with non-nomadic protocols anymore. So he couldn't do that on Hubzilla.
Instead, he made two new forks:- first Osada, forked from Hubzilla, which was the original Zot6 development platform and then evolved into a non-nomadic "gateway" between Zot6 and everything else
- then Zap, forked most likely from Osada or maybe from Hubzilla, which got the whole Zot6 feature set, including nomadic identity, but which lost support for any and all non-nomadic protocols
A bit later, Zot6 became compatible enough with non-nomadic protocols. Forwarding content from Zap via Osada to the rest of the Fediverse was clunky anyway, forwarding content from the rest of the Fediverse via Osada to Zap even more so. So Osada was discontinued.
Instead, a new Osada was forked from Zap and got ActivityPub support. This and the branding were the only differences between Osada and Zap.
In 2019, when both Osada and Zap had become stable, Zap got ActivityPub support itself. The only difference between the two was now that Osada servers had ActivityPub turned on by default, and Zap servers had it turned off by default. It simply didn't make much sense to keep both alive, so Osada was discontinued again.
I think it was also in 2019 that Hubzilla was upgraded to Zot6.
In 2020, Mike made three more forks to develop Zot8, at least one of which was forked from Zap, and those that weren't were forked from one another: Redmatrix 2020, Mistpark 2020 a.k.a. Misty and Osada.
There was a rumour that Zap was the stable one, Misty was a bit more up-to-date, but potentially less stable, Osada was experimental with ActivityPub support on by default, and Redmatrix 2020 was experimental with ActivityPub support off by default. In fact, however, Misty, Osada and Redmatrix 2020 were absolutely identical in all but branding. Mike kept four server applications around to mess with brand fetishists.
In 2022, Mike forked one of the three into Roadhouse to develop Zot11. But Zot11 was no longer compatible with Zot6 as implemented on Hubzilla and Zap, so he declared it a new protocol named Nomad. Roadhouse got additional support for Zot6.
Now Mike had five server applications, still in order to mess with brand fetishists.
Later the same year, Mike forked Roadhouse into something intentionally nameless and brandless. Again, this was done to troll brand fetishists, this time also to facilitate forking and make people think up their own individual names for the fork rather than keeping the existing one. However, the code repository absolutely required a name, so Mike called it streams.
The community needed something to name this nameless thing by, so they took the name of the repository and wrapped it in parentheses to make sure that this is not actually the name. Ever since, it is colloquially being called (streams). By the way, (streams) is running on what would be Zot12 if it wasn't Nomad now.
On New Year's Eve 2022, Mike discontinued Zap, Redmatrix 2020, Misty, Osada and Roadhouse. (streams) was stable enough, and the other five could be upgraded not only to each other by rebasing the server code, but also to (streams). He asked all admins of Zap, Redmatrix 2020, Misty, Osada and Roadhouse servers to upgrade to (streams).
In 2024, (streams) got bogged down by some identity confusion after the stable release branch introduced decentralised IDs as per FEP-ef61, a part of the development of nomadic identity via ActivityPub. Partially in order to be able to sort this out, partially because the time seemed to have come for this to actually work, Mike forked the streams repository into Forte and removed all support for any protocols other than ActivityPub while still keeping it nomadic. And so Forte became the very first Fediverse server application that establishes nomadic identity via ActivityPub.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #DFRN #Zot #Zot6 #Zot8 #Nomad #Mistpark #Friendika #FreeFriendika #Friendica #Red #RedMatrix #Hubzilla #Osada #Zap #Redmatrix2020 #Mistpark2020 #Misty #Roadhouse #Streams #(streams) #Forte -
@jupiter_rowland @growfediverse
Mike Macgirvin is credited for 5 projects on (#)Wikidata:
1️⃣ Friendica (developer)
2️⃣ Hubzilla (dev)
3️⃣ streams (dev)
4️⃣ Zap (dev)
5️⃣ Zot (dev)https://www.wikidata.org/wiki/Special:WhatLinksHere/Q114669840
#Wikidata #MikeMacgirvin #Friendica #Hubzilla #streams #Zap #Zot
-
"Many of these [Zot/Nomad] ]ideas are being ported to ActivityPub in the form of Fediverse Enhancement Proposals (FEPs).
... Streams ... is working with Mitra to create the first implementation of nomadic identity over ActivityPub. This includes working on several related FEPs about identity proofs and conversation containers.
Our goal is for these technologies to spread throughout the fediverse."
-
@Thomas Eibich aka DK2NB
Bauen die Workshops aufeinander auf oder kann man auch einfach so mal vorbei kommen?
Wir haben jedes Mal Leute dabei, die zum ersten Mal bei der Sprechstunde sind und häufig auch erst seit kurzem überhaupt im Fediverse. Das ist also kein Problem. Und da baut auch nichts aufeinander auf.Was ist Hubzilla?
Oh, da muß ich weit ausholen. (Ich kommentiere übrigens gerade von Hubzilla.)
Hubzilla ist das absolute, ultimative Featuremonster im Fediverse. Eine Art Alleskönner, der Features hat, die für die allermeisten Fediverse-Nutzer im Fediverse völlig unvorstellbar sind, aber auch Features, die sich viele im Fediverse wünschen. Wohlgemerkt, ohne zu wissen, daß es diese Features im Fediverse längst gibt.
Hubzilla ist im Prinzip "Facebook trifft WordPress trifft Google Cloud Services trifft noch mehr Zeug" im Fediverse, und es kann mit wenigen Mausklicks aufgebohrt werden zu "Facebook trifft WordPress trifft Google Cloud Services trifft Joplin trifft GeoCities trifft <irgendeine Wiki-Engine hier einsetzen> trifft noch mehr Zeug" im Fediverse. Ja, GeoCities. Man kann buchstäblich Webseiten auf Hubzilla aufbauen.
Hier sind ein paar Links:- offizielle Website (die übrigens selbst auf Hubzilla läuft)
- Wikipedia auf Deutsch (zugegeben, das Lemma ist nicht sehr gut)
- GNULinux.ch: Hubzilla, die mächtige ungeschminkte Königin des Fediverse
- Ein paar Tabellen, in denen ich Mastodon vergleiche mit Friendica (Hubzilla-Vorfahr), Hubzilla selbst, (streams) und Forte (zwei Hubzilla-Nachfahren)
Hubzilla ist übrigens älter als Mastodon.
Hubzillas Vater ist @Mike McCue , ein pensionierter professioneller Software-Entwickler mit fast einem halben Jahrhundert an Erfahrung. Der hat schon 2010, noch vor dem in dem Sommer in den Himmel gehypeten diaspora*, eine extrem vielseitige und extrem leistungsfähige freie, quelloffene, dezentrale Facebook-Alternative gestartet, die ursprünglich Mistpark hieß und heute als Friendica bekannt ist. Die gibt's heute hoch, sie ist Teil des Fediverse, und sie ist mit Mastodon föderiert, seit es Mastodon gibt.
Friendica ist kein Facebook-Klon, sondern eine Facebook-Alternative, die grundsätzlich dieselbe Funktion haben soll wie Facebook, aber besser als Facebook ist. Friendica kann nebenher auch genutzt werden als vollwertiges Blogging-System mit allen Schikanen: Titel, Zusammenfassung, Kategorien, alles Mögliche an Textformatierung, beliebig viele Bilder mitten im Text eingebettet, über 16 Millionen Zeichen.
Friendica wurde aufgebaut auf seinem eigenen Protokoll namens DFRN. Aber ein Killerfeature von Friendica war schon immer, daß es sich in alle möglichen und unmöglichen anderen Richtungen verbinden kann: Fediverse, diaspora*, Tumblr, WordPress, sogar Twitter, ein paar Jahre sogar Facebook und so weiter.
So ganz zufrieden war er damit aber nicht. Ein großes Problem war nämlich, daß jedes Mal, wenn ein öffentlicher Friendica-Node dichtmachte, die Nutzer alles verloren. Auf die Lösung kam er 2011: nomadische Identität, also die Möglichkeit, die eigene Social-Networking-Identität gleichzeitig voll synchron auf mehreren Servern zu haben.
Dafür entwickelte er ab 2011 ein neues Protokoll names Zot, das genau diese Funktion bieten sollte. Um es zu implementieren, forkte Mike noch 2011 einen Friendica-Fork, den er im selben Jahr erstellt hatte, um mit verschiedenen Lizenzen zu experimentieren. (Deswegen steht Friendica heute unter der AGPLv3 und die meisten seiner "Nachfahren" weiterhin unter der MIT-Lizenz.)
So entstand etwas namens "Red" (von spanisch "la red" = "das Netzwerk"). 2012 wurde es komplett neu geschrieben gegen das Zot-Protokoll. Das war der eigentliche Startschuß für Hubzilla. Damals gab Mike übrigens Friendica (das inzwischen auf die AGPLv3 relizensierte Original) an die Community ab. Ende 2012 wurde Red umbenannt in "Red Matrix", weil man "Red" nicht googlen kann.
Allerdings wurde die Red Matrix kaum angenommen, weil sie im Grunde Friendica mit vielleicht ein oder zwei weniger Verbindungsmöglichkeiten und nomadischer Identität war. Die meisten verstanden nomadische Identität aber gar nicht, und von denen, die sie verstanden, glaubten viele, sie gar nicht zu brauchen, weil sie eh ihr Friendica-Konto auf ihrem eigenen Node hatten.
So gab es dann im März 2015 den Schnitt. Mike und seine Mitstreiter aus der Community nahmen die Red Matrix und strickten sie um für neue Zielgruppen, insbesondere Betreiber öffentlicher Server. Dafür wurden haufenweise neue, teilweise optionale Features drangebaut: WebDAV für den eingebauten Filespace, ein CalDAV-Server, der das Frontend des Eventkalenders mitnutzt, ein CardDAV-Server, nichtföderierende Artikel, Planungskarten, Wikis, Webseiten usw. usf. Und das Ganze wurde umbenannt in Hubzilla.
Wir sind übrigens immer noch zehn Monate vor dem Start von Mastodon.
Standardmäßig föderiert Hubzilla nur über sein eigenes Zot-Protokoll. Es unterstützt immer noch einiges an nichtnomadischen Protokollen und Verbindungen, aber alles, was nichtnomadisch und bidirektional ist, ist optional und standardmäßig deaktiviert, muß also in einem neuen Kanal erst aktiviert werden. Darunter fällt auch ActivityPub, das Hubzilla seit Juli 2017 als allererste Software überhaupt implementiert hat, zwei Monate noch vor Mastodon.
Damit war aber das Ende der Fahnenstange noch nicht erreicht.
Mike wollte das Zot-Protokoll noch weiter entwickeln, und zwar auf Arten und Weisen, die möglicherweise die Kompatibilität beeinträchtigten. Das konnte er nicht auf Hubzilla selbst machen.
Also gab er 2018 Hubzilla ab an zwei Entwickler aus der Community und forkte es. Erst kam Osada, das wohl zunächst als Entwicklungsplattform für Zot6 dienen sollte, aber trotzdem noch die meisten von Hubzillas Verbindungsmöglichkeiten hatte. Bei Osada wurde übrigens fast alles wieder entfernt, was beim Umbau von der Red Matrix zu Hubzilla dazugekommen war.
Wie es aber zunächst aussah, würde Zot6 nicht mit nichtnomadischen Protokollen zusammenspielen können. So entstand als zweiter Fork Zap; ich glaube heute, Zap war ein Fork von Osada und nicht von Hubzilla. Jedenfalls behielt Osada die ganzen Verbindungsmöglichkeiten, verlor aber nomadische Identitäten. Zap wiederum blieb nomadisch, unterstützte aber nur Zot6.
Schließlich stellte sich heraus: Zot6 konnte sehr wohl mit nichtnomadischen Protokollen zusammenspielen. Also wurde Osada, wie es war, Anfang 2019 eingestampft. Die Idee, einen Osada-Kanal als Gateway zwischen Zap und dem Rest des Fediverse zu haben, war sowieso gaga und wenig praktikabel. Dafür wurde von Zap kurz darauf ein zweites Osada geforkt, das sich zumindest wieder mit ActivityPub verbinden konnte. Das war zunächst der einzige Unterschied zwischen Osada und Zap.
Im Laufe des Jahres wurden Osada und Zap stabil. Das heißt auch, Osada war so stabil, daß es keinen Grund mehr gab, warum Zap kein ActivityPub können sollte. Kurz darauf war der einzige Unterschied zwischen Osada und Zap neben dem Branding, daß auf Osada-Servern ActivityPub standardmäßig aktiviert und auf Zap-Servern standardmäßig deaktiviert war. Weil auch das Käse war und nur unnötigen Mehraufwand in der Entwicklung mit sich brachte, wurde das zweite Osada im Herbst 2019 komplett in Zap gemerget und eingestellt.
Weil Zap jetzt aber ein stabiler Daily Driver war, brauchte Mike wieder neue Entwicklungsplattformen für Zot8. Dafür wurden 2020 ein drittes Osada, Mistpark 2020 (alias Misty) und Redmatrix 2020 geforkt. Es gab das Gerücht, daß sie verschiedene Stabilitätsstufen darstellten. Tatsächlich waren sie bis auf das Branding identisch, und es waren deshalb drei, weil Mike damit die Markenfetischisten im Fediverse trollen wollte.
Einen stabilen Release mit Zot8 gab es nie. Statt dessen kam im Frühjahr 2021 Roadhouse dazu als Fork von einem von den dreien. Das basierte eigentlich schon auf Zot11, aber Zot11 war zu Zot6 in keinster Weise mehr kompatibel. Also entschied sich Mike, das Protokoll in Nomad umzubenennen. Heute sagt Mike, alle Versionen des Protokolls heißen jetzt Nomad; die Hubzilla-Entwickler widersprechen ihm aber und sagen, Zot6 ist immer noch Zot.
Jetzt hatte Mike fünf Projekte, die unterschiedliche Protokollversionen nutzte, ansonsten aber dasselbe konnten und fast dasselbe UI hatten.
Up- und Crossgrades gingen übrigens ganz einfach, in dem die Codebase des Servers umgestellt wurde. Man konnte von Zap nach Osada, Misty und Redmatrix 2020 upgraden. Man konnte zumindest zwischen Osada, Misty und Redmatrix 2020 hin und her crossgraden. Und man konnte von allen vieren nach Roadhouse upgraden.
Im Oktober 2011 forkte Mike Roadhouse in wieder etwas Neues. Dieses Mal ging er in eine ganz andere Richtung: Was er jetzt erschaffen hatte, hatte keinen Namen. Es hatte kein Logo. Es hatte keine Markenidentität. Es war auch kein Projekt mehr. Alles mit voller Absicht und sehr gut begründet. Noch dazu nahm er sogar die MIT-Lizenz weg und stellte es direktweg in die Public Domain. Damit wollte er noch größere Anreize für Entwickler schaffen, es zu forken, um daraus etwas Eigenes zu bauen.
Das Code-Repository brauchte aber zwingend einen Namen. Also wurde es "streams" genannt (ein Stream ist von Friendica bis heute das, was auf Twitter ein Feed und auf Mastodon eine Timeline ist). Weil nun aber die Community etwas brauchte, womit sie diese neue Software bezeichnen konnte, nahm sie den Namen des Repository und packten ihn in Klammern, um klarzustellen, daß das nicht der Name der Software war. Seitdem wird es seitens der Community "(streams)" genannt.
Von Zap, Osada, Misty, Redmatrix 2020 und Roadhouse konnte durch Rebasen auf (streams) geupgradet werden. Weil (streams) selbst aber keinen Namen, kein Branding und nicht mal einen festgelegten Identifier für den Servertyp hat, übernahm es kurzerhand den Server-Identifier und das Logo von der vorherigen Software. Ich habe selbst mal einen (streams)-Server gesehen, der mit Zap angefangen hatte (wie aus der Subdomain hervorging) und zwischendurch mal Misty war (weil er als Misty gebrandet war), aber vom UI und von der Softwareversion her eindeutig (streams) war.
Zum Silvesterabend 2020 stellte Mike dann Zap, Osada, Misty, Redmatrix 2020 und Roadhouse ein. Wer noch einen Server betrieb, dem war dazu geraten, auf (streams) upzugraden.
(streams) wird heute noch von Mike weiterentwickelt. An Verbindungsmöglichkeiten hat es neben Nomad auch Hubzillas Zot6 und optional, aber standardmäßig aktiviert ActivityPub. Sogar RSS- und Atom-Feeds werden nicht mehr unterstützt, um den Entwicklungsaufwand zu reduzieren.
Der letzte Fork kam im August 2024. Mike war ja damals einer der beiden Entwickler, die an nomadischer Identität über ActivityPub arbeiteten. Im Zuge dieser Entwicklung rollte Mike Portable Objects nach FEP-ef61 im Juni vom "nomadischen" Zweig von (streams) in den hauptsächlichen Entwicklungszweig und im Juli von da in den stabilen Zweig aus. Was im Labor aber funktioniert hatte, sorgte im täglichen Einsatz für Chaos, weil (streams) zuviele verschiedene Identitäten zu jonglieren hatte.
Also forkte Mike (streams) im August zu Forte, entfernte jegliche Unterstützung für Nomad und Zot6 und basierte das ganze Ding komplett auf ActivityPub, und zwar inklusive nomadischer Identität. Das dürfte hauptsächlich passiert sein, um die Nomad- und Zot6-Identitäten loswerden zu können, um das Chaos sichten zu können, aber auch, weil nomadische Identität über ActivityPub die Zukunft sein soll.
Zum 31. August warf Mike erst alle Brocken hin und wollte mit Entwicklung aufhören, weil das alles ein Riesenaufwand war. Er machte aber trotzdem weiter, weil sich in der winzigen (streams)-Community niemand fand, der (streams) und das noch instabile Forte hätte übernehmen können.
Im September wurde erstmals ein Post von Forte durch das öffentliche Fediverse föderiert. Von da an gab es die ersten, die mit ihren eigenen Forte-Servern experimentierten. Und im März 2025 erklärte Mike Forte offiziell für stabil. (streams) lebt aber weiter, denn sein Killerfeature gegenüber Forte ist, daß es ActivityPub nicht braucht. Man kann es also als Zugbrücke verwenden, um das ganze ActivityPub-basierte Fediverse auf einen Schlag auszusperren.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #ActivityPub #Zot #Zot6 #Nomad #Mistpark #Friendica #Red #RedMatrix #Hubzilla #Osada #Zap #Mistpark2020 #Misty #Redmatrix2020 #Roadhouse #Streams #(streams) #Forte -
Mit Zot ist es ein bißchen kompliziert.
Eigentlich heißt Zot jetzt Nomad. Das heißt, Zot11 von 2021, auf dem Roadhouse basierte, war ja zu Zot6 nicht mehr kompatibel und bekam daher einen neuen Namen: Nomad. (streams) basiert auf Nomad, das jetzt eigentlich ungefähr Zot12 sein müßte, aber eben nicht mehr Zot ist.
Das Komplizierte ist jetzt: Mike sagt, das ganze Protokoll in allen Versionen heißt jetzt Nomad. Will sagen, auch Hubzilla basiert laut ihm auf Nomad, nur eben einer älteren Version, und höchstens die Protokollbibliotheken in Hubzilla heißen noch Zot6. Mario Vavti sagt aber, das Protokoll, auf dem Hubzilla basiert, heißt immer noch Zot6.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Hubzilla #Streams #(streams) #Zot #Nomad -
@Marcus Rohrmoser 🌻 Not to my knowledge.
First of all, nomadic identity won't be described in one single FEP that'll cover everything. It was not created on and for ActivityPub. In fact, the concept predates ActivityPub by some six years, and the first implementation predates ActivityPub by some five years.
See, nomadic identity started as an idea. Then Mike built a brand-new protocol around that idea, Zot. Then, in 2012, Mike forked one of his own forks of his own software that is now known as Friendica, originally based on yet protocol designed by himself, and re-wrote the whole thing against Zot. That's how the software was born that's known as Hubzilla now.
As for nomadic identity via ActivityPub, there is only one publicly available software implementation for that. And that's Mike's own Forte. Forte still does everything the Hubzilla/(streams) way which is very very different from how anything else in the Fediverse works, even including Friendica itself, and especially including Mastodon.
Whereas Zot was designed around nomadic identity, ActivityPub isn't. It's having nomadic identity bolted on with a whole slew of FEPs authored by @silverpill who is working on converting Mitra (typical Fediverse software: built only against ActivityPub, non-nomadic, login/account equals identity) into something that's every bit as nomadic as Hubzilla, (streams) and Forte.
Nomadic identity via ActivityPub was originally silverpill's idea, by the way. And that was in 2023. It turned out that this was actually doable, and so he and Mike started working on it, using experimental "nomadic" branches of Mitra and the streams repository respectively. Their approaches were naturally different: silverpill had to make something non-nomadic nomadic. Mike had to make something nomadic be nomadic using a protocol that wasn't made for nomadic identity.
Not only is silverpill's approach much more difficult because Mitra wasn't made for nomadic identity either, but he also took it upon himself to put everything into FEPs by and by. He is still publishing FEP after FEP. Nomadic identity is quite a complex thing from a "Fediverse equals ActivityPub" point of view; it's just that the Hubzilla/(streams) bubble is so used to it whereas silverpill actually has to explore and research something that's natural to Mike.
There's no common set of commands either. There can't be any. Forte, like everything else in the family all the way back to Friendica, is written in PHP. Mitra is written in Rust. Nobody has ever attempted to make something not written in PHP nomadic.
In fact, code sharing would be next to impossible anyway: Forte, like Hubzilla and early Mistpark/Friendika, is published under the MIT license, (streams) is in the public domain, but Mitra is licensed under the GNU Affero GPL v3. Any code coming out of Mitra's conversion to nomadicity would be AGPL-licensed Rust code. And MIT-licensed PHP code that was created when turning Nomad-based (streams) into ActivityPub-based, Nomad-less Forte would be useless for non-nomadic-to-nomadic conversions anyway.
So don't expect any how-to's or the like for converting non-nomadic, ActivityPub-only-by-original-design, login/account-equals-identity Fediverse server software to the same level of nomadicity as Hubzilla, (streams) and Forte until- the first stable release of Mitra with full support for that level of nomadicity is officially rolled out
- silverpill declares that everything necessary for Hubzilla/(streams)/Forte-level nomadic identity via nothing but ActivityPub is cast into FEPs and finalised
Seeing as this has been in the making for some two years now, and I don't even know if the experimental nomadic branch of Mitra even allows cloning right now, I guess this will be a long way to go. He may actually first have to change Mitra from the standard Fediverse model of the account and the login being the identity to Hubzilla's, (streams)' and Forte's model of the identity being a container inside your account and one account being able to host multiple such identities. That's because you can't clone logins.
Oh, by the way, nomadic identity is not just about moving. It's not "moving-your-Mastodon-account-to-another-instance on coke". It's way more.
The core feature is cloning. Imagine you have full, live, hot backups of your Mastodon account on one, two, three, four or more other Mastodon instances. Imagine they all have the same identity, based on which one of them is your main instance. Imagine whatever happens on one of them is sync'd to the others in near-real-time. Imagine you can log into either of them and use either of them all the same, regardless of how many and which of the servers are actually online, as long as at least one is.
Moving is actually even more complex than cloning because it involves both cloning and changing the main instance of your identity.
Allow me to illustrate by supposing Mastodon works like Hubzilla, (streams) and Forte:- Situation:
- You have an account on digitalcourage.social with one channel,
[email protected]. - You want to move to troet.cafe.
- You have an account on digitalcourage.social with one channel,
- Step 1: You create an account on troet.cafe.
- Step 2: There can't be accounts with no channels. You have to add a channel.
So you choose to move your channel[email protected]from digitalcourage.social to troet.cafe. - Step 3: Your channel
[email protected]is cloned over to troet.cafe. - Situation now:
- You have an account on digitalcourage.social with the main instance of your channel; its identity is
[email protected]. - You have an account on troet.cafe with a clone of your channel; its identity is still
[email protected].
- You have an account on digitalcourage.social with the main instance of your channel; its identity is
- Step 4: All data on your channel is synchronised over from your main instance on digitalcourage.social to your clone on troet.cafe. Posts, images, other files, followers, followed, settings, lists, filters etc. etc. pp. Everything.
- Now the main instance and the clone are identical.
Up until here, the process of moving is the same as the process of cloning. What follow is exclusive to moving. - Step 5:
- The clone on troet.cafe is promoted to main instance.
- As there can be only one main instance for each channel, the former main instance on digitalcourage.social is demoted to clone.
- Situation now:
- You have an account on digitalcourage.social with a clone of your channel, formerly the main instance; its identity is
[email protected]. - You have an account on troet.cafe with the main instance of your channel, formerly a clone; its identity is
[email protected].
- You have an account on digitalcourage.social with a clone of your channel, formerly the main instance; its identity is
- Step 6: All your connections on servers of nomadic software are changed from
[email protected]to[email protected], both locally on the servers that you are on and locally on the servers that they are on. - Step 7 (AFAIK, this only happens on (streams) and Forte in reality): All your outbound connections ("followed") on servers running non-nomadic software receive a follow request from
[email protected]which, to them, is an all-new, independent identity. - The actually move is done. What follows is the clean-up that really makes the move a move, namely taking care that nothing is left behind in the old location.
- Step 8: When these last steps are finalised, your clone on digitalcourage.social is deleted. After all, you wanted to move, not to clone.
- Step 9: As your account on digitalcourage.social has no channel on it anymore, the whole account is deleted.
-
I'd rather say:"rediscover the wheel".. the Fediverse is *excruciatingly hard* to navigate, and I'd love to have your help.
So there was this cool discussion at #FediForum. Nomadic Identity with #Zot came up, along with W3C LOLA and others.
So now, I'm just trying to continue the FediForum discussion and collect info about what's out there. I've promised the wagoneers on #Bandwagon that they'll be able to take their accounts anywhere.
So, is Zot the one true way to get this done?
-
@Fabrice Desré @TuxPhones :linux: Ackchually...
The AT protocol has yet to prove that its concept of portable identity works.
In the meantime, @silverpill (creator and maintainer of Mitra) has been working with @Mike Macgirvin 🖥️ (creator of a family tree of almost a dozen Fediverse server applications over a decade and a half, designer of two Fediverse protocols and inventor of nomadic identity as early as 2012) to implement nomadic identity in ActivityPub since 2023. Previously, nomadic identity required the Zot or Nomad protocol. (Oh, and yes, it actually works, and it's being daily-driven by many Hubzilla and (streams) users right now.)
In August, 2024, Mike launched Forte, his most recent creation and the first Fediverse server application to entirely rely upon ActivityPub for nomadic identity. Nomadic identity via ActivityPub has been reality ever since.
In March, 2025, Forte officially had its first stable release. So much about nomadic identity via ActivityPub being experimental. People are using it as their primary daily driver already.
Just because Mastodon doesn't have it, doesn't mean ActivityPub doesn't, or the Fediverse doesn't.
Unfortunately, I don't expect Mastodon to ever implement it. After all, the Mastodon devs have already practically rejected OpenWebAuth as well, another one of Mike's creations.
(This comment was brought to you by a nomadic Hubzilla channel with one clone.)
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #ActivityPub #Zot #Nomad #Mitra #Hubzilla #Streams #(streams) #Forte #NomadicIdentity -
@Hrefna (DHC)
If your server disappeared tomorrow with no ability to export your follower graph, how would you rebuild it?
If you do a server move, what happens to your post history?
Widespread adoption of Nomadic Identity, if it ever happens, may help with this.
I am sure you already know this, but for other readers, these two 2017 articles explain how Nomadic Identity works in Hubzilla, which is based on the Nomad/Zot protocol.
#^https://medium.com/@tamanning/nomadic-identity-brought-to-you-by-hubzilla-67eadce13c3b
#^https://medium.com/@tamanning/getting-started-with-nomadic-identity-how-to-create-a-personal-channel-on-hubzilla-7d9666a428b
Mike Macgirvin recently got Nomadic Identity working on ActivityPub too.
#^https://fediversity.site/item/b69ce5a0-0c22-4933-8393-dce7100f4584
Unfortunately, the ActivityPub world keeps pretending that Mike Macgirvin and his work does not exist (Nomadic Identity has been around and working in Hubzilla for roughly a decade).
There's also OpenWebAuth (Federated Single Sign On). As Sean Tilley explains in this March 2024 article, Nomadic Identity and OpenWebAuth together can enable network resilience, censorship resistance, and ease of migration.
#^https://wedistribute.org/2024/03/activitypub-nomadic-identity/
No idea whether Nomadic Identity, OpenWebAuth, conversation containers, etc. will ever get widespread adoption. At present, the user base of software such as Hubzilla, Forte etc. (which have these features) is negligible. And at least in case of Hubzilla (which I am using), the UI and UX needs a lot of work; don't know about Forte (which is based on ActivityPub).
And yes, all the other problems with the Fediverse that you listed will still remain. At this point, I doubt if the Fedi will ever become socially and politically relevant.
#ActivityPub #ATProto #Nomad #Zot #NomadicIdentity #OpenWebAuth #Fediverse -
@Rob Shearer
Excellent write-up, agree with most of the points.
On a related note: it is a pity that the poorly thought-out and designed Mastodon became the overwhelmingly popular Fediverse platform. I wish it were one of the Mike Macgirvin creations such as Hubzilla or (streams) or Forte, with their advanced features such as Nomadic Identity, OpenWebAuth (Federated Single Sign On), conversation containers for threaded conversations, extremely fine-grained privacy controls, etc.
Nomadic Identity, in particular, is brilliant. This is how it works. You have a channel (that participates in the Fediverse, this is equivalent to an account on Mastodon) on any account on, let us say, Hubzilla instance A. You can open another account on Hubzilla instance B, and create a clone there of your channel on instance A. So this clone becomes a live, real-time backup of your channel; the backup includes your connections as well as your posts. And it is bidirectional. You can log on to your clone channel on B, and use it like your main instance, and now the clone on instance A will mirror your activity. If you wish, you can clone the channel on a third instance C. If one of A or B or C abruptly shuts down, you can continue operating your channel from your clone channel, so you lose nothing.
This addresses one of your pain points as to how account migration does not work on Mastodon.
By the way: you can have multiple channels per instance, and you can have clones of each channel on different instances. So if you wish, you can have separate channels for your hobbies and your professional activities and your politics; all contained and operated within a single account on a particular instance.
You can read more about Nomadic Identity here
#^https://medium.com/@tamanning/nomadic-identity-brought-to-you-by-hubzilla-67eadce13c3b
and here.
#^https://medium.com/@tamanning/getting-started-with-nomadic-identity-how-to-create-a-personal-channel-on-hubzilla-7d9666a428b
It is said that Bluesky is working on pioneering something like Nomadic Identity. Ironically, Mike Macgirvin had already pioneered it all the way back in 2012. He initially did it with Nomad (which underlies Hubzilla and (streams)), a protocol far richer and better-defined than ActivityPub; and recently, he even got Nomadic Identity working on ActivityPub.
#^https://fediversity.site/item/b69ce5a0-0c22-4933-8393-dce7100f4584
Unfortunately, the movers and shakers of the ActivityPub world keep pretending that Mike Macgirvin and his work does not exist.
Then there’s OpenWebAuth for Federated Single Sign On. This enables seamless granting of permissions for you to operate your social dashboard from different parts of the Fediverse.
You can read here how Nomadic Identity and OpenWebAuth together enable network resilience, censorship resistance, and ease of migration.
#^https://wedistribute.org/2024/03/activitypub-nomadic-identity/
There’s also conversation containers—these ensure that unlike on Mastodon, every single post/comment in a conversation thread is visible to every single person participating in or merely viewing the thread. (Also: you don't need @ tagging, anyone who participated in the conversation by replying at least once or by boosting or liking some post is notified of all new posts/comments.)
I won’t elaborate on the fine-grained privacy controls, but I think they too address some of your pain points with Mastodon.
Having said all that, I must mention that your core criticism of Mastodon also applies to Hubzilla, (streams), and Forte: there is asynchronous distribution of “some subset of a global database across some parts of the network”. I personally think there ought to be a truly universal search and community-controlled user-specific custom algorithms to address this problem, but I doubt the vocal part of the userbase here would agree.
And relative to Mastodon, the Hubzilla+(streams)+Forte community is tiny, so there is hardly any local content.
#Nomad #Zot #ActivityPub #Mastodon #Hubzilla #Forte #NomadicIdentity #OpenWebAuth #ConversationContainers #PrivacyControls
@Jeff Atwood -
@Kellam⚙️Бур This may come as a surprise, but: Nomadic identity is not an abstract concept or a science-fiction idea for the Fediverse.
It is reality. It exists. Right now. In stable, daily-driver software that's federated with Mastodon. And it has been for over a decade.
I'm literally replying to you here from a nomadic channel that simultaneously exists on two servers.
Nomadic identity was invented by @Mike Macgirvin 🖥️ (formerly American software developer of about half a century who has been living in rural Australia for decades now) in 2011 and first implemented in 2012. Almost four years before Mastodon was first launched.
In 2010, he had invented the Facebook alternative Friendica, originally named Mistpark and based on his own DFRN protocol.
Over the months, he witnessed lots of privately operated public Friendica nodes shut down with or without an announcement and the users on these nodes lose everything. He added the possibility to export and import Friendica accounts. But that would only help if a permanent shutdown was announced. It did not protect you against shutdowns out of the blue.
There was only one solution to this problem. And that was for someone's identity to not be bound to one server, but to exist on multiple servers simultaneously. The whole thing with everything that's attached to it. Name, settings, connections, posts, files in the file storage etc. etc., everything.
So in 2011, Mike designed a whole new protocol named Zot around this brand-new idea of what he called "nomadic identity" back then already.
In 2012, Mike forked Friendica into something called Red, later the Red Matrix, and rebuilt the whole thing from the ground up against Zot. Red was the first nomadic social networking software in the world, almost four years before Mastodon.
In 2015, ten months before Mastodon was first released, the Red Matrix became Hubzilla, the Fediverse's ultimate Swiss army knife.
I am on Hubzilla myself. This channel of mine is constantly being mirrored between its main instance on https://hub.netzgemeinde.eu and its clone on https://hub.hubzilla.de. Anything that happens on the main instance is backed up on the clone. I can also log into the clone and use that, and whatever happens there is backed up on the main instance.
https://hub.netzgemeinde.eu could go down, temporarily, permanently, doesn't matter; I still have my channel, namely the clone. And I can declare the clone my new main instance.
Well, Mike didn't stop at Hubzilla and its original version of the Zot protocol. He wanted to refine it and advance it, but in ways that wouldn't be possible on daily-driver software.
Zot went through several upgrades: Zot6 in 2018 (backported to Hubzilla in 2020, along with OpenWebAuth magic single sign-on). Zot8 in 2020. Zot11 in 2021 which had become incompatible with Zot6 and therefore was renamed to Nomad. Today's Nomad would be Zot12.
Also, in order to advance and test Zot, Mike created a whole bunch of forks and forks of forks. Osada and Zap for Zot6 in 2018, followed by another short-lived Osada in 2019. A third Osada, Mistpark 2020 (a.k.a. Misty) and Redmatrix 2020 in 2020 for Zot8. Roadhouse for Zot11 Nomad in 2021. All Osadas, Zap, Misty, Redmatrix 2020 and Roadhouse were discontinued on New Year's Eve of 2022.
The most recent software based on Nomad is from October, 2021. It can be found in the streams repository. It is officially and intentionally nameless and brandless, it has next to nodeinfo code that could submit statistics, and it is intentionally released into the public domain. The community named it (streams) after the code repository.
I also have two (streams) channels, one of which is cloned so far.
The newest thing, and that's what the Friendica and Hubzilla veteran @Tim Schlotfeldt ⚓?️? referred to, is nomadic identity using nothing but ActivityPub, no longer relying on a special protocol.
This was not Mike Macgirvin's idea. This came from @silverpill, the creator and developer of the microblogging server application Mitra. He wanted to make Mitra nomadic, make it resilient against server shutdown. But he didn't want to port it to Nomad. He wanted to achieve it with nothing but ActivityPub.
So he hit up Mike. The two came to the conclusion: This is actually possible. And they began to work on it. Amongst the results were several FEPs coined by silverpill.
This time, Mike did not create another fork to develop nomadic identity via ActivityPub. He did it all on the nomadic branch of the streams repository while silverpill did his part on a special development branch of Mitra.
In mid-2024, after enough sparring between (streams) instances, between Mitra instances and between (streams) and Mitra, Mike was confident enough that his implementation of support of nomadic identity via ActivityPub was stable enough. He merged the nomadic branch into the dev branch which ended up being merged into the stable release branch in summer.
Now, at this point, (streams) didn't use ActivityPub for nomadic identity. It still used the Nomad protocol for everything first and foremost, including cloning. But it understood nomadic identity via ActivityPub as implemented on experimental Mitra.
However, while it worked under lab conditions, it blew up under real-life conditions. At this point, (streams) had to handle so many different identities that it confused them, and it couldn't federate with anything yet.
In mid-August, while trying to fix the problem, Mike eventually forked the streams repository into Forte. It got a name again, it got a brand identity again, it got its nodeinfo back, it was put under the MIT license again.
But most importantly: Any and all support for Nomad was ripped out, also to get rid of a whole number of IDs, namely those for Nomad-actually-Zot12 and for Hubzilla's Nomad-actually-Zot6. Forte only uses ActivityPub for everything. And so, Forte also had to fully rely on ActivityPub for nomadic identity, cloning and syncing.
For almost seven months, Forte was considered experimental and unstable. For most of the time, the only existing servers were Mike's.
But on March 12th, 2025, Mike Macgirvin released Forte 25.3.12, the first official stable release of Forte. This is what Tim wrote about. Because this actually made it into Fediverse-wide news.
Not because it's nomadic. Nomadic identity has been daily-driven for over a decade now.
But because it uses ActivityPub for nomadic identity. Which means that you can theoretically make any kinds of Fediverse software nomadic now, all without porting it to the Nomad protocol first.
For the future, Mike and silverpill envision a Fediverse in which one can clone between different server applications. A Fediverse in which one can have one and the same identity cloned across multiple servers of Mastodon, Pixelfed, PeerTube, Mitra, Forte, Mobilizon, Lemmy, BookWyrm etc., all with the same name, all with the same content and settings (as far as the software allows; you will certainly not be able to clone your PeerTube videos to Mastodon and Lemmy).
Even if you don't intend to clone, it will make moving instances and even moving from one software to another dramatically easier.
If you're concerned about your privacy, let me tell you this:
Hubzilla's privacy, security and permissions system is unparalleled in the Fediverse. Except for that on (streams) and Forte which is another notch better.
I can define who can see my profile (my default, public profile on Hubzilla where each channel can have multiple profiles).
I can define who can see my stream and my posts when looking at my channel.
I can define who can see my connections (Hubzilla, (streams) and Forte don't distinguish between follower and followed; they aren't Twitter clones).
I can define who can look into my file space (individual permission settings per folder and per file notwithstanding).
I can define who can see my webpages on Hubzilla (if I have any).
I can define who can see my wikis on Hubzilla (no shit, I've got wikis on my Hubzilla channel).
On Hubzilla, I can define individually for any of these whether it's- everyone on the Internet
- everyone with a recognisable Fediverse account
- everyone on Hubzilla (maybe also on (streams); anyone using ActivityPub is definitely excluded here)
- everyone on the same server as myself (AFAIK, only main instances of channels count here, clones don't)
- unapproved (= followers) as well as approved (= mutual) connections
- confirmed connections
- those of my confirmed connections whom I explicitly grant that permission by contact role
- only myself
There's a whole bunch more permissions than these. And they all have seven or eight permission levels (depending on whether the general non-Fediverse public can be given permission).
On (streams) and Forte, I can define whether things are allowed for- everyone on the Internet (where applicable)
- everyone with a recognisable Fediverse account
- all my approved connections
- only me myself plus those whom I explicitly grant that permission in the connection settings
Yes, connection settings. Hubzilla, (streams) and Forte give you various ways of configuring individual connections, much unlike Mastodon. This includes what any individual connection is allowed to do.
Hubzilla uses so-called "contact roles" for that, presets with a whopping 17 permissions to grant or deny for any one individual connection. That is, what the channel generally allows, a contact role can't forbid.
(streams) and Forte still have 15 permissions per contact, but they lack some features which Hubzilla has permissions for. These permissions can be set individually for each connection, or you can define permission roles that cover all 15 permissions to make things easier.
Okay, how about posting in public vs in private? And when I say "private", I mean "private". It's "private messages" on Hubzilla, (streams) and Forte, not "direct messages".
Hubzilla, (streams) and Forte let you post- in public
- only to yourself
- only to your connections ((streams) and Forte only; Hubzilla requires a privacy group with all your connections in it for this)
- to all members of one specific privacy group (Hubzilla)/access list ((streams), Forte); that's like being able to only post to those on one specific list on Mastodon
- to everyone to whom one specific non-default profile is assigned (Hubzilla only)
- to a specific group/forum (I'll get back to that later)
- to a custom one-by-one selection of connections of yours
Now, let's assume I have a privacy group with Alice, Bob and Carol in it. I send a new post to only this privacy group. This means:- Only Alice, Bob and Carol can see the post and the conversation.
- Alice can reply to me, Bob and Carol.
- Bob can reply to me, Alice and Carol.
- Carol can reply to me, Alice and Bob.
- Nobody else can see the post. Not even by searching for it. Not by hashtag either. Not at all.
- Nobody else can see any of the comments.
- Nobody else can comment.
If one of them was on Mastodon, they'd see my post as a DM, by the way, and they could only reply to me. But that's Mastodon's limitation because it understands neither threaded conversations nor permissions.
Or how about reply control? This is something that many Mastodon users have been craving for quite a while now. Hubzilla, (streams) and Forte have them. Right now. And they work. They have since 2012.
Hubzilla optionally lets me disallow comments on either of my posts. Users on Hubzilla, (streams) and Forte won't even be able to comment; they won't have the UI elements to do so. Everyone else is able to comment locally. But that comment will never end up on my channel. It will never officially be added to the conversation. And at least users on Friendica, Hubzilla, (streams) and Forte will never fetch that comment from my channel as part of the conversation, i.e. never at all.
(streams) and Forte can go even further with all available options. They can disallow comments like Hubzilla. But in addition, they can allow only the members of one particular access list to comment, regardless of who can see the post/the conversation. On top of that, comments can be closed at a pre-defined point in the future. And then you even have a channel-wide setting for how long people can comment on your posts.
Oh, and there's even a setting for who is generally permitted to comment on your posts. And you can additionally allow specific connections of yours to comment on your posts.
Lastly, I've already mentioned groups/forums. Like, you know, Web forums or Facebook groups or subreddits or whatever. Like Guppe Groups on a mountain of coke and with moderation and permission control and optionally private.
Hubzilla has them, and it has inherited them from Friendica. (streams) has them. Forte has them. They're basically channels like social networking channels, but with some extra features. This includes that everything that's send to a group/forum as what amounts to a PM is automatically forwarded to all other members.
On Hubzilla, a forum can be gradually made private by denying permission to see certain elements to everyone but its own members (= connections): the profile, the members, what's going on in it. Depending on what you want or do not want people to see.
On (streams) and Forte, you have four types of forums:- public, and members can upload images and other files to the forum channel
- public, but members cannot upload images and other files to the forum channel
- like above, but additionally, posts and comments from new members must be manually approved by the admin(s) until their connections are configured to make them full members
- private, non-members can't see the profile, non-members can't see the connections, non-members can't see what's going on in it, but members can upload images and other files to the forum channel
In addition, on all three, a group/forum channel can choose to hide itself from directories. This is always an extra option that's independent from public/private.
What we have here is the most secure and most private Fediverse software of all.
And, once again, at its core, this is technology from 2012. It pre-dates Mastodon by almost four years.
Finally, if you want to know how Hubzilla and (streams) compare to Mastodon: I have made a number of tables that compare Mastodon, Friendica, Hubzilla and (streams).
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Mitra #Friendica #Hubzilla #Streams #(streams) #Forte #ActivityPub #Zot #Zot6 #Zot8 #Nomad #NomadicIdentity #Security #FediverseSecurity #Privacy #FediversePrivacy #Permissions -
To create your own image cache, there are lots of options:
- The #distribution project is minimal but extendable. https://distribution.github.io/distribution/
- #Harbor has a lot of functionality for larger orgs: https://goharbor.io/
- #Zot is an alternative to Harbor: https://zotregistry.dev/
- #Artifactory and #Nexus each include a container registry option. -
-
@doctorambient
But do you really think ActivityPub is the ultimate best solution?
Ask Hubzilla or (streams) users, and they're likely to say it isn't.
Even with FEP-ef61 and other unofficial add-ons, ActivityPub will never handle nomadic identity as gracefully as a protocol like Nomad which has been built around nomadic identity and advanced, fine-grained permission control from the get-go.
The main reason why nomadic identity is being introduced to ActivityPub is so that Fediverse server apps that have always only supported ActivityPub can eventually become nomadic without having to be re-written against a wholly different protocol.
#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #ActivityPub #Zot #Nomad #Hubzilla #Streams #(streams) #NomadicIdentity -
@cy
The people who wrote the Fediverse
There were no "people who wrote the Fediverse". These was no committee who laid down the standards.
The Fediverse was invented by @Evan Prodromou. In 2008. By first creating a centralised Twitter alternative silo named Identi.ca.
And then open-sourcing the underlying technology as Laconi.ca, later StatusNet (merged into GNU social in 2013).
And then laying the protocol open as OpenMicroBlogging, later superseded by OStatus.
Then, in 2010, @Mike Macgirvin ?️ decided that the world needs a free, open-source, decentralised, secure alternative to Facebook that's better than Facebook. And so he made Mistpark, today Friendica.
But the features he wanted Friendica to have were impossible to achieve with any existing protocol. OStatus wasn't even that good for microblogging, much less Mike's ambitious plans. Besides, he's an experienced protocol designer. So he created a whole new protocol, DFRN, and built Friendica on top of it. Friendica did adopt OStatus as an extra protocol, though, because Friendica's goal was and still is to federate with everything and then some.
In 2011, Mike had seen many public Friendica nodes shut down with or without warning and people always losing everything and having to start over from scratch. So he decided to do something against it.
He invented nomadic identity. And built a new protocol around it, Zot, because there was no way DFRN could take care of this, let alone OStatus.
In 2012, he forked Friendica into Red and rewrote the whole backend against Zot, which, however, required the creation of yet another identity scheme.
For one, one login could now have multiple fully separate and independent identities on it. For example, my Hubzilla channel URL is https://hub.netzgemeinde.eu/channel/jupiter_rowland.
Besides, one identity could now reside on multiple server instances which is what nomadic identity means.
Red was later renamed Red Matrix and, in 2015, refactored, redesigned and renamed into Hubzilla.
Mastodon and Pleroma started in 2016 as OStatus-based alternative UIs for GNU social. Mastodon was the first to be turned into a stand-alone project with not much interest in connecting to anything outside, all in spite of already being federated with Pleroma, GNU social, Friendica and Hubzilla via OStatus.
ActivityPub came out in 2017. No, not 2018. It was standardised in 2018. But it came out in 2017.
In July, 2017, Hubzilla was the first Fediverse project to integrate ActivityPub. Next to its own Zot, next to diaspora*, next to OStatus etc. On the one hand, Hubzilla tried to stay as close to the ActivityPub spec as possible and feasible. On the other hand, Hubzilla had to make its ActivityPub integration, which has always been an optional add-on, compatible to its own technology, to its own Zot protocol, to the way it works.
In September, Mastodon was the second Fediverse project to adopt ActivityPub. But Mastodon was more interested in doing its own thing and being as close to Twitter as it could than in sticking to a protocol spec, much less connecting to non-Mastodon stuff such as Hubzilla with which it already shared two protocols now.
Mastodon was the one that added Webfinger. ActivityPub doesn't even require Webfinger. The ActivityPub spec doesn't contain Webfinger. But Mastodon requires Webfinger. It can't live without Webfinger. So everything that wants to properly federate with Mastodon needs to implement Webfinger.
After ActivityPub had become a standard, more projects adopted it. But as lax a specification as ActivityPub is, it allowed for a lot of liberties.
Some devs looked at how Mastodon had integrated ActivityPub, decided it was rubbish and did it their own way.
Some devs looked at how Mastodon had integrated ActivityPub, decided they couldn't do it the same way because what they did was too different from Mastodon and did it their own way.
Some devs didn't look at what anyone else did and did it their own way.
Probably none of them looked at how Hubzilla had integrated ActivityPub because none of them even knew that Hubzilla existed. Except for those who were maintaining Friendica now. And Friendica had to make it compatible with DFRN and with the way it had been working since 2010.
Fast-forward to 2023. Mike's current piece of work was the streams repository which contains an intentionally nameless fork of a fork of three forks of a fork (of a fork) of Hubzilla, slimmed down from Hubzilla, but modernised and technologically even more advanced.
It was then that @silverpill, creator and maintainer of Mitra, got into contact with him because he wanted to add nomadic identity to Mitra. Something that's built on ActivityPub and only supports ActivityPub. A first. No-one had ever done nomadic identity with nothing but ActivityPub before.
So the two started working on how to implement nomadic identity using only ActivityPub. Mike had a vision of a Fediverse with nomadic identity all over and Fediverse identities cloned beyond server application borders. Like, a (streams) channel cloned to Mitra, Mastodon, PeerTube and Mobilizon, all with the same identity.
This, however, required another, brand-new way of identifying Fediverse actors. And so FEP-ef61 "Portable Objects" was created.
We're probably in the middle of xkcd 927 now.
Mike set up an experimental branch of (streams) to develop and test nomadic identity via ActivityPub, also since (streams) already had nomadic identity anyway.
Around summer, the "nomadic" branch (for nomadic identity via ActivityPub) seemed reliable enough to merge it into "dev". And in July, "dev" was merged into "release", complete with nomadic-identity-via-ActivityPub code.
It was shortly after that merge that I created my two (streams) channels. The channel URL of my channel for Fediverse memes is https://streams.elsmussols.net/channel/fedimemes_on_streams. But its DID, which all channels created on accounts registered after that merge got, is https://streams.elsmussols.net/.well-known/apgateway/did:key:z6Mkf2dhUa65zBYCNVqs3AHyt8uPixauZ7bPzEJn15LJANsd/actor. And that's only two IDs of the same channel. There are also others for (streams)' native Nomad protocol, Hubzilla's Zot6 protocol, ActivityPub, OAuth, OAuth2 and probably also OpenWebAuth magic single sign-on, another one of Mike's creations. Not to mention that (streams) channels, like Hubzilla channels and Friendica accounts, can also optionally be group actors.
In fact, this blew up into (streams) users' faces because (streams) confused the various IDs to such degrees that it wouldn't federate at all anymore. It took Mike a whole lot of work to iron this out again, so much that he officially retired from Fediverse development on August 31st.
And in the middle of this, he even created yet another fork, Forte, which is (streams) minus Nomad, minus Zot6, based on and supporting only ActivityPub. My guess is still that one of the reasons to create Forte at that point was to get rid of the Nomad and Zot6 IDs to sort the ID mess out.
Even if nomadic identity via ActivityPub should ever become stable and start spreading, I don't expect DIDs to become the one norm in the Fediverse. Not with all those barely or unmaintained projects and those devs who refuse to acknowledge that devs of other projects do great stuff, too.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #OStatus #DFRN #Zot #ActivityPub #Nomad #Laconi.ca #Identi.ca #StatusNet #GNUsocial #Friendica #Hubzilla #Mastodon #Pleroma #Streams #(streams) #Forte #FEP_ef61 -
@Strypey A few more details:
* FEP-ef61: Portable Objects
https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md
Invented in, I think, 2023 by @silverpill for Mitra (based on ActivityPub). Currently implemented there and in @Mike Macgirvin ?️'s streams repository and Forte. Part of the plan to introduce almost Nomad-level, but cross-project nomadic identity to ActivityPub.* FEP-61cf: The OpenWebAuth Protocol
https://codeberg.org/fediverse/fep/src/branch/main/fep/61cf/fep-61cf.md
Invented in 2018 by Mike Macgirvin for Zap (Zot6 development platform; discontinued 2022). Backported to Hubzilla in 2020. Full server-side and client-side implementation only in Hubzilla (based on Zot6, also supports ActivityPub etc.), (streams) (based on Nomad, also supports Zot6 and ActivityPub) and Forte (based on ActivityPub). Friendica has a client-side implementation. Mastodon has a client-side implementation pull request that has to be merged eventually.
CC: @Laurens Hof
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Friendica #Hubzilla #Zap #Streams #(streams) #Forte #Zot #Zot6 #Nomad #ActivityPub #FEP #FEP_ef61 #FEP_61cf #DecentralizedIdentity #NomadicIdentity #OpenWebAuth #SingleSignOn -
@glyn Decentralised identity has been available for longer than Mastodon, let alone ActivityPub. Only that it is known as "nomadic identity" here.
It was first implemented by Friendica creator @Mike Macgirvin ?️ in the Zot protocol in 2011 and in a Friendica fork named Red in 2012, later renamed into the Red Matrix, eventually reworked and renamed into Hubzilla in 2015.
Proof: This Hubzilla channel of mine actually simultaneously resides on two servers.
(Almost) everything that Mike has made afterwards, forks and forks of forks of Hubzilla, used to have or still have nomadic identity implemented.
His streams repository contains a fork of a fork... of Hubzilla that intentionally has no name, and that offers nomadic identity via the Nomad protocol with better compatibility with non-nomadic ActivityPub. In July, it had decentralised IDs as per FEP-ef61 (see also here) implemented, a first step by Mike to fully implement nomadic identity in ActivityPub.
Forte, Mike's most recent fork from August, had all support for Nomad and Zot6 removed and only uses ActivityPub anymore while still offering nomadic identity. To my best knowledge, however, it has yet to be declared stable enough to be daily-driven, and it has no public instances.
Other than all this, a non-public development version of @silverpill's Mitra has nomadic identity via ActivityPub in development. I'm not sure whether FEP-ef61 is implemented in the release version yet. It's the only Fediverse project aiming to implement nomadic identity which Mike Macgirvin has nothing directly to do with.
The ultimate goal is to be able to clone a Fediverse identity across project borders. Only considering stable releases, it's currently only possible to clone Hubzilla channels within Hubzilla, using Zot6, or (streams) channels within (streams), using Nomad.
Unfortunately, Mike has officially retired from Fediverse development and only occasionally submits code to the streams repository and Forte anymore.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #DecentralizedIdentity #NomadicIdentity #ActivityPub #FEP_ef61 #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #Mitra -
@Matthias ⚝ @Evan Prodromou
Another alternative would be to deactivate activity pub (optional) (because it is toxic) and rely on the Diaspora / DFRN.
This would basically create three parallel "Fediverses".
One, the ActivityPub-based one which could be considered "bugged" and illegal as per GDPR because data sniffers would be everywhere.
This part of the Fediverse would quickly wither away and die for one sole reason: Mastodon, which makes up over 70% of today's Fediverse, is developed in Germany, and mastodon.social, which makes up over 20% of today's Fediverse, is hosted in Germany. Germany is a member of the EU and thus GDPR area. In fact, Germany was a driving force behind GDPR. Mastodon, in its entirety, would basically become illegal in its own country. Unless, of course, Gargron took the step to move Mastodon over to the USA entirely and shutter Mastodon gGmbH.
Two, the "safe" Social Web based on the diaspora* protocol and consisting of diaspora* itself, Friendica, Hubzilla and Socialhome. Many users of the latter three (if Friendica still offers this option, and if Socialhome introduces it) will turn ActivityPub off and cut off all ties to the ActivityPub-based Fediverse.
Three, the "even safer" nomadic grid of Hubzilla and (streams), based on the Zot6 protocol. Both definitely do allow ActivityPub being off, and on Hubzilla, it is off on new channels by default.
I guess both would feel quite some relief when they are no longer bound to a "Fediquette" defined entirely by Mastodon users who barely or not at all know that the Fediverse is not only Mastodon. Especially the several public Hubzilla hubs in Germany, including the two biggest ones, would be quick to turn ActivityPub off on a hub level because leaving it on would be illegal suddenly.
I'm not sure what'd happen to @Mike Macgirvin 🖥️'s latest fork, Forte, which is (streams) with Nomad and Zot6 removed and nothing but ActivityPub. On the one hand, like (streams), it has an unparalleled permissions system. On the other hand, ActivityPub itself would become inherently unsafe. Besides, even something as basic as direct messages aren't necessarily that private if Pleroma admins can choose to circumvent direct message privacy on a per-instance level. And yes, Pleroma has that option.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #ActivityPub #Mastodon #Pleroma #diaspora* #Friendica #Hubzilla #Streams #(streams) #Forte #Zot #Zot6 #GDPR -
@Bryan Redeagle
I found a really cool one called Zot that had cross site authentication, which made privacy settings really interesting and useful. Unfortunately, the developer took down all of the drive and instead created a reference application called (streams), the parenthesis are correct. (streams) has no good info or documentation. You have to read the code to figure it out.
A few corrections. Source: I've been using that stuff since before Mastodon was hot. Oh, and this is going to be long.
First of all, the creator, @Mike Macgirvin 🖥️, not only created the Zot protocol, but also a reference implementation at the same time. As in 2012. The reference implementation was named Red and a fork of his very own Friendica from 2010. Since Red turned out to be a not-so-good name, it was renamed Red Matrix. And as it didn't really take off, it was redesigned and renamed into Hubzilla in 2015. Hubzilla still exists today. I'm using it right now.
Mike kept advancing the Zot protocol further and further with a whole string of forks and forks of forks and so forth. Zot6 matured with Zap around 2019 and brought OpenWebAuth magic single sign-on with itself. Both were backported to Hubzilla, which has been maintained by someone else since 2018, in 2010.
Zot's killer feature is not OpenWebAuth magic single sign-on, though. It's nomadic identity. The very thing it was designed for.
In 2021, Zot11 was reached, but it had advanced so far that it was no longer compatible with Zot6, so it was renamed to Nomad. Today's Nomad would be Zot12.
(streams) is only a semi-official name, given to it by the community, based on the name of the code repository. Officially, the application is not a project, it is intentionally nameless (no, I'm not kidding, this thing has no name), it is intentionally devoid of any traces of a brand identity, it intentionally had almost all nodeinfo code removed, and it was intentionally released into the public domain.
As (streams) is not a branded product, it does not have a website either.
The reason why it doesn't have any documentation is another one: The documentation it had was painfully outdated. It was basically handed on from fork to fork to fork and never touched. Parts of it have remained untouched since before Osada and Zap were forked from Hubzilla, and that was in 2018. Other parts still speak of Red, and that name ceased to exist in 2012. I know because Hubzilla's current documentation is every bit as old.
Hubzilla is right now having its entire documentation re-written from scratch in German and English by a community member.
For (streams), however, the only solution was to rip the whole documentation out because no documentation was deemed better than one that's so outdated it's useless.
It was considered not so bad for as long as how few people a) learned about (streams) and b) figured out how to find an open-registration instance of something that has neither third-party instance lists nor a unified instance identifier actually joined (streams). After all, they all came from Hubzilla, so they could figure out most themselves.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #NomadicIdentity #SingleSignOn #OpenWebAuth -
@David Lohner Nein.
Denn Hubzilla basiert nicht auf ActivityPub. Es basiert auf Zot. ActivityPub ist zwar seit Juli 2017 verfügbar. Hubzilla hatte es zuerst, zwei Monate vor Mastodon. Aber es ist ein Add-on, es ist optional, standardmäßig ist es auf Nutzerseite sogar deaktiviert, und es kann für ganze Hubs (= Serverinstanzen) deaktiviert werden. Und selbst mit deaktiviertem ActivityPub wäre Hubzilla immer noch föderiert.
Wenn Hubzilla qua Basisprotokoll nicht Teil des Fediverse wäre, würde ich dir jetzt von außerhalb des Fediverse antworten.
Auch (streams) basiert nicht auf ActivityPub, sondern auf Nomad, einer Weiterentwicklung von Zot, nur daß hier ActivityPub in den Kern eingebaut und standardmäßig aktiviert ist. Aber es kann im Gegensatz zu Nomad abgeschaltet werden.
Und soweit ich das mitbekommen habe, hat auch Friendica erst 2023 von seinem eigenen DFRN als Basisprotokoll auf ActivityPub umgestellt, das es schon seit 2019 unterstützt.
Gemäß der Definition "Fediverse = ActivityPub als Basisprotokoll" gehört Friendica also erst seit der Umstellung auf ActivityPub dazu und nicht schon seit 2010, und Hubzilla und (streams) gehören gar nicht dazu. Gemäß dieser Definition fing das Fediverse erst an zu existieren, als das erste Projekt direkt auf ActivityPub aufgesetzt wurde.
Darüber wird aber nirgendwo diskutiert und auf Mastodon schon gar nicht. 75% der Fediverse-Nutzer haben von Hubzilla noch nie auch nur gehört, von (streams) haben noch weniger gehört. Und daß diese drei nicht schon immer auf ActivityPub basiert haben, wissen noch viel weniger Leute.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #ActivityPub #DFRN #Friendica #Zot #Hubzilla #Nomad #Streams #(streams) -
#snac2, #PeerTube, #WordPress #Misskey, #Akkoma; it's especially refreshing to see a #snac instance in the list.
And only a single mastopub box in the list, lolz.
People are starting to learn that there's no such thing as a mastodon network, and further that there's waaaay mo better #Fediverse platforms to meet whatever their needs and desires are in #DeSoc - many of those Fediverse severs in fact bridging the #protocol_divide by supporting not just #ActivityPub in the Fediverse, but also #OStatus (yes, still), #AT_Protocol, #Nomad, #Zot, #nostr, #Diaspora, and other emerging Fediverse protocols under current development!
w00t 🤘🤠🤘
⛵
.
RE: https://fediverse.one/objects/fdc30534-1166-c797-1d9c-12e934354315
-
@Strypey @Laurens Hof I think I have to jump into this conversation here.
> Fediverse platform Streams has added nomadic identity to their platform, based on ActivityPub
To be clear, Streams has always had Nomadic Identity, using their own protocol (Zot/ Zap/ Nomad, whatever it's currently called).
First of all, a little nitpicking: It is not "officially named 'Streams'" like other projects are officially named "Mastodon" or "Friendica" or "Hubzilla".
It's officially and intentionally unnamed. It's intentionally nameless and brandless. Not even its instances have a unified identifier like "mastodon" or "friendica" or "hubzilla". "Streams" is the name of the code repository which was absolutely required to have a name, so Mike only speaks of the repository, and the community speaks of "(streams)" in parentheses.
And yes, it has always had nomadic identity. And it's at the end of a long string of forks, all by Mike himself, that have been supporting nomadic identity since 2012 when Mike forked Friendica into something named Red and ported it from Friendica's DFRN to his new nomadic Zot protocol.
In other words, nomadic identity has been in use for almost four years longer than Mastodon has been around. And the idea itself is from 2011 when Mike discovered one critical shortcoming of decentralised networks, and that's people losing their online identities when the instances they're on shut down.
Red still exists, only that it has been Hubzilla since 2015.
(streams) is based on a protocol named Nomad. Technically speaking, Nomad would be Zot12, but when Zot11 was reached during the development of Roadhouse which (streams) is a fork of, it had become incompatible with Hubzilla's Zot6. So in order not to confuse people, this version was renamed Nomad.What's changed is ...
> Streams is using FEP-ef61
Mike is actually a big contributor to FEP-ef61 because what FEP-ef61 tries to do, he has done before way back in 2011 when he conceived the Zot protocol and in 2012 when he implemented it for the first time.
So thanks to Mike, the wheel doesn't have to be re-invented from scratch by someone who has never heard of the existence of wheels before, much less seen or even used them.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hubzilla #Streams #(streams) #Zot #Zot6 #Nomad #ActivityPub #FEP_fe61 #NomadicIdentity -
@jupiter_rowland @danie10 @thenexusofprivacy @mikedev
Okay first I should state that I've never actually said that masto isn't a solid and capable platform. It is, but at a severe cost - the design of masto, notwithstanding the insistence on maintaining a historically lackluster feature set when compared with almost any other Fediverse software, is such that it really isn't built for #DeSoc - it really strives to be some sort of unachievable ideal for the monolithic silo model.
No one but me seems to site this nowadays, but masto doesn't even really shine with respect to cost in terms of system resources and stability until you approach the 20,000 user account mark. What? Why would you do that? Back when these stats were being bandied about, Pleroma was showcasing its new #Gopher protocol (browsing) support, and reminding people that it felt perfectly at home on an #rPi. No such claim was ever made for masto, lolz. That doesn't mean that the other platforms aren't just as capable of scaling vertically... but... why? Who's going to foot the bill? Who's going to manage all of those un-vetted people creating accounts on your machines? Why would someone bother with that in the first place?
Community? Nope - there's no sense of community on masto servers, and I'll get to that later. Because you want to create your own private Idaho? Probably.
mastodon.socialis one of, if not the, largest deprecated monolithic silos existing in the Fediverse today. Why? What possible benefit could be derived by driving a million people into a single funnel under the auspices of telling them that they're escaping that very same model? It's ludicrous.No matter what happens in the short term, Eugen is assured of his parachute and comfortable retirement fund, except for the part where he forgot to have his new significant other sign a pre-nup - that might dash his net worth later, but that's another consideration entirely. I hope his marriage is actually a long and fruitful one that lasts forever, he's not a bad guy, he's just been courted and corrupted by the "Ooh shiney" phenomenon of financial entrapments that come with relative success in the media and pop culture.
The reason masto needs to be hard forked (several times, IMO) is not to create a better masto that will lend itself to DeSoc, #smolweb, and self-hosting on people's home networks, but rather, to further dilute the trademark, and especially the brand, effectively killing it if possible, supplanting it with Fediverse instead. People like to bounce around that term inclusivity, well, this accomplishes that.
Forks of masto aren't going to create a better masto. No way. Sure, some improvements on this one, other features on that one, but dilution of the brand until it is only as significant as any other deserving Fediverse platform is and should be the ultimate goal. It's not well suited, architecturally for horizontal scaling anyway, unless you don't mind throwing all those system resources at it that could better serve you elsewhere with something like #GoToSocial or one of the #Misskey and #Pleroma family fork members.
True leaders in the Fediverse will initially be those platforms that have planned ahead and accommodate other DeSoc protocols, arguably Fediverse protocols, at this time, #Diaspora, #OStatus, #Nomad, #Zot, and even others that some #Fedizens turn their noses up at, like #nostr and #Bluesky's #ATP. #ActivityPub is NOT the end-all, be-all for the future. It is the golden calf of today, and just as others that have come before, it will morph and evolve or be obviated by others that will be plugged into the platforms currently running it - #Friendica, #Hubzilla, and Streams are prime examples of this, and Friendica especially, considering it's the only extant original member of the Fediverse for all intents and purposes. One could say that Friendica is the #Slackware of the Fediverse, lolz.
With respect to Friendica in particular, but also Hubzilla and others that have arrived at this obvious conclusion, ActivityPub is merely the major vehicle by which it communicates with other decentralized social communications systems on the Internet. I don't think it has ever lost sight of that, like another of its contemporaries, #GNU_Social did.
Hemming large masses of people onto a single (and at this time appearing to be) and open walled garden has the immediate effect of control over large swaths of population - you can say this, but not that. You can think this, but not that. You can be this, but not that. You can believe this, but not that - under penalty of excommunication.
In reality, we don't have strong friendships with our neighbors - that's why we have fences. We wave to them and say hi, call the cops when they're on vacation and see someone suspicious lurking about their property. That's about the extent of being a neighbor. We invite our friends and coworkers over for BBQ's and to swim in our pools, not so much our neighbors.
The current masto social architecture is the antithesis of that, and so is it's physical architecture - put all the lobsters in the same pot of boiling water. Turn on and off their ability to speak all at once. Force them en masse to endure advertising blitzes (Oh, mark my word that's coming) decided upon by the server admin. It's like Baba O'Reilly by The Who - "Meet the new boss, Same as the old boss".
That's not the promise of Fediverse. it's the antonym.
masto also hinders innovation, attempting to define, dictate even, what should and should not be available - Nomadic identity is but one emerging facet of what is fracturing the masto monopolistic initiative - and that's a good thing, because with the help of FEPs, already, others are adopting various cooperative models for this as well, but discussing that now, and here, at this time, is more of a tangent so I'll get back to the point.
Jupiter:
> That's why people still fork Mastodon to add features that are available just about everywhere else.Indeed it is, and why it has managed to enjoy a reasonable level of notoriety. There's also the wholly undeserved notion of community that actually, in direct opposition to, masto has continually sought to break and in a very big way, break.
There are certainly platforms (mostly forumware) that curate a sense of community, but those days are largely past. Whether it was #gplus, #Myspace, #Faceplant, #InstaSPAM, or #Twitter; because just as it is in real life, #COMMUNITY is that which you define for yourself through your connections - your follows and those who choose to follow your account. The biggest failures in the Fediverse that I've personally observed are those that seek to localize, geographically or by shared interest, a monolithic ivory tower of sameness and similarity amongst people.
I felt so awful for one guy who, so enthusiastically upon discovering the Fediverse, started registering domain names corresponding to several states, thinking that he would be successful in launching a geographically oriented family of masto based servers tending to the shared interests of people by offering them a place to congregate. He quickly discovered the fatal flaw in his model, but was stuck with hefty data center bills to maintain all these masto servers that were largely uninhabited.
Trying to get rid of your masto subscribers when you figure out that you need to egress from it is not an easy task without disenfranchising your user base. I know, because a few years back, not long after
@Gledarchived his #mastodo fork and urged everyone to adopt Pleroma instead, I face the daunting task of trying to convince my user base to migrate elsewhere - it took more than a year to accomplish!Danie:
> thing is though there are also many existing alternatives to Mastodon already on the Fediverse, so why fork it?In a nutshell, because it serves to, at the very least, dilute the masto brand, and more likely kill it. It has served its purpose and now that it has been exposed as a vehicle antithetical to #DeSoc, it's time to deprecate it.
My introduction to the #Fediverse occurred when I stumbled upon an earlier incarnation of #Friendica, started looking at #Red_Matrix, and discovered that the monolithic model, if not having been shown the door, had at least been handed its hat.
The problem at that time, was the effect of Prettiness, and of course, UX. Friendica wasn't too bad in that latter sense, when compared to that of Faceplant, but it sure didn't even come close to being as pretty as Faceplant - or even Myspace, which had only recently fallen into the abyss. That's changed A LOT, even in just the past year, with respect to Friendica and Hubzilla - they're much more intuitive for a layperson parachuting to the ground after jumping from the cesspit over at Faceplant.
I think that more than anything, not being pretty enough for the subjugated chattel coming from Twitter and Faceplant, was the most difficult thing for onboarders to embrace. Mike placed all of his focus on functionality and forward thinking vision with respect to what these and later efforts could provide the masses, but the "prettification" was left to others who didn't step up for the challenge for many years. I'm all for features six-ways to Sunday, but I also feel that many things need to be hidden from the landing page a new user sees upon account creation - the very basics they expect should be there, akin to those available in the deprecated monolithic space; users expect this, but they don't yet know they not only want, but really need all of these other feature sets too, yet some things should left, IMO, to be discovered later by the user.
And in my conversations years ago with Mike, I gleaned as much from him [paraphrased, of course]: "Here's this really bitchen gift for the masses, it does all this kewl stuff, now I leave it up to others to make it pretty" (and with a sense of coherency that these former subjugated chattel can initially get their heads around). Putting all that stuff right in their face was awe inspiring, but foreboding at the same time for many.
Well, finally, people are making it pretty :) And they're also moving much of the overwhelming busy-ness elsewhere in the UI. As a result, there's been an explosion of adoption - not even primarily from former masto folks either.
I'd like to touch on the notion of community one more time in closing. It might be convenient for n00bie onboarders to glean a bit about how a particular platform functions, but just like in your own neighborhood where you live, you make friends elsewhere mostly - at work, at functions of the hobbies you engage in, with friends you meet at the grocery store or libraries, and the beaches or on hiking or 4x4 weekend excursions. It's the same way in the Fediverse, you make your friends through connections here and there through people you discover along the way, and 99% of them ARE NOT on your particular server instance.
They don't need to be either, because this is the Fediverse :)
⛵
.
-
@glyn @We Distribute
It's true that Nomadic Identity is largely only implemented by Streams and Hubzilla at this time, which are PHP implementations of the Zot/Nomad protocol. Admittedly, it's a bit hard to find quality documentation on these. Paradoxically, the implementations are quite mature, and have been around for years at this point.
Yes, nomadic identity was created along with the Zot protocol as early as 2011. Zot was first implemented on the Red Matrix which is based on a Friendica fork, which had its 1.0 release in 2013, and which was renamed into Hubzilla and repositioned with a different set of features in 2015. So all this happened before Mastodon was released.
Nomadic identity has been in daily, stable use for over a decade.
Like Friendica's DFRN before, Zot was never meant to be an officially standardised protocol like ActivityPub that other, completely different and independent server applications could use. Zot and Hubzilla have always been firmly tied to one another. Zot is not nearly as vague as ActivityPub. And Zot not only covers nomadic identity, but also Hubzilla's permission system which exceeds even a Mastodon user's wildest imagination by magnitudes.
Over the years, Mike advanced Zot further and further, often requiring new forks to test Zot. In 2018, two different Osadas and Zap became the testbeds for Zot6 which Hubzilla would later be upgraded to, and short-lived Zap even saw stable releases. In 2020, another Osada and two more projects which resurrected the names Mistpark and Redmatrix were the testbeds for Zot8 which was so advanced that it had become impossible or at least unfeasable to upgrade Hubzilla to it.
Roadhouse from early 2021, a fork of the third Osada, Redmatrix 2020 and/or Mistpark 2020 (they had the same code base), was either the last application on Zot8 or the first one on what would have been Zot11, but what was so advanced that it had become incompatible with Zot6. Therefore, it was renamed Nomad. And it became the base protocol for the nameless, brandless server application in the Streams repository which Mike is currently maintaining and constantly advancing. And current Nomad would be Zot12 if it was still Zot.
The reason why nomadic identity has only ever been implemented in PHP is because the only one who has ever built server applications with nomadic identity was Mike Macgirvin who also created the protocols behind them. And being built in PHP, everything that Mike has ever created from 2010's Mistpark to 2021's (streams) can be installed on a run-of-the-mill LAMP stack without having to fumble around with stuff like Ruby on Rails.
If you come from a "Fediverse = ActivityPub" background, all this may seem strange. But it was the only way for nomadic identity, Zot, Nomad and their implementations to advance to such power so quickly. Mike is still the sole keeper and maintainer of Nomad and its only implementation. This means that nobody else can meddle with it, and Nomad and (streams) are perfectly matched to each other. Thus, (streams) is probably the most quickly advancing Fediverse project currently.
That said, it is not a fully closed ecosystem. However, the idea behind developing stuff for Nomad is vastly different from the idea behind developing stuff for ActivityPub.
If you want to make something for ActivityPub, you usually sit down and start from scratch, from completely zero, except for the ActivityPub spec.
If you want to make something for Nomad, the recommended ways involve (streams). See, unlike Mastodon, (streams), just like Hubzilla, is not an enclosed monolith. It's modular. It can be expanded. And, in fact, both come with official add-ons right away. ActivityPub support itself is an add-on. A big difference is that Hubzilla comes with more add-ons whereas (streams) is slimmed down in this regard to make development easier. But it's possible to add third-party add-on repositories to server installations of both.
So if you want to make something for Nomad, you start with (streams). No need to start from scratch.
Either you simply develop add-ons for (streams) and offer them in a third-party repository that can be added to (streams) instances. Or you could soft-fork (streams), its core is in the public domain, add your stuff, slap a name on it and offer it as a new project.
I myself wouldn't recommend a hard fork, though, seeing as how rapidly (streams) is evolving and improving.
Sure, it'd be possible to develop something against Zot6 or Nomad completely from scratch. But if you build against Zot6 to stay compatible with Hubzilla, you're at Mario Vavti's mercy because he is the main dev of Hubzilla and therefore the keeper of Zot6 now, although I guess he doesn't change much about the protocol anymore.
And if you build against Nomad, you're at Mike's mercy, and Mike keeps advancing Nomad constantly and (streams) along with it. Also, if you build against Nomad, you must go multi-protocol because Hubzilla doesn't understand Nomad, so you also have to implement Zot6.
Standardising Nomad and handing it over to a W3C commission so it's no longer in the hands of one individual would be the worst that could possibly happen to it. Such a commission would water it down and remove stuff that they deem unnecessary. And Mike, no longer in control over Nomad, would have to play along and water (streams) down.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #NomadicIdentity -
@Scott M. Stolz
I am not sure if Solid has the concept of clones or syncing,
As far as I can see, it doesn't. It works wholly differently from nomadic identity.
Currently, Hubzilla hubs are like clients with full data storage that sync their data peer-to-peer.
Now imagine Hubzilla hubs being thin clients with no data storage whatsoever. Next to these hubs, there's another kind of server where your data is stored. Let's call it data server. It's fully independent from the hubs where you have your channel.
You can have as many instances of your identity on as many thin client hubs as you like. One goes down, doesn't matter, you've got more. But all your data is stored on one data server. With one account. One. Every last one of your channel clones on all those thin client hubs is connected to this one data storage.
You may be able to choose where to park your data. But you can only choose exactly one data server where you want to park your data for all your channel clones. You can not clone or mirror your data storage. You've only ever got one instance of that.
If that server goes bellies-up, have fun starting over from scratch. If you're lucky, you may have a backup. If you don't have an up-to-date backup because you haven't made one in a while, or you've never made one in the first place, well, then you're fucked.
It'll be even more fun if Solid won't let you make backups of your data in the first place.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #Solid -
Ryan,
How refreshing!
Another bridging mechanism to extend the reach and interoperability with other Fediverse protocols in the #DeSoc space is most welcome, and from the limited analysis I've been able to perform so far this is a novel approach to what some point in the future will find other Fediverse platforms incorporating in their network stacks.
So far, we've got seamless nostr interoperability to add to the other fine protocols such as Diaspora, ZOT, Nomad, OStatus, ActivityPub, and others in the mix. You might also wish to take a look at the repo for Minds to see how they've made seamless integration between the ActivityPub and nostr portions of the #Fediverse as well, and oh, pay no mind to the infantile and disparaging remarks that some small minded folks in this thread have exhibited - they are free to *defederate themselves from the Fediverse at any time.
We've been following withe some enthusiasm your project in the Fediverse-City community and it would be a pleasure to have you participate there. Your insight into the open and public aspects of Fediverse traffic in the #DeSoc world is a testament to the innovation and evolution that is possible in obviating the proprietary, privacy disrespecting, deprecated monolothic silo networks that have sowed so much acrimony and subjugation over the very people whom they seek to quantify as their business products.
You're performing a great service here, feel free to block any miscreants in this thread who don't understand the definition of public.
Also, might I suggest that instead of offering a `#nobridge keyword index, you think about offering a solution as a FEP here?:
https://codeberg.org/fediverse/fep/There are a lot of Fediverse platform developers I'm sure that you'll find welcoming, encouraging, and willing to offer assistance in formulating solutions to silence the adolescent juvenile mindsets that have been berating you in this thread for your selfless commitment to the well being of us all.
In the future, the Fediverse that we perceive and interact within will become its own heterogeneous superset of networking protocols to facilitate effortless communications between individual parties regardless of which portions of the Fediverse and their associated protocols implemented. Just like #OStatus has been largely supplanted by ActivityPub, and #ZOT has been superseded by #Nomad, the ActivityPub portion of the Fediverse will also eventually be deprecated and replaced by other stacks that will emerge from the ether of creativity. In the meantime, we'll be bridging between the various protocol stacks, and Bridgy-fed is one of those tools that serves to make that a reality :)
Thank you again, for your selfless contribution to #DeSoc and the Fediverse. it's a fantastic achievement that will serve to benefit many in both the #ATP and #ActivityPub portions of the Fediverse!
#tallship #bridgy #FOSS #Fediverse #DeSoc #innovation
⛵️
.
-
Thank you for the optimistic PoV on the entrance of others to the #DeSoc of the Fediverse. It is an optimism that I share - especially with Matthias' announcement just an hour ago that his team behind the development of the #WordPress ActivityPub plugin has just released version 2.0.0 - considering the enormous footprint of WordPress installations across the entire Internet belonging to both common, everyday individuals and companies alike, of every shape and size, this is HUGE news.
It instantly, overnight, positions common folks and businesses to leap into the freedoms afforded them by the existing, privacy respecting, #FOSS based Fediverse that hitherto was... well, a bit of a leap for them psychologically. But now they have a familiar platform with which to begin a journey through the minefields of the deprecated, privacy mining, monolithic silos; its proprietors programming their masses of #subjugated_chattel into livestock holding pens, where they are weighed, measured, packaged, placed into inventory, and sold.
That does raise the issue of an error in your assertions however. You mentioned,
"instances in Meta's fediverses and on Bluesky".The truth however, the reality, is that each are merely a single instance - One big monolithic silo, as described above, with the same incentives of monetization through privacy mining techniques that have made them the dreadnoughts that they are; at least in the case of #Meta (Threads).
Bluesky is of that vertically scaling market as well, but much smaller than the #Faceplant and #InstaSPAM engines operated by Meta, and now their new spearhead into the DeSoc space occupied by ActivityPub and other decentralized or federated protocol based, horizontally scaling instances.
#Bluesky hasn't actually shown their hand yet to the general public, but already, they've disenfranchised (fired) much of their talent; some, actually principal architects of their monolith who were frustrated and disillusioned with the direction Jay has been taking the company - moving further and further away from the disowned public community they spawned, organized, and abandoned following the initial trials and tests of the open source preview version of what became #ATP protocol (ATX).
Even Jack has moved on and embraced yet another horizontally scaling protocol in the DeSoc space, #nostr, and it's already bridged and interoperating flawlessly with the ActivityPub powered portion of the Fediverse, which in turn interoperates with instances running other protocols such as #Nomad, #OStatus, #Streams, #Diaspora, and #ZOT... all of them part of the Fediverse.
Many of the extant #ActivityPub powered instances in the Fediverse merely need to install these capabilities with a couple of clicks to enable this interoperability, while others bridge the divide through infrastructure developed and deployed over the past year or so.
What will be Meta's use case here for their business product?
That's the main question I think folks need to address - not punish the good people on the so-called evil side of the divide, the hitherto subjugated chattel that populate Marks so-called Metaverse or whatever he thinks he can compel people to adopt and endure. The point is, childish, domain level blocking by juvenile minds operating ActivityPub powered #Fediverse server instances only serves to paint themselves (and the users who have to date trusted those admins with being told what they can and cannot see and do) into a corner where they effectively cancel themselves, and find that their users have migrated to other spaces... maybe WordPress, where they truly control their own destiny in the DeSoc space and can now fully participate and engage with others - but on their own terms, not someone else's.
And that, I believe, is what the whole thing has always been about, going back as far as #AngelFire and #GeoCities :)
I do agree with you that we should indeed embrace these common, everyday individuals who, through their programmed ignorance, are mostly clueless as to exactly what the Fediverse is, and more importantly, has always promised for them. This is an opportunity, like Steve Austin, (the Six Million Dollar Man): "We can rebuild them, we have the technology, we can make them better, stronger, faster..."
One more thing I should correct you on, the Fediverse is an internetwork of networks, on the Internet - there are no fediverses, Fediverse is itself a plurality, but your intent wasn't lost on me.
Great article, I enjoyed the read and most of all, your optimistically tempered intent. Thanks for sharing and I hope to see much more from you in the future!
⛵
.
-
I'm seeing an awful lot of Threads sourced nuggets espousing the virtues of, along with optimism surrounding, the #Fediverse lately.
This seems a bit sus to me, like a concerted outreach effort on the part of Meta/Faceplant and a few other largish, commercial actors to popularize their ulterior motives of domination by... Ahem, normalizing the concepts of #DeSoc and more specifically, the ActivityPub powered spaces in the Fediverse.
I actually dunno who MDBHD or John Oliver are, but I'm certain that they're no Oprah, although it would be nice if she would weigh in on the critical mass achieved to date in the adoption of Fediverse technologies that are #FOSS based, and #Privacy respecting.
To date, *Privacy has been of primary consideration and motivation in the development community surrounding the #ActivityPub powered platforms in the Fediverse, but the questionable players entering from the horizontally scaling decentralized social networking industry have, as of late, been overwhelmingly of the deprecated, privacy disrespecting, monolithic silo persuasion. These monolithic-ally inclined companies hailing from vertically thinking companies are an expected, yet suspect group of *privacy mining experts, sophomorically
(sic)wading into the deep end of a demographic consisting mostly of privacy minded* individuals and notable developers of the FOSS based portions of the software world.<tangent>These industrial surveillance engines are already back on their heels as they venture into what many warn as an #EEE incursion - but truth be told, already too late to the game to subjugate, assimilate us: #Diaspora #ZOT #nostr #Nomad #Matrix #TOR #Yggdrasil #I2P #IPFS / #IPNS and others, including blockchain based so-called #Web3 solutions with baked in privacy considerations at the protocol layer are being *Bridged to interoperate with each other and ActivityPub in the Fediverse at rates which the purveyors of industrial surveillance machinery must invariably only describe as "alarming rates" - that's good news for the average schmoes of the world like you and I.</tangent>So why are we, just in the past few weeks, seeing so much attention given to the Fediverse by these #juggernauts, perhaps #dreadnoughts, that for so long have exhibited such great restraint and avoidance of the mere utterance of Fediverse, ActivityPub, or even alluding to the notions of Decentralization? There's certainly a particular spin in their delivery, leveraging third parties that obfuscate their participation in the dissemination of their, Great News.
Speaking of Dreadnoughts, just how was it that the great Bismarck was taken out? Remember? The outgunned and outmatched Royal Navy took out her port rudder! ⛵ 💥
It was the end of an era. A rudder post. The Bismarck was doomed to circle her watery grave.
But I digress...
Make no mistake, obscuring the lines between the privacy respecting FOSS based camps that have historically steered the direction of DeSoc has taken, and the deprecated, proprietary silo companies which have based their entire existence upon advertising and industrial surveillance models that I refer to as The Sunnyvale Syndrome family of data mining engines, is now seeping through the cracks of a clear delineation between these two prinicples - that of uncompromising privacy and open source development and that of proprietary, closed source subjugation methodologies leveraging **YOU as the product in inventory*.
Feel free to boost and share your comments at length here. A million people other than myself are here in the Fediverse and are really interested in just what kind of impact the introduction of these traditionally privacy raiding Industrialists will have upon their... scratch that, our future online safety.
tl;dr: Your very private, personal medical history and data (and that of your minor children, in violation of FERPA regulations) is being wholesaled and auctioned off by the so-called "Big-Tech" entrants and hopefuls that are at this very time knocking on the front door of the ActivityPub portions of Fediverse... Tread lightly, and consider how your every move going forward affects the unwitting consent to farm and sell your most confidential personal information.
it is up to you - it is your choice to affirm or deny - whether industrial surveillance is your birthright to embrace or your nemesis to destroy... You, We, have that power to decide.
#tallship #Privacy #Sunnyvale_Syndrome #meta #HIPAA #PHI #FERPA h/t to: @liaizon
⛵
.
RT: https://social.wake.st/users/liaizon/statuses/111714899199909225 -
@Sandro Santilli Mastodon doesn't have it, and Mastodon doesn't really need it.
The channels structure was created to make nomadic identity possible or at least facilitate it.
Basically, a Hubzilla channel is a Friendica account with boatloads of extra stuff on top. All stuffed into a container. And that container resides on an account on one server.
What nomadic identity does is copy that container to another account on another server. A 1:1 identical copy. Even keeping the same identity, using the domain of the original server. Whenever one of them changes, the other one is kept in sync. They stay identical.
So yes, the identity of that container on foo.social is [email protected], and the identity of its clone on bar.social is still [email protected]. At least it is for servers that understand nomadic identity. Mastodon, for example, will see any post sent from the clone on bar.social as coming from [email protected] which to Mastodon is a wholly different actor from [email protected].
Hubzilla still uses the Zot protocol, it must have been around 2020 when it switched to the current and last version to come out, Zot6.
(streams) is based on Nomad. Nomad should actually be Zot12, but it is so much different from Zot that it is no longer directly compatible with Zot, and it got its own name.
(streams) has actually got even better ActivityPub support than Hubzilla. However, while Hubzilla federates with almost everything that moves, just like its predecessor Friendica, (streams) only supports Nomad, Zot6 and ActivityPub.
#Long #LongPost #CWLong #CWLongPost #FediMeta #CWFediMeta #FediverseMeta #CWFediverseMeta #Fediverse #Hubzilla #Streams #(streams) #Zot #Zot6 #Nomad #NomadicIdentity #Channels -
tl;dr: Hubzilla has had at least some of this for over a decade now. And it won't replace any of it with a new standard tailor-made for Mastodon.
@silverpill If you look past projects based on ActivityPub and at projects that have ActivityPub as an additional protocol, some of this already exists.- Data portability. In my opinion, this is the most important problem. I'm in favor of FEP-ef61, which also solves identity portability and unlocks many new features.
Exists in the shape of nomadic identity. Invented by @Mike Macgirvin 🖥️ in 2011 with his Zot protocol and first deplayed in 2012 with the Red Matrix, nowadays known as Hubzilla. Also available on (streams), Mike's current project at the end of a string of forks from Hubzilla, now based on the Nomad protocol.
Mike would like to see nomadic identity and other special features of the Zot and Nomad protocols included in the ActivityPub protocol. He has actually submitted a number of proposals for this. They were all rejected. Even though he is a protocol developer first and foremost, and he has both created and worked on more Fediverse protocols than anyone else, so he should be considered competent.
Nomadic identity with ActivityPub won't come unless either Evan Prodromou and the W3C commission cave in and allow Mike's suggestions, or someone re-invents the wheel from scratch in a way that's utterly incompatible to Hubzilla and (streams). And it won't come to Mastodon unless Eugen Rochko can imply that Mastodon has had it first.
And there will never be a nomadic identity standard that meets Mike's requirements as well as Eugen's wishes.- End-to-end encryption. MLS has become a standard, and it would be wise to adopt it. Issue 3 at fediverse-ideas provides a good overview of what we have at the moment (not much). Some variation of FEP-ae97 is likely needed to make end-to-end encryption work.
AFAIK, all three of Mike's still existing projects, Friendica from 2010, Hubzilla from 2012/2015 and (streams) from 2021, have it. Optionally, but still. I think Friendica actually advertises military-grade encryption.- Plugins. Something like Pleroma MRF, but cross-platform (e.g. Wasm-based). Also, pluggable timeline algorithms.
Friendica, Hubzilla and (streams) have had support for add-ons, including third-party add-ons, plus a number of official add-ons since their respective inceptions. If you want a cross-platform add-on standard, I hope you don't expect these three to throw their own standards over board in favour of the new standard. Otherwise, good luck developing a replacement for Pubcrawl that makes Zot-based Hubzilla compatible with ActivityPub while working on ActivityPub-based Mastodon just the same. Friendica, Hubzilla and (streams) rely on add-ons for all federation beyond their respective base protocols (DFRN, Zot, Nomad).- Groups. We have several competing standards for groups: FEP-1b12, FEP-400e, Mastodon developers are working on their own standard. It would be nice to converge on a single standard, that also supports private groups.
Friendica, Hubzilla and (streams) have had support for discussion groups/forums since their respective inception. On Friendica, a group is a user account with special settings; on Hubzilla and (streams), it's a channel with special settings. In addition, especially Hubzilla and (streams) have access permission control on a level that most people for whom the Fediverse is only ActivityPub couldn't imagine in their wildest dreams. All three can be used by users from all over the Fediverse already now.
Good luck forcing Friendica to give up its 13-year-old standard that's used by Fediverse News, just to name one, and Hubzilla to give up its 11-year-old standard that blows everything else but what (streams) does out of the water. Good luck forcing them to adopt something inferior.
On the other hand, good luck forcing Lemmy and /kbin to switch to a wholly different standard. Don't forget that these two exist as well. And good luck having the Fediverse outside of Hubzilla and (streams) adopt both server-side and client-side OpenWebAuth.
And I'm not even talking about how different Fediverse projects handle threads differently. Mastodon has a Twitter-like thread structure: many posts, tied together with mentiones. Just about everything that's built on ActivityPub has taken this over. Friendica, Hubzilla and (streams) have a Facebook/blog/Tumblr-like thread structure: one post, the start post, and many comments which aren't posts. It's similar on Lemmy and /kbin which are Reddit clones, only that they don't allow thread starters to moderate their own threads.- Quoting. FEP-e232 is a proposed standard, but most fediverse applications still use non-standard properties. Mastodon developers are trying to invent something completely different.
This is something that almost the whole Fediverse has implemented, save for Mastodon.
And again, Friendica has had quotes since its inception in 2010, almost six years before Mastodon was launched (which, by the way, federated with Friendica and Hubzilla on the spot). Hubzilla has had quotes since 2012, inherited from Friendica. Their way of quoting is dead-simple: BBcode.[quote][/quote](streams) supports Markdown and HTML in addition to BBcode, but otherwise it's the same.
Oh, and by the way: Friendica, Hubzilla and (streams) have also supported quote-posts a.k.a. quote-tweets a.k.a. quote-toots a.k.a. quote-boosts from their very beginnings.- Markets. So far there's only one server implementation capable of processing payments.
At least two. Hubzilla has a payment add-on, too. It isn't installed on all hubs, but it's there.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #CWFedisplaining #Fediverse #Mastodon #MastodonIsNotTheFediverse #NotOnlyMastodon #ActivityPub #Friendica #DFRN #Hubzilla #Zot #Streams #(streams) #Nomad #Lemmy #kbin #/kbin #NomadicIdentity #OpenWebAuth #Group #Groups #Forum #Forums #Quote #Quotes #Encryption #E2EE #E2EEncryption -
(Sollte dieser Kommentar abgehackt wirken, öffnet ihn an seiner Quelle. Da sollte er komplett sein.)
@Dalbo (extinct) | flo Das kann man gar nicht vereinheitlichen. Schon gar nicht so, daß es für alle Use-Cases und alle Anforderungen immer zu 100% paßt.
Ich bin der Jupiter Rowland, von dem @Dalbo (extinct) | flo einen Kommentar verlinkt hat. Und ich schlage mich schon seit geraumer Zeiten mit dem Thema #AltText und #Bildbeschreibung herum. Aus mehreren Gründen.
Zunächst einmal bin ich zwar im #Fediverse, aber nicht auf #Mastodon. Ich bin auf #Hubzilla, das weder für Posts selbst noch für Alt-Text eine in der Praxis wirklich relevante Längenbeschränkung hat und noch dazu sehr drastisch anders funktioniert als Mastodon.
Auf Mastodon hast du 500 Zeichen für den Post. Bilder werden als Dateien direkt an den Post angehängt. Jedes Bild hat 1500 Zeichen für den Alt-Text. Und für den Alt-Text gibt es ein separates Eingabefeld.
Auf Hubzilla hast du einige zigtausend Zeichen für den Post. Bilder werden hochgeladen auf den in Hubzilla eingebauten Cloud File Space und dann wie in einem Blogpost oder auf einer Website in den Post eingebettet. Nix mit Dateianhang. Der Alt-Text ist auch kein separates Feld. Er muß per Hand eingearbeitet werden in den BBcode, mit dem das Bild eingebettet wird. Er ist also Teil des Post und unterliegt damit denselben (quasi nicht vorhandenen) Beschränkungen.
Mario Vavti wird einen Deibel tun, das über den Haufen zu schmeißen, damit es genauso funktioniert wie auf Mastodon. Und Mike Macgirvin, der #DFRN, #Friendica, #Zot, #NomadischeIdentität, #Hubzilla und #Streams erfunden hat und heute noch (streams) betreut, das dahingehend genauso funktioniert wie Hubzilla, wird einen Deibel tun, (streams) so umzubauen.
So, dazu kommt noch etwas: Im Fediverse liebt man lange, detailreiche #Bildbeschreibungen. Alles, was dir auf "So schreibt man inklusiven Alt-Text für eine kommerzielle/wissenschaftliche Website"-Seiten beigebracht wird, ist hier kompletter Käse.
Die Leute auf Mastodon freuen sich ein Loch in den Bauch, wahnwitzige 1500 Zeichen für Alt-Text zu haben. Im Tröt selber haben sie nur 500 Zeichen. Minus den eigentlichen Tröt, minus CWs, minus Hashtags. Da packen sie dann für ihre Begriffe hochdetaillierte Bildbeschreibungen rein. Nix mit kurz und prägnant und nur das für den Post Wesentliche.
Deswegen sind hier im Fediverse meistens "Alt-Text" und "Bildbeschreibung" absolut synonym und vollwertig gegeneinander austauschbar.
Aber: Ich habe vor Monaten mal debattiert mit einer Nutzerin, die aufgrund einer körperlichen Behinderung so tatterig und grobmotorisch ist, daß sie einen Mauszeiger nicht so präzise und ruhig auf ein Bild bewegen kann, daß sie so den Alt-Text lesen kann.
Die hat mir gesagt: Detaillierte, informative Bildbeschreibungen im Alt-Text sind Mist. Und zwar dann, wenn sie Informationen enthalten, die sonst nirgendwo im Post zu finden sind. Nicht im eigentlichen Post-Text und auch nicht im Bild, jedenfalls nicht für komplette Laien. Wenn es im Alt-Text steht, ist es für Leute wie sie unerreichbar, und die Informationen sind für Leute wie sie verloren.
Okay, auf Mastodon geht es nicht anders. Die einzige Alternative wäre ein Thread, der auch nicht sehr barrierefrei ist.
Aber überall sonst geht es anders. Überall sonst hat man für den Post selbst ein Vielfaches der Kapazität, die man für den Alt-Text hat. Außer auf Friendica, Hubzilla und (streams), wo beides quasi unbeschränkt ist, zumal der Alt-Text ja eh Teil des Posts ist.
Wenn man nicht einfach nur einen kurzen, aufs Wesentlichen reduzierten Bildersatz schreibt, sondern wirklich in der Bildbeschreibung groß und detailliert beschreibt und erklärt und informiert, dann sollte man die nicht auf Biegen und Brechen in den Alt-Text tun, wenn man es nicht muß. Und überall, was nicht Mastodon ist, muß man das nicht.
Ich selbst bin dazu übergegangen, Bildbeschreibungen nur noch in den Post-Text zu tun. Es sieht nicht gut aus, aber barrierefreier wird es nicht mehr. Und ich bin endgültig nicht mehr gebunden an das 1500-Zeichen-Limit beim Alt-Text. Das setzen Mastodon & Co. nämlich im Gegensatz zum Post-Text rigoros durch und schneiden alles dauerhaft ab, was über 1500 Zeichen hinausgeht.
Meine Bildbeschreibungen erreichen nämlich regelmäßig geradezu titanische Ausmaße. Ich habe häufig sehr viel zu beschreiben, weil es in meinen Bildern fast nur Dinge gibt, die niemand kennt. Mitunter sogar sehr viele davon. Mit einfach nur Nennen ist es da nicht getan; dann kommen die Sehbehinderten und fragen: "Ist ja schön und gut, aber wie sieht das aus?" Und ohne Erklärung kommen im Grunde alle und fragen: "Was ist das jetzt genau, was tut es, wie funktioniert es?" Alleine um zu erklären, wo die Bilder entstehen, brauche ich manchmal über tausend Zeichen.
Gut, das ist eine Randerscheinung, aber so etwas gibt es eben. Und das läßt sich nicht in einen angeblich für alle gleichermaßen funktionierenden Standard pressen.
CC: @Anne Roth @Free Software Foundation Europe -
Basically, everything in the #Fediverse that's based on #ActivityPub is built against #Mastodon. Because Mastodon defines the ActivityPub spec all alone.
Says the man who has created more federated protocols - #DFRN, #Zot, #Nomad - and Fediverse projects than anyone else and invented #NomadicIdentity.
Mike Macgirvin wrote the following post Tue, 05 Sep 2023 22:28:16 +0200 I provided my input to the AP spec editor and it was rejected outright. Everything I provided to the ActivityPub editor was rejected outright. If there were any questions, it had to go through the Mastodon dictator, who rejected anything he didn't invent. And then the ActivityPub editor would likewise reject it. "Mastodon has millions of users, you don't".
That's the way the process works.
The major concern was that nomadic identity is hard, and the clock was ticking on when the spec had to be finalised. The ActivityPub editor also insisted that it be done using the draft digital identity spec. So that ensured it would never make it into ActivityPub.
Here we are 5-6 years later and they still can't figure out how to do nomadic identity in a decentralised framework (outside of using torrents or centralised resolvers). Meanwhile we've had it, used it, and improved it for well over a decade.
There's a specification in the public domain. Some complain that it isn't enough, but I'm one person in a planet of 8 billion and haven't had any help developing this. The only help I ever get is with bike shed stuff - web interfaces. Not one person has offered any help polishing up the spec or improving the actual implementation code or even offered critique and discussing the subject. Just "I can't use this. Bye." [edit: apologies. That isn't entirely correct. I did get help from one person.]
I've started to pick it up and try again using did's as a proof of concept, but I'm retired now and really can't be bothered dying on the same hill over and over again.
But I will try and update Nomad (the protocol, formerly Zot) to use a did: form. It's just a replacement WebMTA for delivering JSON ActivityStreams which is nomadic aware. There's still no chance of it ever getting into ActivityPub unless it's invented by the Mastodon dictator.
Meanwhile the spec is in the public domain and there are working implementations and it federates with ActivityPub and nobody is holding a gun to anybody's head.
https://codeberg.org/streams/streams -
@volkris The belief that each Fediverse project is a different graphical front-end app for the exact same technological back-end is complete non-sense. It sounds like all Fediverse projects run the self-same back-end Web server technology and just put different Web interfaces or mobile apps on top.
#Firefish, formerly known as #CalcKey, is quite a bit different from #Mastodon. And it's still microblogging based on #ActivityPub.
#Friendica is vastly different from Mastodon, also because its base protocol is #DFRN and not ActivityPub. It has an add-on for ActivityPub connectivity.
#Hubzilla and #Streams are even more different from Mastodon. They're based on two versions of #Zot, and they even have an architecture that's extremely different from all other Fediverse projects, even Friendica included, and that wouldn't even be possible with ActivityPub. -
@Chris Trottier In the #Fediverse, you're only semi-safe from search warrants at best.
If a #Mastodon instance hosted in the USA is being targetted by the authorities, the admin can easily go through even private communication. Instances hosted abroad can shrug this off, and most US newcomers to Mastodon reside on mastodon.social hosted in Germany where US Federal law and state laws don't apply, but many have moved to US-based instances since.
If you want actual privacy, if you want access control that's worth the name, if you want encrypted communication, forget #ActivityPub and everything that's based on it. Instead, go for #DFRN or, better yet, #Zot and what's based on it, and keep your close friends all on instances using at least largely the same protocol. -
Ummm... Yeah... The view is skewed methinks?
@tkinias
You said:
> I wonder how many young people even know that .gif was just a crappy 8-bit file format with patent problems?
"Is", actually. "Is just a crappy 8-bit file format".
Yes, observationally, a .gif has become somewhat synonymous with any relatively short, shitty, meme-ism, much like an .avi, but I would suggest that what you're generating is more of a Fediverse (mastotronic, actually) limitation whereby the user effects a download of the meme in .gif format and it shows up on your storage device as an mp4 file - this is not a limitation of the file format except in the sense of a #Fediverse (in this case, mastotron) limitation.
The conversion occurs when you d/l the graphic to a local file system - and it is shameless.
For example I save them through matrix since they retain their, as you put it, their "crappy 8-bit file format" as intended, instead of the fucking #Frankenstein bullshit that mastopub servers force - Mastodon, by the way, is already on its way out - the Fediverse has left it behind and increasingly, it seeks kludges to remain relevant in the #ActivityPub sectors of the Fediverse.
Bye bye #mastopub and #Eugen's brief grip on the Fediverse and all the phenomenal emerging technologies that are largely replacing it in the world of #ActivityPub alone!
Fuck that guy. He's a #simp bitch.
#tallship #FOSS #DeSoc #evolution #matrix #noster #Diaspora #ZOT #Bovine #tapir
⛵
. -
@CynthesisToday If you want to speak to someone who really knows his way around communications protocols, I'll have to refer you to @mike, creator of #Friendica, #RedMatrix, #Hubzilla, #Osada, #Zap, #Misty, #Roadhouse and #Streams and of the #FederatedSocialWeb protocols #DFRN (base protocol for Friendica) and #Zot (base protocol for all the others), thus also inventor of #NomadicIdentity, as well as contributor to both the #Diaspora protocol and #ActivityPub.
-
@Codex ☯️♈☮ @CynthesisToday I think the #Fediverse is the easiest to understand for those who halfway know their way around computer stuff if you start at the protocol level.
#ActivityPub is a digital communications protocol standard. Like e-mail or RSS or Atom or XMPP or Matrix, for example. Or like #StatusNet or the #Diaspora protocol or #DFRN or #Zot, now known as #Nomad in its latest incarnation.
The server application projects that are based on ActivityPub are different server-side software implementations of the same protocol. Some have more features, some have fewer, some specialise in particular tasks which is possible because ActivityPub is not specialised itself, not a one-trick pony.
Like, for XMPP, you have jabberd and ejabberd and Openfire and Prosody and Tigase. For e-mail, you've got various mail servers and MTAs.
The main difference here is that ActivityPub is so versatile in its capabilities that it can be used for a whole lot of different things. #Mastodon, #Pleroma, #Akkoma, #MissKey, #CalcKey etc. were made for microblogging. But ActivityPub can also be used for actual blogging platforms like #Plume or #WriteFreely, for video streaming like in the cases of #PeerTube and #Owncast, for audio streaming like in the cases of #Funkwhale and #Castopod and for link aggregators/discussion communities like in the cases of #Lemmy and #kbin. Only to name a few examples.
Still, there are enough parts of this protocol fixed so that all these projects, all these implementations of ActivityPub can connect to one another and ideally communicate with one another.
Now, why is all this made so that they can connect to one another?
That's because they all use the same protocol. The alternative would have been to do like Mike MacGirvin did with DFRN for #Mistpark, later #Friendika, today known as #Friendica, and create a whole new protocol from scratch, even though StatusNet was readily available. Well, only that Mike's intention was to federate Friendica with everything that moved, regardless of protocol.
Okay, better comparison: The alternative would have been to do like the four Diaspora* creators and create a whole new protocol from scratch with no intention whatsoever to connect to the outside world.
Well, instead, all those clones of YouTube and Instagram and Reddit and GoodReads and so forth chose ActivityPub. It was a win-win situation: They could use an existing protocol which actually worked for them instead of taking upon themselves designing a whole new protocol first and then their server application on top. And they could expect a wider audience, namely everything else that uses ActivityPub. Two birds, one stone.
Oh, and by the way: Neither the Fediverse nor ActivityPub was designed around Mastodon, nor was ActivityPub designed by Eugen Rochko (Mike Macgirvin did have some saying in it, though, AFAIK), and quite a few Fediverse projects already existed before Mastodon. Pleroma is three and a half weeks older. MissKey is two years older AFAIK. #Hubzilla was forked from Friendica four years before Mastodon came out. This means that Friendica has to be even older: six years older than Mastodon.
None of these projects will ever give in to Mastodon's limitations and reduce their own feature set for the convenience of Mastodon users. Oh, and neither will the projects that came after Mastodon. If something from another Fediverse project doesn't look good on Mastodon, it's Mastodon's problem. -
@Dr. Jorge Caballero
Hear me out: 1-click privacy-conscious quoting.
@Dr. Jorge Caballero schrieb:Hear me out: 1-click privacy-conscious quoting.
>Hear me out: 1-click privacy-conscious quoting.
"Hear me out: 1-click privacy-conscious quoting."
«Hear me out: 1-click privacy-conscious quoting.»
(↑ All these were copy-pasted, by the way. But at least the upper two are fully legitimate quotes here. ↑)
I don't want to alarm you, but here on a bone-stock #Hubzilla 8.4 Web interface, I can gleefully circumvent any and all privacy safeguards any #Mastodon fork or any mobile app connected to any Mastodon instance could possibly present to me with absolutely no obstacles. And I have countless ways of quoting. I could #quote anyone.
That's because Hubzilla is neither a Mastodon fork nor an alternate Mastodon interface nor a Mastodon client app. It's a wholly separate project that's almost four years older than Mastodon, based on the #Zot protocol that's five years older than Mastodon and seven years older than #ActivityPub. It federates to Mastodon and everything else based on ActivityPub through an optional built-in connector, but internally, it speaks a language more powerful than ActivityPub.
By the way, the same goes for #Friendica, another separate project that's the direct predecessor of Hubzilla, based on the #DFRN protocol and six years older than Mastodon, as well as #Streams, another separate project that was launched last year as an "indirect" fork of a fork... of Hubzilla, based on the latest incarnation of Zot, now named #Nomad. Unlike Hubzilla, both have ActivityPub on by default.
Now I'm curious whether your privacy safeguards have any effect on other #Fediverse projects based on ActivityPub such as #Mitra, #Pleroma, #Akkoma, #MissKey, #CalcKey or #FoundKey.
#MastodonIsNotTheFediverse -
@Kaity A @Ada While I do appreciate your effort, how much of the Fediverse do you plan this to cover within less than, say, two months?
blahaj.zone?
All #Mastodon instances?
Or all instances of all #Fediverse projects?
The latter, so much I can tell you, will be impossible to achieve. First of all, of course, this would require extensive modification to many Fediverse projects that aren't Mastodon. Keep in mind that there are some projects that are both years older than Mastodon and based on a protocol that is not #ActivityPub.
#Friendica (6 years older than Mastodon) might have to dig deeply into its UI, its underlying #DFRN protocol (8 years older than ActivityPub), of course the ActivityPub connector and maybe actually also all the other connectors, of which Friendica has many. If bad comes to worse, Friendica would have to enforce Mastodon users' quote and interaction limits upon #Diaspora users, and Diaspora* and Mastodon aren't even federated with one another and only touch each other on a few projects that are federated with both.
Second, the development of some projects has slowed down to an almost or actual still-stand. You won't see #Plume integrate everything that you've planned before July. It'd be a miracle to see Plume even roll out a bugfix release until then.
Third, @Mario Vavti and @mike are very unlikely let anyone on Mastodon force them to design #Hubzilla and #Streams, or even the #Zot or #Nomad protocol, in any particular way. It's bad enough that the Mastodon core devs try to bully them into re-designing stuff that's many years older than Mastodon.
By the way, both Hubzilla and (streams) have part of what you want to introduce built in already now. Hubzilla actually had it before Mastodon even existed.
What you're trying to do is
a) re-invent the wheel
b) make your wheel design mandatory for the whole Fediverse
c) force Hubzilla and (streams) to discard their way of handling permissions which is firmly integrated with the Zot/Nomad protocol and its own very detailed and fine-grained permission control, the kind of which even the #CalcKey devs couldn't imagine in their wildest dreams, and which has seen some 11 years of daily operation, and replace it with yours
Fourth, there are still some instances of some projects out there that haven't seen a single update this whole year. Or for over a year. There still seem to be Hubzilla hubs alive that run 5.x or even 4.x while the current version is 8.2, and 8.4 is just around the corner. There are also still instances of the (indirect) Hubzilla forks #Osada and #Zap alive, and both projects have been EOL and discontinued since New Year's Eve. These instances will continue not having what you want the whole Fediverse to have.
Next question: How exactly do you want such limitations to be enforced? Do you simply want to keep offending posts/comments from being created? Or do you actually want to go as far as UI buttons being greyed out or disappearing altogether on the UIs of all Web interfaces of all projects and on all desktop and mobile apps?
In the case of quoting, either will be very difficult to achieve outside of Mastodon, especially on the old #FederatedSocialWeb projects Friendica and Hubzilla and their newest offspring, (streams).
See, when Mastodon will introduce quotes, it'd be a button, and everything else will be hocus-pocus happening in the background. On Friendica and Hubzilla, quotes, just like any kind of text formatting, are done with BBcode which is in the post/comment editor in plain sight and can be edited. In (streams)' case, Markdown and HTML come on top.
There are about a thousand and one ways for me to quote you or anyone else. I'd demonstrate a selection of them, but Mastodon's text formatting limitations won't let me, at least not short of taking a screenshot of both the source code and what it looks like. If you want to keep everyone on Friendica, Hubzilla and (streams) from quoting those who don't want to be quoted with 100% reliability, these three projects would need editors that could catch all possible ways of quoting someone. If you still want them to rule out false positives, it's really approaching impossibility. -
@stefanm
#Plattform war während meiner IT-Tätigkeit immer die Hardware. #Fediverse ist nach meinem Verständnis der Oberbegriff für das #Netzwerk, das Posts/Nachrichten über unterschiedliche #Protokolle, wie #ActivityPub, #Zot, #Diaspora und/oder #DFRN zwischen unterschiedlichen #Knoten, wie #Mastodon, #friendica, #hubzilla, #pixelfed, etc. verteilt, so dass auf diese in jedem #Knoten im #Netzwerk zugegriffen werden kann.