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

@SK Yeah, that's a classic: Mastodon users who don't know much about the Fediverse beyond Mastodon, and who think that if Mastodon doesn't have a feature, the Fediverse doesn't. Some of them have been around since October/November 2022 or even since February/March 2022.

"The Fediverse must introduce $FEATURE."

"Um, the Fediverse already has $FEATURE. Hubzilla has had it since 2015/since 2012 when it still was the Red Matrix/Friendica has had it since 2010. This feature is literally older than Mastodon itself. Just because Mastodon doesn't have it, doesn't mean the Fediverse doesn't have it."

"Actually, everything except Mastodon has $FEATURE."

My experience is that the Fediverse outside of Mastodon, and what features it has to offer, is completely incomprehensible to those who haven't used non-Mastodon Fediverse server software for at least six months as their daily driver. Incomprehensible like a four-dimensional hypercube.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #NotOnlyMastodon #FediverseIsNotMastodon #MastodonIsNotTheFediverse #Friendica #RedMatrix #Hubzilla #MastodonCentricity

@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

@Kristian Echt portable Daten und nomadische Identität gibt's in Fediverse seit 13 Jahren, seit Mike Macgirvin mit Red (später Red Matrix, heute Hubzilla) angefangen hat. Das ist keine Science-Fiction, das ist kein Experimentalfeature, das ist stabil und wird von Produktivkanälen genutzt. Ich schreibe hier von einem Hubzilla-Kanal, der über zwei Hubs geklont ist.

Was Mike da gebaut hat, ist zum einen um Größenordnungen besser als das, was Bluesky vorhat. Zum anderen: Bluesky hat bis heute nicht geliefert. Mikes Erfindung ist dagegen seit mehr als einem Jahrzehnt ein bombenstabiler Daily Driver.

Seit August 2024 gibt's mit Forte (Fork eines Forks eines Forks dreier Forks eines Forks (eines Forks?) eines Forks eines Forks von Friendica; alles immer noch von Mike) die erste Fediverse-Serveranwendung, die nomadische Identität komplett über ActivityPub abfackelt, die nomadisch ist, aber an Protokollen nur ActivityPub kann. Forte ist inzwischen auch offiziell stabil.

Das einzige, woran jetzt noch gearbeitet wird, ist, wie man etwas, was a) von vornherein nur auf ActivityPub (oder einem anderen ursprünglich nichtnomadischen Protokoll) gebaut wurde, b) nie nomadisch war, und c) wo das Konto/der Login auch die Identität ist, so nomadisch bekommt wie Hubzilla, (streams) oder Forte. Das macht silverpill, der Entwickler hinter Mitra, und der schreibt auch die ganzen FEPs dazu.

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

Hatte diaspora* damals wirklich die ganzen Verbindungsmöglichkeiten? Ist schon so lange her.

Ich staune auch darüber, daß Friendica damals noch die Facebook-Erweiterung hatte und es doch einen ganzen Batzen Red-Matrix-Server gab. Sean Tilley hatte einen, der später auch mal Hubzilla-Themes gebaut hat, Farthinghale Arms ist wohl auch irgendwann zu Hubzilla upgegradet worden, und Els Mussols, heute auf (streams), existierte auch schon in der Red Matrix.

#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #diaspora* #Friendica #RedMatrix #Hubzilla #Streams #(streams)

Manchmal bin ich auch in Erklärungsnot. Das hier ist mir nicht komplett so passiert (in Teilen schon), aber wenn man sich mal anguckt, wie sich manche Leute aufführen, die auch schon seit Oktober/November 2022 dabei sind...



Ja, ich kann mehr als 500 Zeichen im Fediverse posten.

Nein, ich tröte nicht.

Ich bin auf Hubzilla. Da habe ich im Grunde kein Zeichenlimit.

Nein, Hubzilla ist keine Mastodon-Instanz.

Nein, Hubzilla ist auch kein Mastodon-Fork.

Hubzilla hat mit Mastodon überhaupt gar nichts zu tun. Hubzilla wurde schon immer von Mastodon unabhängig entwickelt. Deswegen tröte ich auch nicht. Auf Hubzilla trötet man nicht.

Doch, das geht. Das Fediverse ist nicht nur Mastodon. Im Fediverse gibt es noch 150 andere Serveranwendungen als Mastodon. Und die sind alle miteinander und mit Mastodon verbunden.

Nein, Hubzilla ist nicht nachträglich an Mastodon drangebaut worden.

Nein, Gargron hat nicht 2022 das Fediverse erfunden. Nur weil du erst 2022 davon gehört hast, heißt das nicht, daß es das vorher noch nicht gab. Mastodon ist von 2016.

Nein, Gargron hat auch nicht 2016 das Fediverse erfunden. Das Fediverse ist viel älter als Mastodon.

Nein, das Fediverse fing wirklich nicht mit Mastodon an. Und das Fediverse war auch nie nur Mastodon.

Nein, wirklich nicht. Mastodon ist von Januar 2016. Hubzilla ist von März 2015. Als Mastodon startete, gab es Hubzilla schon zehn Monate. Und Mastodon hat sich mit Hubzilla verbunden und nicht umgekehrt. So, und Hubzilla ist eigentlich sogar von 2012, damals hieß es noch Red Matrix. Und die Red Matrix ist ein Fork von Friendica von Juli 2010. Das gab es also schon fünfeinhalb Jahre, als Mastodon startete. Und Mastodon hat sich auch mit Friendica verbunden und nicht umgekehrt. Und eigentlich ging es schon 2008 los, als StatusNet startete. Und damit hat sich Mastodon auch verbunden, als es startete. Das heißt, als Mastodon startete, war es sofort mit StatusNet verbunden, mit Friendica verbunden und mit Hubzilla verbunden.

Nein, das Fediverse ist nicht nur für Reintext-Microblogging.

So, nochmal zum Mitmeißeln: 200.000 Zeichen in einem Post mit Textformatierung und beliebig vielen Bildern, die direkt in den Post eingebettet sind, gibt's schon fünfeinhalb Jahre länger als 500 Zeichen ohne Textformatierung und mit Bildern nur als Dateianhänge. Friendica war zuerst hier und Hubzilla auch. Und Mastodon hat überhaupt nicht zu bestimmen, wie das ganze Fediverse aussieht.



Habt ihr das mitgekriegt, Anfang des Jahres? Haufenweise Leute, die schon auf Mastodon waren, aber auch noch auf Facebook, haben sich zusätzlich bei Friendica registriert. Nicht etwa, weil sie endlich was Ordentliches benutzen wollten. Nein, sondern, weil sie Facebook-Freunde hatten, die nach Friendica umziehen wollten. Und weil sie dachten, man braucht ein Friendica-Konto, um Friendica-Nutzern zu folgen. Die wußten ganz einfach nicht, daß man Friendica-Konten von Mastodon aus folgen kann.

Auch das waren durchaus wieder Leute, die seit Oktober/November 2022 dabei waren.

Sympathisch waren dann die, die begriffen hatten, daß Friendica und Mastodon sich miteinander verbinden können, und dann "in den Äther" gefragt haben, welches von den Konten sie behalten sollten. Irgendwie kann Friendica dann doch mehr als Mastodon, vor allem Sachen, die sie schon ewig auf Mastodon haben wollten.



Aber sogar die Mastodon-Entwickler scheinen teilweise regelrecht gehirngewaschen zu sein. Einen gibt's, selbst wenn der wußte, daß sein Gegenüber ein Hubzilla-Veteran ist, hat er noch behauptet und felsenfest darauf beharrt, daß Mastodon die einzige Fediverse-Serveranwendung ist, die "feature-komplett" ist.

#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #NichtNurMastodon #Friendica #RedMatrix #Hubzilla

@Joaquim Homrighausen @Kevin Beaumont To be fair, full data portability via ActivityPub has only been available in a stable release of anything for two weeks.

That was when @Mike Macgirvin 🖥️'s Forte, created in mid-August of 2024 as a fork of his own streams repository and the latest member of a family of software that started in 2010 with Friendica, had its very first official stable release.

And, in fact, Forte just uses ActivityPub to do something that (streams) and its predecessors all the way to the Red Matrix from 2012 (known as Hubzilla since 2015) have been doing using the Nomad protocol (formerly known as Zot). It's called nomadic identity. This is technology that's over a dozen years old on software that was built around this technology from the get-go, only that it was recently ported to ActivityPub.

Now, nomadic identity via ActivityPub was @silverpill's idea. He wanted to make his Mitra nomadic. He started working in 2023. The first conversion of existing non-nomadic server software to nomadic still isn't fully done, much less officially rolled out as a stable release.

If Mastodon actually wanted to implement nomadic identity, they would first have to wait until Mitra has a first stable nomadic release. Then they would have to wait until nomadic identity on Mitra (and between Mitra and Forte) has become stable and reliable under daily non-lab conditions. (Support for nomadic identity via ActivityPub on (streams) worked nicely under lab conditions. When it was rolled out to the release branch, and existing instances upgraded to it, it blew up in everyone's faces, and it took months for things to stabilise again.)

Then they would have to look at how silverpill has done it and how Mike has done it. Then they would have to swallow their pride and decide to adopt technology that they can't present as their own original invention because it clearly isn't. And they would have to swallow their pride again and decide against making it incompatible with Mitra, Forte and (streams) just to make these three look broken and inferior to Mastodon.

And only then they could actually start coding.

Now look at how long silverpill has been working on rebuilding Mitra into something nomadic. This takes a whole lot of modifications because the concept of identity itself has to be thrown overboard and redefined because your account will no longer be your identity and vice versa. Don't expect them to be done in a few months.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Mitra #RedMatrix #Friendica #Hubzilla #Streams #(streams) #Forte #DataPortability #NomadicIdentity

@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

@Danie van der Merwe Um, the Red Matrix was actually renamed from Red, which was renamed from Friendica Red, which was forked from Friendica.

#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Friendica #RedMatrix

@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

@Plastic Paragraph @Sal Rahman Nomadic identity, as invented by @Mike Macgirvin 🖥️ in 2011 and first implemented in the Zot protocol from 2011 and the Friendica fork Red in 2012 and used by Hubzilla and the streams repository today, goes even further.

Its basic functionality is to keep at least one clone of your identity on another server.

On most Fediverse projects, e.g. Mastodon, your identity is in your account and thus bound to one specific server.

Hubzilla and (streams) put "identity containers" into your account, so-called channels. Your identity is not directly put into your account, but into one of these channels. The channel separates your identity, your connections, your posts, your settings, your files etc. etc. from your login credentials.

This makes two things possible. One, you can have multiple, completely separate identities (channels) on one and the same account, accessible through one and the same login.

Two, and here does nomadic identity come into play: A channel can be cloned to another server.

Such a clone is not a dumb copy like when you move from one Mastodon server to another Mastodon server. It's a real-time, bidirectional, live, hot backup. And it's fully identical to the main instance of your channel, down to the identity, at least as perceived by server applications that know nomadic identity. Anything that happens on the main instance is mirrored to all clones, and anything that happens on a clone is mirrored to the main instance and the other clones.

For example: The main instance of my channel is on hub.netzgemeinde.eu. Thus, my identity is [email protected].

I've got one clone on hub.hubzilla.de. Hubzilla and (streams) understand nomadic identity. They know that this clone is the same [email protected]. Even if I should send something from my clone which I've actually done once when Netzgemeinde was acting up, Hubzilla and (streams) connections still perceive it as coming from [email protected].

The big advantage of this is resilience against server shutdowns. This is actually the very reason why Mike invented nomadic identity in the first place: He saw Mistpark/Friendica nodes disappearing into thin air upon short notice or spontaneously. He saw users lose everything from one day or hour or minute to the next and always have to start over from zero. And he knew that the only solution for this problem would be if a user's identity resided on multiple servers simultaneously.

Nomadic identity makes channels even resilient against the shutdown of the server that contains the main instance. You can always declare any clone the main instance. If you still have a main instance, it's demoted to clone. All of your connections on Hubzilla and (streams) are automatically changed accordingly. The only difference in practice between the main instance and a clone is that the main instance is the one that defines the identity.

A byproduct of nomadic identity is that it provides the best way to move an identity from one server to another. It first creates a clone. Then it declares the clone the new main instance, turning the old instance into a clone. Then it deletes the old instance. If the account on the old server doesn't hold any more channels, the whole account is deleted.

So not only can you move with actually absolutely everything, a Mastodon user's wet dream that will probably never come true, but you can do so with relative ease and quite safely, and most of all, you don't leave a dead identity/account behind.

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

@Scott M. Stolz It's a bit murky what exactly happened back then.

Friendica started as Mistpark before a German told Mike what a German understands when reading that word, namely manure park. It was then renamed to Friendika because the desired Friendica domain was still blocked.

Free Friendika was a fork of Friendika by someone who wasn't content with Friendika's license. Free Friendika was on GitHub right away while Friendika wasn't. The fork involved copying Friendika's whole repository to GitHub.

Friendika was renamed Friendica in 2011 or 2012 when that name had become available.

It was afterwards that Friendica's own code repository was migrated to GitHub. Due to a GitHub "quirk", Friendica was automatically declared a fork of Free Friendika which is technically false.

What exactly happened license-wise is murky to me. Friendica can't have started under the AGPL because that'd exclude re-licensing a fork. But interestingly, Hubzilla is MIT-licensed.

So whatever license Friendica started out under, it might have been the community which put it under the AGPL after taking over from Mike who was now tinkering with the Zot protocol.

Looking at the licenses, it's very likely that Mike didn't fork Friendica Red off Friendica but off Free Friendika, itself a hard fork of Friendika. Thus, some improvements on Friendica never made it to Friendica Red.

I also guess it was named Friendica Red first and then renamed Red (from spanish la red = "the net") after the whole backend had been re-written against Zot, and the whole thing had stopped being Friendica in the first place. The re-naming to Red Matrix must have been a kind of marketing decision.

It's even unclear what exactly was the base for Osada later. Case in point: Well after the release of Hubzilla, Mike's own instances were still all branded "Red Matrix" although this project should have been abandoned in early 2015 when Hubzilla was created from it.

So either the Red Matrix was renamed Hubzilla and reworked into what was Hubzilla 1.0 in July, but Mike kept the "Red Matrix" brand for his own instances. In this case, Osada was forked from Hubzilla, and most everything added from the Red Matrix to Hubzilla was removed again from Hubzilla to Osada.

Or Hubzilla was forked from the Red Matrix, mostly soft-forked, the Red Matrix became Hubzilla's smaller and more experimental brother, and Mike's own instances all became testbeds for development that would have been more difficult with the extra Hubzilla cruft in the way. In this case, chances are bigger that Mike forked Osada from the Red Matrix which had never had all that extra Hubzilla stuff that Osada never had either.

Either way, the path from Mistpark to Hubzilla is both very complicated and very murky, and so I guess it's kind of justified to simplify it a bit. At the same time, it's too short to simplify it the same the path from either the Red Matrix or Hubzilla to (streams) can be simplified because the latter has had many more forks in it ("a fork of a fork... of a fork of {Hubzilla|the Red Matrix}").

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Forks #Mistpark #Friendika #FreeFriendika #Friendica #RedMatrix #Hubzilla

@KubikPixel™ Kommt ganz drauf an, was man will.

Die beste direkte Alternative dürfte #Firefish ex #CalcKey sein, das #Mastodon in Features weit voraus ist. #Volltextsuche hat Mastodon gerade erst eingeführt, so daß die mangels brauchbarer Indizes noch gar nicht richtig nutzbar ist. Firefish hatte sie schon immer, weil auch #Misskey sie schon immer hatte.

#Textformatierungen und #Zitate konnten Firefish und Misskey meines Wissens auch schon immer. Mastodon kann beides nur anzeigen, während Firefish sogar Textformatierungen erzeugen kann, die Mastodon nicht anzeigen kann.

Oder Zeichenlimits beim Schreiben von Posts. Mastodon kann nur 500 Zeichen. Für mehr muß der Admin so tief in die Software einsteigen, daß man fast schon von einem Fork reden könnte. Firefish kann standardmäßig 3000 Zeichen, was der Admin meines Wissens auf der Oberfläche einstellen, also noch erhöhen kann. Zugegeben, beide hacken #AltText rigoros bei 1500 Zeichen ab.

Last but not least unterstützt Firefish meines Wissens die Mastodon-API, sollte also gute Unterstützung durch Mastodon-Apps haben bis darauf, daß man mit Apps, die nur für Mastodon entwickelt werden, auch fast nur das machen kann, was Mastodon kann.

#Friendica ist natürlich noch mächtiger. Es hat Zeichenlimits in den Zigtausenden, es unterstützt wohl noch mehr Formatierungen, es hat einen Filehoster eingebaut, es hat einen öffentlichen Kalender eingebaut, man kann Konten als moderierte Gruppen/Foren einrichten usw. Und es hat mit all dem schon Erfahrungein seit 2010.

Der Hauptnachteil dürfte aber sein, daß es weiter von Mastodon entfernt ist als Firefish. Es gibt mehr, was anders ist und anders läuft. Was man auf Mastodon gelernt oder von Twitter mitgenommen hat, kann man auf Friendica eigentlich gleich wieder vergessen.

Posts schreibt man nicht wie Tweets, sondern wie Blogposts. Bilder werden nicht als Dateien angehängt, sondern woanders hochgeladen (meistens im eingebauten Dateispeicher) und irgendwo im Text eingebettet. Alt-Text ist kein separates Feld, sondern muß per Hand in den BBcode eingeflochten werden. Ein Content-Warning-Feld gibt's nicht, aber eins für den Titel und eins für die Zusammenfassung, wobei sich letzteres dann als dasselbe wie Content Warnings auf Mastodon entpuppt. Direktnachrichten gehen nicht mit @ und Rechteeinstellen, sondern mit !. Antworten sind nicht auch Posts, sondern Kommentare, und das ist ganz was anderes als ein Post. Und so weiter.

Klar, Friendica kann mehr und einiges auch besser, aber Mastodon-Umsteiger müssen im Prinzip alles ganz neu lernen.

#Streams von 2021 ist in Teilen noch mächtiger als Friendica (wobei ein Teil von Friendicas Features wieder fehlt), #Hubzilla von 2015 ist durchweg noch sehr viel mächtiger. Aber hier ist die Umgewöhnung noch heftiger, alleine schon, weil die eigene Identität nicht durchs Konto definiert ist, sondern in einem Kanal "containerisiert". Und man kann auf demselben Konto mehrere Kanäle mit separaten Identitäten haben. Und dann kommt noch #NomadischeIdentität oben drauf, auch wenn die eigentlich der feuchte Traum vieler Mastodon-Nutzer ist. Sie erfordert nur eben Um-die-Ecke-Denken.

Hubzilla ist natürlich so ziemlich der ultimative Alleskönner. Es ist mehr als nur Friendica mit ein bißchen Extrazeugs, wobei vieles genauso funktioniert wie auf Friendica und somit ganz anders als auf Mastodon.

Hubzilla ist ein "Social CMS", das einem neben Social Networking und Gar-nicht-so-Microblogging auch voll formatiertes Macroblogging bietet, das sich in der Funktion kaum vom Gar-nicht-so-Microblogging unterscheidet, außerdem einfache Websites, Wikis, Cloudspeicher mit WebDAV, CalDAV und CardDAV und so weiter und so fort. Oben drauf gibt's ein sehr detailliertes Rechtemanagement, das auch eng verzahnt ist mit #SingleSignOn durch #OpenWebAuth.

Aber auf der einen Seite steht dieser gigantische Funktionsberg, und auf der anderen Seite steht die Benutzeroberfläche. An sich könnte die extrem flexibel sein, sie unterstützt Komplett-Themes, die für jeden Kanal individuell wählbar wären. In der Praxis gibt es aber nur noch ein Theme, das gepflegt wird. Das ist noch von 2012, wurde aus einem Friendica-Standardthema für die #RedMatrix umgebaut, hat sich seitdem kaum bis gar nicht verändert und hat mit Usability kaum etwas zu tun. Alternativen sind in der Mache, aber noch nicht offiziell verfügbar.

Dazu kommt die Dokumentation. Die wurde geschrieben von Entwicklern, die nicht wußten, wie man Nichtentwicklern etwas erklärt, also z. B. ganz normalen Endnutzern, und liest sich streckenweise eher wie ein technisches Lastenhaft. Noch dazu ist sie zu erheblichen Teilen so hoffnungslos veraltet, daß sie überhaupt nicht nutzbar ist.

Ach ja: Textformatierung gibt's. Textformatierung mit Klickibunti und Echtzeit-WYSIWYG gibt's nicht. Wer keinen BBcode kann, hat verloren, weil einem auch die Buttons nur BBcode in den Editor packen. Auch wenn zum Glück zumindest die BBcode-Implementation von Hubzilla ziemlich gut dokumentiert und halbwegs aktuell ist.

(streams) hat nicht mehr den Funktionsumfang von Hubzilla. Das Ziel ist hier eigentlich nicht, von vornherein einen Alleskönner zu haben, sondern eine Codebasis, um daraus was feines Eigenes zu bauen. Die Oberfläche sieht ganz ähnlich aus, ist aber einen Tick zugänglicher, vielleicht auch deshalb, weil es vieles einfach nicht mehr gibt. Erleichternd dürfte für einige dazukommen, daß auf (streams) alles wahlweise mit BBcode, Markdown oder HTML formatiert werden kann, so daß man keinen BBcode lernen muß, wenn man schon Markdown kann.

(streams) hat auch eine bessere Anbindung von #ActivityPub und Verbesserungen in der nomadischen Identität. Dafür kann es sich mit nichts anderem mehr verbinden, außer daß es immer noch RSS-Feeds erzeugt und E-Mail-Benachrichtigungen verschicken kann.

Näher an Mastodon ist es damit aber nicht. Im Gegenteil: Verwirrend ist schon mal, daß es sich nicht um ein in sich geschlossenes Projekt mit Namen und Marke handelt. Es ist gar kein Projekt, sondern nur ein Code-Repository. Es hat auch keinen Namen und kein Logo. Es ist wirklich mit voller Absicht namenlos. Der Name "Streams" und das Wellenlogo gehören beide zum Repository, nicht zur Software. Daher auch die Klammern um den "Namen".

Das heißt auch, daß die einzelnen Instanzen keine einheitliche Projektidentität haben. Mastodon-Instanzen identifizieren sich alle als Mastodon. Hubzilla-Instanzen identifizieren sich alle als Hubzilla. (streams)-Instanzen identifizieren sich als irgendwas, weil man da selbst etwas eintragen kann und muß. Waitman Gobbles öffentliche Instanz namens Rumbly identifiziert sich beispielsweise nicht als "Streams", sondern als "-get".

Folge: Es ist nicht möglich, (streams)-Instanzen automatisiert zu crawlen, zu identifizieren und aufzulisten. Das wird noch zusätzlich dazu erschwert, daß mit ebenso voller Absicht die Statistikausgabe aus (streams) komplett entfernt wurde. Die einschlägigen Projekt- und Instanz-Listenseiten fürs #Fediverse listen allesamt keine (streams)-Instanzen, und das werden sie auch nicht, weil das zum einen nicht gewollt und zum anderen wegen der uneinheitlichen Identifikation der Instanzen gar nicht möglich ist.

Folge: (streams)-Instanzen zu finden, ist Detektivarbeit. Das dürfte auch erklären, warum es bei (streams) einen noch höheren Anteil an persönlichen Instanzen gibt, zumal es kaum öffentliche Instanzen mit offener Registrierung gibt.

Ein gemeinsamer Nachteil von Hubzilla und (streams) ist: Smartphone-Apps kann man vergessen. Für Hubzilla gibt's eine, die seit 2018 nicht mehr gepflegt wird, also mehr als die Hälfte der Zeit, die es Hubzilla gibt. Die funktioniert inzwischen gar nicht mehr. Und auch die hat den Fokus nur aufs Mikroblogging gelegt.

(streams) wird wohl nie eine Smartphone-App haben, eben weil es kein in sich geschlossenes Projekt mit fixer Projektidentität ist.

Beide unterstützen nicht die Mastodon-API, soweit ich weiß. Also ist man so oder so auf den Webbrowser angeweisen. Andererseits sind beide Projekte so mächtig, daß es kaum möglich sein dürfte, ihren jeweils kompletten Funktionsumfang in eine dann immer noch leicht bedienbare Smartphone-App zu pressen.

@Scott M. Stolz
Well, channels have the advantage that all your content is "containerised", so-to-speak. And the ID of the container can be independent from the domain it is on. That makes both #NomadicIdentity and multiple channels with different IDs on one account possible.

#Mastodon and the other projects based on #ActivityPub have no such containers. All content is lying directly on the account. Attributing it to a wholly different ID on a different instance might be kind of difficult.

No wonder Mike has introduced channels with the #RedMatrix back then.

It could be done, but if it is done, it would most likely be just Mastodon to Mastodon...

Well, truth be told, full nomadic cloning between #Hubzilla and #Streams isn't possible either. You can move from Hubzilla to Streams using the same technology as nomadic identity, but you can't create a nomadic clone. Vice versa is at least strongly disrecommended by Mike.

But if you could at least move from a nomadic Mastodon to Hubzilla or (streams)...

@Tokyo Outsider (337ppm) If that's so, then the issue lies in Hubzilla's very concept. And that concept is at least about four years older than #Mastodon. It became reality either in 2012 when #Friendica was forked into the largely re-written #RedMatrix from which #Hubzilla would emerge in 2015, and that was still almost a year before Mastodon came out. Or that concept is even as old as the #Zot protocol which is from 2011.

The decision that was made was to not throw Hubzilla's basic concept and its fine-grained access permission control system away just to make it less confusing for Mastodon users. A concept into which Mike Macgirvin had invested four years of work. The same Mike Macgirvin who had created Friendica from nothing to a 1.0 release within four months.

@OpenSim

It's happening. Probably.

The #Fediverse and the #Metaverse will grow another bit closer again.

The #HoloNeon grid has announced that it will create an elaborate, bi-directional connection between the grid and its own (streams) instance. This will actually include the automatic creation of an #OpenSim avatar for each channel created.

I sincerely hope they'll #OpenSource that development.

Here's the official announcement:

Aeris Irides wrote the following post Sun, 20 Aug 2023 05:28:06 +0200 We will connect streams federated server to OpenSimulator federated metaverse server.

Objectives:

• create account will happen on streams, account will be created on OpenSimulator server.
• Sync passwords when updated on streams instance.
• Photos marked full perm in OS will show up on streams feed
• Profile photo changed in OS will appear on streams profile and vice-versa
• Notifications (@metions, @replies, @privatemessage, etc) will popup in OS viewer.

A bit of explanation, especially for those of you who don't know the Fediverse beyond Mastodon and Lemmy:

#Streams is a code repository which contains a Fediverse server application created in 2022 that can be seen as a descendant of the #RedMatrix from 2012 and its successor #Hubzilla (see here) from 2015. While it doesn't have quite as many features as Hubzilla, it still goes well beyond what Mastodon has to offer and even surpasses Lemmy here and there. It offers #NomadicIdentity which is nothing new; the Red Matrix was created to introduce it, and Hubzilla has it, too.

Since this Fediverse server application is intentionally nameless and brandless, it is usually being referred to by the name of the repository in parentheses: (streams).

Before you ask: Yes, (streams) federates with Mastodon and Lemmy.

And now for those of you who have found this post elsewhere than on Lemmy:

#OpenSimulator, #OpenSim in short (see here), is basically #SecondLife in free, open-source, community-driven, decentralised and federated. So it's a platform for 3-D #VirtualWorlds.

Unlike so many others, it wasn't created recently to cash in on the metaverse hype. It has been around since 2007, it has been federated since 2008, and the OpenSim community has been using the term "metaverse" regularly since at least 2010, most likely even longer. It's also non-commercial at its core, and it probably offers the cheapest land of all virtual worlds.

Holo Neon is one of over 400 known active OpenSim grids (worlds), most of which, like Holo Neon, are connected to each other on the so-called #Hypergrid.

It's one of only very few which have a #cryptocurrency integrated, and the one that Holo Neon uses can't be traded for real money. Most grids don't have any currency at all; some use the grid-overarching Gloebit, some only have "monopoly money" that can't be traded with real money, and a very few commercial grids have their own currencies.

@🍄🌈🎮💻🚲🥓🎃💀🏴🛻🇺🇸 @Johannes Ernst #Mastodon didn't invent their CW technology.

The very same thing already existed on #Friendica when it was launched under the name of Mistpark. And that was in July, 2010, almost six years before Mastodon. The Friendica fork #RedMatrix / #Hubzilla has had it since before Mastodon, too. Both still exist, they're part of the #Fediverse, and they're federated with Mastodon. I'm on Hubzilla myself.

The only difference is that Mistpark/Friendika/Friendica and Red Matrix/Hubzilla didn't call it "content warning". They called it "summary". The purpose was to provide a summary for very long posts. Where Mastodon has a 500-character limit, these projects practically don't have any limits. I've heard of a Friendica instance with a 70,000-character limit. So this was included so you don't have humongous long-form blog posts pop up right before you, and you can choose whether or not to see it.

That being said, especially for users on these projects, the use of this as CWs on Mastodon can be treacherous. See, when you toot something on Mastodon directly, you include images, and you put a CW on the whole toot, the images are blurred.

When you write a post on Friendica or Hubzilla, you include images, and you add a summary (which will serve as a CW on Mastodon), then Mastodon has to convert the linked and embedded images (that's how Friendica and Hubzilla do it) into file attachments. And it doesn't blur them. They stay in plain sight.

Now, most Mastodon users don't know where a "toot" comes from. They'll assume that everything in their timelines is actually a toot that originated on Mastodon. Many don't even know that there's something else in the Fediverse than Mastodon.

So when they see a post with a CW on it, but unblurred images with sensitive content, they'll assume either carelessness or bad intention. And you're likely to be scolded for what's actually a software limitation. (I should file an issue about this on GitHub.)

In the meantime, on Hubzilla where the post actually came from, users have to click at least twice, sometimes even three times to see the images unblurred: once to get past the automatically added content warning (optional and configurable), then to get past the summary and finally to unblur the images which have been flagged sensitive.

But none of these measures translate to Mastodon properly or, in two cases, at all.

@rabble @Fediverse Report Only halfway through it due to lack of time, but in that half, the only pre-#Mastodon, pre-#ActivityPub hint was a very brief mention of the #OStatus protocol and #StatusNet. And it doesn't sound like the other half would actually deal with anything between identi.ca and Mastodon.

Then again, #Bluesky tries to convince us that the concept of #NomadicIdentity is their original pioneering creation, so naturally, they'd never admit that it was actually invented along with the #Zot protocol in 2011 and has been in use since the creation of the #RedMatrix in 2012 from which eventually #Hubzilla emerged.

And the representatives of ActivityPub and #Nostr would never admit either that there are protocols and projects that are more powerful than theirs while also being older and having been in active use for longer.

Interestingly, not even #Diaspora was mentioned.

So basically, this isn't about the origins of the concept of open social media platforms and their largely unknown history prior to Mastodon. It's about the history of three specific platforms.

Or should I continue listening, and what I think is missing is yet to come?

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

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