Show threadJupiter RowlandNov 2
@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
Netzgemeinde/Hubzilla

Show threadJupiter RowlandAug 29, 2025
@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:

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
Thomas Eibich aka DK2NB (@[email protected])

4.2K Posts, 178 Following, 149 Followers · Fachlehrer und Schulleiter (Fachschule Heilerziehungspflege), Heilpädagoge, Heilerziehungspfleger, Krankenpfleger Vinyl collector HamRadio Operator DK2NB, DOK B11, CW, QRP Linux Debian (stable) Gnome Desktop 1. FCN Genealogie Eibich, Ullrich - Niemes, Nordböhmen Grillmeier, Höreth - Arzberg, Fichtelgebirge

radiosocial.de
Show threadJupiter RowlandJun 22, 2025
@craignicol Since this hasn't been resolved yet: No, there is no such thing.

Your identity is bound to the main instance of your channel.


If you promote the clone on baz.social to your new main instance for whatever reason and thereby demote the current main instance on foo.social to clone, your ID will change.


In a purely nomadic network (Hubzilla or (streams) with respective optional protocols off), this won't be an issue. All your connections will be rewritten from [email protected] to [email protected], both locally on all servers with your channel on them and remotely on all servers that are home to your connections. Your followers won't notice the change. Even mention auto-complete may no longer list your old ID.

Mastodon and the non-nomadic rest of the Fediverse don't understand nomadic identity anyway. For them, the four instances of your channel are four fully separate accounts with four fully separate identities. If someone on Mastodon thinks that you have four separate active accounts, and they decide to follow all four for reasons only they know, they will get the same post four times and probably accuse you of running bot accounts, only that they can fully interact with whatever they think is a bot.

CC: @Ben Pate 🤘🏻 @Eugenus Optimus ?? @Johannes Ernst @Tim Chambers

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #ActivityPub #Zot #Zot6 #Nomad #Mastodon #Hubzilla #Streams #(streams) #NomadicIdentity
Tim Chambers (@[email protected])

66.5K Posts, 5.29K Following, 17.6K Followers · Technologist, writer, who is fascinated by how new politics impacts technology and vice versa. #fedi22 #indieweb #fediverse

Indieweb.Social
Show threadJupiter RowlandJun 22, 2025
@Ben Pate 🤘🏻 I’ve skimmed the FEP (with more studies to come) and I doubt Mastodon et al will implement this. It seems like a breaking change that a big project just couldn’t undertake.
Well, I think that chances are nil that Mastodon will even consider this. I mean, when was the last time that they've implemented something developed by another Fediverse project, especially a non-commercial one? And in this case, on top of it all, it'd mean that Eugen Rochko would have to admit that Mike Macgirvin was right about something. He'd rather go on headbutting, hoping he'll win just by having the project with more users.

Otherwise, yes, it'll come with big changes. I remember last summer. The streams repository used to have its own "nomadic" branch; while (streams) has always been nomadic, this branch was for the development of support for nomadic identity via ActivityPub (while, of course, (streams) itself would continue to use Nomad for nomadic identity).

In June, Mike was confident enough about the nomadic branch to merge it into the dev branch. In July, he merged the dev branch with the release branch for a new release, thereby introducing decentralised identities as per FEP-ef61 to all (streams) servers that'd upgrade from then on. Again, (streams) was already nomadic at this point with identities separate from logins and accounts.

Still, (streams) blew up. What had worked under lab conditions failed out in the open. (streams) was unable to federate or connect with anything. With DIDs new in the game, it had to juggle so many identifiers that it got them mixed up. After all, it also had to handle various already existing ActivityPub IDs plus the Nomad IDs plus the Zot6 IDs to stay compatible with Hubzilla.

And (streams) was being daily-driven by a few dozen people back then with no way to move anywhere. It has never been possible to clone from (streams) to Hubzilla after all.

Mike had to spend hours upon hours trying to find the fault in the first place and then fix it. This may have been the reason why he officially launched Forte in mid-August: He probably took (streams) and ripped out everything that isn't ActivityPub to get rid of the Nomad and Zot6 IDs. And it must have been easier to actually make Forte clone via ActivityPub than to get (streams) going again. He largely achieved the latter until the end of August when he officially quit developing Fediverse software and declared both repositories up for grabs.

So the whole new DID system is likely to cause trouble.

In addition, non-nomadic projects based on ActivityPub (i.e. literally everything that isn't Hubzilla, (streams) and Forte) will have to switch from the usually model of the account and login being the identity to Hubzilla's, (streams)' and Forte's channel model. This is a big change, it will make onboarding more difficult, and it will be hard to sell to the existing users how it's supposed to be better than how things were before.

Also, it will break compatibility, so it will have to be rolled out in slices, by and by. For example, Mastodon would first have to roll out a new version that understands identities that are separate from logins and ideally bundle it with must-have security fixes and bugfixes to ensure that as many servers as possible will upgrade. In fact, they may actually have to backport that feature to Mastodon 4.3, 4.2, 4.1, 4.0, maybe even to 3.x because some admins refuse to upgrade to 4.0.

Only when most Mastodon servers understand identities separate from logins, Mastodon can introduce these separate identities to mastodon.social and mastodon.online. Otherwise they'd end up in a situation in which mastodon.social, the flagship instance of the whole freaking Fediverse, interacts with (streams) and Forte better than with the rest of Mastodon.

And then we can talk about cloning and syncing. By the way: "Let's first implement better moving before we tackle cloning" would be non-sense. Moving with nomadic identity requires cloning. It literally involves cloning. If you can't clone yet, you can't move.

Again, look at Mitra. silverpill decided to go nomadic in 2023. It's still in early development now.

Also: I see the mechanism for splitting an identity and recovering if a server goes down, but how is profile data supposed to be synchronized between servers in the first place? How does it get distributed?
I'm not a Fediverse developer, but AFAIK, FEP-ef61 doesn't cover everything that makes up nomadic identity.

Three things I know. One is when syncs happen.

Zot has the ability to trigger syncs built in. This means that if something changes in one instance of your channel, this triggers an immediate syncing process to all other instances. Nomadic syncing happens in near-real-time. ActivityPub doesn't have this feature, and it can't be implemented by FEP either. So nomadic identity via ActivityPub will probably have to rely on cronjobs to trigger syncs.

Basically, on Hubzilla (Zot6) and (streams) (Nomad), it works like this: You use one instance of your channel. You change something. The server notices these changes and nearly immediately pushes them to the other servers with instances of your channel in much the same fashion as an incremental backup.

On Forte (ActivityPub), there must be something that collects and lists changes. If changes are listed on an instance of your channel, when the cronjob kicks in, these changes are sent to the servers with the other instances.

Conflicts that arise if you use two instances of your channel at the same time are probably solved by always overwriting older data with newer data.

The second one is that initial syncing can be selective. When you create a new clone, you can choose to not sync everything over yet. The actual profile with (almost) all settings, the posts/comments/DMs and the files in the cloud storage can be sync'd separately from one another, and they can also be sync'd after the fact if you don't immediately need all your files on your clone yet.

Later syncing always involves everything that has been sync'd at least once.

The third one is that nomadic identity with more than two instances doesn't work in a hub-and-spoke way. If you log into one of your clones and you use it, the changes are not sync'd from that clone to the main instance and from there to the other instance. If the main instance was offline, nothing would be sync'd at all. Rather, everything is sync'd from that clone to the main instance and directly to the other clones. Each instance of your channel is aware of all other instances.

In short, nomadic identity can be described as "OwnCloud/Nextcloud/OpenCloud, but it's peer-to-peer, and it's between servers rather than between workstations".

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #ActivityPub #Zot #Zot6 #Nomad #Mastodon #Hubzilla #Streams #(streams) #NomadicIdentity
Netzgemeinde/Hubzilla

Jupiter RowlandJun 20, 2025
@Marcus Rohrmoser 🌻 Not to my knowledge.

First of all, nomadic identity won't be described in one single FEP that'll cover everything. It was not created on and for ActivityPub. In fact, the concept predates ActivityPub by some six years, and the first implementation predates ActivityPub by some five years.

See, nomadic identity started as an idea. Then Mike built a brand-new protocol around that idea, Zot. Then, in 2012, Mike forked one of his own forks of his own software that is now known as Friendica, originally based on yet protocol designed by himself, and re-wrote the whole thing against Zot. That's how the software was born that's known as Hubzilla now.

As for nomadic identity via ActivityPub, there is only one publicly available software implementation for that. And that's Mike's own Forte. Forte still does everything the Hubzilla/(streams) way which is very very different from how anything else in the Fediverse works, even including Friendica itself, and especially including Mastodon.

Whereas Zot was designed around nomadic identity, ActivityPub isn't. It's having nomadic identity bolted on with a whole slew of FEPs authored by @silverpill who is working on converting Mitra (typical Fediverse software: built only against ActivityPub, non-nomadic, login/account equals identity) into something that's every bit as nomadic as Hubzilla, (streams) and Forte.

Nomadic identity via ActivityPub was originally silverpill's idea, by the way. And that was in 2023. It turned out that this was actually doable, and so he and Mike started working on it, using experimental "nomadic" branches of Mitra and the streams repository respectively. Their approaches were naturally different: silverpill had to make something non-nomadic nomadic. Mike had to make something nomadic be nomadic using a protocol that wasn't made for nomadic identity.

Not only is silverpill's approach much more difficult because Mitra wasn't made for nomadic identity either, but he also took it upon himself to put everything into FEPs by and by. He is still publishing FEP after FEP. Nomadic identity is quite a complex thing from a "Fediverse equals ActivityPub" point of view; it's just that the Hubzilla/(streams) bubble is so used to it whereas silverpill actually has to explore and research something that's natural to Mike.

There's no common set of commands either. There can't be any. Forte, like everything else in the family all the way back to Friendica, is written in PHP. Mitra is written in Rust. Nobody has ever attempted to make something not written in PHP nomadic.

In fact, code sharing would be next to impossible anyway: Forte, like Hubzilla and early Mistpark/Friendika, is published under the MIT license, (streams) is in the public domain, but Mitra is licensed under the GNU Affero GPL v3. Any code coming out of Mitra's conversion to nomadicity would be AGPL-licensed Rust code. And MIT-licensed PHP code that was created when turning Nomad-based (streams) into ActivityPub-based, Nomad-less Forte would be useless for non-nomadic-to-nomadic conversions anyway.

So don't expect any how-to's or the like for converting non-nomadic, ActivityPub-only-by-original-design, login/account-equals-identity Fediverse server software to the same level of nomadicity as Hubzilla, (streams) and Forte until
  • the first stable release of Mitra with full support for that level of nomadicity is officially rolled out
  • silverpill declares that everything necessary for Hubzilla/(streams)/Forte-level nomadic identity via nothing but ActivityPub is cast into FEPs and finalised

Seeing as this has been in the making for some two years now, and I don't even know if the experimental nomadic branch of Mitra even allows cloning right now, I guess this will be a long way to go. He may actually first have to change Mitra from the standard Fediverse model of the account and the login being the identity to Hubzilla's, (streams)' and Forte's model of the identity being a container inside your account and one account being able to host multiple such identities. That's because you can't clone logins.

Oh, by the way, nomadic identity is not just about moving. It's not "moving-your-Mastodon-account-to-another-instance on coke". It's way more.

The core feature is cloning. Imagine you have full, live, hot backups of your Mastodon account on one, two, three, four or more other Mastodon instances. Imagine they all have the same identity, based on which one of them is your main instance. Imagine whatever happens on one of them is sync'd to the others in near-real-time. Imagine you can log into either of them and use either of them all the same, regardless of how many and which of the servers are actually online, as long as at least one is.

Moving is actually even more complex than cloning because it involves both cloning and changing the main instance of your identity.

Allow me to illustrate by supposing Mastodon works like Hubzilla, (streams) and Forte:

  • Situation:
    • You have an account on digitalcourage.social with one channel, [email protected].
    • You want to move to troet.cafe.
  • Step 1: You create an account on troet.cafe.
  • Step 2: There can't be accounts with no channels. You have to add a channel.
    So you choose to move your channel [email protected] from digitalcourage.social to troet.cafe.
  • Step 3: Your channel [email protected] is cloned over to troet.cafe.
  • Situation now:
    • You have an account on digitalcourage.social with the main instance of your channel; its identity is [email protected].
    • You have an account on troet.cafe with a clone of your channel; its identity is still [email protected].
  • Step 4: All data on your channel is synchronised over from your main instance on digitalcourage.social to your clone on troet.cafe. Posts, images, other files, followers, followed, settings, lists, filters etc. etc. pp. Everything.
  • Now the main instance and the clone are identical.
    Up until here, the process of moving is the same as the process of cloning. What follow is exclusive to moving.
  • Step 5:
    • The clone on troet.cafe is promoted to main instance.
    • As there can be only one main instance for each channel, the former main instance on digitalcourage.social is demoted to clone.
  • Situation now:
    • You have an account on digitalcourage.social with a clone of your channel, formerly the main instance; its identity is [email protected].
    • You have an account on troet.cafe with the main instance of your channel, formerly a clone; its identity is [email protected].
  • Step 6: All your connections on servers of nomadic software are changed from [email protected] to [email protected], both locally on the servers that you are on and locally on the servers that they are on.
  • Step 7 (AFAIK, this only happens on (streams) and Forte in reality): All your outbound connections ("followed") on servers running non-nomadic software receive a follow request from [email protected] which, to them, is an all-new, independent identity.
  • The actually move is done. What follows is the clean-up that really makes the move a move, namely taking care that nothing is left behind in the old location.
  • Step 8: When these last steps are finalised, your clone on digitalcourage.social is deleted. After all, you wanted to move, not to clone.
  • Step 9: As your account on digitalcourage.social has no channel on it anymore, the whole account is deleted.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mitra #Hubzilla #Streams #(streams) #Forte #NomadicIdentity #ActivityPub #Zot #Zot6 #Nomad #FEP #MovingInstances #Clone #Clones
mitra

Federated social network

Codeberg.org
Show threadJupiter RowlandJun 20, 2025
@Ben Pate 🤘🏻 Mike himself considers Nomad a legacy protocol now. He has placed all his bets on ActivityPub, and that includes nomadic identity, OpenWebAuth integration and full-blown permissions systems.

What would probably be the most useful for you is documentation is how to take a typical Fediverse project (non-nomadic, only uses ActivityPub, account/login equals identity) and make it nomadic. Including whether to still only allow one identity on each login, or whether to switch to how Hubzilla, (streams) and Forte do it, containerise identities and allow multiple identities on one login (because seriously, that'd make going nomadic a whole lot easier).

Forte could never deliver that, for Forte is the offspring of a family that had been nomadic with identities independent from the account/login for a dozen years when Forte was made.

What you want to do, make non-nomadic ActivityPub-based software nomadic, has only been attempted once: Mitra. And, again, it's in such an early experimental stage that I can't even say whether the nomadic Mitra branch is actually nomadic as in cloneable at this point. I'm actually pretty sure silverpill's FEPs will change over time as he gains experience with making something non-nomadic nomadic.

Don't count on anything being finalised at this point. Not until silverpill merges the nomadic code into a new release or at least declares that his personal daily driver identity is cloned now.

And don't count on anything regarding cross-server-type nomadic identity finalised until silverpill announces having cloned his daily driver identity to Forte, and/or Mike announces having cloned one of his daily-driver channels to Mitra.

If you didn't have Bandwagon already going, if you wanted to start from scratch, my suggestion would be to not start with something basic, non-nomadic, based on ActivityPub and with the identity tied to the account and then see how you can make it nomadic.

My suggestion would be to see if you can do it by making one or multiple add-ons for Forte, (streams) or Hubzilla and putting them into a third-party repository. If that wasn't feasible because you'd need the core to be different, my suggestion would be a soft fork of Forte or (streams), depending on whether nomadicity or a focus on ActivityPub is more important.

Hubzilla, (streams) and Forte are all flexible, multi-purpose and especially modular enough to be able to build almost everything on top of them. Even if you need a different core, all three can be soft-forked. Hubzilla and Forte are under the MIT license, the streams repository contains nameless, brandless public domain software that was made to be forked. And especially (streams) and Forte can profit from 15 years of development and 15 years of experience with daily-driven production servers, accounts and channels. Not to mention that they've got features right now which most other Fediverse devs couldn't even imagine that anything in the Fediverse has them.

In general, starting from zero with nomadic Fediverse server software is nonsense. Starting from zero with Nomad-based software is even more non-sense. Starting from zero with software based on Hubzilla's Zot6 is much more nonsense because Zot6 is hopelessly outdated and on life support because Hubzilla lives on it.

I know this won't help you. It's just what I have to tell those who want to develop new nomadic server software.

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

Jupiter RowlandMar 20, 2025
@Kellam⚙️Бур This may come as a surprise, but: Nomadic identity is not an abstract concept or a science-fiction idea for the Fediverse.

It is reality. It exists. Right now. In stable, daily-driver software that's federated with Mastodon. And it has been for over a decade.

I'm literally replying to you here from a nomadic channel that simultaneously exists on two servers.

Nomadic identity was invented by @Mike Macgirvin 🖥️ (formerly American software developer of about half a century who has been living in rural Australia for decades now) in 2011 and first implemented in 2012. Almost four years before Mastodon was first launched.

In 2010, he had invented the Facebook alternative Friendica, originally named Mistpark and based on his own DFRN protocol.

Over the months, he witnessed lots of privately operated public Friendica nodes shut down with or without an announcement and the users on these nodes lose everything. He added the possibility to export and import Friendica accounts. But that would only help if a permanent shutdown was announced. It did not protect you against shutdowns out of the blue.

There was only one solution to this problem. And that was for someone's identity to not be bound to one server, but to exist on multiple servers simultaneously. The whole thing with everything that's attached to it. Name, settings, connections, posts, files in the file storage etc. etc., everything.

So in 2011, Mike designed a whole new protocol named Zot around this brand-new idea of what he called "nomadic identity" back then already.

In 2012, Mike forked Friendica into something called Red, later the Red Matrix, and rebuilt the whole thing from the ground up against Zot. Red was the first nomadic social networking software in the world, almost four years before Mastodon.

In 2015, ten months before Mastodon was first released, the Red Matrix became Hubzilla, the Fediverse's ultimate Swiss army knife.

I am on Hubzilla myself. This channel of mine is constantly being mirrored between its main instance on https://hub.netzgemeinde.eu and its clone on https://hub.hubzilla.de. Anything that happens on the main instance is backed up on the clone. I can also log into the clone and use that, and whatever happens there is backed up on the main instance.

https://hub.netzgemeinde.eu could go down, temporarily, permanently, doesn't matter; I still have my channel, namely the clone. And I can declare the clone my new main instance.

Well, Mike didn't stop at Hubzilla and its original version of the Zot protocol. He wanted to refine it and advance it, but in ways that wouldn't be possible on daily-driver software.

Zot went through several upgrades: Zot6 in 2018 (backported to Hubzilla in 2020, along with OpenWebAuth magic single sign-on). Zot8 in 2020. Zot11 in 2021 which had become incompatible with Zot6 and therefore was renamed to Nomad. Today's Nomad would be Zot12.

Also, in order to advance and test Zot, Mike created a whole bunch of forks and forks of forks. Osada and Zap for Zot6 in 2018, followed by another short-lived Osada in 2019. A third Osada, Mistpark 2020 (a.k.a. Misty) and Redmatrix 2020 in 2020 for Zot8. Roadhouse for Zot11 Nomad in 2021. All Osadas, Zap, Misty, Redmatrix 2020 and Roadhouse were discontinued on New Year's Eve of 2022.

The most recent software based on Nomad is from October, 2021. It can be found in the streams repository. It is officially and intentionally nameless and brandless, it has next to nodeinfo code that could submit statistics, and it is intentionally released into the public domain. The community named it (streams) after the code repository.

I also have two (streams) channels, one of which is cloned so far.

The newest thing, and that's what the Friendica and Hubzilla veteran @Tim Schlotfeldt ⚓?️‍? referred to, is nomadic identity using nothing but ActivityPub, no longer relying on a special protocol.

This was not Mike Macgirvin's idea. This came from @silverpill, the creator and developer of the microblogging server application Mitra. He wanted to make Mitra nomadic, make it resilient against server shutdown. But he didn't want to port it to Nomad. He wanted to achieve it with nothing but ActivityPub.

So he hit up Mike. The two came to the conclusion: This is actually possible. And they began to work on it. Amongst the results were several FEPs coined by silverpill.

This time, Mike did not create another fork to develop nomadic identity via ActivityPub. He did it all on the nomadic branch of the streams repository while silverpill did his part on a special development branch of Mitra.

In mid-2024, after enough sparring between (streams) instances, between Mitra instances and between (streams) and Mitra, Mike was confident enough that his implementation of support of nomadic identity via ActivityPub was stable enough. He merged the nomadic branch into the dev branch which ended up being merged into the stable release branch in summer.

Now, at this point, (streams) didn't use ActivityPub for nomadic identity. It still used the Nomad protocol for everything first and foremost, including cloning. But it understood nomadic identity via ActivityPub as implemented on experimental Mitra.

However, while it worked under lab conditions, it blew up under real-life conditions. At this point, (streams) had to handle so many different identities that it confused them, and it couldn't federate with anything yet.

In mid-August, while trying to fix the problem, Mike eventually forked the streams repository into Forte. It got a name again, it got a brand identity again, it got its nodeinfo back, it was put under the MIT license again.

But most importantly: Any and all support for Nomad was ripped out, also to get rid of a whole number of IDs, namely those for Nomad-actually-Zot12 and for Hubzilla's Nomad-actually-Zot6. Forte only uses ActivityPub for everything. And so, Forte also had to fully rely on ActivityPub for nomadic identity, cloning and syncing.

For almost seven months, Forte was considered experimental and unstable. For most of the time, the only existing servers were Mike's.

But on March 12th, 2025, Mike Macgirvin released Forte 25.3.12, the first official stable release of Forte. This is what Tim wrote about. Because this actually made it into Fediverse-wide news.

Not because it's nomadic. Nomadic identity has been daily-driven for over a decade now.

But because it uses ActivityPub for nomadic identity. Which means that you can theoretically make any kinds of Fediverse software nomadic now, all without porting it to the Nomad protocol first.

For the future, Mike and silverpill envision a Fediverse in which one can clone between different server applications. A Fediverse in which one can have one and the same identity cloned across multiple servers of Mastodon, Pixelfed, PeerTube, Mitra, Forte, Mobilizon, Lemmy, BookWyrm etc., all with the same name, all with the same content and settings (as far as the software allows; you will certainly not be able to clone your PeerTube videos to Mastodon and Lemmy).

Even if you don't intend to clone, it will make moving instances and even moving from one software to another dramatically easier.

If you're concerned about your privacy, let me tell you this:

Hubzilla's privacy, security and permissions system is unparalleled in the Fediverse. Except for that on (streams) and Forte which is another notch better.

I can define who can see my profile (my default, public profile on Hubzilla where each channel can have multiple profiles).
I can define who can see my stream and my posts when looking at my channel.
I can define who can see my connections (Hubzilla, (streams) and Forte don't distinguish between follower and followed; they aren't Twitter clones).
I can define who can look into my file space (individual permission settings per folder and per file notwithstanding).
I can define who can see my webpages on Hubzilla (if I have any).
I can define who can see my wikis on Hubzilla (no shit, I've got wikis on my Hubzilla channel).

On Hubzilla, I can define individually for any of these whether it's
  • everyone on the Internet
  • everyone with a recognisable Fediverse account
  • everyone on Hubzilla (maybe also on (streams); anyone using ActivityPub is definitely excluded here)
  • everyone on the same server as myself (AFAIK, only main instances of channels count here, clones don't)
  • unapproved (= followers) as well as approved (= mutual) connections
  • confirmed connections
  • those of my confirmed connections whom I explicitly grant that permission by contact role
  • only myself

There's a whole bunch more permissions than these. And they all have seven or eight permission levels (depending on whether the general non-Fediverse public can be given permission).

On (streams) and Forte, I can define whether things are allowed for
  • everyone on the Internet (where applicable)
  • everyone with a recognisable Fediverse account
  • all my approved connections
  • only me myself plus those whom I explicitly grant that permission in the connection settings

Yes, connection settings. Hubzilla, (streams) and Forte give you various ways of configuring individual connections, much unlike Mastodon. This includes what any individual connection is allowed to do.

Hubzilla uses so-called "contact roles" for that, presets with a whopping 17 permissions to grant or deny for any one individual connection. That is, what the channel generally allows, a contact role can't forbid.

(streams) and Forte still have 15 permissions per contact, but they lack some features which Hubzilla has permissions for. These permissions can be set individually for each connection, or you can define permission roles that cover all 15 permissions to make things easier.

Okay, how about posting in public vs in private? And when I say "private", I mean "private". It's "private messages" on Hubzilla, (streams) and Forte, not "direct messages".

Hubzilla, (streams) and Forte let you post
  • in public
  • only to yourself
  • only to your connections ((streams) and Forte only; Hubzilla requires a privacy group with all your connections in it for this)
  • to all members of one specific privacy group (Hubzilla)/access list ((streams), Forte); that's like being able to only post to those on one specific list on Mastodon
  • to everyone to whom one specific non-default profile is assigned (Hubzilla only)
  • to a specific group/forum (I'll get back to that later)
  • to a custom one-by-one selection of connections of yours

Now, let's assume I have a privacy group with Alice, Bob and Carol in it. I send a new post to only this privacy group. This means:
  • Only Alice, Bob and Carol can see the post and the conversation.
  • Alice can reply to me, Bob and Carol.
  • Bob can reply to me, Alice and Carol.
  • Carol can reply to me, Alice and Bob.
  • Nobody else can see the post. Not even by searching for it. Not by hashtag either. Not at all.
  • Nobody else can see any of the comments.
  • Nobody else can comment.

If one of them was on Mastodon, they'd see my post as a DM, by the way, and they could only reply to me. But that's Mastodon's limitation because it understands neither threaded conversations nor permissions.

Or how about reply control? This is something that many Mastodon users have been craving for quite a while now. Hubzilla, (streams) and Forte have them. Right now. And they work. They have since 2012.

Hubzilla optionally lets me disallow comments on either of my posts. Users on Hubzilla, (streams) and Forte won't even be able to comment; they won't have the UI elements to do so. Everyone else is able to comment locally. But that comment will never end up on my channel. It will never officially be added to the conversation. And at least users on Friendica, Hubzilla, (streams) and Forte will never fetch that comment from my channel as part of the conversation, i.e. never at all.

(streams) and Forte can go even further with all available options. They can disallow comments like Hubzilla. But in addition, they can allow only the members of one particular access list to comment, regardless of who can see the post/the conversation. On top of that, comments can be closed at a pre-defined point in the future. And then you even have a channel-wide setting for how long people can comment on your posts.

Oh, and there's even a setting for who is generally permitted to comment on your posts. And you can additionally allow specific connections of yours to comment on your posts.

Lastly, I've already mentioned groups/forums. Like, you know, Web forums or Facebook groups or subreddits or whatever. Like Guppe Groups on a mountain of coke and with moderation and permission control and optionally private.

Hubzilla has them, and it has inherited them from Friendica. (streams) has them. Forte has them. They're basically channels like social networking channels, but with some extra features. This includes that everything that's send to a group/forum as what amounts to a PM is automatically forwarded to all other members.

On Hubzilla, a forum can be gradually made private by denying permission to see certain elements to everyone but its own members (= connections): the profile, the members, what's going on in it. Depending on what you want or do not want people to see.

On (streams) and Forte, you have four types of forums:
  • public, and members can upload images and other files to the forum channel
  • public, but members cannot upload images and other files to the forum channel
  • like above, but additionally, posts and comments from new members must be manually approved by the admin(s) until their connections are configured to make them full members
  • private, non-members can't see the profile, non-members can't see the connections, non-members can't see what's going on in it, but members can upload images and other files to the forum channel

In addition, on all three, a group/forum channel can choose to hide itself from directories. This is always an extra option that's independent from public/private.

What we have here is the most secure and most private Fediverse software of all.

And, once again, at its core, this is technology from 2012. It pre-dates Mastodon by almost four years.

Finally, if you want to know how Hubzilla and (streams) compare to Mastodon: I have made a number of tables that compare Mastodon, Friendica, Hubzilla and (streams).

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Mitra #Friendica #Hubzilla #Streams #(streams) #Forte #ActivityPub #Zot #Zot6 #Zot8 #Nomad #NomadicIdentity #Security #FediverseSecurity #Privacy #FediversePrivacy #Permissions
Nomadic identity - Join the Fediverse

⚝ Mirko ⚝Mar 19, 2025

Spannend:

#ActivityPub #Zot6 #Nomad #NomadicIdentity #Friendica

fediversity.site/channel/miked…

Forte v25.3.12 released

Announce: Forte v25.3.12 released Forte is the first fediverse platform to provide full nomadic identity (with near realtime sync of your cloned fediverse instances) completely over ActivityPub, using no other nomadic support protocols. All of your content and media and settings and connections...

Show threadJupiter RowlandOct 19, 2024
@Strypey A few more details:

* FEP-ef61: Portable Objects

https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md
Invented in, I think, 2023 by @silverpill for Mitra (based on ActivityPub). Currently implemented there and in @Mike Macgirvin ?️'s streams repository and Forte. Part of the plan to introduce almost Nomad-level, but cross-project nomadic identity to ActivityPub.

* FEP-61cf: The OpenWebAuth Protocol

https://codeberg.org/fediverse/fep/src/branch/main/fep/61cf/fep-61cf.md
Invented in 2018 by Mike Macgirvin for Zap (Zot6 development platform; discontinued 2022). Backported to Hubzilla in 2020. Full server-side and client-side implementation only in Hubzilla (based on Zot6, also supports ActivityPub etc.), (streams) (based on Nomad, also supports Zot6 and ActivityPub) and Forte (based on ActivityPub). Friendica has a client-side implementation. Mastodon has a client-side implementation pull request that has to be merged eventually.

CC: @Laurens Hof

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Friendica #Hubzilla #Zap #Streams #(streams) #Forte #Zot #Zot6 #Nomad #ActivityPub #FEP #FEP_ef61 #FEP_61cf #DecentralizedIdentity #NomadicIdentity #OpenWebAuth #SingleSignOn
Strypey (@[email protected])

45.6K Posts, 3.41K Following, 3.26K Followers · Free human being of this Earth. Pākeha in Aotearoa. Be excellent to each other! BTW When I say Trained #MOLE, I mean generative models, what the hype bubble calls "AI", see; https://disintermedia.net.nz/invasion-of-the-mole-trainers/ Email: strypey @disintermedia.net.nz Jabber: [email protected] Matrix: @strypey:matrix.iridescent.nz All my posts here are CC BY-SA 4.0 (or later). #Vegan #Permaculture #PeerProduction #SoftwareFreedom #PlatformCooperatives #FreeCode #CreativeCommons #SciFi #Comedy #Juggling #fedi22

Mastodon - NZOSS
Show threadJupiter RowlandOct 12, 2024
@glyn Decentralised identity has been available for longer than Mastodon, let alone ActivityPub. Only that it is known as "nomadic identity" here.

It was first implemented by Friendica creator @Mike Macgirvin ?️ in the Zot protocol in 2011 and in a Friendica fork named Red in 2012, later renamed into the Red Matrix, eventually reworked and renamed into Hubzilla in 2015.

Proof: This Hubzilla channel of mine actually simultaneously resides on two servers.

(Almost) everything that Mike has made afterwards, forks and forks of forks of Hubzilla, used to have or still have nomadic identity implemented.

His streams repository contains a fork of a fork... of Hubzilla that intentionally has no name, and that offers nomadic identity via the Nomad protocol with better compatibility with non-nomadic ActivityPub. In July, it had decentralised IDs as per FEP-ef61 (see also here) implemented, a first step by Mike to fully implement nomadic identity in ActivityPub.

Forte, Mike's most recent fork from August, had all support for Nomad and Zot6 removed and only uses ActivityPub anymore while still offering nomadic identity. To my best knowledge, however, it has yet to be declared stable enough to be daily-driven, and it has no public instances.

Other than all this, a non-public development version of @silverpill's Mitra has nomadic identity via ActivityPub in development. I'm not sure whether FEP-ef61 is implemented in the release version yet. It's the only Fediverse project aiming to implement nomadic identity which Mike Macgirvin has nothing directly to do with.

The ultimate goal is to be able to clone a Fediverse identity across project borders. Only considering stable releases, it's currently only possible to clone Hubzilla channels within Hubzilla, using Zot6, or (streams) channels within (streams), using Nomad.

Unfortunately, Mike has officially retired from Fediverse development and only occasionally submits code to the streams repository and Forte anymore.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #DecentralizedIdentity #NomadicIdentity #ActivityPub #FEP_ef61 #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #Mitra
What is nomadic identity? - Join the Fediverse