#osada — Public Fediverse posts

@Chao-c'

Also, ALT text translates with the rest of the post, which can be helpful for images which contain only foreign language text.

Hubzilla is the most incompatible ActivityPub software in Fediverse. You do just lot of things wrong, to put it mildly.

You still seem to think that Gargron invented ActivityPub and the Fediverse, that Mastodon is the one and only reference implementation of ActivityPub, and that everything that doesn't work exactly like Mastodon is broken.

Here are the facts:

Mastodon was launched in January, 2016.

Hubzilla was launched in March, 2015. Counting an earlier incarnation named Red, it was created in May, 2012, when Friendica's creator re-wrote his own fork of a Friendica fork of his own.

Mastodon implemented ActivityPub in September, 2017, when the spec wasn't finalised yet.

Hubzilla implemented ActivityPub in July, 2017. Two months before Mastodon. Hubzilla was the first software to ever implement ActivityPub.

Hubzilla implemented ActivityPub strictly by the book. It has always tried to stick as close to the official W3C ActivityPub spec as possible.

Mastodon, in stark contrast, has always been stretching the ActivityPub spec until it broke. Not only that, but it has always been adding stuff outside the spec. First it did so to take over certain features from StatusNet which was its original protocol. More recently, it did so with the very intention to break compatibility with the rest of the Fediverse and make everything that isn't Mastodon look broken. And people like you keep falling for it because they think they know for a fact that Mastodon is the ActivityPub reference implementation.

The whole Fediverse has to break the ActivityPub spec just to be able to federate with Mastodon.

yes, the Hubzilla author is writing Streams, with nomadic identity, but it also means, that he understands, that Hubzilla approach is kind of dead-end.

You know nothing. Whereas I can rattle down the whole history from Mistpark in 2010 to today.

Mike Macgirvin, creator of Friendica, Hubzilla, (streams) and Forte created his post-Hubzilla server applications because he kept advancing the Zot protocol. And he couldn't implement these advancements into Hubzilla because they bore the chance of breaking compatibility with what already existed.

(streams) is not a completely new development, nor is it a straight Hubzilla fork.

(streams) is a 2022 fork of Roadhouse.
Which was a 2022 fork of either the third Osada or Mistpark 2020 or Redmatrix 2020.
Which were 2020 forks of Zap (or each other, but at least one of them was forked from Zap).
Which was a 2018 fork of either Hubzilla itself or the first Osada, which was a 2018 fork of Hubzilla.

Osada and Zap were created to develop Zot6. In its early stages of concept, Mike expected Zot6 to be incompatible with everything else. Mind you, he didn't see that as something bad. Advancing Zot was necessary because the then-current version of Zot was less than optimal. And Mike's vision was a decentralised, nomadic network named the "Grid", entirely based on Zot. The Grid would have been vastly superior to the existing Fediverse in every way possible.

So the issue with his early draft of Zot6 was that it was quite incompatible with non-nomadic protocols. Nomadic Zot6 content could not be translated into non-nomadic protocols like the diaspora* protocol or ActivityPub.

Thus, developing Zot6 on Hubzilla was out of question. Zot6 would have broken too much on Hubzilla. Besides, Hubzilla was bad as a platform to experiment on due to its wealth of supported protocols and other features, all of which would have had to be made compatible with Zot6.

And this is the real reason why Mike created Osada and Zap. From how I see it, and how I remember what he talked about back in the day (I was there, yes), he first forked Osada from Hubzilla. Then he ripped everything out that he didn't need, including support for all protocols except for Zot itself, ActivityPub, RSS and Atom, including the CMS stuff like articles, planning cards, notes, wikis and webpages, etc. Then he modified what was left against his early version of Zot6.

Then he discovered that a cloned Osada channel couldn't properly send content via ActivityPub.

Then, shortly afterwards, he forked Osada into Zap. He removed nomadic identity from Osada which kept ActivityPub and ActivityPub support from Zap which stayed nomadic.

The idea was to have a nomadic, cloned channel on Zap as your main channel that would only connect to Hubzilla, Osada and Zap, and to have an additional, non-nomadic channel on Osada that would serve as a "gateway" between nomadic Zap and the non-nomadic ActivityPub Fediverse.

Of course, this was highly impractical. But by 2019, Mike found a way to make Zot6 compatible with non-nomadic protocols. So, in early 2019, Mike discontinued Osada and forked a new Osada from Zap which only differred from Zap by having ActivityPub support while still being nomadic. This enabled Mike to have one development platform for Zot6 in conjunction with non-nomadic protocols and another one on which ActivityPub did not stand in the way.

Later in 2019, both Osada and Zap got stable releases. At that point, Osada and Zap were identical in code. Both had ActivityPub support. It was included into their cores now and no longer an add-on like on Hubzilla. They only had two differences. One was the branding. The other one was that Osada servers had ActivityPub activated by default, and Zap servers had ActivityPub disabled by default. Keeping Osada around was unnecessary now, so ActivityPub was activated by default on Zap, and Osada was discontinued. Zot6 was so stable that it was soon backported to Hubzilla.

Mike wasn't done yet, though. He now wanted to develop Zot8. Again, he did not want to develop protocol changes on stable production software that people potentially daily-drove.

Thus, three new forks emerged in 2020: another Osada, Mistpark 2020 (a.k.a. Misty) and Redmatrix 2020 (named after the Red Matrix, the name that Hubzilla bore from late 2012 to early 2015 between being created as Red and being re-branded into Hubzilla). Mike used them to develop Zot8. They were identical in all but brand identity.

This was fully intentional on Mike's part to confuse the hell out of the brand fetishists that were growing more and more numerous in the Fediverse. His goal was for people to declare Osada or Misty or Redmatrix the best Fediverse software and superior to everything else, just for him to tell them that Osada, Misty and Redmatrix are absolutely identical. In fact, the three remained identical to Zap in features.

Zot8 never got stable because Mike kept advancing it further and further. In early 2022, he was at Zot11. But Zot11 was so incompatible with everything else, including previous Zot versions, that Mike declared it a new protocol of its own and renamed it Nomad. In order to test-drive it, he forked Osada or Misty or Redmatrix into Roadhouse. After all, there were people who were daring enough to daily-drive production channels on Osada, Misty and Redmatrix, albeit only few. Roadhouse was still identical in features to Zap, Osada, Misty and Redmatrix.

It was now possible to crossgrade between Zap, Osada, Misty, Redmatrix and Roadhouse by simply rebasing the server code.

Later in 2022, he created a new fork of Roadhouse itself. The reason for this was not further protocol advancement. No, this time, it mostly had branding and licensing reasons.

First of all, he wanted to make that fork as easy for others to fork and adopt as possible. Everything he had developed so far was under the MIT license (he himself had relicensed Friendica under the AGPLv3 in 2011, but he didn't actually develop on Friendica; he developed on a fork named Free-Friendika that was still MIT-licensed and then backported the changes to the Friendica repository, and Red was a Free-Friendika fork). This new repository was released into the public domain. At first, the whole thing was never primarily intended to be installed on servers as it was, but rather to be forked as the base of something new.

At least the core and Mike's own add-ons were. What third-party add-ons from Hubzilla times were still there got to keep their maze of licenses. This was intentional on Mike's part, too. It would make it impossible for commercial players to scoop up the whole thing and relicense it into something non-free and commercial without breaking any licenses, or without pumping tons of money into their legal department to work around that maze of licenses.

Also, Mike removed any and all naming and branding from the software. He absolutely intentionally made it nameless. You've read that right. He did this for two reasons. One, whoever wanted to fork it would have to give the fork an individual name and an individual branding. Two, this was to mess with brand fanbois and brand fetishists even more: This thing had no brand to gush over to begin with.

Furthermore, Mike removed all nodeinfo code that he could possibly get away with removing. Again, this was intentional. One intention was to stop this software from automatically joining the "my Fediverse project is bigger than yours" and "my server is bigger than yours" rat races. He intentionally did everything he could to keep this software away from The Federation, Fediverse Observer, FediDB and the like.

The other intention was for the case of commercial players looking for free code to steal. If this software had really taken off and left its stats proving its popularity everywhere, some big commercial player would have been likely to try and steal this software, make it commercial and non-free and release it as their own original creation. So his intention was for them to not even be able to find it in this case. (This, by the way, was the reason why he relicensed Friendica under the AGPLv3, and why he hardly ever spoke about Free-Friendika: Now that Friendica was growing popular, he didn't want big commercial players to scoop up code of his under a license that they could change to non-free.)

This server application became the first and only one in the Fediverse with no fixed server type identifier, in fact, with none at all by default. It has one text field for the server name, just like Mastodon and Friendica and Hubzilla and the like. But it has an additional field where the server type, i.e. the identifier for the software, can be entered. If none is entered, it's derived from the server name. Mike used to have a server that identified as "Y" because, as he said, "Y is not X."

While the application itself is nameless (for it still is), the code repository did require a name of sorts. Mike named the repository "streams".

Now, the community needed something to call that nameless software when they spoke about it. So they unofficially established "(streams)", complete with parentheses that make sure that this is not actually the name of this software. Those who say, "Streams," with a capital S and no parentheses, and who use that term as if it's an official name, usually sincerely believe that this is the official name.

Mike himself uses "streams" without the parentheses because even he needs something to call his own software by. Before Forte was made, he preferred talking about the streams repository without directly mentioning the software. And he himself denied that (streams) is even a project. It's just a bunch of code that runs.

As far as I know, it was now possible to freely crossgrade between six different server applications because they were still identical in features. Only that Mike also had six server applications to take care of now.

So on December 31st, 2022, Mike discontinued Zap, Osada, Misty, Redmatrix and Roadhouse. Admins who ran either of these on their servers were recommended to rebase their servers to the streams repository. In this case, by the way, the old branding was kept. I've seen a server that still had "zap" as its subdomain which indicated that it was set up as a Zap server, that had Misty branding, but that actually ran (streams).

From then on, Mike dedicated his time to maintaining and developing only the streams repository. He still occasionally helped Hubzilla out, though.

In 2023, the Mitra creator and developer silverpill approached Mike. The goal was to make Mitra nomadic. I guess earlier attempts using a blockchain and crypto technology didn't come to fruition, so it had to be Mike's way which had proven itself stable for more than a decade. However, Mitra was to remain based on ActivityPub.

It was in this exchange that Mike realised that ActivityPub could indeed be used for nomadic identity if a few things were added to it. One outcome was FEP-ef61 "Portable Objects" which introduced decentralised IDs (DIDs) that would not be bound to any one server domain.

Instead of creating a whole new server application to play with, Mike simply made a "nomadic" branch in the streams repository (even though the software was already nomadic) in which he implemented support for nomadic identity via ActivityPub. Support as in (streams) understanding it while internally still using Nomad for nomadicity.

In June, 2024, Mike considered the "nomadic" branch reliable enough and merged it into the "dev" branch.

In July, 2024, Mike merged the "dev" branch into the "release" branch which caused DIDs as per FEP-ef61 to be rolled out to existing production servers. On accounts created on this new version, channels would have a DID internally. On accounts greated on any previous version, even new channels would keep the old ID system for the time being. This way, existing accounts and channels weren't messed with.

However, what had worked under supervised and restricted lab conditions completely blew up under real-life conditions. Again, I was there on (streams) with a pre-DID account and two channels on it. I still have them. (streams) channels wouldn't federate with anything anymore. It had become impossible to send anything anywhere. What Mike was facing was nothing short of an enigma because not even he knew what was going in.

So he started tinkering. In mid-August, Mike forked the streams repository into something named and branded Forte. He did so so he could rip the Nomad protocol out while still keeping the entire functionality. He had to get rid of Nomad because he had discovered that (streams) got confused juggling all the many IDs it had to deal with, so he had to weed out the Nomad and Zot6 IDs to make things easier. But he couldn't possibly have done that on (streams) proper.

This way, Mike created the very first Fediverse server software that uses ActivityPub for full nomadicity, including cloning.

By the end of August, things got back to normal. But Mike, having spent every free minute in the last few weeks to get (streams) back into working condition, was burned out. He sent an open message around in which he declared that he would completely retire from Fediverse development, and both the streams repository and Forte were up for grabs.

But nobody was found who could take over either. (streams) and Forte probably had way fewer than 100 users combined. Those few who would have been able to maintain either didn't have time. One did have time and was willing to do so, but he didn't know how to code. He eventually did start teaching himself, and he occasionally contributes merge requests, but there was no way he could take over as the only dev for either, much less both. So Mike had to go on, whether he wanted or not, albeit at a somewhat slower pace.

This is why Mike is still developing (streams) and Forte to this day.

By the way: The reason why Mike "abandoned" his old software was because he needed to invest all his time into protocol development and advancement. Mike isn't the one to constantly maintain stable server software unless he absolutely has to.

In 2011, he handed Friendica over to two new developers so that he had time to create the Zot protocol.

In 2015 already, he handed Hubzilla over to two new developers so that he had time to explore the advancement of the Zot protocol. He still contributed to Hubzilla's development.

In 2019, he wanted to hand Osada and Zap over to the community, now that they were stable, so he had time to develop Zot8. But the Osada/Zap community was so tiny that he couldn't get a new dedicated developer team together.

In 2024, he wanted to hand (streams) and Forte over to the community because fixing (streams)' huge identity bug, which led to Forte's creation, had burnt him out. He wanted to quit. But, again, he couldn't because (streams) didn't have a single user who had both the time and the knowledge to take over as the new main dev.

Consider this: Gargron was a young man when he made Mastodon. I think he was still at university. Mike Macgirvin made Friendica, he had some three decades of professional work in IT and software under his belly. Gargron was at the beginning of his career. Mike had quit and moved from the USA to the western Australian outback where he has been living as a farmer ever since. He might actually be older than Gargron's parents.

while nomadic identitity would be cool thing, currently it does not exist

Take off your Mastodon glasses and look at the Fediverse and what it actually is like.

Nomadic identity does exist. Not as a vague idea, not as a concept on paper, but as a stable, production-grade feature that has been used to its full extent for well over a decade now. Just because Mastodon doesn't have it, doesn't mean the Fediverse doesn't have it. And just because Mastodon doesn't recognise it, doesn't mean it doesn't exist.

The Fediverse has loads of features which Mastodon users want "the Fediverse" to have. It has features which many Mastodon users have never wanted "the Fediverse" to have such as quote-posts, introduced by Mike Macgirvin on Mistpark in 2010. It even has features that are completely and utterly unimaginable for Mastodon users, and it has had even these since as early as 2010, 2012 or 2015.

Nomadic identity was invented by Mike Macgirvin in 2011 with the Zot protocol.

It was first implemented by him in mid-2012 when he rewrote Red against Zot. This means that Hubzilla itself has been offering full-blown nomadic identity since 2012, almost four years longer than Mastodon has existed.

This very Hubzilla channel that I'm commenting from right here, right now, is actually nomadic. It is cloned across two servers: hub.netzgemeinde.eu and hub.hubzilla.de. And it has been since before Elon Musk announced to take over Twitter in early 2022. When I sent you this comment, it was automatically sync'd over to hub.hubzilla.de. When you sent the comment that I'm replying to, it was automatically sync'd over to hub.hubzilla.de. The clone has actually been of great help at least once.

Unfortunately, non-nomadic software identifies cloned channels as fully separate accounts with fully separate identities. But rest assured: @Jupiter Rowland on hub.hubzilla.de is my clone. It's the live, hot, real-time, bidirectional backup of the main instance of my channel, @Jupiter Rowland on hub.netzgemeinde.eu that you're following now. They're both one and the same channel with one and the same identity, [email protected], even though Mastodon is unable to see it as such. Go check both. You'll see they've got all the same content in them, including comments from others. Including your comment. How else can [email protected] possibly have one of your comments under a post if you've only sent that comment to [email protected] if it weren't for nomadic identity?

Even nomadic identity via ActivityPub is available as a stable, production-grade feature in stable, production-grade software right now as we speak. Forte was the first to be fully nomadic via nothing but ActivityPub, as of mid-August, 2024. Tootik, based on Gemini instead of the World Wide Web, is fully nomadic at server level, too. Mitra is fully nomadic by means of the Minimitra client.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #MastodonCentricity #MastodonNormativity #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares #QuotePostDebate #QuoteTootDebate #ActivityPub #Zot #Zot6 #Zot8 #Nomad #Friendica #Red #RedMatrix #Hubzilla #Osada #Zap #Mistpark #Mistpark2020 #Misty #Redmatrix2020 #Roadhouse #Streams #(streams) #Forte #Tootik #Mitra #Minimitra #NomadicIdentity

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Wie es dann weiterging, lag nicht an Mikes Sprunghaftigkeit.

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

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

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

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

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

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

Warum drei?

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

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

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

Warum?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

So, nun noch das Wort zu Smartphone-Apps.

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

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

Apps von Drittentwicklern?

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

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

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

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

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

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

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

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

tl;dr:

2010:

• DFRN
• Mistpark/Friendika/Friendica
  (DFRN)

2011:

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

2015:

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

2018:

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

2020:

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

2022:

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

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

The long version:

In 2010, he created

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

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

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

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

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

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

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

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

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

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

Instead, he made two new forks:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@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

@Hamiller Friendica

Nach diesem Muster ist er auch bei Friendica und Hubzilla vorgegangen.

Na ja, es war ähnlich.

2012 war Friendica längst stabil und im Grunde fertig. Er hat es an die Community abgegeben, Red abgeforkt und mit Zot experimentiert.

2018 war Hubzilla stabil und im Grunde fertig. Er hat es an die Community abgegeben, Osada und Zap abgeforkt und mit Zot6 experimentiert.

2020 war Zap stabil und im Grunde fertig. Er hat es an die Community abgegeben und das zweite Osada gleich mit. Nachdem die Community umgehend Osada eingestellt hat, weil es eh mit Zap beinahe identisch war, hat Mike ein drittes Osada, ein neues Mistpark und eine neue Redmatrix abgeforkt, um mit Zot8 zu experimentieren.

Aus den Experimenten ging nie etwas Stabiles hervor. Statt dessen hat er von einem von den dreien 2021 Roadhouse geforkt, um mit der nächsten Zot-Evolutionsstufe zu experimentieren, die dann in Nomad umbenannt wurde.

(streams) aus demselben Jahr sollte dann Roadhouse in stabil werden. Und Mike wollte (streams) nicht wieder forken. Dann kam Mike aber an einen Punkt, wo er sagte: Nomadische Identität geht auch mit ActivityPub. Ich brauche kein eigenes Protokoll mehr, ich muß nur dabei mithelfen, ActivityPub dahin zu bringen, daß es Nomad ersetzen kann.

Weil er aber (streams) nicht forken wollte, hat er das Ganze auf (streams) selbst versucht umzusetzen. Blöderweise läuft das in der Praxis nicht so geschmeidig, wie es in der Theorie angedacht war.

Statt jetzt aber seinen einzigen stabilen Release endgültig in eine Bastelbude zu verwandeln, hat er jetzt Forte abgeforkt und nimmt das zum Basteln, während (streams) wieder auf stabile Beine kommen soll. Auch das macht er selber, weil das keiner für ihn übernimmt. Und die (streams)-Community ist keine drei Jahre nach der Entstehung von (streams) noch zu klein, um so bald die Entwicklung von (streams) zu übernehmen. Kaum einer zieht von Hubzilla um, ganz neu nach (streams) kommt eh keiner, auf Mastodon weiß kaum einer, daß es (streams) gibt, und die, die davon wissen, trauen sich nicht hin.

Und so wird Mike beides weiterentwickeln. Forte wird wahrscheinlich zunächst ein Soft Fork bleiben, damit Mike sich nicht dieselbe Arbeit zweimal machen muß.

So gesehen ist das eher vergleichbar mit Zap und den ersten zwei Osadas, wo Mike schon mal zwei Projekte mit in Teilen unterschiedlicher Codebase am Laufen hatte.

CC: @Raphael

#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Friendica #Red #RedMatrix #Hubzilla #Osada #Zap #Mistpark2020 #Misty #Redmatrix2020 #Roadhouse #Streams #(streams) #Forte

@Raphael Momentan entwickelt Mike beide aktiv weiter.

Es kann gut sein, daß er (streams) erstmal zu Stabilität bringen will und Forte hat, um damit mit neuen Sachen zu experimentieren. Ich weiß es nicht, aber es kann gut sein, daß Forte der Versuch wird, erstmals komplett ohne eigenes Protokoll auszukommen. (streams) ist ja das Ende einer Kette von Weiterentwicklungen von Zot. Forte könnte das nächste Protokollexperimentierfeld sein: dieses Mal alles nur noch mit ActivityPub. Dann muß er dafür nicht (streams) nehmen.

Das wäre im Prinzip wie 2018, nachdem er Osada und Zap abgeforkt hat, wenn er damals auch offiziell der Hubzilla-Maintainer geblieben wäre.

#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hubzilla #Osada #Zap #Streams #(streams) #Forte

@Stefan Bohacek It has partly become a museum already.

Of Mike's projects, only Roadhouse is missing because it never really took off. But the Red Matrix is there, Mistpark is there, Osada is there, Zap is there.

Calckey is still there. Wildebeest is there which was so questionable I've got my doubts it still exists.

#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Calckey #Wildebeest #Mistpark #Mistpark2020 #Misty #RedMatrix #Osada #Zap #Fediverse

Z radością zawiadamiam, że po długawej przerwie opublikowałem trzecią i ostatnią część mojego artykułu o solidarnościowej opiece zdrowotnej. Zapraszam do lektury i rozmowy. Poprzednie części podlinkowane w tekście.

#Osada #Zdrowie #oddolność #wszechkryzys #MSDN
Solidarnościowa Opieka Zdrowotna cz. 3 - Osada. Anarchizm na koniec świata.

@Jens Ljungkvist :mastodon: @Jeff Sikes @Kainoa @Chris Trottier Something similar to "one account on all projects" is already in the works.

By and by, #Fediverse projects may adopt #OpenWebAuth, a #SingleSignOn implementation developed by @mike for #Hubzilla and currently implemented on Hubzilla, its direct predecessor #Friendica and its latest not-quite direct descendant, #Streams. An implementation is also in development on #Mastodon. It should not be confused with #OAuth and #OAuth2, these are something entirely different.

What OpenWebAuth is that it recognises logins elsewhere. When I'm logged into this Hubzilla account, and I visit another Hubzilla hub or maybe a Friendica node or a (streams) instance, it will automatically recognise me. And it will grant me some extra "guest permissions" like being able to post directly on the wall of another Hubzilla or (streams) channel.

What it does not do, however, is give me all the power on any Friendica node, Hubzilla hub or (streams) instance that a logged-in user with a user account has.

I can't go to another Hubzilla hub and create a clone of my channel or create a brand-new channel or post an article or start a wiki or upload files just with my OpenWebAuth login credentials. And when Mastodon introduces OpenWebAuth, I still won't be able to go to any one random Mastodon instance and start tooting. All this would still require a local user account on that one specific instance.

One account for the whole Fediverse is utopic. It's technologically impossible or just very very very unfeasible.

The Fediverse has 24,000+ instances of dozens of projects. If you want full local user power everywhere in the Fediverse, you'll need one registered account on each one of these 24,000+ instances.

Whenever someone joins mastodon.social, then RATATATATATATATATATATA, 24,000+ more accounts with the same login credentials will have to be created automatically.

Also, the Fediverse has 12,000,000+ users. If you want full local user power everywhere in the Fediverse, then everyone else must have it, too. So every single instance of each Fediverse project will have to have one account per Fediverse user. The only exceptions would be those very few projects which are designed for only one user account.

However, personal instances of projects that are designed for multiple user accounts will all be affected. The hapless Mastodon user who comes over to your personal Hubzilla hub to act like a registered user will neither know nor care if that hub is running on a root server in a data centre with two 36-core Xeon CPUs and enough RAM to make a 3-D CAD workstation cry or on a Raspberry Pi at your home.

Now, let's assume someone has set up a new Web server with some Fediverse project installed on it. It doesn't matter if that's Mastodon or #CalcKey or #Lemmy or #Mitra or (streams) or whatever as long as it has #ActivityPub. They start that thing up for the first time: sudo systemctl start nginx or so.

And RATATATATATATATATATATA TATATATATATATATATATATA TATATATATATATATATATATA TATATATATATATATATATATA TATATATATATATATATATATA TATATATATATATATATATATA, that poor thing will sit for WEEKS registering over twelve million user accounts.

Why? Because anyone in the Fediverse might come over anytime soon and want to use just this one specific instance as if they had registered their personal user account there. In order to be able to do that, they need a user account.

By the way, not even the notorious featherweight #Pleroma could handle 12,000,000+ user accounts on one instance. Mastodon can do that even less, not to mention the heavyweight Friendica or the super-heavyweight Hubzilla.

Speaking of Hubzilla, maybe a new Hubzilla hub might get away more easily when starting up for the first time. On Hubzilla, ActivityPub is optional per hub and then per channel. The hub admin can switch it on and off, and if it's on, the users can switch it on and off again for each one of their channels.

So if ActivityPub is off on the admin side by default, new Hubzilla hubs will only register one user account for each Hubzilla and (streams) user out there, maybe also for the users on the few remaining instances of the #Zotlabs projects that went EOL on New Year's Eve 2022, #Redmatrix, #Osada, #Zap, #Misty a.k.a. #Mistpark2020 and #Roadhouse. They all speak one native language, #Zot.

But once the admin activates the Pubcrawl app for their hub, that hub will immediately start registering user accounts for every user on every instance of every project that connects to Hubzilla via ActivityPub, each account with one channel with Pubcrawl on. And it will spend weeks or months doing so and not have any server resources left to do anything else in the meantime.

Speaking of Hubzilla, there's also #NomadicIdentity, the killer feature of the Zot protocol. Hubzilla has it, (streams) has it, and the (un)dead Zotlabs projects have it.

Ideally, each Fediverse user would not get one account on each Hubzilla hub and each (streams) instance with one separate, unique channel on it. They would first get the accounts. On one account on one Hubzilla hub, one channel would be created. This channel would then be cloned across all Hubzilla hubs and to (streams).

Advantage: Each Fediverse user would only have one channel for Hubzilla and (streams) together. They would have the exact same content on all Hubzilla hubs and, minus what Hubzilla can do that (streams) can't, all (streams) instances.

Obvious disadvantage: Whenever someone decides to do something on that channel, it would have to be synced to all its clones in near-real-time, causing a lot of network traffic.

And if you set up a new Hubzilla hub or (streams) instance, the creation of 12,000,000+ accounts would actually become a lesser problem. The bigger problem would be the 12,000,000+ channels that will be cloned onto your machine with everything on them. You'd better attach a few petabytes worth of HDD capacities to your personal little Raspberry Pi.

By the way, if everyone had full local user rights on each Fediverse instance, the Fediverse would have over 300 billion local accounts.

@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.

@ophiocephalic 🐍 @Tim Chambers @Fediverse Report @Spread Mastodon As a #FederatedSocialWeb veteran and former self-hoster of my own private #Friendica and #Hubzilla instances, I have to say that I can hardly see literally absolutely the whole Fediverse fediblocking #Meta.

You have to keep a few things in mind.

First of all, the Fediverse is not only #Mastodon. Nor is the Fediverse only about a dozen big projects. The Fediverse is dozens upon dozens of big and small projects.

For the whole Fediverse to fediblock Meta, every single last one of them, even just recently launched private proof-of-concept alphas of brand-new projects which nonetheless will federate, will require not only a mandatory instance-wide blocking mechanism, but a mandatory standard blacklist with Meta's instance on it. Otherwise developers can't test-drive their new Fediverse server application without their test instance being defederated left and right for not blocking Meta.

Of course, this would also mean that everything that even only as much as understands #ActivityPub would require such a mandatory default blacklist with Meta on it. Even if it isn't based on ActivityPub. Even if ActivityPub is an add-on, a plug-in, maybe even third-party like in the case of #WordPress. Even if ActivityPub has to be manually activated instance-wide by the admin and then separately by the users for each one of their channels like in Hubzilla's case.

That is, putting Meta on the same list as all other defederated instances would probably be considered not enough. Blocking Meta would have to be hard-coded into the engine of the project itself, also to mandatorily roll it out to all instances of all projects. Instance block lists aren't part of the source code, and if they became that, lots of not-so-techy instance admins would end up with file conflicts they can't solve because the git pull involved in the upgrade would try to create a file that already exists.

Still, this wouldn't be 100% water-tight. An absolutely mandatory fediblock for Meta would mean certain death for lots and lots of small private instances. Admins of such tiny instances often only do the very bare necessities to keep them running. Sometimes they rarely or never even upgrade the underlying operating system, much less the Fediverse project running on it. Why should they? It runs. And an upgrade means a) a hassle and b) probably more of a hassle if stuff breaks.

Just to prove my point: There are still Mastodon 3.x instances in the Fediverse. There are still a very few running small instances of #Osada and #Zap, both of which have been discontinued on New Year's Eve 2022. These projects are no longer maintained. They won't get any updates anymore. They were superseded by #Streams, and not everyone who still runs these old projects wants to do the switch.

And then there are those projects that are technically still in development, but whose development has slowed down dramatically. Look at how often #Pleroma rolls out new versions. And Pleroma isn't exactly obscure, it has public instances. Or look at #Plume which counts as still actively developed, but whose devs barely find any time to do anything, so it often doesn't get any updates in many months. I don't even think that Plume has any means of blocking instances by blacklist.

So if blocking Meta becomes mandatory, you can fediblock an entire long-form blogging project out of the Fediverse with all its private and public instances because not a single instance will participate in blocking Meta, because not a single instance is even capable of doing that, because the capability is not included and rolled out in time, because the devs can't find the time to include it.

@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.

@Probably Paul 🌍 @maegul @Kevin Davidson @Ada #CalcKey has full #NomadicIdentity?

As in, you can have identical clones of your account/channel simultaneously on multiple instances? They're kept in-sync with each other in real-time? All clones display the same Webfinger ID which uses the domain of the primary instance? And you can make any clone your new primary instance?

Because this is what nomadic identity actually means.

The only projects known to me that support it are #Hubzilla, #Streams and the now-defunct #Zotlabs projects #Redmatrix, #Osada, #Zap, #Misty a.k.a. #Mistpark2020 and #Roadhouse, basically everything created by Mike Macgirvin after #Friendica.

In fact, I've got my doubts that full nomadic identity can be pulled off without having multiple channels per account/login. And this is another feature which the projects mentioned above have and the ActivityPub-based microblogging/macroblogging/"social network" projects don't.

Or are you referring to how easy it is to move your entire account with everything on it from one instance to another? That isn't what nomadic identity means.

Theory: There were three projects named #Osada.

Osada 1: forked from #Hubzilla (or the code base of Mike's #RedMatrix instance?) as the first step towards #Zap on the quest for Zot/6. Probably the only one that still federated with Diaspora*. The only one without #NomadicIdentity (Zap always had it). Turned out a dead end.

Osada 2: literally Zap with ActivityPub. In fact, in the end, both had the same code base, Osada was Zap with the admin-side ActivityPub switch on, and Zap was Osada with that switch off. Made it to a stable 2.0 release. When Zap officially received ActivityPub support and was handed over to the community, Osada 2 was redundant and discontinued.

Osada 3: must have been another Zap fork in the fray that also contained experimental Redmatrix (mostly Mike's instance which had never seen the Hubzilla branding and then became its own project) and yet another Zap fork which revived the old #Friendica name #Mistpark, now usually shortened to #Misty, which was created to be even more stable than Zap. Said to have ended with the same code base as Misty, save for the branding, or at least on the same level of stability. Discontinued at the end of 2022 and superseded by #Streams. Only one known survivor on the same domain as one out of two Zap instances known to me (not counting Mike's Zap-branded (streams) instance).

#Mistpark2020 hashtag because it didn't fit into the text anymore.

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

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

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

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

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

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

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

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

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

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

@Tokyo Outsider (337ppm) #Streams will never supersede/replace #Hubzilla because they're radically different concepts.

Hubzilla is intended as a federated, nomadic, all-powerful jack-of-all-trades. Also, like almost all other Fediverse projects, Hubzilla is a self-contained, "run-as-is" project.

(streams) is not even a Fediverse "service" or "platform" at all. (streams) isn't a branded product like Mastodon or Hubzilla. It is not a coherent, self-contained product, it's a code repository. And it's usually written (streams) because neither is "Streams" a brand name like "Mastodon" or "Hubzilla", nor is the three waves logo a brand logo. The term (streams) is only being used because that thing needed something to refer to it as.

@mike created it as a tool kit with the intention for people to take the code and build something nice out of it which is not branded "Streams" thenl. This was not his primary intention, but his only intention. While it's possible to install and run vanilla (streams) on a server as if it was a coherent, self-contained Fediverse project, and while this has been done, (streams) has never been intended for this use.

Maybe, at some point in the future, Hubzilla itself will be ported to (streams). But its name will remain Hubzilla, and the logo will remain the same.

Also, most (streams) instances use neither the name "Streams" nor the three-waves logo to make themselves known. Case in point: the Communities page on Rumbly.net which itself is one of the few public (streams) instances known to me, and which doesn't identify as "Streams" either.

For example, Mike's private instance is branded #Zap, complete with the Zap logo. But it's (streams). I think it was upgraded from Zap (which itself started out as a Hubzilla fork to test-drive Zot/6, then was declared stable, and (streams) is a fork of a fork of a fork of Zap), and Mike deliberately left the name and the logo in.

Look through the Community Types column. You'll see lots of names you've never heard of. Behind not exactly few of them are (streams) instances. If it has that "colourful guy" as a logo which is a replacement for a missing logo, it has to be a practically unbranded (streams) instance.

Any picture that only appears once usually marks a (streams) instance, too. There are a few examples: This is a #Roadhouse instance with probably no active administration, or the admin doesn't know that Roadhouse (the direct predecessor of (streams) and Mike's last branded creation) hasn't heard of (streams) yet or that anything post-Hubzilla should be upgraded to it.

Another funny case: Streem identifies as "Streemz" while carrying the #Misty a.k.a. #Mistpark2020 logo (Misty was made between Zap and Roadhouse).

Online Lutherans is an exception: It's an utterly undermaintained Zap instance with the logo replaced.

An even more hilarious exception: Gidi's Osada is one of the last remaining #Osada instances. Osada was forked off Hubzilla along with Zap, and it started out as Zap + ActivityPub (Zap was Zot/6 only). When Zot/6 was ready for prime-time, and Hubzilla was upgraded to it, Osada was merged with Zap (before that, the only difference between the two was the instance-wide ActivityPub switch on the admin panels), just to re-emerge later as one of four experimental Zap forks on the way to Zot/8 and eventually Zot/11 a.k.a. Nomad.

By the way, there are two more ways of identifying (streams). One: Click the burger menu. If there's a "Communities" entry, it's (streams). If there's a "Sites" entry, it's one of its EOL predecessors. Two: If it has the same colour scheme as my Hubzilla channel, it's most likely (streams).

@Chris Trottier @Fediverse News Back in 2010, when mainstream mass media were raving about the crowd-funding campaign for #Diaspora, he dropped the 1.0 version of #Mistpark which, at this point already, was more powerful in every possible way than Diaspora* would be a decade later. Mistpark would soon be renamed #Friendika which then became #Friendica.

In 2011, over a decade before #Bluesky, he invented #NomadicIdentity with the #Zot protocol.

In 2012, still over a decade before Bluesky, he forked Friendica into Friendica Red, then renamed Red (from Spanish "la red" = "the network"), then renamed #RedMatrix. In 2015, it went stable and was renamed #Hubzilla. Two stable point releases within five and a half years with no budget while crowd-funded Diaspora* was still a rather lack-lustre public alpha. And that's still several months before #Mastodon.

Friendica, Hubzilla, #Zap (EOL) and #Streams are only the four stable projects he created, all without crowd-funding. This does not include the various experimental projects that led to everything post-Friendica, all of which are past their EOL now that (streams) is out: #Osada, #Misty a.k.a. #Mistpark2022, #Roadhouse plus re-emerged Redmatrix and Osada. And even Zap started out as an experiment and was eventually declared stable after fully merging with Osada.

@Kristian @Chris Trottier Free, non-corporate, decentralised projects have different intents and purposes than non-free, commercial, corporate, centralised silos. They're created by different people for different people, for different target audiences. And even the huge corporate silos don't start with a shiny iPhone app and then develop the server backend around it.

If it's free (as in, for example, Affero GPL), decentralised and distributed, it's made by geeks for geeks first and foremost. #Friendica first became available in 2010, and unlike Facebook, it never had the intention of becoming the next Internet for everyone in the world. Also, behind Facebook stood a huge megacorporation. Behind Friendica stood only one man, @mike, all alone, with zero budget. And yet, he managed to release something that was more powerful than Diaspora*, where at the same time only the crowdfunding campaign was running, would ever become.

Friendica's target audience were geeks. The same people that also used Linux as their main OS. Friendica wasn't made for the same people as Facebook or the iPhone. In fact, your typical Friendica user wouldn't touch an iPhone or any other Apple product with a 10-foot barge pole. They'd rather have a Nokia N900, and that was a clunky QWERTY slider that ran a modified Debian GNU/Linux.

#Redmatrix, the direct successor of Friendica, was experimental. Its sole purpose was to work on the brand-new #Zot protocol and the concept of #NomadicIdentity. It still had a small number of users and an even smaller number of instances, but they were generally voluntary guinea pigs. At this time, Friendica was already maintained by its own community which is about as far away from a Silicon Valley gigacorp as you could possibly get.

Redmatrix wasn't declared ready for prime time until late 2015 when it was renamed #Hubzilla. And even then, it didn't come with the "vision" of rolling over the mass market and replacing Facebook, WordPress, MediaWiki and the various GAFAM cloud services in one fell swoop. Again, Hubzilla was developed pretty much only by Mike Macgirvin.

#Osada and #Zap were both largely experimental again. Mike had forked them off Hubzilla because he still wasn't satisfied with what Zot could do at the time. However, the development of the new version #Zot6 couldn't happen on that monster named Hubzilla that was in everyday use now. That's why these two new projects were launched.

There's a good reason why they were two projects. Zap was there first. Zap was the actual Zot6 testbed, and thus, Zap was Zot6-only. Osada retained compatibility with Friendica and Hubzilla to test how well Zot6 would interact with ActivityPub with had meanwhile appeared as a draft and, IIRC, adopted by both Friendica and Hubzilla. Eventually, Osada and Zap ended up having the exact same codebase, and the difference between the two was an admin switch: ActivityPub on made it Osada, ActivityPub off made it Zap. As this was non-sense, Osada was axed, and Zap got ActivityPub and was declared the next stable one.

First, Zap's main killer feature over Hubzilla was Zot6 which had introduced #OpenWebAuth. When Zot6 was finally backported to Hubzilla, the remaining advantage was that Zap wasn't nearly as bloated with a somewhat less overwhelming UI. By the way, Redmatrix continued to exist with one user until Mike Macgirvin upgraded his own instance to Zap.

Now, again, you can't tinker with something that's stable. And tinkering continued. #Mistpark, Friendica's early name, returned in 2020, as did Redmatrix and Osada, all as Zap forks at various stages of instability and being experimental, none intended for a wider audience. And all created by Mike Macgirvin again. You could happily switch back and forth between Redmatrix, Osada, Zap and #Misty by simply rebasing your server code. (Installing either usually involved "git clone".)

He actually had a very good reason for this maze of names: He is opposed to big mass products with big brand identities. He wants to offer people technical solutions, not cool stuff with a sleek brand on it.

Anyways, on top of all this came #Roadhouse, another fork from somewhere in this conglomerate which was created in 2021 and solely intended for the development of the next Zot version, originally named Zot8, now known as #Nomad. Roadhouse was so experimental that there has never even been an official text saying what it actually was.

Also in 2021 came #Streams, a Roadhouse derivative that started out just as mysterious but was eventually intended for the public. It's often also referred to as (streams) because it's different from its predecessors in one point: It's even less of a brand. It isn't a product to be used as-is. (streams) is not a "Fediverse platform" that's waiting for its own iPhone app. (streams) is a code repository on Codeberg. And its purpose is for others to take the code and make something out of it. It isn't meant to be run as-is, although you can do that, and some people do. And even then, it comes without a fixed brand and kind of asks you to "rebrand" it, even on a per-instance basis. Most (streams)-based instances don't identify as (streams). Mike who is still involved in the project has his own instance based on (streams) but, probably deliberately and intentionally, still has it identify as Zap.

Another interesting fact: (streams) uses a wild hodge-podge of free licenses. Most of it is in the public domain, but parts of it are under various free licenses which aren't compatible with each other. This is fully intentional, too. It makes using (streams) for commercial products pretty much impossible because no corporate legal department will be able to figure out how to legally comply with all these licenses at the same time. Free use stays basically unlimited, though.

By the way: As of January 1st, 2023, Redmatrix, Osada, Zap, Misty and Roadhouse are EOL and discontinued, and their code repositories were closed. Instances running them can and shall be upgraded to (streams). All that's left is Friendica (the old faithful one), Hubzilla (the nomadic monster) and (streams) (the one for the tinkerers).

Now there's still the question: Why do all these projects, in fact including #Mastodon, use this approach? Why do they start with a server platform plus Web frontend instead of doing as big corporations do and start with an iPhone app and develop a server backend around it? Why appeal to a small bunch of Linux nerds rather than to a mass-market of billions?

Because if you want to go free and decentralised and distributed and federated, you'll need those Linux nerds before everyone else.

First of all, you'll need someone to run instances. Thus, you'll need people who are willing and able to do that. This requires Linux knowledge. The ability to use the command line. The ability to set up and configure a Web server. Network knowledge to connect it to the internet. You can't set up a Web server from zero with three taps on a mobile app.

In fact, when Diaspora* was young, it only ran on Mac servers. All four creators were Apple fanbois who didn't care for anything without the Apple brand on it. The Diaspora* server application was built against macOS. The result was a dire lack of public pods (instances) and everyone piling on the official pod. Mac users don't run Web servers at home, and I guess there were no hosting companies that offered Web hosting on Macs. The devs eventually had to make the server app at least halfway Linux-compatible to get more people to run pods, and you still had to compile Ruby on Rails from sources on Debian stable because Diaspora* depended on a newer version.

Also, you'll need these tech geeks to spot and report bugs. Your typical Windows or Apple user doesn't report bugs; they only complain about them or switch to a competing product. In stark contrast, many Linux users even know how to file a good and informative bug report. Some are even capable of submitting pull requests with bug-fixing patches through git.

And at least in the case of Mike's projects, you'll need a community that's capable of taking over the project itself and continuing its development. You'll need people who know how to code. You'll need people who know how to use git. And so forth. You'll hardly find such people amongst the masses who have spent all their digital lives in the cosy world of corporate-designed GUIs.

If, for example, Mastodon had started out with iPhone and Android apps and gone from there, appealing to a rather tech-illiterate mass audience, it would probably never have become decentralised. At least not beyond the federation between mastodon.social, mastodon.online and whatever more instances Eugen Rochko would have had to launch because these two were full.

And why not? Because Mastodon wouldn't have appealed to people who know how to install and run Mastodon instances. Mastodon would have only had the Windows/Mac/iPhone/Android crowd as users. All the geeks who would have known how to set up and run a Web server would have stayed on Friendica and Hubzilla. Some may have used ActivityPub to connect to Mastodon, but hardly anyone would have switched to that actually inferior platform with a wholly different crowd on it.

@Stark There is, for example, #Zot. Zot was created along with a #Friendica "fork" (actually almost complete rewrite) named #RedMatrix which, upon its 1.x release, become #Hubzilla.

I don't have the exact technical specs, but it should work similarly to #ActivityPub. It's much much more powerful, though.

For starters, Zot was created for something that goes even beyond federation, namely #NomadicIdentity. Not only does it facilitate the move an entire channel from one instance to another, it lets you have your channel on multiple instances at once and automatically keeps all copies in sync. If the hub with your main channel on it goes down, doesn't matter, you have an identical clone or several.

Besides, Zot was not only designed for messaging. After all, Zot can keep channel on that monster named Hubzilla in sync. With everything on them. Not only posts, entire threads and contacts, but articles, wikis, notes, the content of your WebDAV-equipped cloud file storage, your public event calendar, your private CalDAV calendars, your private CardDAV address book etc.

This gets really interesting if you're on Hubzilla, and you have another Hubzilla channel amongst your contacts. That channel may have a number of nomadic clones, but you only see one of them as the main one. The channel owner can seamlessly change which one is the main, and all you notice is that the hub URL has changed.

The current and last version of Zot is Zot6, originally developed for and with the Hubzilla successors #Osada and #Zap, then backported to Hubzilla.

#Streams, basically a code repository which evolved from Zap through another two steps, already uses #Nomad, a kind of successor to Zot which nonetheless can communicate with Zot. Streams shows what Nomad is capable of: Instead of a "fully-featured" server platform, Streams is meant to be a code base for advanced Fediverse projects, i.e. you can strap onto it whatever you want to develop. Whatever it may be, Nomad can keep it in sync between multiple instances.

@mike

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@smallcircles (Humane Tech Now) The list of apps isn't quite up-to-date anymore.

The old #Zotlabs projects #Redmatrix, #Osada, #Zap, #Mistpark2020 and #Roadhouse were discontinued as of December 31st and superseded by whatever you get out of the #Streams repository (#^https://codeberg.org/streams/streams).

#Top5 community types I'd like to see #Fediverse instances based on #Streams identify as:

5: #Redmatrix or #Osada, but without having been upgraded from such.

4: O'Sada. The icon is a photograph of a ship's steering wheel, the colour scheme is mostly green, the default language is Irish.

3: MacSada. Ditto, but with a tartan instead of green and Scots Gaelic instead of Irish. Claim that you've borrowed the webspace the instance runs on. All because someone was quicker with the O'Sada idea.

2: MySpace.

1: GeoCities. Postpone this until there's a website app for Streams like the one for #Hubzilla.