@Alison Wilder Because if you want full-blown user rights and all the same features as a local user on all over 30,000 Fediverse instances, you need a local user account on each one of them.

This means two things:

• If you come over to the Fediverse for the first time, and you register your first account on Mastodon, you automatically also register an account on 30,000+ more instances.
• If you decide to host your own instance of whatever, and you spin it up for the first time, your instance immediately creates tens of millions of user accounts. One for everyone who has ever joined the Fediverse. Because anyone may decide to come over to your instance and use it, just like so.

For one, this is utter overkill.

Besides, this is technologically impossible. This would require all Fediverse instances to know all other Fediverse instances. With no exceptions. Like, if I start up my own (streams) instance for the first time, and half a second later, someone on the other side of the globe starts up a Gancio instance, they would immediately have to know each other. And all the other instances in the Fediverse.

And, of course, it would require a newly-launched instance to know all Fediverse users. Again, with no exception.

How and from which source are they supposed to know?

That said, there is a single sign-on system for the Fediverse. It's called OpenWebAuth. It was created by @Mike Macgirvin (creator of Friendica and all its descendants) in the late 2010s already for now-defunct Zap, a fork (of a fork?) of Hubzilla which, in turn, is a fork of the currently hyped Facebook alternative Friendica. It was backported to Hubzilla in 2020. Everything that came after Zap, including the still existing streams repository, got it, too.

However, first of all, OpenWebAuth is only fully implemented on Hubzilla, (streams) and Forte. Plus, it has client-side support on Friendica. This means that Hubzilla, (streams) and Forte recognise logins on all four, but Friendica doesn't recognise logins from anywhere.

As for Mastodon, OpenWebAuth implementation was actually developed to the point of an official merge request in Mastodon's GitHub repository. As far as I know, it was rejected. Mastodon won't implement OpenWebAuth, full stop.

Besides, it doesn't give you all the same power as a local user. You can't log into Friendica, go to a Hubzilla hub and create a wiki or a webpage or a CalDAV calendar, just like so.

OpenWebAuth is only for guest permissions. Because on Hubzilla, (streams) and Forte, permissions are everything.

For example, let's assume you have an account and a channel on (streams). Let's also assume that your (streams) channel and this Hubzilla channel of mine here are connected. Furthermore, let's assume that I've decided to only allow my own full connections to see my profile.

If you're logged out, and you go to my profile page, you see nothing.

But then you log in. And you come back to my profile page (provided your browser is configured so that the Hubzilla hub that I call home is allowed to create cookies). My home hub recognises your login on (streams). It identifies you as you, as one of my contacts. Thus, it identifies you as someone who is permitted to see my profile.

And all of a sudden, you see my profile.

That, for example, is what OpenWebAuth is for.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Friendica #Hubzilla #Zap #Streams #(streams) #Forte #SingleSignOn #OpenWebAuth

tl;dr: Hubzilla has had at least some of this for over a decade now. And it won't replace any of it with a new standard tailor-made for Mastodon.

@silverpill If you look past projects based on ActivityPub and at projects that have ActivityPub as an additional protocol, some of this already exists.

- Data portability. In my opinion, this is the most important problem. I'm in favor of FEP-ef61, which also solves identity portability and unlocks many new features.

Exists in the shape of nomadic identity. Invented by @Mike Macgirvin in 2011 with his Zot protocol and first deplayed in 2012 with the Red Matrix, nowadays known as Hubzilla. Also available on (streams), Mike's current project at the end of a string of forks from Hubzilla, now based on the Nomad protocol.

Mike would like to see nomadic identity and other special features of the Zot and Nomad protocols included in the ActivityPub protocol. He has actually submitted a number of proposals for this. They were all rejected. Even though he is a protocol developer first and foremost, and he has both created and worked on more Fediverse protocols than anyone else, so he should be considered competent.

Nomadic identity with ActivityPub won't come unless either Evan Prodromou and the W3C commission cave in and allow Mike's suggestions, or someone re-invents the wheel from scratch in a way that's utterly incompatible to Hubzilla and (streams). And it won't come to Mastodon unless Eugen Rochko can imply that Mastodon has had it first.

And there will never be a nomadic identity standard that meets Mike's requirements as well as Eugen's wishes.

- End-to-end encryption. MLS has become a standard, and it would be wise to adopt it. Issue 3 at fediverse-ideas provides a good overview of what we have at the moment (not much). Some variation of FEP-ae97 is likely needed to make end-to-end encryption work.

AFAIK, all three of Mike's still existing projects, Friendica from 2010, Hubzilla from 2012/2015 and (streams) from 2021, have it. Optionally, but still. I think Friendica actually advertises military-grade encryption.

- Plugins. Something like Pleroma MRF, but cross-platform (e.g. Wasm-based). Also, pluggable timeline algorithms.

Friendica, Hubzilla and (streams) have had support for add-ons, including third-party add-ons, plus a number of official add-ons since their respective inceptions. If you want a cross-platform add-on standard, I hope you don't expect these three to throw their own standards over board in favour of the new standard. Otherwise, good luck developing a replacement for Pubcrawl that makes Zot-based Hubzilla compatible with ActivityPub while working on ActivityPub-based Mastodon just the same. Friendica, Hubzilla and (streams) rely on add-ons for all federation beyond their respective base protocols (DFRN, Zot, Nomad).

- Groups. We have several competing standards for groups: FEP-1b12, FEP-400e, Mastodon developers are working on their own standard. It would be nice to converge on a single standard, that also supports private groups.

Friendica, Hubzilla and (streams) have had support for discussion groups/forums since their respective inception. On Friendica, a group is a user account with special settings; on Hubzilla and (streams), it's a channel with special settings. In addition, especially Hubzilla and (streams) have access permission control on a level that most people for whom the Fediverse is only ActivityPub couldn't imagine in their wildest dreams. All three can be used by users from all over the Fediverse already now.

Good luck forcing Friendica to give up its 13-year-old standard that's used by Fediverse News, just to name one, and Hubzilla to give up its 11-year-old standard that blows everything else but what (streams) does out of the water. Good luck forcing them to adopt something inferior.

On the other hand, good luck forcing Lemmy and /kbin to switch to a wholly different standard. Don't forget that these two exist as well. And good luck having the Fediverse outside of Hubzilla and (streams) adopt both server-side and client-side OpenWebAuth.

And I'm not even talking about how different Fediverse projects handle threads differently. Mastodon has a Twitter-like thread structure: many posts, tied together with mentiones. Just about everything that's built on ActivityPub has taken this over. Friendica, Hubzilla and (streams) have a Facebook/blog/Tumblr-like thread structure: one post, the start post, and many comments which aren't posts. It's similar on Lemmy and /kbin which are Reddit clones, only that they don't allow thread starters to moderate their own threads.

- Quoting. FEP-e232 is a proposed standard, but most fediverse applications still use non-standard properties. Mastodon developers are trying to invent something completely different.

This is something that almost the whole Fediverse has implemented, save for Mastodon.

And again, Friendica has had quotes since its inception in 2010, almost six years before Mastodon was launched (which, by the way, federated with Friendica and Hubzilla on the spot). Hubzilla has had quotes since 2012, inherited from Friendica. Their way of quoting is dead-simple: BBcode. [quote][/quote] (streams) supports Markdown and HTML in addition to BBcode, but otherwise it's the same.

Oh, and by the way: Friendica, Hubzilla and (streams) have also supported quote-posts a.k.a. quote-tweets a.k.a. quote-toots a.k.a. quote-boosts from their very beginnings.

- Markets. So far there's only one server implementation capable of processing payments.

At least two. Hubzilla has a payment add-on, too. It isn't installed on all hubs, but it's there.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #CWFedisplaining #Fediverse #Mastodon #MastodonIsNotTheFediverse #NotOnlyMastodon #ActivityPub #Friendica #DFRN #Hubzilla #Zot #Streams #(streams) #Nomad #Lemmy #kbin #/kbin #NomadicIdentity #OpenWebAuth #Group #Groups #Forum #Forums #Quote #Quotes #Encryption #E2EE #E2EEncryption

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

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