It's Friday, so why not have some fun?!

I have added sample data processing terms (based on the UK GDPR) to my sample terms for registered users of fedi services.

Feedback is welcome.

https://forge.neilzone.co.uk/neil/sample_fedi_terms

#fedimeta#GDPR #lawfedi

It's Friday, so why not have some fun?!

I have added sample data processing terms (based on the UK GDPR) to my sample terms for registered users of fedi services.

Feedback is welcome.

https://forge.neilzone.co.uk/neil/sample_fedi_terms

#fedimeta#GDPR #lawfedi

@Tim Chambers There isn't much that we can do.

These standards, just like the various laws that triggered their creation, suppose that all social networks and social media are

• commercial and corporate with loads of money behind them
• centralised silos
• staffed with thousands upon thousands upon thousands of employees in office blocks all around the world

For comparison, Hubzilla probably shows what's the best the Fediverse can do. It has an optional field for new registrations to confirm that they're over a certain age.

However, almost all Hubzilla hubs have a "staff" of exactly one. A hobbyist. Unlike Mastodon servers, Hubzilla hubs don't even have moderators because Hubzilla is all about self-empowerment and self-moderation.

Is that one admin honestly expected to verify the authenticity of the IDs and the birth certificates of newly-registrated users with the authorities in almost 200 different nations?

There used to be a time when such regulations only applied to services from a certain size upward or from a certain revenue upward. But now something that can only be done by big corporations becomes mandatory for tiny hobbyist projects.

Besides, how are these measures supposed to keep 13-year-olds from spinning up their own single-user Fediverse servers on machines at home? If this is supposed to be absolutely, 100% guaranteed to be absolutely, 100% water-tight, the two Hubzilla devs would have to check and verify the identity of everyone who wants set up their own hub before they allow the git-based installer to clone the repository from Framagit onto their servers.

CC: @ IEEE Spectrum

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # Hubzilla # AgeVerification

@Tim Chambers And again, Friendica, Hubzilla, (streams) and Forte are way ahead. They were all made modular right from the start, and they can all be expanded with third-party add-ons and third-party themes (provided someone makes them) by adding third-party git repositories to your server. It helps that they themselves are all installed via git in the first place.

For example, it's possible to add entirely new protocols as add-ons. On Hubzilla, protocols that aren't Zot (ActivityPub, diaspora*, RSS/Atom etc.) are add-ons and off by default for new channels. Hubzilla's counterpart to Mastodon's lists, only vastly more powerful, is called "privacy groups" and an official add-on that's off by default again. CalDAV calendar server? Wikis? Webpages? All add-ons. (streams) and Forte have a somewhat different set of add-ons and a different set of add-ons that are on or off by default for new channels.

You can bolt all kinds of stuff to these four as third-party add-ons. Want a dating platform in the Fediverse? Just write an add-on for one or several of these four that ties into their (main, public) profiles with their dozens of fields, and you've got one.

Better yet: You can upgrade the whole server, the core, the official add-ons, the official themes, third-party add-ons, third-party themes, in one fell swoop. Not first the official stuff and then each third-party repo one by one, but all at once. At least on Hubzilla, (streams) and Forte, util/udall is the little helper that does it all for you.

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # Friendica # Hubzilla # Streams # (streams) # Forte # git # ThirdParty # AddOns # PlugIns

@ Anuj Ahooja Friendica has had full support for formatted long-form articles since its inception 15 years ago. The same goes for all its surviving descendants, created by the same developer: Hubzilla from 2015, (streams) from 2021, Forte from 2024. In addition, Hubzilla can be used to post federating long-form articles (which are automatically sent to Fediverse connections and Atom feed subscribers) and optionally also to post non-federating long-form articles (which aren't sent anywhere).

Friendica has also been able to subscribe to both RSS and Atom feeds since its inception. The same goes for Hubzilla.

This is not new to the Fediverse at all.

See also my Mastodon vs Friendica, Hubzilla, (streams) and Forte feature comparison tables here: https://hub.netzgemeinde.eu/item/0a75de76-eb27-4149-b708-f20b2f79d392. (By the way: This is a non-federating Hubzilla article.)

CC: @ Michael Marek @ Elias Probst

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # Friendica # Hubzilla # Streams # (streams) # LongForm # LongFormText # LongFormContent

@liaizon @steffenloewe Good finds! Added to #Wikidata. https://www.wikidata.org/w/index.php?title=Special:Contributions&target=Nemo+bis&dir=prev&offset=20250615163651&limit=4 #FediMeta

@Strypey

Is there a test server where I can have a look at this?

I don't think there's a public hub that's reliably always switching to release candidates. But if you're daring, you may try zotum.net; it's running dev code, so it's always ahead of the others.

# FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Hubzilla

@Strypey

You say this like it's a bad thing.

Not at all.

One advantage is, as you've said, that the backend and the Web frontend can have their own developers, development of both can largely be detached, and they can be upgraded separately from one another.

Separate Web frontends can be developed by people who actually know a thing or two about frontend development and UI design. I mean, look at the Web UIs of some all-in-one Fediverse server applications. They're often the digital counterpart of random knobs and switches poked through a piece of cardboard and labelled with a ball pen, just so that these knobs and switches are there. Sometimes they're the equivalent of expecting all kinds of end users to operate DIP switches, but hey, they're still better than soldering and unsoldering wires.

Another advantage is that server software for which alternative frontends exist does not have to drag its default frontend around. There are Mastodon servers with alternative frontends, but they still have to have the two official Web UIs installed (the default one and the Tweetdeck-style one) because they're firmly welded to the backend. I guess we all know what a heavyweight Mastodon is, and I'm certain that part of the weight is caused by the built-in Web UIs. In stark contrast, you can set up an Akkoma server with Mangane instead of Akkoma-FE, as in without having to also install Akkoma-FE.

By the way, Hubzilla is an interesting case here. Not only is its default UI very configurable, but Hubzilla itself is highly themeable, and third-party themes almost amount to entirely new UIs. At the same time, however, practically all official development efforts went only into the backend for most of its existence.

Any Hubzilla UI has to wrestle an immense wealth of features, and not exactly new features were added over time. This, however, caused Hubzilla's UI to gradually turn into a jumbled mess because some of the new UI elements were seemingly added in totally random places. Not only was the UI never cleaned up, but the default theme is perpetually stuck in 2012 (the name "Redbasic" says it all, it was made for Hubzilla when Hubzilla was still named Red), it was derived from an early Friendica theme, and even Friendica wasn't pretty back then. Also, the documentation was completely neglected.

So the situation last year was that there was only one working Hubzilla theme left, and that was Redbasic. It was the only theme that was even only upgraded to work with newer Hubzilla versions. There used to be other official themes, but they eventually ended up so outdated that they were removed altogether. @Sean Tilley's third-party themes were last touched seven years ago, that must have been around the time when Hubzilla 3 came out. At the same time, the official documentation was not only highly incomplete, but it was so outdated that parts of it were simply false. It partly referred to features that had been axed many years ago (tech levels) and features that simply were never there (four different mention styles), and parts of it even still spoke of Red. Thus, nobody even knew how to develop new themes for current Hubzilla.

That was when the community stepped in. @ Der Pepe (Hubzilla) ⁂ ⚝ sat down and rewrote the entire help. @ Scott M. Stolz not only started working on his NeuHub themes, but in the same process, he reverse-engineered Hubzilla's theming system to write documentation for theming Hubzilla which had never been written before AFAIK. Around that time, @ ????? was dabbling with specialised themes for certain purposes, e.g. one very clean theme for Hubzilla channels used as long-form blogs. Later on, @ Saiwal joined the fray with his now-popular Utsukta themes.

Granted, Hubzilla still carries Redbasic around, not only as the default for new channels unless the admin chooses another one, but also as a fallback in case a new Hubzilla version doesn't support existing third-party themes anymore. The latter is becoming less likely as the Utsukta themes are being built against Hubzilla's development versions now. Besides, it's in Hubzilla's nature that everything on a hub is updated at the same time, including third-party repositories.

In general, the Hubzilla community is no longer that easily satisfied with a UI that "just works", and the devs have taken notice. Hubzilla 10.4, now a release candidate, will spruce up certain core parts of the UI. It will introduce a tree-style thread view as the new default instead of its current chronological view, something that Friendica, (streams) and Forte have had for significantly longer. That is, this is actually a side-effect of the introduction of "lazy loading" conversations to reduce the server workload. Also, upon user request, it will add a button to add images to comments.

If (streams) and Forte grow bigger, the same could happen there. They have two official themes to choose from, fairly new Fresh and an older version of Redbasic. However, they don't have a large enough community for all the same things to happen to them that happened to Hubzilla, although Pepe has said he'd rewrite the (streams) and Forte help as well, seeing as Mike had ripped them out entirely with no replacements as they were too outdated at that point. Maybe someone will even write a guide on how to adapt Hubzilla themes to (streams) and Forte.

That is, (streams) and Forte are both already the result of several years of UI and UX advancement and improvements and making them fit for a Mastodon-dominated Fediverse (where Hubzilla is still geared towards a Fediverse which it will dominate itself by the mid-to-late 2010s). This is stuff which can't be taken care of in themes because it concerns the UI engine itself, and it's partly tied deeply into the backend.

While Hubzilla, (streams) and Forte won't be able to do without their official themes anytime soon, the official themes don't significantly weigh them down. Still, they require some maintenance work to keep up with the backend.

Wouldn't Mastodon would be better if it specialised in developing apps, and outsourced the server side to people who know how to do back-end engineering?

This makes me wonder which half Mastodon would be willing to outsource. I think they'd rather hold on to the backend and pass all the frontends on. Of course, this would come with the advantage of the official Mastodon mobile app actually becoming somewhat decent rather than remaining the "we need an official app, no matter how" kluge that it is today.

CC: @Tim Chambers @rakoo

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # ActivityPub # Mastodon # Akkoma # AkkomaFE # Mangane # Akkomane # Hubzilla # Streams # (streams) # Forte

@Strypey So Pleroma and Akkoma (which, for some reason, is missing from the list) actually use the ActivityPub C2S API to connect their frontends? Even though Pleroma predates ActivityPub and started out as an alternative GNU social frontend, much like Mastodon?

I mean, they're famous for having separate repositories for the server and the Web frontend (same name with "-FE" attached). And they're equally famous for having servers that forgo the official frontend in favour of third-party stuff, most notably Mangane.

So if Mangane actually makes use of that API rather than a homebrew *oma client API, it could be used as or, if need be, modified into a sparrings partner for API-testing purposes, not to mention that it's living proof that the API actually works. As it integrates with Pleroma and Akkoma that well, I've got my doubts that it only uses the Mastodon client API.

In the cases of (streams) and Forte which are almost the same software save for protocol support, the Web UI is much closer to the server backend, as flexible and modifyable it is. In their cases, the question would be whether they could be used to test just how far feature support in the ActivityPub C2S API can possibly go, maybe even whether it'd be possible to use the ActivityPub C2S API to build an almost fully-featured (streams)/Forte client app (except, of course, Web UI configuration and (streams)' per-channel ActivityPub switch which might cut the whole app off the server).

CC: @Tim Chambers @rakoo

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # ActivityPub # Pleroma # PleromaFE # Akkoma # AkkomaFE # Mangane # Akkomane # Streams # (streams) # Forte # API

I wish there was an option to stop a specific account's posts from appearing in the local timeline. I could use a feature like that to avoid that in smaller instances the local timeline gets less useful to me by being dominated by users that, although often interesting, post very frequently. 'Cause if I go and mute them, then I can't see their posts even if I create a list exclusively for accounts that post very frequently and add them to it; I tried this earlier.

#FediMeta

@Strypey Still, the headbutting was often justified for Mike. Unless, of course, you say that Mastodon is and has always been the one and only Fediverse gold standard and the one and only ActivityPub reference implementation.

I'll give you an example: In July, 2017, Mike's Hubzilla was the very first Fediverse server software to implement ActivityPub. Mike played strictly by the rules. As Hubzilla has a character limit of over 16.7 million and supports text formatting on the same level as the best long-form blogging platforms out there, he declared Hubzilla long-form and made Hubzilla send Article-type objects. Just as the spec demands.

In September, Mastodon became the second Fediverse server software to implement ActivityPub. But Gargron did not play by the rules. He only implemented a tiny subset of the protocol, namely what suited him. And he also broke it: Mastodon could display Article-type objects at their full length. But Gargron staunchly refused to implement any support for anything that goes beyond plain text. The ActivityPub spec explicitly says that Article-type objects are formatted. But Gargron wanted Mastodon to be a purist, minimalist, old-school, original-gangsta, Twitter-cloning microblogging platform. And stuff like bold type, italics, headlines, embedded in-line images or titles aren't purist, minimalist, old-school, original-gangsta, Twitter-cloning microblogging.

And so Mastodon took fully formatted, long-form-blog-style posts from Hubzilla and ripped everything out that wasn't plain text. It basically defaced Hubzilla posts. That is, it had been defacing Friendica and Hubzilla posts all the same ever since it was launched. But this time, there was a spec that actually defined what Mastodon was doing as wrong. And that spec had been finalised and pronounced a W3C standard meanwhile.

So Mike asked Gargron to please follow the official ActivityPub spec and make Mastodon support full HTML rendering for Article-type objects.

Gargron refused. Old-skool microblogging is plain text and only plain text, full stop.

This went back and forth. Eventually, Gargron presented a "solution": Mastodon now "renders" Article-type objects by showing the title and, right below, a link to the original. That is, basically not at all anymore. Of course, this meant that the vast majority of Mastodon users no longer read what came from Friendica and Hubzilla because they couldn't be bothered to open that link.

Mike saw this as a direct assault against Friendica and Hubzilla and an attempt at excluding both from "the Fediverse" which was almost entirely Mastodon at that point already. So he himself had to break the spec and make Hubzilla send Note-type objects instead so that Mastodon renders them at all. It still defaces them to this day.

(Friendica's solution was to send an Article-type object when a post has a title and a Note-type object when it doesn't have a title. Optionally, it can always send Note-type objects.)

By the way: This very same head-butting has returned. Not between Gargron and Mike, though, but between Gargron and much bigger players. Platforms like Flipboard and Ghost have introduced ActivityPub, and they send Article-type objects just as the ActivityPub spec demands. The same goes for WordPress. And, of course, they don't send plain-text "long tweets". They send fully formatted news articles and blog posts.

And now they demand Mastodon, as the biggest player in the Fediverse by user count, make their Article-type objects look just like they look at the source. They demand Mastodon not only render bold type, italics, headlines and the rest of the subset of text formatting that was introduced with Mastodon 4 in October, 2022. They also demand Mastodon show the titles and, most importantly, leave the images embedded within the articles in place, no matter how many they are.

This is no longer Gargron and his devs vs a guy in the Australian outback. This is Gargron and his devs who try hard to bend the Fediverse to their will and assume supreme control over it vs the Ghost Foundation, Flipboard, Inc. and Automattic, Inc. that play strictly by the ActivityPub rules. And I dare say that Automattic, Inc. alone has more money and more market power than Mastodon gGmbH and Mastodon, Inc. combined.

Mastodon has always gotten away with ignoring and breaking standards, re-inventing wheels and implying towards its religious followers that the whole Fediverse was built upon Mastodon and around Mastodon, and that everything that does things differently from Mastodon is inherently a broken add-on to Mastodon or an evil intruder. This time, they won't. And I guess they've actually taken it into consideration.

CC: @Tim Chambers @rakoo

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # ActivityPub # Mastodon # Friendica # Hubzilla # WordPress # Ghost # Flipboard

@Tim Chambers I guess the main obstacle in development right now is that there are no clients to pair the server applications with and test them against.

Then again, it would take a whole lot of clients. One unified client that covers e.g. Pleroma just as neatly as (streams) is impossible, seeing as how extremely different the two are.

CC: @Strypey @ just small circles 🕊 @ Ben Pate 🤘🏻 @rakoo

# FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # ActivityPub # Pleroma # Streams # (streams)

@StrypeyLocally writing content to the database of an ActivityPub-based server will inevitably require a local user account on that very server.

I mean, we already have OpenWebAuth magic sign-on which was invented by @ Mike Macgirvin ?️ for Hubzilla in 2017, and which also has full implementations in his later server applications (streams) and Forte and a client-side implementation on Mike's first project, Friendica. But without an actual account on another server, OpenWebAuth can only authenticate you on that other server as a guest and grant you certain guest permissions. It does not give you all the powers of a local user, at least not without a local account.

Also, if you want to actually log in on another server, you will inevitably need local login credentials on that server. Which means that a user account with these login credentials must be created prior to you logging in on that server so that that server knows your login name and your password. Even if you want to use something like OAuth, that server will still require to know your credentials. They will have to be in that server's database before you can successfully log in.

A server cannot and will not authenticate you against credentials in a wholly different remote server's database. What you and many other Fediverse users dream of can only be solved in two ways and both only theoretically because, in practice, they are just as impossible or at least very unfeasible.

Either if you register an account on one Fediverse server, that account with the exact same credentials is simultaneously created on literally all other Fediverse servers, and on Hubzilla, (streams) and Forte, you also automatically get a channel along with that account. This also means that each Fediverse server that's installed and spun up for the first time will immediately have to create tens of millions of accounts so that everyone all over the Fediverse automatically has login credentials on that server. I guess it should be clear that this is impossible, also because this requires a) a centralised list of absolutely all Fediverse accounts and identities and b) a centralised list of all Fediverse servers to be hard-coded into every last instance of every last Fediverse server out there.

Now, I keep reading stuff like, "But I don't want to use all Fediverse servers!" No, but you want to be able to use any Fediverse server. And then you will have to have an account there. How is the Fediverse supposed to know in advance which servers you will visit this year, the next two years, five years, ten years so that accounts can be automatically created for you exactly there and nowhere else?

See? And that's why, if you want to be able to use any server like with a local account, every server must be prepared for it before you arrive.

Or drive-by registration: You visit a Fediverse server for the first time, your active login is recognised by that Fediverse server, and an account is created for you on the fly with the exact same login credentials as where you're already logged in. That's its own can of worms.

Also, it requires remote authentication. OpenWebAuth. As I've already said: This is technology that's eight years old, and that's being daily-driven right now. But: You will never have this on Mastodon. There actually is a pull request for Mastodon from two years ago that would have implemented client-side OpenWebAuth support. It was never merged. It was silently rejected by the Mastodon developers. The PR was closed in November, 2024.

Some people go even further: They don't just want their login credentials wherever they go, they want their whole identity cloned to everywhere. They want all their stuff, all their posts and comments and DMs, all their followers and followed, all their settings, all their filters etc. etc. pp., they want it everywhere all the same. Like a nomadic identity (an invention by Mike from 2011, first implemented in 2012) across up to 30,000 servers.

Now, you and many others on Mastodon are probably going to cry out, "YES, YES, PLEASE MAKE THIS REALITY!"

But seriously: I myself have actually cloned enough Hubzilla and (streams) channels of mine in my time. None of them even had nearly as much content on them as your Mastodon account. And I can tell from a lot of personal experience that this cannot be done within a blink of an eye.

Nomadic identity won't come to Mastodon anyway. Nomadic identity via ActivityPub is probably being daily-driven already. Forte has it, and it relies on it. But Mastodon will never implement it. In particular, Mastodon would rather re-invent the "nomadic identity" wheel in a way that's incompatible with what we already have than implement something made by Mike Macgirvin. Not after all the head-butting that has happened between Mike and Gargron over the years.

And OpenWebAuth won't come to Mastodon either. Probably also for the same reason.

CC: @Tim Chambers @rakoo @ Ben Pate 🤘🏻

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

@Strypey

The main reason devs haven't wanted to use the C2S API in the AP spec is network effect. Clients devs don't want to use it because Mastodon doesn't, and servers devs don't want to use it because their services wouldn't work with all the clients following the Mastodon API.

It's actually tempting to imagine a vicious circle here: If almost everything has the Mastodon client API implemented, it isn't worth developing dedicated client apps that also cover other servers' extra features.

Instead, the reason why all kinds of server applications have the Mastodon client API implemented is because they absolutely need some phone apps that work with them. Just look around the Fediverse. Almost everyone is exclusively on phones nowadays. And especially iPhone users wouldn't touch a Web browser with a 10-foot barge pole if they don't absolutely have to, so expecting them to use the Web UI means you're stuck in a bubble or a time where smartphones are still a gimmick.

That's why even Friendica has implemented the Mastodon client API. I mean, Mastodon and Friendica are very different, and the Mastodon client API only covers a small fraction of what Friendica can do. It actually doesn't cover some critical everyday features.

At the same time, there's little to no incentive for those who can develop mobile apps to make apps for anything that isn't Mastodon. Many start working on Fediverse apps at a point when they still believe the Fediverse is only Mastodon. Or if they don't, at least they've never heard of Pleroma and its family, Misskey and its family, Friendica and its family (where Hubzilla would require a wholly different app than Friendica, and (streams) and Forte would require a wholly different app than both) etc. Or they genuinely think that developing the umpteenth iPhone app for Mastodon is worth the effort more than developing the first stable dedicated iPhone app for Friendica. It's a miracle that stuff like Aria for the *key family exists.

It seems like of all the server apps that don't do *blogging (purist long-form blogging stuff like WriteFreely excluded), Hubzilla, (streams) and Forte are the only ones that don't have the Mastodon client API implemented. And I can't see them do it. For one, their devs steer clear of all proprietary, non-standard Mastodon technology. But other than that, these three are even less like Mastodon than Friendica, and they work even less like Mastodon. Even using a Mastodon app for stuff like basic posting is out of question because it pretty much requires access to the per-post permission settings, something that Mastodon doesn't have implemented, and therefore, neither do the apps for it.

Now, Hubzilla, (streams) and Forte can be installed as so-called Progressive Web Apps. But only Hubzilla veterans ever do that, and that's for three reasons: One, next to nobody has ever heard of the very concept of PWAs. Two, all that people know is installing apps from the Apple App Store and the Google Play Store. And three, people want native mobile interfaces in the style of whatever phone they use. It doesn't matter how well the Web UIs of these three adapt to mobile screens, especially since 90% of all phone users have totally forgotten that you can rotate a phone sideways.

Hubzilla actually has its own client API, and I think (streams) and forte have their own one, too. But nobody has ever even only tried to build a native mobile app for either of them. Hubzilla's devs even have to admit that they don't know how well Hubzilla's client API works because there has literally never been a sufficiently-featured counterpart to test it against. All there is is an extremely basic Android app built by one of them that's available as a download somewhere, and all it can do is send very basic posts, I think, even only at your default settings. It's just a proof of concept.

The ActivityPub C2S API is just as untested.

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # Mastodon # MastodonAPI # Friendica # Hubzilla # Streams # (streams) # Forte # ActivityPub # API # ClientAPI # MastodonAPI

@ just small circles 🕊 It's not Fedi UX. It's Mastodon UX. Big difference.

Here on Hubzilla, I see the whole thread as one right away, all the way to the start post, without having to look at it at its origin.

The only improvement that I'm waiting for is the tree-style view that'll soon be rolled out with Hubzilla 10.4 (Friendica, (streams) and Forte already have tree-style views whereas Hubzilla had a strictly chronological thread view until the recent RCs).

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Hubzilla # Conversations # ThreadedConversations

@ Ben Pate 🤘🏻 In the words of a diaspora* developer, if Mozilla and Vivaldi "implemented ActivityPub", they'd actually "implement Mastodon". That'd mean catching more users with less effort than implementing vanilla ActivityPub and implementing features that Mastodon doesn't have. Besides, both used to have or still have a Mastodon server, but they don't seem to be aware that there's a Fediverse beyond Mastodon, much less what it's like and how it works.

In fact, they wouldn't even implement the ActivityPub C2S API at all. They'd implement the Mastodon client API and only the Mastodon client API.

CC: @rakoo @Tim Chambers

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # ActivityPub # Mastodon # MastodonAPI

@ craignicol Redundancy. Resilience against losing the server that you're on by being on another server simultaneously.

Also, just because you can spread your identity across multiple servers and even server types, doesn't mean you can only have one identity.

Look at me, for example:

• I have @ Jupiter Rowland on the Hubzilla hubs hub.netzgemeinde.eu and hub.hubzilla.de.
• I have my "in-world sister's" channel @ Juno Rowland on the same two Hubzilla hubs. It's still a separate and fully independent identity, and I could clone either of them to other Hubzilla hubs independently from one another. Like, I could clone @ Jupiter Rowland to hub.hubzilla.hu and @ Juno Rowland to klacker.org or whatever.
• I have my in-world image-posting channel @ Jupiter Rowland's (streams) outlet on the (streams) servers streams.elsmussols.net and nomad.fedi-verse.hu.
• I have my Fediverse meme channel @ Jupiter's Fedi-Memes on (streams) on the (streams) server streams.elsmussols.net; I haven't cloned it yet.
• In addition, I also have my non-nomadic WriteFreely blog @ Aus Hypergrid und Umgebung and my non-nomadic Lemmy account @ Jupiter Rowland.

That's six fully separate, fully independent Fediverse identities, even though Mastodon and most of the rest of the Fediverse (anything that doesn't understand nomadic identity) perceive them as nine identities. And as you can see, what you may have taken for utter science-fiction two minutes ago is being daily driven in the Fediverse right now. And it has been for well over a decade, for longer than Mastodon has been around.

Why have I cloned my identities? For the very reason that nomadic identity was invented in the first place: redundancy. Safety. Always having a live backup. Resilience against servers shutting down or malfunctioning. It was invented because its inventor, the creator and then-still-maintainer of Friendica, kept seeing Friendica users lose everything whenever a Friendica node disappeared. And he understood that the only way to really make an identity resilient against server shutdown is for it to reside on at least two servers simultaneously.

If glasgow.social goes belly-up unexpectedly, you lose everything. Potentially forever. Good luck starting over from scratch.

If hub.netzgemeinde.eu goes belly-up, I lose nothing because I still have the identical clones, live, hot, bidirectional backups, on hub.hubzilla.de.

Tell you what: A while ago, hub.netzgemeinde.eu did go belly-up. The queue worker was so overloaded that the hub was bogged down. Nothing went in, nothing went out. Without a clone, I would have been fscked.

Luckily, I had my clone. I logged into hub.hubzilla.de and used my clone to a) do what I'd normally do on hub.netzgemeinde.eu and, especially, b) alert the admin who was on vacation. He and the Hubzilla lead developer ssh'd onto the server and fixed the issue. This might never have happened, hadn't I had that clone on another server.

So you could:

• make a Crohn-related identity and clone it or not
• make a Doctor Who fandom identity and clone it or not
• make an activist identity and clone it or not
• make a Web development-related identity and clone it or not

Oh, by the way: The aforementioned six identites may or may not be all of my Fediverse identities. I may or may not have more than these. You wouldn't be able to tell unless I told you.

CC: @ Johannes Ernst @Tim Chambers @ Ben Pate 🤘🏻

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # Hubzilla # Streams # (streams) # NomadicIdentity

@ craignicol Redundancy. Resilience against losing the server that you're on by being on another server simultaneously.

Also, just because you can spread your identity across multiple servers and even server types, doesn't mean you can only have one identity.

Look at me, for example:

• I have @ Jupiter Rowland on the Hubzilla hubs hub.netzgemeinde.eu and hub.hubzilla.de.
• I have my "in-world sister's" channel @ Juno Rowland on the same two Hubzilla hubs. It's still a separate and fully independent identity, and I could clone either of them to other Hubzilla hubs independently from one another. Like, I could clone @ Jupiter Rowland to hub.hubzilla.hu and @ Juno Rowland to klacker.org or whatever.
• I have my in-world image-posting channel @ Jupiter Rowland's (streams) outlet on the (streams) servers streams.elsmussols.net and nomad.fedi-verse.hu.
• I have my Fediverse meme channel @ Jupiter's Fedi-Memes on (streams) on the (streams) server streams.elsmussols.net; I haven't cloned it yet.
• In addition, I also have my non-nomadic WriteFreely blog @ Aus Hypergrid und Umgebung and my non-nomadic Lemmy account @ Jupiter Rowland.

That's six fully separate, fully independent Fediverse identities, even though Mastodon and most of the rest of the Fediverse (anything that doesn't understand nomadic identity) perceive them as nine identities. And as you can see, what you may have taken for utter science-fiction two minutes ago is being daily driven in the Fediverse right now. And it has been for well over a decade, for longer than Mastodon has been around.

Why have I cloned my identities? For the very reason that nomadic identity was invented in the first place: redundancy. Safety. Always having a live backup. Resilience against servers shutting down or malfunctioning. It was invented because its inventor, the creator and then-still-maintainer of Friendica, kept seeing Friendica users lose everything whenever a Friendica node disappeared. And he understood that the only way to really make an identity resilient against server shutdown is for it to reside on at least two servers simultaneously.

If glasgow.social goes belly-up unexpectedly, you lose everything. Potentially forever. Good luck starting over from scratch.

If hub.netzgemeinde.eu goes belly-up, I lose nothing because I still have the identical clones, live, hot, bidirectional backups, on hub.hubzilla.de.

Tell you what: A while ago, hub.netzgemeinde.eu did go belly-up. The queue worker was so overloaded that the hub was bogged down. Nothing went in, nothing went out. Without a clone, I would have been fscked.

Luckily, I had my clone. I logged into hub.hubzilla.de and used my clone to a) do what I'd normally do on hub.netzgemeinde.eu and, especially, b) alert the admin who was on vacation. He and the Hubzilla lead developer ssh'd onto the server and fixed the issue. This might never have happened, hadn't I had that clone on another server.

So you could:

• make a Crohn-related identity and clone it or not
• make a Doctor Who fandom identity and clone it or not
• make an activist identity and clone it or not
• make a Web development-related identity and clone it or not

Oh, by the way: The aforementioned six identites may or may not be all of my Fediverse identities. I may or may not have more than these. You wouldn't be able to tell unless I told you.

CC: @ Johannes Ernst @Tim Chambers @ Ben Pate 🤘🏻

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # Hubzilla # Streams # (streams) # NomadicIdentity

@ Ben Pate 🤘🏻 Allow me to take a look at this from a Hubzilla/(streams)/Forte point of view.

The Sin of Overwhelming Complexity: Instance Selection Paralysis

The only way to really combat this effectively is by hiding the whole concept of servers/instances at first, railroading everyone to a server and only letting them know about decentralisation and servers/instances after the fact.

In theory, this could be doable with Hubzilla, (streams) and Forte, and even better than with Mastodon with its themed servers. It wouldn't make sense to offer Hubzilla, (streams) or Forte servers for certain topics or target audiences, seeing as the whole thing would become moot the very moment when you make your first clone on another server. Simply build a kind of "automatic on-boarder" that sends everyone to the geographically closest open-registration server.

In practice, that'd be a bad idea, but for a different reason than on Mastodon. And that's how these servers tend to be very different. Not in topic. Not in target audiences. Not in rules. But in features. Hubzilla is modular, (streams) is modular, Forte is modular, and each admin decides differently on which "apps" to activate. Then you want to join Hubzilla for one cool feature, but the on-boarder railroads you to a server where that very feature isn't even activated.

Sure, the on-boarder could include the option to select certain features that you absolutely must have in your new home and then pick a server that has them. But that'd be extra hassle and extra confusing.

Besides, where'd you put that on-boarder? On the official Hubzilla website? Haha, no can do. The official Hubzilla website is a webpage on a Hubzilla channel itself. It's all just dumb old static HTML with a CSS. If it's even HTML and not Markdown or BBcode, that is. You couldn't add scripts to it if you tried.

Oh, and (streams) and Forte don't even have official websites. And (streams) will never have one, seeing as it's officially and intentionally nameless, brandless and totally not even a project. Their "websites" are readme files in their code repositories on Codeberg.

The Sin of Inconsistent Navigation: Timeline Turmoil

The streams on Hubzilla, (streams) and Forte are quite a bit different from Mastodon timelines.

First of all, what you usually don't have on public servers is the counterpart to Mastodon's local timeline and Mastodon's federated timeline. On all three, this would be only one stream, the "public stream" or "pubstream". It can be switched by the admin to either what'd be local or what'd be federated. However, public servers usually have it off entirely. Unavailable even to local users. That's because the admins don't want to be held liable for what's happening on the pubstream.

Technically speaking, you only have one stream on a public server, and that's your channel stream. It's much more efficient than a Mastodon timeline because it always shows entire conversations by default instead of detached single-message piecemeal, and because it has a counter for unread messages which even lists these unread messages for you to directly go to the corresponding conversation. But that's another story.

However, your channel stream can be viewed on your channel page, conversation by conversation, or it can be viewed on the stream page as an actual stream with all conversations shown in a feed/timeline-like fashion, one upon another, and with its own set of built-in filters such as "only my own messages" or "only conversations started by members of one particular privacy group/access list" or "only conversations from one particular group actor". It's actually much more convenient than any Mastodon timeline, but for those who want a Twitter clone for dumb-dumbs, it can be very overwhelming.

Yes, Hubzilla, (streams) and Forte are much more complex in handling than, say, snac2. But they're also much more complex in features than snac2. That power is their USP. And that power must be harnessed somehow.

The Sin of Remote Interaction Purgatory: Federation Gymnastics

Sure, Hubzilla, (streams) and Forte have some of the best built-in search systems in the whole Fediverse. They can pull almost everything onto your channel stream just by searching for it. And if it has replies, chances are they pull these in as well.

But still, they're geared towards desktop users. They still require copy-paste. Phone users don't copy paste. Most of them don't even know the very concept of copy-paste. For most of those who do, copy-paste is much too fumbly if the input device available to them is a 6" touch screen.

You can't blame them, though. This is next to impossible to do any differently. I mean, you won't see a button magically appear with which you can pull in just that one post or comment you want to pull in.

Rather, the issue is that they can only reel in almost everything. Sometimes the search returns nothing, like a void. Sometimes the search runs indefinitely without any kind of result. This may be because someone has blocked your channel, because someone has blocked your entire server, because the server someone is on has blocked you or your entire server, because Hubzilla/(streams)/Forte doesn't understand the URI pasted into the search field or whatever.

So this is made worse by Hubzilla, (streams) and Forte not knowing what they can search for, what they can't and why not.

Connecting with someone whom you encounter on your channel stream is fairly easy. Connections can be initiated with only two clicks. Either you click their long name, and you're taken to a pretty much distraction-less local "intermediate page" with a striking green button that's labelled "+ Connect". Or if you don't want to leave the channel page, you hover your mouse cursor over their profile picture, click on the little white arrow that appears, and you get a small menu that offers you the "Connect" option as well. Granted, even some veterans don't know the latter trick because it isn't immediately advertised on the channel page.

Also, sure, you don't simply follow them right off the bat with nothing else to do like on Mastodon. You're taken to your Connections page, and you have to configure the connection (you don't have to do that on Mastodon because you can't configure connections on Mastodon).

Following accounts/channels from the directory is a bit easier. The green "+ Connect" button is there right away (unless you're already connected). However, Hubzilla's directory only lists channels based on the Nomad protocol, i.e. Hubzilla and (streams) channels, because ActivityPub is only implemented in an optional, off-by-default-for-new-channels add-on whereas it's in the core and on by default on (streams) and the only available protocol on Forte.

Importing contents or following actors when seeing them locally on other servers without copy-pasting and searching can be done. It requires OpenWebAuth magic single sign-on, however, and it requires it to be implemented on all servers of all Fediverse server applications from Mastodon to WordPress to Ghost to Flipboard. Hubzilla, (streams) and Forte are the only Fediverse server applications with full (client-side and server-side) OpenWebAuth implementations. But that's of little use if the rest of the Fediverse doesn't have server-side implementations, and Mastodon has even silently rejected a mere client-side implementation already developed to a pull request two years ago.

The Sin of DM Disasters Waiting to Happen

I think this is less of an issue on Hubzilla, (streams) and Forte because they handle DMs differently from Mastodon (which "the Fediverse" actually refers to in the article).

On all three, DMs are integrated into their extensive, fine-grained permissions system in which everything is only public if it's really public. The difference between a post and a DM is not just a switch.

If I want to DM you, I can either tag you @!{benpate@mastodon.social} rather than @[url=/@benpate%40mastodon.social]Ben Pate 🤘🏻[/url]. Then you're a) the only one to whom the message is sent (it literally doesn't even go out to any other server than mastodon.social plus my clone on hub.hubzilla.de as can be seen in the delivery report) and b) the only one who is granted permission to view the message.

Or I can use the padlock icon and select you from the opening list as the sole recipient. The very moment that I select certain recipients, the post I'm composing quits being public, and the padlock icon switches from open to closed. This isn't a one-click or two-click toggle. You don't do that casually. It's basically configuration. It requires so many mouse clicks that you do it consciously and intentionally. If you want to post in private, you have to really want to post in private.

Better yet: You can default to posting only to a certain limited target audience. In fact, by default on a brand-new channel, you only post to the members of one privacy group/access list (which is a Mastodon list on coke and 'roids). You have to manually reconfigure your new channel if you want to post to the general public by default.

If you preview your post, you can see whether it's a direct message to one or multiple single connections (envelope icon next to your long name), a limited-permissions message to one or multiple privacy groups/access lists/group actors (closed padlock icon) or actually public (no icon).

Even better yet: Posts to group actors generally aren't public. Posts to at least Friendica groups, Hubzilla forums, (streams) groups and Forte groups are never public. They do not go out to your followers as well unless they're connected to the same group. And this is independent from whether a group is public or private. You can't accidentially post to a group actor in public, and if you do, you don't post to that group actor at all, at least not in a way that makes the group actor forward your post to its other connections.

Granted, what does not happen is your background switching from your background colour or background image (which can be user-configured) to red #800000 or a yellow-and-back chevron pattern when you change visibility and permissions to something that isn't public.

The Sin of Ghost Conversations and Phantom Follower Counts

And again, when @Tim Chambers says, "the Fediverse", he almost exclusively means Mastodon. He writes as if the entire Fediverse handled conversations as terribly as Mastodon, as if the entire Fediverse was as blissfully unaware of enclosed conversations as Mastodon. Which is not the case.

Hubzilla, (streams) and Forte, as well as their ancestor Friendica, handle conversations in ways that exceed Mastodon users' imaginations and wildest dreams by magnitudes. Unlike Mastodon, they know threaded conversations, and they see them as enclosed objects where only the start post counts as a post, and everything else counts as a comment.

This means that once you've received a post on your stream, you will also receive all comments on that post, regardless of whether or not you follow the commenters, regardless of whether or not they mention you. That's because all four reel in the comments not from the commentors, but from the original poster who is perceived as the owner of the thread. Only blocks or channel-wide filters can prevent comments from coming in.

Beyond that, (streams) was the first to introduce Conversation Containers. Forte inherited them from (streams), and when they were defined in FEP-171b, Hubzilla implemented them, too.

Here on Hubzilla, I can see all comments in this thread because my channel has fetched them directly from @ Johannes Ernst. And I can actually see them right away because that's the default view here on Hubzilla, rather than Mastodon's piecemeal.

Even if you import a post manually using the search feature (and you better import the actual start post), AFAIK existing comments will eventually be backfilled. Comments that come in after importing will definitely end up on your stream as part of the thread.

So this is not a shortcoming of the Fediverse. The Fediverse has been able to do better for 15 years. It's a shortcoming of Mastodon.

The only "issue" here may be that it sometimes takes some time for a comment to show up for some reasons. But unless there are blocks or filters in play, it eventually will.

The Sin of Invisible Discovery: The Content Mirage

I'm not going to pick on the audacious implication that "Eugen and team" invented the Fediverse.

But Tim writes like literally everyone wants "the Fediverse" (read, actually Mastodon) to be literally Twitter without Musk.

Also:

• Friendica has had full-blown full-text search since its inception as early as 2010. Five and a half years longer than Mastodon has even existed.
• Hubzilla has had full-blown full-text search since its inception as early as 2011 when it was forked from Free-Friendika. It has inherited full-text search from Friendica.
• (streams) and Forte have had full-blown full-text search since their respective inception in 2021 and 2024, both having inherited it themselves.

Oh, and none of them has an explicit opt-in switch to soothe panicking Twitter converts because panicking Twitter converts have never been the primary target audience of either of them.

Instead, on Hubzilla, whether someone can find your content depends on whether they've got permission to view it in the first place ("Can view my channel stream and posts"). If it's public, they have it. Full stop. Public is public is public. Stop whining. You've made it public, now deal with everything being able to see it.

(streams) and Forte behave the same. In addition, they have an extra permission: "Grant search access to your channel stream and posts". This controls who may search your channel stream using your own local search feature while visiting your channel locally. Something that isn't even possible on Mastodon.

As for not having any content on my channel stream before I connect to anyone: I, for one, do not want some algorithm to force content upon me that I'm not interested in. Full. Frigging. Stop. I want to have full and exclusive control over what I see and what I don't.

The Sin of User Discovery Hell

Can it really be that Mastodon's directory is so much worse than Friendica's, Hubzilla's, (streams)' and Forte's directories? I guess it is because it really only lists local accounts on that one particular server. A side-effect of Mastodon being a microblogging service and Twitter clone. And not a full-blown, fully-featured social network and Facebook alternative. No, seriously, it isn't that.

Friendica is. It was designed as such. It was designed to take Facebook's place, and not by aping and cloning Facebook, but by being better than Facebook.

The directory on each node is decentralised. It lists all actors known to that node. What's outright unimaginable from a Mastodon point of view: It takes the keywords in the profiles into account. Better even: It ranks suggestions by the number of matching keywords.

Want something centralised instead? Try the Friendica Directory. Looking for people? Looking for news accounts? Looking for groups? There are specialised tabs for that. Friendica can tell them apart, and so can the Friendica Directory.

Caveat: The Friendica Directory only lists Friendica accounts. Friendica's built-in directory should list everything it knows. I haven't used Friendica in many years, but I guess this even includes diaspora* accounts because why not?

Hubzilla has indirectly inherited its directory from Friendica. This is the directory on Netzgemeinde, the biggest Hubzilla hub.

Again, it lists local as well as federated channels. You can choose whether to see only local channels ("This Website Only") or federated channels as well. You can choose whether channels flagged NSFW shall be listed or not ("Safe Mode"). You can choose to only have group actors listed that let themselves be listed ("Public Forums Only"). You have a cloud of keywords from the keyword lists in the profiles that you can filter by (Mastodon doesn't even have keyword lists in profiles). You have full-text search for names and keywords. There's even a Facebook-style suggestion mode that proposes connections to you with a ranking based on your keywords and their keywords as well as the number of common connections, and that still has the same filters.

Caveat this time: Hubzilla's directory only supports the one sole protocol built into Hubzilla's core. And that's Zot6. This means that Hubzilla's directory only lists Hubzilla and (streams) channels because Hubzilla and (streams) are the only Fediverse server applications that support Zot6.

(streams) and Forte have inherited their directories again. And they probably have the most powerful decentralised directories in the entire Fediverse. I'd give you a link, but (streams) directories generally aren't public; only local channels can access them.

These directories are similar to the ones on Hubzilla. You see local and federated actors, and you can choose to only see local actors ("This Website Only"). You can choose to only see group actors ("Groups Only"). You can choose to not see channels flagged NSFW ("Safe Mode"). What's new: Inactive actors can be kept out, too ("Recently Updated").

Now it comes: (streams) has ActivityPub built into its core, and it's on by default on new channels. Forte is entirely based on ActivityPub.

This means that their directories can list anything from anywhere that uses ActivityPub. "Groups Only" gives you Guppe groups, Lemmy communities, /kbin and Mbin magazines, PieFed communities, Mobilizon groups, Flipboard magazines, Friendica groups, Hubzilla forums, (streams) groups, Forte groups etc., all on one list.

(streams) has a slight edge over Forte here because it also lists Hubzilla and (streams) channels that have ActivityPub off such as the Streams Users Tea Garden where ActivityPub was turned off with the very intention to keep Mastodon out.

If there was a gigantic Forte server, as big as mastodon.social, and its directory was accessible to the public, that directory would be the best directory in the Fediverse for anything really. If it was on (streams), it would list more, but it would confuse some users of e.g. Mastodon who'd try to follow Hubzilla or (streams) channels that have ActivityPub off. Forte simply doesn't list these because it can't find them.

A global directory of everything sounds like a good idea, but it's next to impossible to implement.

Either the directory would go look for actors itself. In order to do that, it would have to know within a split-second not only whenever a new actor is created somewhere so it can index that actor right away, but also whenever a new server is spun up so that the admin actor can be indexed, and that server can be watched. How is it supposed to know all that?

Well, or the directory, a single, monolithic, centralised website, would have to be hard-coded into all Fediverse server software. That way, each server could immediately report newly created actors to the central directory upon their creation.

For starters, this would make the whole Fediverse depend on one single centralised website under the control of, if bad comes to worse, one person.

Besides, this would be a privacy nightmare. Let's suppose I create a new (streams) channel that's supposed to be private. Its existence and all its properties would be sent to the central directory before I can set it to private and restrict its permissions. This wouldn't be so bad on Hubzilla because I'd make the channel private before I turn on PubCrawl and make the channel accessible to the directory in the first place because the directory would only understand ActivityPub.

Of course, the directory would mostly be built against Mastodon. It would not understand the permissions systems implemented on Hubzilla, (streams) and Forte, and it might happily siphon off the profiles of channels where access to the profile is restricted and make them publicly accessible. On the other hand, this is likely to mean that the directory couldn't read most of Hubzilla's, (streams)' and Forte's profile text fields anyway because Mastodon doesn't have them.

But such a centralised directory wouldn't make connecting to other users that much easier and more convenient. You'd still have to copy and paste URLs or IDs into your local search and search for them (unless you're on Friendica, Hubzilla, (streams) or Forte where you can connect to URLs directly). At the very least, you should be able to go to the centralised directory and follow anyone just by clicking or tapping them. That, however, would require OpenWebAuth support on both your home server and that directory.

Ideally, that directory would be firmly built into all instances of all Fediverse software from snac2 to Mastodon to Hubzilla, even replacing any existing directory to confuse people less. But that would make the Fediverse even more dependent on one central website and its owner, something which should be avoided at all cost.

Lastly, nothing can ever be built into all instances of all Fediverse software. Remember that there's software with living instances that's barely being developed such as Plume. There's even software with living instances that's been officially pronounced dead such as Calckey, Firefish or /kbin. How are Firefish servers supposed to implement such a feature if nobody maintains Firefish anymore, and even the code repository was deleted?

CC: @ Risotto Bias

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # Friendica # Hubzilla # Streams # (streams) # Forte # OpenWebAuth # SingleSignOn # NomadicIdentity # Search # FullTextSearch # Directory # Permissions # Privacy # Conversations # ThreadedConversations # FEP_171b # ConversationContainers